From lordmorgul at gmail.com Sat Dec 1 00:01:08 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 30 Nov 2007 16:01:08 -0800 Subject: kde-4.0(rc1) hitting rawhide Dec 1-7 In-Reply-To: <4750A069.7040401@codewiz.org> References: <474C6891.2090007@math.unl.edu> <4750A069.7040401@codewiz.org> Message-ID: <4750A444.30509@gmail.com> Bernardo Innocenti wrote: >> The challenge will be replacing the current kde3-based >> desktop with a kde4-based one, while at the same time still providing a >> kde3 development platform (ie, so one can still build/run kde3 >> applications). > > Projecting the current stability of KDE4 ahead, it seems more > cautious to leave the two parallel installable for some time. Its already been said thats probably not workable due to how they'll be conflicting with each other. See Rex's earlier reply below. Anyone who has access to do multiple installs (xen or vmware) may want to do that for testing however, it'd at least be less painful at first. Re: notice of rawhide doom: kde4 coming Dec 1-7 Rex Dieter wrote: > John Summerfield wrote: > >> Will it be possible to install these on F8 alongside the existing KDE, >> with the ability to choose which at login? > > In short, no. The kde3 and kde4 desktops (for the most part) are not > parallel-installable, so it's an either/or thing. > > Having said that, the kde4 development platform (kdelibs4, kdepimlibs, > kdebase4) is already available for F-7/8 in order build and run kde4-based > applications. We are also considering building some parts of kde4, like > kde4 versions of kdeedu and kdegames, for F-7/8 as well. > > -- Rex -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From bernie at codewiz.org Sat Dec 1 00:02:15 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Fri, 30 Nov 2007 19:02:15 -0500 Subject: Bootup speed for F8 In-Reply-To: <1196445465.22277.60.camel@localhost.localdomain> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196445465.22277.60.camel@localhost.localdomain> Message-ID: <4750A487.3050901@codewiz.org> Adam Jackson wrote: > I hit most of the low-hanging fruit for X startup performance already in > rawhide. The rest is... harder. What did you actually do? We'd also like to reduce boot time and possibly move X early in the startup process. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From dimi at lattica.com Sat Dec 1 02:06:40 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 30 Nov 2007 21:06:40 -0500 Subject: Bootup speed for F8 In-Reply-To: <20071130161846.GA6497@nostromo.devel.redhat.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> Message-ID: <1196474800.4645.3.camel@dimi.lattica.com> On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote: > 1) bootchart weirdness (as it's from when bootchart starts) > 2) hotplug issues with a driver in the initrd not initializing right Well, maybe, but I think it's a common problem: http://lattica.com/pub/bootchart-20071130-f8.png In my case, that initial time is close to 11s! And mind you, it's no bootchard weirdness, I've always noticed it. Wall time for the above boot sequence is: * GRUB -> X: 25s * X -> login: 40s * login -> usable: 20s That's almost 1.5 minutes, with all the user interaction removed. -- Dimi Paun Lattica, Inc. From jbarnes at virtuousgeek.org Sat Dec 1 05:50:15 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 30 Nov 2007 21:50:15 -0800 Subject: Bootup speed for F8 In-Reply-To: <1196474800.4645.3.camel@dimi.lattica.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> Message-ID: <200711302150.16122.jbarnes@virtuousgeek.org> On Friday, November 30, 2007 6:06 pm Dimi Paun wrote: > On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote: > > 1) bootchart weirdness (as it's from when bootchart starts) > > 2) hotplug issues with a driver in the initrd not initializing > > right > > Well, maybe, but I think it's a common problem: > http://lattica.com/pub/bootchart-20071130-f8.png > > In my case, that initial time is close to 11s! And mind > you, it's no bootchard weirdness, I've always noticed it. Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on another. I briefly looked at the nash scripts and hotplug code in the initrd. It looks like we spend a lot of time waiting for the kernel to generate hotplug events and settle down the devices... I'm not sure how much of it could reasonably be trimmed, maybe comparing to a non-initrd config would make sense? I think this is pjones' stuff, so there are probably good reasons for the way things are. Jesse From david at fubar.dk Sat Dec 1 06:23:09 2007 From: david at fubar.dk (David Zeuthen) Date: Sat, 01 Dec 2007 01:23:09 -0500 Subject: Bootup speed for F8 In-Reply-To: <200711302150.16122.jbarnes@virtuousgeek.org> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> Message-ID: <1196490189.6750.38.camel@oneill.fubar.dk> On Fri, 2007-11-30 at 21:50 -0800, Jesse Barnes wrote: > On Friday, November 30, 2007 6:06 pm Dimi Paun wrote: > > On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote: > > > 1) bootchart weirdness (as it's from when bootchart starts) > > > 2) hotplug issues with a driver in the initrd not initializing > > > right > > > > Well, maybe, but I think it's a common problem: > > http://lattica.com/pub/bootchart-20071130-f8.png > > > > In my case, that initial time is close to 11s! And mind > > you, it's no bootchard weirdness, I've always noticed it. > > Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on > another. I briefly looked at the nash scripts and hotplug code in the > initrd. It looks like we spend a lot of time waiting for the kernel to > generate hotplug events and settle down the devices... I'm not sure how > much of it could reasonably be trimmed, maybe comparing to a non-initrd > config would make sense? I think this is pjones' stuff, so there are > probably good reasons for the way things are. In the perfect world (and on 99% of the other distros), the initramfs can exit to real user space as soon as the root device is mounted. I know that on Fedora (at least in the past) we play some really ugly tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the devices are in a specific order (scsi_wait_scan.ko etc.). Seems literally like a waste of time; better fix the rest of the OS not to rely on things like kernel names. Then again, I haven't looked at this for some time... It would be interesting to compare to other distros like SUSE, Debian and Ubuntu to see how much slower or faster we are. David From tgl at redhat.com Sat Dec 1 06:51:57 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 01 Dec 2007 01:51:57 -0500 Subject: DJB's software components In-Reply-To: <1196432626.9238.1.camel@localhost.localdomain> References: <1196432626.9238.1.camel@localhost.localdomain> Message-ID: <12572.1196491917@sss.pgh.pa.us> "Tom \"spot\" Callaway" writes: > Recently, most (all?) of Dan Bernstein's software was relicensed into > the public domain. > Please hold off on packaging and submitting these packages for review > into Fedora, pending legal advice as to whether he can actually do that > or not, under US law. [ blink... ] I would be interested to know what legal theory claims that DJB cannot relicense his own work. regards, tom lane From kevin.kofler at chello.at Sat Dec 1 07:18:34 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 1 Dec 2007 07:18:34 +0000 (UTC) Subject: DJB's software components References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> Message-ID: Tom Lane redhat.com> writes: > [ blink... ] I would be interested to know what legal theory claims > that DJB cannot relicense his own work. Believe it or not, in most European countries, you can't place anything in the public domain, especially not after you claimed copyright for it first. Under such a system, you can only license your rights (e.g. under a BSD-style license), not give them up. In addition, there may be rights which cannot even be licensed, for example in France, you can't use a work in a way which hurts the author's image/reputation (and I believe that part of a French copyright doesn't even expire); even if the license allows it, the clause allowing it is void (or if it's a broad BSD-style "you can do anything" clause, reinterpreted so "anything" doesn't include hurting the author's reputation). (Of course all this is not legal advice, I am not a lawyer, laws may vary wildly between countries in Europe, and the above paragraph may contain mistakes. But disclaimers aside, I hope I got the general idea across. ;-) ) Kevin Kofler From jfrieben at gmx.de Sat Dec 1 08:17:29 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 01 Dec 2007 09:17:29 +0100 Subject: Guidelines for creating subpackages? Message-ID: <20071201081729.62750@gmx.net> I have recently submitted a bug report for the "vtk" package, see https://bugzilla.redhat.com/show_bug.cgi?id=388211 because vtk-devel depends on a fair number of packages including "vtk-qt" which in turn pulls in "qt" and analog dependencies which is rather annoying. To my surprise, the bug got closed immediately as "NOTABUG". The "plplot" package however, shows a fine granularity which allows to avoid the unnecessary installation of undesired libraries/toolkits: plplot, plplot-devel, plplot-gnome, plplot-gnome-devel, plplot-java, plplot-java-devel, plplot-libs, plplot-octave, plplot-perl, plplot-tk, plplot-tk-devel, plplot-wxGTK, plplot-wxGTK-devel. Shouldn't there be a standard policy how to proceed in such cases? The procedure adopted in the "plplot" case obviously appears more appealing to me .. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From pertusus at free.fr Sat Dec 1 12:11:41 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Dec 2007 13:11:41 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201081729.62750@gmx.net> References: <20071201081729.62750@gmx.net> Message-ID: <20071201121141.GB3017@free.fr> On Sat, Dec 01, 2007 at 09:17:29AM +0100, Joachim Frieben wrote: > I have recently submitted a bug report for the "vtk" package, see > > https://bugzilla.redhat.com/show_bug.cgi?id=388211 > > Shouldn't there be a standard policy how to proceed in such cases? The procedure adopted in the "plplot" case obviously appears more appealing to me .. A standard policy is not desirable in my opinion. More subpackages may allow for better granularity, but the user has to install and sometime know about more packages. There is also added packaging complexity. So definitely the packager choice. -- Pat From Lam at Lam.pl Sat Dec 1 12:33:11 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 1 Dec 2007 13:33:11 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201121141.GB3017@free.fr> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> Message-ID: <20071201133311.73550516@pensja.lam.pl> Dnia 2007-12-01, o godz. 13:11:41 Patrice Dumas napisa?(a): > A standard policy is not desirable in my opinion. More subpackages > may allow for better granularity, but the user has to install > and sometime know about more packages. There is also added > packaging complexity. So definitely the packager choice. There's also more metadata, so even slower yum (not that you can actually notice at this point), some people might even think it's a bad idea at the repository/distribution level. On the other hand, subpackages are the only way to escape the infamous "dependency hell" that's still scaring some people away from Fedora. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From markg85 at gmail.com Sat Dec 1 13:02:14 2007 From: markg85 at gmail.com (Mark) Date: Sat, 1 Dec 2007 14:02:14 +0100 Subject: Bootup speed for F8 In-Reply-To: <1196490189.6750.38.camel@oneill.fubar.dk> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> Message-ID: <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> Here is my bootchart from initng [1] with the note that NetworkManager doesn't want to start and sound is out of the question as well. Those first 8 seconds are exactly the same in initd [2] as they are in initng. With initd it isn't much of an issue because it's slow already and ust doesn't mather much. with initng it's nearly HALF of the boot time!! now it's gonna something that would be nice to get fixed. About looking in scripts in initrd.. how do you do that? is there a guide for it somewhere? or is this [3] still good for it? [1] http://img252.imageshack.us/img252/2538/bootchartpx1.png [2] http://img530.imageshack.us/img530/6483/bootchartsw0.png [3] http://www.mail-archive.com/unattended-info at lists.sourceforge.net/msg04445.html 2007/12/1, David Zeuthen : > > On Fri, 2007-11-30 at 21:50 -0800, Jesse Barnes wrote: > > On Friday, November 30, 2007 6:06 pm Dimi Paun wrote: > > > On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote: > > > > 1) bootchart weirdness (as it's from when bootchart starts) > > > > 2) hotplug issues with a driver in the initrd not initializing > > > > right > > > > > > Well, maybe, but I think it's a common problem: > > > http://lattica.com/pub/bootchart-20071130-f8.png > > > > > > In my case, that initial time is close to 11s! And mind > > > you, it's no bootchard weirdness, I've always noticed it. > > > > Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on > > another. I briefly looked at the nash scripts and hotplug code in the > > initrd. It looks like we spend a lot of time waiting for the kernel to > > generate hotplug events and settle down the devices... I'm not sure how > > much of it could reasonably be trimmed, maybe comparing to a non-initrd > > config would make sense? I think this is pjones' stuff, so there are > > probably good reasons for the way things are. > > In the perfect world (and on 99% of the other distros), the initramfs > can exit to real user space as soon as the root device is mounted. > > I know that on Fedora (at least in the past) we play some really ugly > tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the > devices are in a specific order (scsi_wait_scan.ko etc.). Seems > literally like a waste of time; better fix the rest of the OS not to > rely on things like kernel names. > > Then again, I haven't looked at this for some time... It would be > interesting to compare to other distros like SUSE, Debian and Ubuntu to > see how much slower or faster we are. > > David > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From tcallawa at redhat.com Sat Dec 1 13:05:05 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 01 Dec 2007 08:05:05 -0500 Subject: ntfsprogs change in devel Message-ID: <1196514305.3432.31.camel@localhost.localdomain> I bumped ntfsprogs in devel to 2.0.0, this comes with a corresponding soname bump. I didn't think that this affected any other packages, but apparently, at least one (testdisk) links to libntfs. So, this is your heads-up. :) ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From buildsys at redhat.com Sat Dec 1 13:15:42 2007 From: buildsys at redhat.com (Build System) Date: Sat, 1 Dec 2007 08:15:42 -0500 Subject: rawhide report: 20071201 changes Message-ID: <200712011315.lB1DFgYK019227@porkchop.devel.redhat.com> New package bolzplatz2006 Slam Soccer 2006 is a funny football game in 3D-comic-style New package getmail POP3, IMAP4 and SDPS mail retriever with Maildir delivery New package libcmpiutil CMPI Utility Library New package libconfig C/C++ configuration file library New package libopensync-plugin-gnokii gnokii plugin for libopensync New package libopensync-plugin-syncml SyncML plugin for libopensync New package mythes-cs Czech thesarus New package mythes-de German thesarus New package mythes-en English thesarus New package mythes-pl Polish thesarus New package mythes-sk Slovak thesarus New package tokyocabinet A modern implementation of a DBM Updated Packages: SIBsim4-0.16-1.fc9 ------------------ * Fri Nov 30 2007 Christian Iseli 0.16-1 - Version 0.16. aoetools-21-1.fc9 ----------------- * Fri Nov 30 2007 Patrick "Jima" Laughton 21-1 - New upstream release at-3.1.10-18.fc9 ---------------- * Tue Oct 30 2007 Marcela Maslanova - 3.1.10-18 - Bug 398981: change on correct permissions * Fri Oct 05 2007 Marcela Maslanova - 3.1.10-17 - Bug 250147: add optional support for gnome-keyring to passwd pam stack * Wed Aug 22 2007 Marcela Maslanova - 3.1.10-16 - macro with_pam instead of have_pam - license tag is gplv2+ because of license in source files curl-7.17.1-3.fc9 ----------------- * Fri Nov 30 2007 Jindrich Novy 7.17.1-3 - drop useless ldap library detection since curl doesn't dlopen()s it but links to it -> BR: openldap-devel - enable LDAPS support (#225671), thanks to Paul Howarth - BR: krb5-devel to reenable GSSAPI support - simplify build process - update description dcraw-8.80-1.fc9 ---------------- * Fri Nov 30 2007 Nils Philippsen - 8.80-1 - version 8.80 - change license tag to GPLv2+ desktop-file-utils-0.14-1.fc9 ----------------------------- * Fri Nov 30 2007 Christopher Stone 0.14-1 - Upstream sync - Remove no longer needed short option patch dhcpv6-1.0.2-1.fc9 ------------------ * Fri Nov 30 2007 David Cantrell - 1.0.2-1 - Upgraded to new upstream version, dhcpv6-1.0.2 eclipse-1:3.3.1.1-11.fc9 ------------------------ * Fri Nov 30 2007 Andrew Overholt 3.3.1.1-11 - Fix PermSize option (thanks to Mary Ellen Foster for testing). * Fri Nov 23 2007 Andrew Overholt 3.3.1.1-10 - Move eclipse.ini for real. * Fri Nov 23 2007 Andrew Overholt 3.3.1.1-9 - Move eclipse.ini in %files section. gdm-1:2.21.2-0.2007.11.20.4.fc9 ------------------------------- * Fri Nov 30 2007 Matthias Clasen - 1:2.21.2-0.2007.11.20.4 - Use the new "substack" support in pam to make keyring unlocking work * Tue Nov 20 2007 Ray Strode - 1:2.21.2-0.2007.11.20.3 - use metacity for now ghostscript-8.61-5.fc9 ---------------------- * Fri Nov 30 2007 Tim Waugh 8.61-5 - Fixed runlibfileifexists patch. * Fri Nov 30 2007 Tim Waugh 8.61-4 - Revert previous change, but define .runlibfileifexists, not just runlibfileifexists. * Wed Nov 28 2007 Tim Waugh 8.61-3 - No longer need runlibfileifexists. - Use runlibfile in cidfmap. gnome-keyring-2.20.2-2.fc9 -------------------------- * Fri Nov 30 2007 Matthias Clasen - 2.20.2-2 - Reenable auto-unlock * Mon Nov 26 2007 Matthias Clasen - 2.20.2-1 - Update to 2.20.2 * Sun Nov 11 2007 Matthias Clasen - 2.20.1-4 - Don't ship a .la file (#370531) jd-1.9.8-0.1.svn1570.fc9 ------------------------ * Fri Nov 30 2007 Mamoru Tasaka - 1.9.8-0.1.svn1570 - svn 1570 * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 * Thu Nov 15 2007 Mamoru Tasaka - 1.9.7-0.4.rc071105 - 1.9.7 rc 071115 kernel-2.6.24-0.61.rc3.git5.fc9 ------------------------------- * Fri Nov 30 2007 Kyle McMartin - Oops! Local make-build-go-faster kernel.spec patch slipped in, reverted. * Fri Nov 30 2007 Jarod Wilson - FireWire OHCI 1.0 Isochronous Receive support (#344851) * Fri Nov 30 2007 John W. Linville - Some wireless bits headed for 2.6.24 libdhcp-1.99.1-1.fc9 -------------------- * Fri Nov 30 2007 David Cantrell - 1.99.1-1 - Upgrade to libdhcp-1.99.1 libdrm-2.4.0-0.2.fc9 -------------------- * Fri Nov 30 2007 Dave Airlie - 2.4.0-0.2 - Update to a newer upstream snapshot libselinux-2.0.45-1.fc9 ----------------------- * Fri Nov 30 2007 Dan Walsh - 2.0.45-1 - Upgrade to upstream * dlopen libsepol.so.1 rather than libsepol.so from Stephen Smalley. * Based on a suggestion from Ulrich Drepper, defer regex compilation until we have a stem match, by Stephen Smalley. * A further optimization would be to defer regex compilation until we have a complete match of the constant prefix of the regex - TBD. * Thu Nov 15 2007 Dan Walsh - 2.0.43-1 - Upgrade to upstream * Regenerated Flask headers from policy. libsemanage-2.0.14-3.fc9 ------------------------ * Thu Nov 29 2007 Dan Walsh - 2.0.14-3 - Allow semanage_genhomedircon to work with out a USER int homedir.template * Sat Nov 10 2007 Dan Walsh - 2.0.14-2 - Fix semanage_select_store to allocate memory, fixes crash on invalid store libsepol-2.0.15-1.fc9 --------------------- * Fri Nov 30 2007 Dan Walsh 2.0.15-1 - Upgrade to latest from NSA * clarify and reduce neverallow error reporting from Stephen Smalley. libtheora-0:1.0beta2-3.fc9 -------------------------- * Thu Nov 29 2007 Hans de Goede 1.0beta2-3 - Update png2theora to latest svn version (bz 400911) mesa-7.1-0.6.fc9 ---------------- * Fri Nov 30 2007 Dave Airlie 7.1-0.6 - Rebuild against a new libdrm mkinitrd-6.0.19-6.fc9 --------------------- * Fri Nov 30 2007 Jeremy Katz - 6.0.19-6 - rebuild for libdhcp6client bump mock-0.8.11-1.fc9 ----------------- * Thu Nov 29 2007 Clark Williams - 0.8.11-1 - fixes from mebrown: - added back -q and -v flags - print yum output by default - added --offline option - cleaned up uid handling ntfsprogs-2.0.0-2.fc9 --------------------- * Fri Nov 30 2007 Tom "spot" Callaway 2.0-2 - excludearch ppc ppc64 * Fri Nov 30 2007 Tom "spot" Callaway 2.0-1 - bump to 2.0 openoffice.org-1:2.3.1-9.5.fc9 ------------------------------ * Thu Nov 29 2007 Caolan McNamara - 1:2.3.1-9.5 - split out thesauri - move autocorrect files into langpacks and make appropiate aliases - allow "import uno" to just work out of the box * Sat Nov 24 2007 Caolan McNamara - 1:2.3.1-9.4 - Resolves: rhbz#384391 add openoffice.org-2.3.1.ooo83930.sw.flushanchors.patch - split out libhyphen and hyphenators - add openoffice.org-2.3.1.ooo84001.slideshow.gccisaprick.patch coz gcc hates us - drop openoffice.org-2.3.1.83876.unopkg.avoida11y.patch coz upstream won't do it * Thu Nov 22 2007 Caolan McNamara - 1:2.3.1-9.3 - Resolves: rhbz#247634 add openoffice.org-2.3.1.ooo82911.sd.insertbackground.patch (jnavrati) - Resolves: rhbz#386371 add workspace.sw8u10bf02.patch (caolanm) - add openoffice.org-2.3.1.83876.unopkg.avoida11y.patch to avoid unopkg crapping out on first run with a11y enabled and no X (caolanm) - add openoffice.org-2.3.1.ooo83877.sal.allowsoftlinkdelete.patch to allow sal to delete softlinks (caolanm) - add openoffice.org-2.3.1.ooo83878.unopkg.enablelinking.patch to enable linking to unpacked extensions already on the fs when registering (caolanm) ==> makes extension rpm packaging non-wasteful and safe paps-0.6.8-1.fc9 ---------------- * Fri Nov 30 2007 Akira TAGOH - 0.6.8-1 - New upstream release. - Remove patches merged and unnecessary anymore: - paps-makefile.patch - paps-formfeed.patch - paps-0.6.6-encoding.patch - paps-typo-font-scale.patch - paps-0.6.6-segfault.patch - paps-0.6.6-font-option.patch - paps-0.6.6-lcctype.patch - paps-0.6.8-shared.patch: Enable building shared library. - paps-0.6.8-wordwrap.patch: Update a bit to get it working without an wordwrap mode. - Add paps-libs and paps-devel package. - paps-cups.patch: Update. - paps-cpilpi.patch: Update. - Fix the wrong rendering with CPI option. (#237202) - Fix the unnecessary rotation with the landscape option when paps is running as CUPS filter. (#222137) pirut-1.3.28-1.fc9 ------------------ * Fri Nov 30 2007 Jeremy Katz - 1.3.28-1 - Warn users on edit/removal of repos that come from packages (#404921) python-2.5.1-16.fc9 ------------------- * Fri Nov 30 2007 James Antill - 2.5.1-16 - Fix pyconfig.h comment typo. - Add back test_support.py and the __init__.py file. - Resolves: rhbz#387401 * Tue Oct 30 2007 James Antill - 2.5.1-15 - Do codec lowercase in C Locale. - Resolves: 207134 191096 - Fix stupid namespacing in pysqlite, minimal upgrade to 2.3.3 pysqlite - Resolves: 263221 * Wed Oct 24 2007 James Antill - 2.5.1-14 - Remove bintuils dep. for live CD ... add work around for ctypes rhythmbox-0.11.3-8.fc9 ---------------------- * Fri Nov 30 2007 - Bastien Nocera - 0.11.3-8 - Update patch for the Podcast parsing to include the browser plugin for the iTunes detection * Fri Nov 30 2007 - Bastien Nocera - 0.11.3-7 - Add patch to avoid crashing if no Python plugins are enabled by default (#393531) spandsp-0.0.4-0.8.pre16.fc9 --------------------------- * Fri Nov 30 2007 Jeffrey C. Ollie - 0.0.4-0.8.pre16 - Fix release version * Fri Nov 30 2007 Jeffrey C. Ollie - 0.0.4-0.8.pre16 - Update to 0.0.4pre16 synaptics-0.14.4-12.fc9 ----------------------- * Fri Nov 30 2007 Caolan McNamara 0.14.4-12 - Resolves: rhbz#396891 patch it to at least work tetex-3.0-50.fc9 ---------------- * Fri Nov 30 2007 Jindrich Novy 3.0-50 - fix nasty bug in epstopdf (#241794) * Wed Nov 21 2007 Jindrich Novy 3.0-49 - update chinese font paths (#392221), thanks to Masaki Chikama * Tue Nov 20 2007 Jindrich Novy 3.0-48 - update japanese font paths (#392221), thanks to MATSUURA Takanori - don't touch .base files ufraw-0.13-2.fc9 ---------------- * Fri Nov 30 2007 Nils Philippsen - 0.13-2 - make preview scrollable, window resizable * Fri Nov 30 2007 Nils Philippsen - 0.13-1 - version 0.13 - build cinepaint plugin from Fedora 7 on (#282641) wesnoth-1.2.8-3.fc9 ------------------- * Fri Nov 30 2007 Brian Pepple - 1.2.8-3 - Re-add the server-gid that accidently got removed. * Fri Nov 30 2007 Brian Pepple - 1.2.8-2 - Add patch to drop ogg test from configure script, until better workaround. - Enable python support. * Thu Nov 29 2007 Brian Pepple - 1.2.8-1 - Update to 1.2.8. Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 anaconda - 11.4.0.4-1.i386 requires libdhcp-1.99.so.0 anaconda - 11.4.0.4-1.i386 requires libdhcp6client-0.99.0.so.0 audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5 octave-forge - 20071014-3.fc9.i386 requires octave(api) = 0:api-v28 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 perl-Wx - 0.80-1.fc9.i386 requires perl(Wx::Wx_Exp) ruby-gtkmozembed - 0.16.0-16.fc9.i386 requires gecko-libs = 0:1.8.1.9 sysprof - 1.0.8-2.fc8.i386 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.i386 requires libntfs.so.9 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 anaconda - 11.4.0.4-1.x86_64 requires libdhcp-1.99.so.0()(64bit) anaconda - 11.4.0.4-1.x86_64 requires libdhcp6client-0.99.0.so.0()(64bit) audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit) octave-forge - 20071014-3.fc9.x86_64 requires octave(api) = 0:api-v28 openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 perl-Wx - 0.80-1.fc9.x86_64 requires perl(Wx::Wx_Exp) ruby-gtkmozembed - 0.16.0-16.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 sysprof - 1.0.8-2.fc8.x86_64 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.x86_64 requires libntfs.so.9()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 anaconda - 11.4.0.4-1.ppc requires libdhcp-1.99.so.0 anaconda - 11.4.0.4-1.ppc requires libdhcp6client-0.99.0.so.0 audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071014-3.fc9.ppc requires octave(api) = 0:api-v28 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 perl-Wx - 0.80-1.fc9.ppc requires perl(Wx::Wx_Exp) ruby-gtkmozembed - 0.16.0-16.fc9.ppc requires gecko-libs = 0:1.8.1.9 testdisk - 6.8-1.fc8.ppc requires libntfs.so.9 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 anaconda - 11.4.0.4-1.ppc64 requires libdhcp-1.99.so.0()(64bit) anaconda - 11.4.0.4-1.ppc64 requires libdhcp6client-0.99.0.so.0()(64bit) audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit) octave-forge - 20071014-3.fc9.ppc64 requires octave(api) = 0:api-v28 openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 perl-Wx - 0.80-1.fc9.ppc64 requires perl(Wx::Wx_Exp) ruby-gtkmozembed - 0.16.0-16.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 testdisk - 6.8-1.fc8.ppc64 requires libntfs.so.9()(64bit) From buildsys at fedoraproject.org Sat Dec 1 13:48:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 1 Dec 2007 08:48:30 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-01 Message-ID: <20071201134830.9004F15212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 4 ldns-1.2.2-1.fc6 ruby-activerecord-1.15.6-1.fc6 ruby-activesupport-1.4.4-1.fc6 zabbix-1.4.2-3.fc6 Changes in Fedora Extras 6: ldns-1.2.2-1.fc6 ---------------- * Thu Nov 29 2007 Paul Wouters - 1.2.2-1 - Upgraded to 1.2.2. ruby-activerecord-1.15.6-1.fc6 ------------------------------ * Thu Nov 29 2007 David Lutterkort - 1.15.6-1 - New version ruby-activesupport-1.4.4-1.fc6 ------------------------------ * Thu Nov 29 2007 David Lutterkort - 1.4.4-1 - New version zabbix-1.4.2-3.fc6 ------------------ * Sat Dec 01 2007 Dan Horak 1.4.2-3 - add security fix (#407181) From markg85 at gmail.com Sat Dec 1 13:56:33 2007 From: markg85 at gmail.com (Mark) Date: Sat, 1 Dec 2007 14:56:33 +0100 Subject: Bootup speed for F8 In-Reply-To: <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> Message-ID: <6e24a8e80712010556k1810c6b0la0f28d332cf31fda@mail.gmail.com> 2007/12/1, Mark : > About looking in scripts in initrd.. how do you do that? is there a > guide for it somewhere? or is this [3] still good for it? reply to myself.. i just found this link [1]. seems to be oke for me. i have the boot at about 20 seconds now. the loading of the kernel modules seems to take up most time.. perhaps it's better if those default kernel modules got compiled in? And there was indeed a scsi_wait module in the init script. i kicked it out and it gave me a (about) 2 second boot boost. My new bootchart: [2]. [1] http://bbs.archlinux.org/viewtopic.php?pid=282849#p282849 [2] http://img401.imageshack.us/img401/6272/bootchartsnel20secql1.png (20 seconds) From alan at redhat.com Sat Dec 1 14:09:13 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 1 Dec 2007 09:09:13 -0500 Subject: DJB's software components In-Reply-To: References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> Message-ID: <20071201140913.GA9617@devserv.devel.redhat.com> On Sat, Dec 01, 2007 at 07:18:34AM +0000, Kevin Kofler wrote: > Believe it or not, in most European countries, you can't place anything in the > public domain, especially not after you claimed copyright for it first. Under > such a system, you can only license your rights (e.g. under a BSD-style There are quite a few you don't want to. Don't assume that "public domain" has any attached liability waivers From s.adam at diffingo.com Sat Dec 1 15:32:13 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sat, 01 Dec 2007 10:32:13 -0500 Subject: Bootup speed for F8 In-Reply-To: <1196474800.4645.3.camel@dimi.lattica.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> Message-ID: <1196523133.5807.3.camel@Diffingo.localdomain> On Fri, 2007-11-30 at 21:06 -0500, Dimi Paun wrote: > Well, maybe, but I think it's a common problem: > http://lattica.com/pub/bootchart-20071130-f8.png > > In my case, that initial time is close to 11s! And mind > you, it's no bootchard weirdness, I've always noticed it. > > Wall time for the above boot sequence is: > * GRUB -> X: 25s > * X -> login: 40s > * login -> usable: 20s > > That's almost 1.5 minutes, with all the user interaction > removed. IIRC development stopped on gdm-early-login because it was trouble for users with system files that were NFS-mounted (/var and /usr I think), but that was one really easy way to make things seem faster without actually the decreasing boot time. Stewart From chris.stone at gmail.com Sat Dec 1 15:49:35 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 1 Dec 2007 07:49:35 -0800 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201133311.73550516@pensja.lam.pl> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: On Dec 1, 2007 4:33 AM, Leszek Matok wrote: > Dnia 2007-12-01, o godz. 13:11:41 Patrice Dumas napisa?(a): > > > A standard policy is not desirable in my opinion. More subpackages > > may allow for better granularity, but the user has to install > > and sometime know about more packages. There is also added > > packaging complexity. So definitely the packager choice. > There's also more metadata, so even slower yum (not that you can actually > notice at this point), some people might even think it's a bad idea at the > repository/distribution level. > > On the other hand, subpackages are the only way to escape the > infamous "dependency hell" that's still scaring some people away from Fedora. This is an *extremely* important topic. Let's face it, if Fedora wants to have any hope of becoming a base distribution for all other distributions, then all optional requires will need to be split into sub-packages. We must have as fine a granularity in our packages as possible. There is no way in hell anyone is going to use Fedora packages when they are forced to bring in dozens of unneeded and unwanted packages. I cannot stress enough how important this is. From tcallawa at redhat.com Sat Dec 1 16:07:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 01 Dec 2007 11:07:56 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: <1196525276.3432.44.camel@localhost.localdomain> On Sat, 2007-12-01 at 07:49 -0800, Christopher Stone wrote: > On Dec 1, 2007 4:33 AM, Leszek Matok wrote: > > Dnia 2007-12-01, o godz. 13:11:41 Patrice Dumas napisa?(a): > > > > > A standard policy is not desirable in my opinion. More subpackages > > > may allow for better granularity, but the user has to install > > > and sometime know about more packages. There is also added > > > packaging complexity. So definitely the packager choice. > > There's also more metadata, so even slower yum (not that you can actually > > notice at this point), some people might even think it's a bad idea at the > > repository/distribution level. > > > > On the other hand, subpackages are the only way to escape the > > infamous "dependency hell" that's still scaring some people away from Fedora. > > This is an *extremely* important topic. > > Let's face it, if Fedora wants to have any hope of becoming a base > distribution for all other distributions, then all optional requires > will need to be split into sub-packages. To be fair, some software works on a model like this, and some does not. Trying to force software which is not designed in such a fashion into a sub-packaged hierarchy is a good way to get a headache. Not that I disagree, simply that it isn't really possible to put up hard and fast guidelines that say "thou shalt subpackage everything to ensure minimal dependencies". For example, a motivated SIG could go through and suggest subpackage improvements, where relevant, without needing to have explicit guidelines forcing it. ~spot From jim at meyering.net Sat Dec 1 15:57:58 2007 From: jim at meyering.net (Jim Meyering) Date: Sat, 01 Dec 2007 16:57:58 +0100 Subject: Versioning svn checkouts In-Reply-To: <20071129202959.GA9414@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu, 29 Nov 2007 15:29:59 -0500") References: <20071127022448.GB24257@angus.ind.WPI.EDU> <200711280848.24953.sgrubb@redhat.com> <200711281133.19824.sgrubb@redhat.com> <474DD09B.8040907@redhat.com> <20071129202959.GA9414@nostromo.devel.redhat.com> Message-ID: <87abouv249.fsf@rho.meyering.net> Bill Nottingham wrote: > Petr Machata (pmachata at redhat.com) said: >> Steve Grubb wrote: >> > kdepim-enterprise-svn20070926.tar.bz2 >> >> As a side note, I always wondered why to use date in the release tag of >> package, whose sources come from non-cvs versioning system. For svn, in >> my opinion, it would make more sense to use the tree revision number; >> for git, similarly, sha1 id of the tree. > > Well, git sorts sanely. git does not. Comments in the spec > (or similar) might help with this. For git-based projects, I like to use something based on the output of git-describe. Then you get the best of both worlds: a regular version string, a sequence number, and an SHA1 prefix. For example, the latest version of autoconf does this: $ autoconf --version |head -1 autoconf (GNU Autoconf) 2.61a.312-b524b That means it's built from the 312th change-set since the 2.61a tag. The SHA1 of that change-set starts with "b524b". In the case of autoconf, you can map from the above string back to its SHA1 by prepending a 'v' (to get the tag name) and inserting a 'g' after the '-' (because git requires this). Then use git-rev-parse: $ git-rev-parse v2.61a.312-gb524b b524b0f996c9c1e9a81a3e3cdcc11517c39adb7c From myfedora at richip.dhs.org Sat Dec 1 16:23:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 01 Dec 2007 09:23:26 -0700 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201121141.GB3017@free.fr> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> Message-ID: <1196526206.22135.9.camel@localhost6.localdomain6> On Sat, 2007-12-01 at 13:11 +0100, Patrice Dumas wrote: > On Sat, Dec 01, 2007 at 09:17:29AM +0100, Joachim Frieben wrote: > > I have recently submitted a bug report for the "vtk" package, see > > > > https://bugzilla.redhat.com/show_bug.cgi?id=388211 > > > > Shouldn't there be a standard policy how to proceed in such cases? The procedure adopted in the "plplot" case obviously appears more appealing to me .. > > A standard policy is not desirable in my opinion. More subpackages > may allow for better granularity, but the user has to install > and sometime know about more packages. There is also added > packaging complexity. So definitely the packager choice. Wait, wait, wait. Are you saying that we've been talking about Fedora and how it's a democracy, how we're trying to give users a choice through spins even though Fedora chooses defaults ... and packagers are free to ignore users' petitions? The user doesn't HAVE to know about the subpackages in order for them to be installed when needed. That's what we're supplying the needed information for to yum to be able to make it make good decisions. Packagers are responsible to the users, too, and a lack of a guideline will guarantee that issues like this will come back again and again. As a packager (or one-in-progress), I would WANT guidelines. I'm doing this for the community, and not just to scratch my own personal itch (a point sorely lacking in many open-source projects). -- Richi Plana From mszpak at wp.pl Sat Dec 1 16:37:41 2007 From: mszpak at wp.pl (Marcin =?UTF-8?B?WmFqxIVjemtvd3NraQ==?=) Date: Sat, 1 Dec 2007 17:37:41 +0100 Subject: Presto and yum security plugin Message-ID: <20071201173741.7d257076@szpak> Hi, When I started using yum presto and a repository for F8 [1] given at its homepage, yum-security stopped telling me which packages fix security issues. Is it a known issue? Is it a problem with presto repository (which maybe doesn't contain that info), presto plugin itself or a general incompatibility of mixing those plugins? [1] - http://lesloueizeh.com/f8/i386/updates Regards Marcin From jbarnes at virtuousgeek.org Sat Dec 1 16:46:54 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sat, 1 Dec 2007 08:46:54 -0800 Subject: Bootup speed for F8 In-Reply-To: <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <1196490189.6750.38.camel@oneill.fubar.dk> <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> Message-ID: <200712010846.54327.jbarnes@virtuousgeek.org> On Saturday, December 01, 2007 5:02 am Mark wrote: > Here is my bootchart from initng [1] > with the note that NetworkManager doesn't want to start and sound is > out of the question as well. > > Those first 8 seconds are exactly the same in initd [2] as they are > in initng. With initd it isn't much of an issue because it's slow > already and ust doesn't mather much. with initng it's nearly HALF of > the boot time!! now it's gonna something that would be nice to get > fixed. > > About looking in scripts in initrd.. how do you do that? is there a > guide for it somewhere? or is this [3] still good for it? Nice... initng does seem like a nice project and a conceptual improvement over what we currently have. And yeah, I just pulled apart the initrd to poke around, and also downloaded the mkinitrd package so I could look at the nash and other sources. Jesse From rdieter at math.unl.edu Sat Dec 1 17:13:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 01 Dec 2007 11:13:55 -0600 Subject: Guidelines for creating subpackages? References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: Christopher Stone wrote: > This is an *extremely* important topic. > > Let's face it, if Fedora wants to have any hope of becoming a base > distribution for all other distributions, then all optional requires > will need to be split into sub-packages. > > We must have as fine a granularity in our packages as possible. When/if it makes sense, and doesn't create an unduly increased maintainance burden, sure. -- Rex From jdieter at gmail.com Sat Dec 1 17:15:48 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 01 Dec 2007 19:15:48 +0200 Subject: Presto and yum security plugin In-Reply-To: <20071201173741.7d257076@szpak> References: <20071201173741.7d257076@szpak> Message-ID: <1196529348.3206.4.camel@jndwidescreen.lesbg.loc> On Sat, 2007-12-01 at 17:37 +0100, Marcin Zaj?czkowski wrote: > Hi, > > When I started using yum presto and a repository for F8 [1] given at > its homepage, yum-security stopped telling me which packages fix > security issues. > > Is it a known issue? Is it a problem with presto repository (which > maybe doesn't contain that info), presto plugin itself or > a general incompatibility of mixing those plugins? > > [1] - http://lesloueizeh.com/f8/i386/updates I think the problem is that I'm not including the necessary metadata in the presto repositories. I regenerate the metadata rather than pulling it from upstream, which could be what the problem is. Short-term solution is that I pull the metadata from fedoraproject.org. Long-term solution is to get the official repositories presto-enabled. I'm not sure where we're at on that. 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 s.adam at diffingo.com Sat Dec 1 17:19:04 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sat, 01 Dec 2007 12:19:04 -0500 Subject: What's your opinion on using alternatives for mesa-libGL(U)? Message-ID: <1196529544.3587.9.camel@Diffingo.localdomain> Hi, I'm wondering what you're opinions/arguments for or against using alternatives to symlink the libraries of mesa-libGL and mesa-libGLU. One advantage of this system is that for users who have the nVidia or AMD/ATI drivers installed is that games which have /usr/lib/libGL.so.1 hardcoded won't be having so much trouble anymore getting their games to work properly. The proprietary libGL files can be placed somewhere without overwriting libGL.so.1.2 and the symlink will point it to the right place. Another advantage is that switching between drivers becomes a breeze - Simply relink libGL.so.1 and change /etc/X11/xorg.conf. However, you can also argue that it isn't much better that ldconfig or LD_LIBRARY_PATH=[...] What do you think? Stewart From chris.stone at gmail.com Sat Dec 1 17:24:36 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 1 Dec 2007 09:24:36 -0800 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: On Dec 1, 2007 9:13 AM, Rex Dieter wrote: > Christopher Stone wrote: > > > This is an *extremely* important topic. > > > > Let's face it, if Fedora wants to have any hope of becoming a base > > distribution for all other distributions, then all optional requires > > will need to be split into sub-packages. > > > > We must have as fine a granularity in our packages as possible. > > When/if it makes sense, and doesn't create an unduly increased maintainance > burden, sure. All I am saying is that if we want Fedora to be used as a base distribution for other distributions, we need to start focusing a lot more as a community on making sub-packages for optional requirements. From jonathan.underwood at gmail.com Sat Dec 1 17:36:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 1 Dec 2007 17:36:19 +0000 Subject: Guidelines for creating subpackages? In-Reply-To: <1196526206.22135.9.camel@localhost6.localdomain6> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <1196526206.22135.9.camel@localhost6.localdomain6> Message-ID: <645d17210712010936h5a2b0f25y1339a3734b101c39@mail.gmail.com> On 01/12/2007, Richi Plana wrote: > Wait, wait, wait. Are you saying that we've been talking about Fedora > and how it's a democracy, how we're trying to give users a choice > through spins even though Fedora chooses defaults ... and packagers are > free to ignore users' petitions? > > The user doesn't HAVE to know about the subpackages in order for them to > be installed when needed. That's what we're supplying the needed > information for to yum to be able to make it make good decisions. > > Packagers are responsible to the users, too, and a lack of a guideline > will guarantee that issues like this will come back again and again. > > As a packager (or one-in-progress), I would WANT guidelines. I'm doing > this for the community, and not just to scratch my own personal itch (a > point sorely lacking in many open-source projects). Personally I agree with Tom, but remember - you're free to draft a guideline and take it to the packaging committee. That's the surefire way to get things changed if you're solving a real world problem. From mszpak at wp.pl Sat Dec 1 17:37:54 2007 From: mszpak at wp.pl (Marcin =?ISO-8859-2?B?WmFqsWN6a293c2tp?=) Date: Sat, 1 Dec 2007 18:37:54 +0100 Subject: Presto and yum security plugin References: <20071201173741.7d257076@szpak> <1196529348.3206.4.camel@jndwidescreen.lesbg.loc> Message-ID: <20071201183754.5bb2ff78@szpak> On 2007-12-01 18:15:48, Jonathan Dieter wrote: > On Sat, 2007-12-01 at 17:37 +0100, Marcin Zaj?czkowski wrote: > > When I started using yum presto and a repository for F8 [1] given at > > its homepage, yum-security stopped telling me which packages fix > > security issues. > > > > Is it a known issue? Is it a problem with presto repository (which > > maybe doesn't contain that info), presto plugin itself or > > a general incompatibility of mixing those plugins? > > I think the problem is that I'm not including the necessary metadata > in the presto repositories. I regenerate the metadata rather than > pulling it from upstream, which could be what the problem is. > > Short-term solution is that I pull the metadata from > fedoraproject.org. Long-term solution is to get the official > repositories presto-enabled. I'm not sure where we're at on that. It's not a big problem for me (I usually apply all updates). I've just played a little bit with available yum plugins and discover that issue, which could be problem in F9 (with official Presto support). I will check again later with the official repositories (when available :) ). Regards Marcin From rdieter at math.unl.edu Sat Dec 1 17:47:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 01 Dec 2007 11:47:12 -0600 Subject: Guidelines for creating subpackages? References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: Christopher Stone wrote: > All I am saying is that if we want Fedora to be used as a base > distribution for other distributions, we need to start focusing a lot > more as a community on making sub-packages for optional requirements. I'm curious, can you describe precisely the reasoning from 1. more subpkgs for optional components ... X. improves fedora as a base X+1. profit! ? It's not entirely clear to me that making subpkgs is really a (or the!) major requirement for X. -- Rex From jfrieben at gmx.de Sat Dec 1 17:50:13 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 01 Dec 2007 18:50:13 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: <20071201175013.39810@gmx.net> > When/if it makes sense, and doesn't create an unduly increased > maintainance > burden, sure. I understand, but why then have been built vtk, vtk-python, vtk-qt, and vtk-tcl packages but only a combined vtk-devel package which depends on the former ones? In order to minimize maintenance work, a more consistent approach would have been to build a single vtk package like there is a single vtk-devel package, although I'd prefer to see corresponding vtk-python-devel, vtk-qt-devel, and vtk-tcl-devel packages. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From markg85 at gmail.com Sat Dec 1 18:06:58 2007 From: markg85 at gmail.com (Mark) Date: Sat, 1 Dec 2007 19:06:58 +0100 Subject: Bootup speed for F8 In-Reply-To: <200712010846.54327.jbarnes@virtuousgeek.org> References: <1196375699.3036.9.camel@dimi.lattica.com> <1196490189.6750.38.camel@oneill.fubar.dk> <6e24a8e80712010502n71402534lece74bae4d9272f1@mail.gmail.com> <200712010846.54327.jbarnes@virtuousgeek.org> Message-ID: <6e24a8e80712011006vce6fbe2peb88003ed5755287@mail.gmail.com> 2007/12/1, Jesse Barnes : > On Saturday, December 01, 2007 5:02 am Mark wrote: > > Here is my bootchart from initng [1] > > with the note that NetworkManager doesn't want to start and sound is > > out of the question as well. > > > > Those first 8 seconds are exactly the same in initd [2] as they are > > in initng. With initd it isn't much of an issue because it's slow > > already and ust doesn't mather much. with initng it's nearly HALF of > > the boot time!! now it's gonna something that would be nice to get > > fixed. > > > > About looking in scripts in initrd.. how do you do that? is there a > > guide for it somewhere? or is this [3] still good for it? > > Nice... initng does seem like a nice project and a conceptual > improvement over what we currently have. > > And yeah, I just pulled apart the initrd to poke around, and also > downloaded the mkinitrd package so I could look at the nash and other > sources. > > Jesse i (sadly) don't think there is a lot to you can speed up in the initrd->init script.. it's all loading modules and initializing/mounting the partitions... speeding it up means excluding modules or removing them completely and compile them in the kernel (which would be better for the default modules like lvm, sata and pata) LinuxBIOS would give some seconds speed boost.. but that's not really a solution that is possible for anyone. btw.. it would be nice if bootchart could run before nash.. and right after grub.. Thosefirst few seconds in bootchart (about 7 in my case now) seem to be waste but seem to be RedHat Nash running... From cweyl at alumni.drew.edu Sat Dec 1 18:46:46 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 1 Dec 2007 10:46:46 -0800 Subject: "heads-up" page for rawhide? Message-ID: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> Hey all -- Do we already have a "major updates/changes" page for rawhid/F-9? To help maintainers (the non-killed ones, of course) keep track of things like openldap rebases, ntfs libs, potential perl updates, etc.... -Chris -- Chris Weyl Ex astris, scientia From buildsys at fedoraproject.org Sat Dec 1 18:47:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 1 Dec 2007 13:47:21 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-01 Message-ID: <20071201184721.11A3C15212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 1 wesnoth-1.2.8-1.fc6 Changes in Fedora Extras 6: wesnoth-1.2.8-1.fc6 ------------------- * Sat Dec 01 2007 Brian Pepple - 1.2.8-2 - Update to 1.2.8. Fixes #405661 (CVE-2007-5742) - Enable python support. - Update licence tag. From rdieter at math.unl.edu Sat Dec 1 19:07:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 01 Dec 2007 13:07:50 -0600 Subject: Guidelines for creating subpackages? References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> Message-ID: Joachim Frieben wrote: >> When/if it makes sense, and doesn't create an unduly increased >> maintainance burden, sure. > I understand, but why then have been built vtk, vtk-python, vtk-qt, > and vtk-tcl packages but only a combined vtk-devel package IMO, the primary focus of package splits should be for benefitting runtime. -- Rex From lists at ebourne.me.uk Sat Dec 1 22:11:32 2007 From: lists at ebourne.me.uk (Martin Ebourne) Date: Sat, 1 Dec 2007 22:11:32 +0000 (UTC) Subject: Extreme memory usage for gnome-panel related apps References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> Message-ID: On Fri, 30 Nov 2007 09:34:09 +0100, Mark wrote: > i was just looking through the system monitor to see how my memory usage > was doing and that gave me a impressive (negative way) result. I've made > a screenshot [1] of it and edited it a little. > ... > Now the notebook i'm typing this on has 1GB om memory and runs Fedora > fine so if i look at it that way than the ram usage is fine. but keep in > mind the people with less memory (256 or 512 MB's) they are gonna get a > hard time with this fedora. My total memory usage at the time of this > writing is: 432.00 MB (with GIMP on.. if that's closed than it's "just" > 400 MB). > > What i'm trying to say here is that those gnome-panel applets are taking > up way to much memory regardless of the memory you can afford or have in > your computer. > ... > So.. is something gonna change with this memory abuse? > , > [1] > http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png I agree with you completely about the memory usage of Fedora 8, it has got VERY bloated recently. This laptop is x86_64 and has 1GB RAM. Up to and including FC6 this was fine and it hardly ever reached the limit, performance was always good. Starting with Fedora 7, and really much more obvious now with Fedora 8 I'm finding it's using far too much RAM and regularly hitting swap very badly. Performance has suffered considerably. I've been thinking of shelling out some cash on 2x 1GB SODIMMs, but unfortunately these DDR1 versions are very expensive. As an example, there's two users logged in at the moment, I'm running evolution, galeon, and an xterm. The other login has nothing extra running, it's just gnome. Here is the output of free: total used free shared buffers cached Mem: 1027656 1008372 19284 0 43276 135564 -/+ buffers/cache: 829532 198124 Swap: 1048568 48 1048520 Yes, 810MB of memory really in use. I'm running gdesklets but not running other new stuff such as NetworkManager, yum applets, compiz etc. This level of memory use feels quite excessive. Unfortunately determining where RAM has gone is still somewhat difficult on Linux. It would be great to have Matt Mackall's patches in, or Exmap available. The best I've found without having to patch the kernel is: http://www.pixelbeat.org/scripts/ps_mem.py Running this as root, the biggest culprits are: Private + Shared = RAM used Program 3.4 MiB + 7.6 MiB = 11.0 MiB notification-area-applet (2) 10.6 MiB + 1.8 MiB = 12.4 MiB gconfd-2 (2) 11.8 MiB + 1.3 MiB = 13.1 MiB bbackupd 4.4 MiB + 9.4 MiB = 13.8 MiB evolution-alarm-notify (2) 5.3 MiB + 8.9 MiB = 14.2 MiB mail-notification (2) 4.7 MiB + 9.7 MiB = 14.4 MiB metacity (2) 8.2 MiB + 7.5 MiB = 15.7 MiB gnome-power-manager (2) 4.1 MiB + 11.6 MiB = 15.7 MiB padevchooser 15.3 MiB + 556.0 KiB = 15.8 MiB restorecond 14.5 MiB + 1.6 MiB = 16.1 MiB xterm 6.0 MiB + 10.3 MiB = 16.3 MiB notification-daemon (2) 6.0 MiB + 11.7 MiB = 17.7 MiB wnck-applet (2) 6.1 MiB + 11.7 MiB = 17.8 MiB clock-applet (2) 8.8 MiB + 12.5 MiB = 21.3 MiB mixer_applet2 (2) 11.0 MiB + 13.4 MiB = 24.5 MiB gnome-panel (2) 13.9 MiB + 15.7 MiB = 29.7 MiB /usr/libexec/re 23.0 MiB + 9.0 MiB = 31.9 MiB gnome-settings-daemon (2) 21.5 MiB + 15.8 MiB = 37.3 MiB nautilus (2) 23.9 MiB + 18.0 MiB = 41.9 MiB evolution 30.3 MiB + 13.2 MiB = 43.5 MiB /usr/bin/sealer (2) 34.7 MiB + 14.7 MiB = 49.5 MiB deskbar-applet 43.1 MiB + 8.5 MiB = 51.7 MiB beagled (2) 50.8 MiB + 10.4 MiB = 61.2 MiB Xorg (2) 80.2 MiB + 12.7 MiB = 92.9 MiB python (4) 80.6 MiB + 16.1 MiB = 96.7 MiB galeon Galeon seems a bit heavy at 80M for a few tabs, but mozilla based browers aren't renowned for being light. What really stands out for me here is deskbar-applet, how can that be using all that memory? Also sealert and beagled are very excessive. To verify the numbers above I killed these tasks off and checked the reduction in used space (- buffers). The expectation is to see the private memory returned, and that's almost exactly what I got: 1 x deskbar-applet 35MB 2 x beagled 44MB 2 x sealert 32MB Over 100MB returned by removing a few almost never used programs, but I'm still at 698MB, which is still way too much. Looking back up that list there's many other things that are using too much memory. How does a clock applet use over 6MB of private memory? Cheers, Martin. From chris.stone at gmail.com Sat Dec 1 22:38:10 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 1 Dec 2007 14:38:10 -0800 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: On Dec 1, 2007 9:47 AM, Rex Dieter wrote: > Christopher Stone wrote: > > > All I am saying is that if we want Fedora to be used as a base > > distribution for other distributions, we need to start focusing a lot > > more as a community on making sub-packages for optional requirements. > > I'm curious, can you describe precisely the reasoning from > 1. more subpkgs for optional components > ... > X. improves fedora as a base > X+1. profit! > ? Sorry, confused by X and X+1 and profit! Have no clue what you are talking about. Can you try being more down to earth please. > It's not entirely clear to me that making subpkgs is really a (or the!) > major requirement for X. It's very simple. It will allow you to more easily make a customized distribution from a Fedora base. If you cannot understand this simple concept, I'm afraid I cannot explain it to you in any more simpler terms. From triad at df.lth.se Sat Dec 1 22:40:04 2007 From: triad at df.lth.se (Linus Walleij) Date: Sat, 1 Dec 2007 23:40:04 +0100 (CET) Subject: Bootup speed for F8 In-Reply-To: <1196523133.5807.3.camel@Diffingo.localdomain> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <1196523133.5807.3.camel@Diffingo.localdomain> Message-ID: On Sat, 1 Dec 2007, Stewart Adam wrote: > IIRC development stopped on gdm-early-login because it was trouble for > users with system files that were NFS-mounted (/var and /usr I think), > but that was one really easy way to make things seem faster without > actually the decreasing boot time. Depends on how you define boot time. If you say boot is done when the system is interactive, you cut several seconds. "Other OS:es" obviously use this approach, the perceptual being what matters. Surely, this must be fixable, it'd be such a boost.. Linus From mmcgrath at redhat.com Sat Dec 1 22:53:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 01 Dec 2007 16:53:43 -0600 Subject: "heads-up" page for rawhide? In-Reply-To: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> References: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> Message-ID: <4751E5F7.7010605@redhat.com> Chris Weyl wrote: > Hey all -- > > Do we already have a "major updates/changes" page for rawhid/F-9? To > help maintainers (the non-killed ones, of course) keep track of things > like openldap rebases, ntfs libs, potential perl updates, etc.... > One thing we'd like to sometime soon is get a news.fedoraproject.org site with various rss feeds in it. A major updates/changes rss feed for rawhide would certainly be useful on that site. -Mike From seg at haxxed.com Sat Dec 1 23:04:05 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Dec 2007 17:04:05 -0600 Subject: Guidelines for creating subpackages? In-Reply-To: <1196526206.22135.9.camel@localhost6.localdomain6> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <1196526206.22135.9.camel@localhost6.localdomain6> Message-ID: <1196550245.9577.3.camel@localhost> On Sat, 2007-12-01 at 09:23 -0700, Richi Plana wrote: > Wait, wait, wait. Are you saying that we've been talking about Fedora > and how it's a democracy, how we're trying to give users a choice > through spins even though Fedora chooses defaults ... and packagers > are > free to ignore users' petitions? Fedora is a democracy? I must have missed that memo: https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00387.html Says right there in the release notes. Meritocracy: http://docs.fedoraproject.org/release-notes/f8/en_US/index.html#sn-Welcome -------------- 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 Sat Dec 1 23:25:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Dec 2007 17:25:47 -0600 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> Message-ID: <1196551547.9577.21.camel@localhost> On Sat, 2007-12-01 at 22:11 +0000, Martin Ebourne wrote: > I agree with you completely about the memory usage of Fedora 8, it has > got VERY bloated recently. I remember when I popped 512mb into my system back around 2002. Was running Red Hat 8 as I recall. I never, ever got the thing to use more than half of it. No matter how many tabs I opened in Mozilla, no matter how many kernels I compiled, I had a good 256mb worth of disk cache at all times, and it never hit swap. I remember losing entire 100mb files because that machine was a bit flaky and would hang sometimes, with the file never being written to disk. I got into a habit of typing 'sync' a few times after doing anything important, a habit I still have to this day. So now I'm sitting on a laptop with 512mb, running Fedora 8. I'm running Galeon and Evolution, and they're eating up 304M RAM and 428M swap. Sigh. -------------- 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 Sat Dec 1 23:42:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 00:42:33 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <1196526206.22135.9.camel@localhost6.localdomain6> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <1196526206.22135.9.camel@localhost6.localdomain6> Message-ID: <20071201234233.GA2729@free.fr> On Sat, Dec 01, 2007 at 09:23:26AM -0700, Richi Plana wrote: > > Packagers are responsible to the users, too, and a lack of a guideline > will guarantee that issues like this will come back again and again. A guideline won't solve that issue either. Guidelines that don't follow best practices won't be followed by knowledgable packagers. > As a packager (or one-in-progress), I would WANT guidelines. I'm doing > this for the community, and not just to scratch my own personal itch (a > point sorely lacking in many open-source projects). The point is not here. A guideline cannot be easily done, because there are pro and cons and the final weighting is dependent on the specific case. To take the vtk example, the runtime packages are split, to allow for fine-grained dependencies, and the -devel is monolithic, because many users assume that the devel package gives all that it needed to develop with the package, and on a devel platform fine grained dependencies are not an big issue. Still if the devel package was split it could also be acceptable, so there is definitely no easy solution, and it is best left to the packager (except in extreme cases, be it in split or in monolithic). -- Pat From ricky at fedoraproject.org Sat Dec 1 23:42:56 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 1 Dec 2007 18:42:56 -0500 Subject: "heads-up" page for rawhide? In-Reply-To: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> References: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> Message-ID: <20071201234256.GF732@Max.nyc1.dsl.speakeasy.net> On 2007-12-01 10:46:46 AM, Chris Weyl wrote: > Do we already have a "major updates/changes" page for rawhid/F-9? To > help maintainers (the non-killed ones, of course) keep track of things > like openldap rebases, ntfs libs, potential perl updates, etc.... Not sure if this is exactly what you're looking for, but until we do have a news.fedoraproject.org, there are a couple of RSS feeds at http://fedoraproject.org/infofeed/. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Dec 2 00:04:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 2 Dec 2007 00:04:31 +0000 (UTC) Subject: "heads-up" page for rawhide? References: <7dd7ab490712011046q732f7b10yed4a0fa3f41e28b3@mail.gmail.com> Message-ID: Chris Weyl alumni.drew.edu> writes: > Do we already have a "major updates/changes" page for rawhid/F-9? The ones I know about: * X11 breakage: AFAIK the worst of that has already been passed, but our X.Org X11 maintainers probably know more about this than I do. * KDE 4: we're working on this right now (first builds already started). If you're using KDE, expect some short-term breakage and chaos. On the other hand, you'll have the privilege of being able to try out the cool new KDE 4 desktop. :-) If you're using some KDE apps under another desktop, they should continue to work with no noticeable changes, but there's the possibility of some accidental temporary breakage due to the transition (mainly the kdelibs->kdelibs3 and kdelibs4->kdelibs changes). * the usual soname bumps: we have soname bumps for openldap and openssl announced for Monday. Kevin Kofler From s.adam at diffingo.com Sun Dec 2 00:50:18 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sat, 01 Dec 2007 19:50:18 -0500 Subject: Bootup speed for F8 In-Reply-To: References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <1196523133.5807.3.camel@Diffingo.localdomain> Message-ID: <1196556618.31181.7.camel@Diffingo.localdomain> On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote: > Depends on how you define boot time. If you say boot is done when the > system is interactive, you cut several seconds. > > "Other OS:es" obviously use this approach, the perceptual being what > matters. > > Surely, this must be fixable, it'd be such a boost.. > > Linus That's exactly what I mean - An early login can make the boot seem to boot much faster even if it really isn't. Waiting is what makes things seem long; the faster the user interacts, the faster things seem. Stewart From jkeating at redhat.com Sun Dec 2 02:03:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 1 Dec 2007 21:03:06 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> Message-ID: <20071201210306.79152152@redhat.com> On Sat, 1 Dec 2007 14:38:10 -0800 "Christopher Stone" wrote: > It's very simple. It will allow you to more easily make a customized > distribution from a Fedora base. If you cannot understand this simple > concept, I'm afraid I cannot explain it to you in any more simpler > terms. This is the classic argument. "We need subpackages!" "Why?" "Because it will make Fedora better as a base!" "Why?" "Because it will!" "How?" "Because it will! If you don't get that, then your dumb!" -- 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 loupgaroublond at gmail.com Sun Dec 2 02:20:59 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 1 Dec 2007 21:20:59 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201210306.79152152@redhat.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> Message-ID: <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> On Dec 1, 2007 9:03 PM, Jesse Keating wrote: > This is the classic argument. > > "We need subpackages!" > > "Why?" > > "Because it will make Fedora better as a base!" > > "Why?" > > "Because it will!" > > "How?" > > "Because it will! If you don't get that, then your dumb!" For those "dumb" people, the more granular the packages are, the easier it is to pick and choose what you want. You have more "choice". If the packages are lumps of things, it's very hard to pull out what your 1% use case needs and doesn't need. For those "smart" people, too much choice is generally a Very Bad Thing (TM). As I understand, one goal of the guys doing mkinitrd is to include bash, a 800k program into the image. Why? So we don't have to choose and maintain 15 different shells. People talk about the 'balkanization' of a platform. I would call splitting packages up unecessarily the 'gentooification' of Fedora. If your 1% user base needs a package done slightly different, then it's something that IMHO should be done internally. I might be wrong here, and I would like to hear if there are any respin ideas or use cases that aren't for embedded/minimal systems that would need such ubiquitous fragmentation. (for non-native english speakers, ubiquitous means all encompassing, or thorough) -Yaakov From davej at redhat.com Sun Dec 2 02:52:15 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 1 Dec 2007 21:52:15 -0500 Subject: Bootup speed for F8 In-Reply-To: <1196490189.6750.38.camel@oneill.fubar.dk> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> Message-ID: <20071202025215.GC31160@redhat.com> On Sat, Dec 01, 2007 at 01:23:09AM -0500, David Zeuthen wrote: > I know that on Fedora (at least in the past) we play some really ugly > tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the > devices are in a specific order (scsi_wait_scan.ko etc.). Seems > literally like a waste of time; better fix the rest of the OS not to > rely on things like kernel names. We scsi_wait_scan for the root disk to come up. We don't enforce any kind of ordering. Dave -- http://www.codemonkey.org.uk From wtogami at redhat.com Sun Dec 2 03:38:07 2007 From: wtogami at redhat.com (Warren Togami) Date: Sat, 01 Dec 2007 22:38:07 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: <20071201175013.39810@gmx.net> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> Message-ID: <4752289F.4010001@redhat.com> Joachim Frieben wrote: >> When/if it makes sense, and doesn't create an unduly increased >> maintainance >> burden, sure. > > I understand, but why then have been built vtk, vtk-python, vtk-qt, > and vtk-tcl packages but only a combined vtk-devel package which > depends on the former ones? This might be a parallel to pidgin-perl or libpurple-tcl, but there is only one pidgin-devel package. The reason perl or tcl was split out into sub-packages is because the vast majority of users don't need the perl or tcl capability, but including them in the main package caused all users to pull in tcl and perl when they were not necessary. -devel on the other hand is not meant to be installed except by developers. It might pull a large number of things, also needed only by developers. This is not inconsistent. Warren From chris.stone at gmail.com Sun Dec 2 06:11:40 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 1 Dec 2007 22:11:40 -0800 Subject: Guidelines for creating subpackages? In-Reply-To: <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> Message-ID: On Dec 1, 2007 6:20 PM, Yaakov Nemoy wrote: > People talk about the 'balkanization' of a platform. I would call > splitting packages up unecessarily the 'gentooification' of Fedora. And despite all the efforts the Fedora community has put into making it easy to make custom Fedora spins, people still go to gentoo for their custom spins. I have a colleague who tried to make a custom distro for cisco systems, and he tried to use Fedora, but do to some idiotic dependency he could not use the packages he needed without pulling in a bunch of extra garbage he didn't want like X. He ended up just using gentoo because it was so much easier. I will try and ask him the specific details of his problem for the purposes of this discussion if anyone is interested. > If your 1% user base needs a package done slightly different, then > it's something that IMHO should be done internally. I'm not talking about a 1% user base, I'm talking about a complete paradigm shift on how we think about what Fedora is. I think Fedora should be viewed more as a base or reference platform to make other distributions from, and not just simply as another packaged distro for a typical end user. From david at fubar.dk Sun Dec 2 11:31:00 2007 From: david at fubar.dk (David Zeuthen) Date: Sun, 02 Dec 2007 06:31:00 -0500 Subject: Bootup speed for F8 In-Reply-To: <20071202025215.GC31160@redhat.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> Message-ID: <1196595060.4121.16.camel@oneill.fubar.dk> On Sat, 2007-12-01 at 21:52 -0500, Dave Jones wrote: > On Sat, Dec 01, 2007 at 01:23:09AM -0500, David Zeuthen wrote: > > > I know that on Fedora (at least in the past) we play some really ugly > > tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the > > devices are in a specific order (scsi_wait_scan.ko etc.). Seems > > literally like a waste of time; better fix the rest of the OS not to > > rely on things like kernel names. > > We scsi_wait_scan for the root disk to come up. Uhm no. First, you hardly have to use a kernel module to wait for a device to appear; come one, this is uevent 101: a single udev rule that investigates the block device and exits the initramfs if it's indeed the root fs will suffice. Or, if you want to rewrite all of udev like Peter has done, just hook into the uevent event processing yourself. Second, the point of scsi_wait_scan.ko is to make the SCSI stack wait for all scans to have finished before uevents are generated. A side effect of this is that the order is deterministic; e.g. since events are only generated when all devices have been detected, one can send them in order. > We don't enforce any kind of ordering. Reality also suggest otherwise. Just try an old livecd image (F8t3 will do I think) using an initramfs from mayflower (using udev; waiting only for the rootfs) vs. a newer one using an initramfs from mkinitrd. In the former the devices are randomly assigned; in the latter they're not... As an anecdote, the former freaked Anaconda out as I wanted to install to /dev/sdf (the hard disk in my box; /dev/sda through /dev/sde was my disk tower). Which again confirms we do stupid things in the initramfs because user space is just utterly broken. In conclusion: scsi_wait_scan.ko is a stupid stopgap fix because some people can't be bothered to fix their user space. Fedora is an example of that. The price that we all pay is that it takes longer to boot for _everyone_. There's a host of other problems with mkinitrd that I won't go into here. David From bernie at codewiz.org Sun Dec 2 08:04:00 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sun, 02 Dec 2007 03:04:00 -0500 Subject: [Fedora-legal-list] DJB's software components In-Reply-To: <1196440081.9238.7.camel@localhost.localdomain> References: <1196432626.9238.1.camel@localhost.localdomain> <1196440081.9238.7.camel@localhost.localdomain> Message-ID: <475266F0.5030902@codewiz.org> Tom "spot" Callaway wrote: > And the answer is that we are fine to pick these up. Hold lifted. Nice! Is anyone working on packaging qmail already? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From jfrieben at gmx.de Sun Dec 2 08:53:45 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 02 Dec 2007 09:53:45 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <4752289F.4010001@redhat.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> Message-ID: <20071202085345.309030@gmx.net> > > I understand, but why then have been built vtk, vtk-python, vtk-qt, > > and vtk-tcl packages but only a combined vtk-devel package which > > depends on the former ones? > > This might be a parallel to pidgin-perl or libpurple-tcl, but there is > only one pidgin-devel package. The reason perl or tcl was split out > into sub-packages is because the vast majority of users don't need the > perl or tcl capability, but including them in the main package caused > all users to pull in tcl and perl when they were not necessary. > > -devel on the other hand is not meant to be installed except by > developers. It might pull a large number of things, also needed only by > developers. This is not inconsistent. > > Warren First of all, vtk-devel at least pulls in vtk-python, vtk-tcl, vtk-qt, tcl, tk, qt beyond packages that were already required by the base system. Are these packages specific to developers? I doubt so. Moreover, what you call developers are not necessarily hardcore developers of the package under consideration, so it might be simple people who just need/want to build an application based upon the VTK toolkit. As a matter of fact, Fedora does not even include a single application that uses any of vtk, vtk-python, vtk-qt, vtk-tcl [well, vtk-examples and vtk-testing but that probably doesn't count]. Apart from using 3rd party binaries, any person interested in the vtk package necessarily is what you call 'developer'. So, the term 'user' essentially loses any meaning in this context. Finally, the case of the plplot package shows that my initial request is by no means exotic, and I maintain my point that it would be sign of userfriendliness not to impose unneeded packages like the ones enumerated above on a user of the vtk package. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From jonathan.underwood at gmail.com Sun Dec 2 10:28:25 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Dec 2007 10:28:25 +0000 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202085345.309030@gmx.net> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> Message-ID: <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> On 02/12/2007, Joachim Frieben wrote: > Finally, the case of the plplot package shows that my initial request > is by no means exotic, and I maintain my point that it would be sign > of userfriendliness not to impose unneeded packages like the ones > enumerated above on a user of the vtk package. The point remains though: no matter what side of the fence you sit on regarding greater package granularity, I think Tom is bang on the money - crafting a guideline to fit the broad and diverse range of upstream packages in order to achieve your desired goal seems impossible to me. Arguing over the merits or otherwise of increasing the packaging granularity isn't going to change anything. If you really believe this is an important and required change, try drafting the guideline. From pertusus at free.fr Sun Dec 2 10:42:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 11:42:30 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202085345.309030@gmx.net> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> Message-ID: <20071202104230.GA3312@free.fr> On Sun, Dec 02, 2007 at 09:53:45AM +0100, Joachim Frieben wrote: > > First of all, vtk-devel at least pulls in vtk-python, vtk-tcl, vtk-qt, > tcl, tk, qt beyond packages that were already required by the base > system. Are these packages specific to developers? I doubt so. > Moreover, what you call developers are not necessarily hardcore > developers of the package under consideration, so it might be simple > people who just need/want to build an application based upon the VTK > toolkit. Though it is not easy to know by advance which binding they will need. > As a matter of fact, Fedora does not even include a single application > that uses any of vtk, vtk-python, vtk-qt, vtk-tcl [well, vtk-examples > and vtk-testing but that probably doesn't count]. In fact paraview uses vtk, though for right reasons still uses an internal version, but hopefully one day will use the system vtk. But more generally you cannot predict which package will use which library or binding. You have to package as if your library could be used even if it is not currently. There are a lot of software that are still not in fedora. > Apart from using 3rd party binaries, any person interested in the vtk > package necessarily is what you call 'developer'. So, the term 'user' > essentially loses any meaning in this context. > Finally, the case of the plplot package shows that my initial request > is by no means exotic, and I maintain my point that it would be sign > of userfriendliness not to impose unneeded packages like the ones > enumerated above on a user of the vtk package. You mean plplot requires vtk-devel? Or plplot-devel requires vtk-devel? Runtime fine grained dependencies are very desirable but devel fine grained dependencies are optional nad in the case of vtk, I think that it is best left to the packager, and I think that most vtk users expect all the binding to be there when installing vtk-devel. -- Pat From denis at poolshark.org Sun Dec 2 10:51:27 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 02 Dec 2007 11:51:27 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> Message-ID: <47528E2F.1050203@poolshark.org> Yaakov Nemoy wrote: > On Dec 1, 2007 9:03 PM, Jesse Keating wrote: >> This is the classic argument. >> >> "We need subpackages!" >> >> "Why?" >> >> "Because it will make Fedora better as a base!" >> >> "Why?" >> >> "Because it will!" >> >> "How?" >> >> "Because it will! If you don't get that, then your dumb!" > > For those "dumb" people, the more granular the packages are, the > easier it is to pick and choose what you want. You have more > "choice". If the packages are lumps of things, it's very hard to pull > out what your 1% use case needs and doesn't need. I feel the most important thing must remain ease of installation for end-users. If you "yum install foo", you expect foo to be fully working after installation (and how many dependencies it pulls is not necessarily important if you're using yum directly). Remember we don't really have a mechanism in place to say "since you just installed foo, you should really consider installing foo-extras, foo-extensions and foo-plugins as well. And then there's installing from pirut. If I want to install clamav, I open up pirut and search for "clamav". I get 17 packages. Which one do I have to install to have a sufficient setup ? Splitting packages to make dependencies easier to manager is a good idea, but first we may want to think about ways to make this less confusing to the end user. When I search for clamav, I'd like to see a big red line for the main clamav installation line (with all the dependencies it will pull hidden from view), and a side panel with a list of optional packages (plugins and al) with descriptions. Do we have enough metadata right now to produce something like this ? -denis From ruben at rubenkerkhof.com Sun Dec 2 11:00:57 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sun, 2 Dec 2007 12:00:57 +0100 Subject: Please, make lftp orphaned!!! In-Reply-To: <20071130193335.GA2836@free.fr> References: <200709141829.07383.alain.portal@free.fr> <20070914195135.GD2511@free.fr> <20071130112235.5586d084@redhat.com> <20071130193335.GA2836@free.fr> Message-ID: <1AE445C6-1A90-4330-A1C5-FFD2443201F7@rubenkerkhof.com> On 30 nov 2007, at 20:33, Patrice Dumas wrote: > On Fri, Nov 30, 2007 at 11:22:35AM -0500, Jesse Keating wrote: >> On Fri, 14 Sep 2007 21:51:35 +0200 >> Patrice Dumas wrote: >> >>> I contacted the maintainer, as per the AWOL procedure. We'll see. >> >> Has there been progress on this? We'd like to see the package >> orphaned >> so that somebody could pick it up. > > The maintainer finally responded and did the most urgent stuff. So he > isn't AWOL. If I recall well, however there is another maintainer now. > > -- > Pat See https://bugzilla.redhat.com/225984 Ruben From pertusus at free.fr Sun Dec 2 11:05:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 12:05:44 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <47528E2F.1050203@poolshark.org> References: <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> Message-ID: <20071202110544.GC3312@free.fr> On Sun, Dec 02, 2007 at 11:51:27AM +0100, Denis Leroy wrote: > > I feel the most important thing must remain ease of installation for > end-users. If you "yum install foo", you expect foo to be fully working > after installation (and how many dependencies it pulls is not necessarily > important if you're using yum directly). Remember we don't really have a > mechanism in place to say "since you just installed foo, you should really > consider installing foo-extras, foo-extensions and foo-plugins as well. End-users also expect a package install not to drag in packages that are not useful. Especially system administrator end-users who care about avoiding bloat. Installing everything may be confusing too, not for a user who just don't care about what is installed on his computer but for a user who want to keep control. -- Pat From jfrieben at gmx.de Sun Dec 2 11:46:33 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 02 Dec 2007 12:46:33 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> Message-ID: <20071202114633.312870@gmx.net> > The point remains though: no matter what side of the fence you sit on > regarding greater package granularity, I think Tom is bang on the > money - crafting a guideline to fit the broad and diverse range of > upstream packages in order to achieve your desired goal seems > impossible to me. Arguing over the merits or otherwise of increasing > the packaging granularity isn't going to change anything. If you > really believe this is an important and required change, try drafting > the guideline. If you had read my initial posting you would have noticed that I had simply asked if such guidelines wouldn't be a useful thing. I don't care if there are or not as long as package maintainers respond in a reasonable and cooperative way to user request/concerns. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From buildsys at redhat.com Sun Dec 2 12:02:38 2007 From: buildsys at redhat.com (Build System) Date: Sun, 2 Dec 2007 07:02:38 -0500 Subject: rawhide report: 20071202 changes Message-ID: <200712021202.lB2C2c3U002666@porkchop.devel.redhat.com> New package BlockOutII A free adaptation of the original BlockOut DOS game New package kdebase-workspace K Desktop Environment - Workspace New package kdebase3 K Desktop Environment 3 - core files New package kdelibs3 K Desktop Environment 3 - Libraries New package oggconvert A simple GNOME application that converts media to Free formats New package seekwatcher Utility for visualizing block layer IO patterns and performance New package writer2latex Writer2LateX Document Converter New package xchat-ruby An X-Chat plugin providing scripting functionality with Ruby Removed package kdelibs4 Removed package kdebase4 Updated Packages: anaconda-11.4.0.4-2 ------------------- * Fri Nov 30 2007 Jeremy Katz - 11.4.0.4-2 - rebuild for new libdhcp6client audacious-1.4.2-3.fc9 --------------------- * Sat Dec 01 2007 Ralf Ertzinger 1.4.2-3 - Add patch to fix streams sometimes being left open - Obsolete: audacious-docklet * Mon Nov 19 2007 Ralf Ertzinger 1.4.2-2 - Update to 1.4.2 * Tue Aug 28 2007 Fedora Release Engineering - 1.3.2-3 - Rebuild for selinux ppc32 issue. cfengine-2.2.3-1.fc9 -------------------- * Sat Dec 01 2007 Jeff Sheltren 2.2.3-1 - Update to upstream 2.2.3 - Remove unneeded patches (hostrange and glibc open) compiz-fusion-0.6.0-7.fc9 ------------------------- * Sat Dec 01 2007 Adel Gadllah 0.6.0-7 - Adding the patch isn't enough .. we have to apply it ;) * Sat Dec 01 2007 Adel Gadllah 0.6.0-6 - Backport upstream openoffice menu fix * Sun Oct 28 2007 Adel Gadllah 0.6.0-5 - Rediff patch digikam-doc-0.9.3-0.1.beta3.fc9 ------------------------------- * Sat Dec 01 2007 Marcin Garski 0.9.3-0.1.beta3 - Update to 0.9.3-beta3 evolution-2.21.2-4.fc9 ---------------------- * Sat Dec 01 2007 Matthew Barnes - 2.21.2-4.fc9 - Fix a corrupted patch that caused GNOME bug #499291. * Thu Nov 29 2007 Matthew Barnes - 2.21.2-3.fc9 - Add patch for GNOME bug #499920 (invalid #include). * Fri Nov 23 2007 Matthew Barnes - 2.21.2-2.fc9 - Rebuild against newer libpisync.so. glest-2.0.1-4.fc9 ----------------- * Sat Dec 01 2007 Aurelien Bompard 2.0.1-4 - add a symlink to the "scenarios" directory (bug 403401) * Sat Oct 06 2007 Aurelien Bompard 2.0.1-3 - incorporate opengl-games-utils' functionality into the wrapper script gsynaptics-0.9.13-2.1 --------------------- * Sat Dec 01 2007 Thorsten Leemhuis - 0.9.13-2 - BR gnome-doc-utils * Sat Dec 01 2007 Thorsten Leemhuis - 0.9.13-1 - Update to 0.9.13 - ship touchpad.png, fixes #401891 inkscape-0.45.1-3.fc9 --------------------- * Sun Dec 02 2007 Lubomir Kundrak - 0.45.1-3 - Satisfy desktop-file-validate, so that Rawhide build won't break * Sat Dec 01 2007 Lubomir Kundrak - 0.45.1-2 - Use GTK print dialog - Added compressed SVG association (#245413) - popt headers went into popt-devel, post Fedora 7 - Fix macro usage in changelog isomaster-1.2-2.fc9 ------------------- * Sat Dec 01 2007 Marcin Zajaczkowski - 1.2-2 - Utility removed from Categories in .desktop file to prevent duplication in a menu * Sat Oct 27 2007 Marcin Zajaczkowski - 1.2-1 - updated to 1.2 - removed viewer-variable patch (merged with upstream) kdebase-6:3.96.2-1.fc9 ---------------------- * Sat Dec 01 2007 Kevin Kofler 3.96.2-1 - merge changes from Sebastian Vahl's version: - update to 3.96.2, remove beta warnings - BR: kde-filesystem >= 4 - only remove conflicts when building as kdebase4, update file list - run xdg-icon-resource forceupdate for hicolor when building as kdebase - make this the default kdebase for F9 again * Mon Nov 19 2007 Kevin Kofler 3.96.0-4 - don't list libkdeinit4_*.so, we remove all of them as conflicts * Mon Nov 19 2007 Kevin Kofler 3.96.0-3 - remove new directory/files %{_kde4_datadir}/templates (conflict with KDE 3) kdebase-runtime-3.96.2-2.fc9 ---------------------------- * Sat Dec 01 2007 Kevin Kofler 3.96.2-2 - no longer set kde3_desktop on F9 - update file list for !kde3_desktop (Sebastian Vahl) - don't ship country flags even for full version (as in kdebase 3) kdelibs-6:3.96.2-3.fc9 ---------------------- * Sat Dec 01 2007 Kevin Kofler 3.96.2-3 - install profile scripts as 644 instead of 755 (Ville Skytt??, #407521) * Sat Dec 01 2007 Kevin Kofler 3.96.2-2 - BR openssh-clients and subversion (Sebastian Vahl) - make this the default kdelibs for F9 again * Thu Nov 29 2007 Rex Dieter 3.96.2-1 - kde-3.96.2 kdetoys-7:3.96.2-1.fc9 ---------------------- * Thu Nov 29 2007 Rex Dieter 7:3.96.2-1 - kde-3.96.2 * Wed Nov 28 2007 Rex Dieter 7:3.96.1-2 - touchup a bit for cvs import - drop libs subpkg (no shlibs present) * Sat Nov 24 2007 Sebastian Vahl 7:3.96.1-1 - kde-3.96.1 kdeutils-6:3.96.2-2.fc9 ----------------------- * Sat Dec 01 2007 Rex Dieter 6:3.96.2-2 - kcalc_32bit patch * Sat Dec 01 2007 Rex Dieter 6:3.96.2-1 - kde-3.96.2 * Sat Nov 24 2007 Sebastian Vahl 6:3.96.1-1 - kde-3.96.1 - added epoch in changelog (also backwards) kernel-2.6.24-0.62.rc3.git5.fc9 ------------------------------- * Sat Dec 01 2007 John W. Linville - Some wireless bits headed for 2.6.25 - Make ath5k use software WEP * Fri Nov 30 2007 Kyle McMartin - Oops! Local make-build-go-faster kernel.spec patch slipped in, reverted. * Fri Nov 30 2007 Jarod Wilson - FireWire OHCI 1.0 Isochronous Receive support (#344851) ktorrent-2.2.4-2.fc9 -------------------- * Sat Dec 01 2007 Roland Wolters - 2.2.4-2 - changed build require from kdelibs-devel to kdelibs3-devel munin-1.2.5-3.fc9 ----------------- * Fri Nov 30 2007 Kevin Fenzi - 1.2.5-3 - Removed unnneeded plugins.conf file (fixes #288541) - Fix license tag. - Fix ip_conntrack monitoring (fixes #253192) - Switch to new useradd guidelines. octave-forge-20071014-4.fc9 --------------------------- * Sat Dec 01 2007 Alex Lancaster 20071014-4 - Rebuild for new octave oorexx-3.2.0-2.fc9 ------------------ * Sat Dec 01 2007 Gerard Milmeister - 3.2.0-2 - exclude arch ppc64 * Sat Dec 01 2007 Gerard Milmeister - 3.2.0-1 - new release 3.2.0 perl-Wx-0.80-2.fc9 ------------------ * Fri Nov 30 2007 Tom "spot" Callaway - 0.80-2 - fix bogus requires rsibreak-0.8.0-3.fc9 -------------------- * Sat Dec 01 2007 Roland Wolters - 0.8.0-3 - changed build require from kdelibs-devel to kdelibs3-devel - removed qt-devel dependency, kdelibs3-devel dep should be enough telepathy-salut-0.1.11-1.fc9 ---------------------------- * Sat Dec 01 2007 Brian Pepple - 0.1.11-1 - Update to 0.1.11. - Add min. version of check needed. tetex-fonts-hebrew-0.1-8.fc9 ---------------------------- * Sat Dec 01 2007 Dan Kenigsberg 0.1-8 - Link to newly-named culmus-fonts. Bug #391161 xen-3.1.2-1.fc9 --------------- * Sat Dec 01 2007 Daniel P. Berrange - 3.1.2-1.fc9 - Upgrade to 3.1.2 bugfix release * Sat Nov 03 2007 Daniel P. Berrange - 3.1.0-14.fc9 - Disable network-bridge script since it conflicts with NetworkManager which is now on by default zabbix-1.4.2-4.fc9 ------------------ * Sat Dec 01 2007 Dan Horak 1.4.2-4 - add security fix (#407181) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.i386 requires gecko-libs = 0:1.8.1.9 sysprof - 1.0.8-2.fc8.i386 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.i386 requires libntfs.so.9 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 sysprof - 1.0.8-2.fc8.x86_64 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.x86_64 requires libntfs.so.9()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5 monodevelop - 0.17-4.fc9.ppc requires boo openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.ppc requires gecko-libs = 0:1.8.1.9 testdisk - 6.8-1.fc8.ppc requires libntfs.so.9 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 testdisk - 6.8-1.fc8.ppc64 requires libntfs.so.9()(64bit) From jfrieben at gmx.de Sun Dec 2 12:19:21 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 02 Dec 2007 13:19:21 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202104230.GA3312@free.fr> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <20071202104230.GA3312@free.fr> Message-ID: <20071202121921.312870@gmx.net> > > First of all, vtk-devel at least pulls in vtk-python, vtk-tcl, vtk-qt, > > tcl, tk, qt beyond packages that were already required by the base > > system. Are these packages specific to developers? I doubt so. > > Moreover, what you call developers are not necessarily hardcore > > developers of the package under consideration, so it might be simple > > people who just need/want to build an application based upon the VTK > > toolkit. > > Though it is not easy to know by advance which binding they will need. This argument applies to both runtime [needed to run the binary] and development [needed to build the binary] packages and could rather be understood as an argument -against- splitting runtime packages. > > As a matter of fact, Fedora does not even include a single application > > that uses any of vtk, vtk-python, vtk-qt, vtk-tcl [well, vtk-examples > > and vtk-testing but that probably doesn't count]. > > In fact paraview uses vtk, though for right reasons still uses an > internal version, but hopefully one day will use the system vtk. But > more generally you cannot predict which package will use which library > or binding. You have to package as if your library could be used even > if it is not currently. There are a lot of software that are still > not in fedora. This is still no argument in favour of a monolithic development package when there exist split runtime packages. The packager of a source RPM always has to ensure that both requirements -and- build requirements are defined correctly in the spec file. This usually even allows to steer which bindings are enabled or disabled during the [autotools] configure phase. Btw, the reason for pointing out the absence of any package built against vkt-* was that Warren had made a distinction between users and developers which simply does not apply well to VTK in Fedora .. > > Apart from using 3rd party binaries, any person interested in the vtk > > package necessarily is what you call 'developer'. So, the term 'user' > > essentially loses any meaning in this context. > > Finally, the case of the plplot package shows that my initial request > > is by no means exotic, and I maintain my point that it would be sign > > of userfriendliness not to impose unneeded packages like the ones > > enumerated above on a user of the vtk package. > > You mean plplot requires vtk-devel? Or plplot-devel requires vtk-devel? Of course not. I had cited the plplot package as an example where no monolithic development package but development subpackages corresponding to runtime packages already do exist. > Runtime fine grained dependencies are very desirable but devel fine > grained dependencies are optional nad in the case of vtk, I think that > it is best left to the packager, and I think that most vtk users expect > all the binding to be there when installing vtk-devel. > > -- > Pat Fine grained runtime dependencies are not very useful when development packages pull them in altogether, thus effectively thwarting the whole effort. "Thinking" that most VTK users expect all the bindings is not what I would call a strong point. I -am- a VTK user, and I have actually expressed my discontent. So, the current score is rather 0:1! -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From jonathan.underwood at gmail.com Sun Dec 2 12:30:41 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Dec 2007 12:30:41 +0000 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202114633.312870@gmx.net> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> <20071202114633.312870@gmx.net> Message-ID: <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> On 02/12/2007, Joachim Frieben wrote: > > The point remains though: no matter what side of the fence you sit on > > regarding greater package granularity, I think Tom is bang on the > > money - crafting a guideline to fit the broad and diverse range of > > upstream packages in order to achieve your desired goal seems > > impossible to me. Arguing over the merits or otherwise of increasing > > the packaging granularity isn't going to change anything. If you > > really believe this is an important and required change, try drafting > > the guideline. > > If you had read my initial posting you would have noticed that I had > simply asked if such guidelines wouldn't be a useful thing. I don't > care if there are or not as long as package maintainers respond in a > reasonable and cooperative way to user request/concerns. I imagine most packagers would react favourably to such requests, given a reasonable use case, and even better, a spec file patch. Have you submitted a patch for your vtk case for discussion to the package maintainer? From pertusus at free.fr Sun Dec 2 12:38:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 13:38:24 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> References: <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> <20071202114633.312870@gmx.net> <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> Message-ID: <20071202123824.GD3312@free.fr> On Sun, Dec 02, 2007 at 12:30:41PM +0000, Jonathan Underwood wrote: > > I imagine most packagers would react favourably to such requests, > given a reasonable use case, and even better, a spec file patch. Have > you submitted a patch for your vtk case for discussion to the package > maintainer? The issue is certainly not about providing a patch or not, but about the relevance to split the devel subpacakge. -- Pat From pertusus at free.fr Sun Dec 2 12:40:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 13:40:08 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202121921.312870@gmx.net> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <20071202104230.GA3312@free.fr> <20071202121921.312870@gmx.net> Message-ID: <20071202124008.GE3312@free.fr> On Sun, Dec 02, 2007 at 01:19:21PM +0100, Joachim Frieben wrote: > > > First of all, vtk-devel at least pulls in vtk-python, vtk-tcl, vtk-qt, > > > tcl, tk, qt beyond packages that were already required by the base > > > system. Are these packages specific to developers? I doubt so. > > > Moreover, what you call developers are not necessarily hardcore > > > developers of the package under consideration, so it might be simple > > > people who just need/want to build an application based upon the VTK > > > toolkit. > > > > Though it is not easy to know by advance which binding they will need. > > This argument applies to both runtime [needed to run the binary] and > development [needed to build the binary] packages and could rather be > understood as an argument -against- splitting runtime packages. No, because runtime package would be bring in by dependent packages (though there are none currently there could be). -- Pat From jonathan.underwood at gmail.com Sun Dec 2 12:56:53 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Dec 2007 12:56:53 +0000 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202123824.GD3312@free.fr> References: <20071201121141.GB3017@free.fr> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> <20071202114633.312870@gmx.net> <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> <20071202123824.GD3312@free.fr> Message-ID: <645d17210712020456g638cddfg1e6bb0dcc42f4253@mail.gmail.com> On 02/12/2007, Patrice Dumas wrote: > On Sun, Dec 02, 2007 at 12:30:41PM +0000, Jonathan Underwood wrote: > > > > I imagine most packagers would react favourably to such requests, > > given a reasonable use case, and even better, a spec file patch. Have > > you submitted a patch for your vtk case for discussion to the package > > maintainer? > > The issue is certainly not about providing a patch or not, but about the > relevance to split the devel subpacakge. I disagree in many cases forcing a split into many subpackages proves fruitless because you end up with circular dependencies between the sub-packages, and so you haven't really achieved much. Right now, the OP is trying to put the burden of proof of whether this is beneficial or not on the vtk packager. Providing a patch would provide the basis on which to have a technical discussion. The current discussion is far too hand wavy and nebulous. From jonathan.underwood at gmail.com Sun Dec 2 12:58:30 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Dec 2007 12:58:30 +0000 Subject: Guidelines for creating subpackages? In-Reply-To: <645d17210712020456g638cddfg1e6bb0dcc42f4253@mail.gmail.com> References: <20071201121141.GB3017@free.fr> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> <20071202114633.312870@gmx.net> <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> <20071202123824.GD3312@free.fr> <645d17210712020456g638cddfg1e6bb0dcc42f4253@mail.gmail.com> Message-ID: <645d17210712020458o28cacc44uea21fc5b61bb0f6f@mail.gmail.com> On 02/12/2007, Jonathan Underwood wrote: > I disagree in many cases forcing a split into many subpackages proves Sorry, poor grammar - that should have read "I disagree. In many cases..." From jfrieben at gmx.de Sun Dec 2 13:30:28 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 02 Dec 2007 14:30:28 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201175013.39810@gmx.net> <4752289F.4010001@redhat.com> <20071202085345.309030@gmx.net> <645d17210712020228h28bf1a73t9f8c351daf7573d9@mail.gmail.com> <20071202114633.312870@gmx.net> <645d17210712020430x30939953hec2e5f3980d86cf2@mail.gmail.com> Message-ID: <20071202133028.95720@gmx.net> -------- Original-Nachricht -------- > Datum: Sun, 2 Dec 2007 12:30:41 +0000 > Von: "Jonathan Underwood" > An: "Development discussions related to Fedora" > Betreff: Re: Guidelines for creating subpackages? > I imagine most packagers would react favourably to such requests, > given a reasonable use case, and even better, a spec file patch. Have > you submitted a patch for your vtk case for discussion to the package > maintainer? - Well, I had submitted a corresponding bug report, namely https://bugzilla.redhat.com/show_bug.cgi?id=388211 which got closed immediately as "NOTABUG" based on the personal taste of the/one package co-/maintainer after which I felt compelled to bring the issue to this list in order to learn about how other community members think about it. - The "reasonable use case" is that as an exclusive GNOME user I'm encumbered with certain packages/toolkits that I'd like to get rid of on my system, and that current dependencies prevent me from doing so. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From Matt_Domsch at dell.com Sun Dec 2 13:56:42 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 2 Dec 2007 07:56:42 -0600 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 Message-ID: <20071202075642.A15743@humbolt.us.dell.com> This is a full top-to-bottom rebuild of rawhide using mock 0.8.10 running on 7 Fedora 8 builders. The rpmdiff results have been enhanced to ignore dist tag mismatches, so every package now has an rpmdiff comparsison against it's corresponding binary RPM in rawhide, even if the dist tag has changed to .fc9 in this rebuild. libunwind.i386 failed to complete build in 6 hours and was timed out by mock. I believe this is a failure in its testsuite - it was consuming 100% CPU that whole time. Fedora Rawhide-in-Mock Build Results for x86_64 Sun Dec 1 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5037 Number failed to build: 414 Number expected to fail due to ExclusiveArch or ExcludeArch: 35 Leaving: 379 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 379 ---------------------------------- BackupPC-3.1.0-1.fc9 (build/make) trasher GtkAda-2.8.0-7.fc7 (build/make) gemi HippoDraw-1.21.1-2.fc8 (build/make) pfkeb LabPlot-1.5.1.6-4.fc8 (build/make) chitlesh Miro-0.9.9.9-1.fc9 (build/make) tscherf,alexlan MyPasswordSafe-0.6.7-1.20061216.fc8 (build/make) ertzing NetworkManager-openvpn-0.7.0-3.svn3047.fc9 (build/make) timn OpenSceneGraph-2.2.0-3.fc9 (build/make) corsepiu QuantLib-0.8.1-4.fc9 (build/make) spot R-waveslim-1.6-4.fc8 (build/make) jamatos TnL-071111-1.fc9 (build/make) jwrdegoede agistudio-1.2.3-4.fc8 (build/make) limb airsnort-0.2.7e-11.fc7 (build/make) awjb alacarte-0.11.3-4.fc8 (build/make) rstrode,jpmahowa,sindrepb alex-2.1.0-5.fc8 (build/make) bos,petersen alliance-5.0-10.20070718snap.fc8 (build/make) chitlesh amarokFS-0.5-1.fc7 (build/make) faucamp amsn-0.96-7.fc7 (build/make) tjikkun atitvout-0.4-7 (build/make) awjb audacious-docklet-0.1.1-2.fc7 (build/make) avr-binutils-2.17-4.fc8 (build/make) jwrdegoede avr-libc-1.4.6-4.fc8 (build/make) jwrdegoede awesfx-0.5.0d-4.fc7 (build/make) stransky bacula-2.0.3-11.fc8 (build/make) ixs,mmcgrath beagle-0.2.18-1.fc8 (build/make) alexl binutils-2.17.50.0.18-1 (build/make) jakub blitz-0.9-3.fc8 (build/make) sergiopr blogtk-1.1-8.fc7 (build/make) pfrields bluecurve-kde-theme-1.0.0-1.fc8 (build/make) rstrode,rdieter,davidz,than,kkofler bluecurve-kwin-theme-1.0.0-1.fc8 (build/make) rstrode,rdieter,davidz,kkofler bmpx-0.40.13-6.fc9 (build/make) akahl bolzplatz2006-1.0.3-3.fc9 (build/make) jwrdegoede bouml-3.3.3-1.fc9 (build/make) rishi callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2 camstream-0.26.3-12.fc8 (open_missing_mode) nomis80 castor-0.9.5-1jpp.7 (build/make) pcheung chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig clips-6.24-22.fc7 (build/make) rvinyard clisp-2.43-3.fc9 (build/make) gemi compat-erlang-R10B-10.7.fc7 (build/make) gemi compiz-0.6.2-4.fc9 (build/make) krh compizconfig-backend-kconfig-0.6.0-1.fc9 (build/make) izhar,izhar conexus-0.5.3-2.fc8 (build/make) rvinyard cryptix-asn1-20011119-7jpp.2 (build/make) vivekl crystal-1.0.5-1.fc8 (build/make) chitlesh cvs-1.11.22-12.fc8 (build/make) jmoskovc cyrus-sasl-2.1.22-9.fc9 (build/make) sconklin d3lphin-0.9.2-2.fc8 (build/make) chitlesh d4x-2.5.7.1-3.fc7 (build/make) thias dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus darcs-1.0.9-6.fc8 (build/make) jjh,petersen dekorator-0.3-3.fc7 (build/make) faucamp eclipse-3.3.1.1-11.fc9 (build/make) overholt,oliver,overholt eclipse-emf-2.2.2-1.fc7 (build/make) overholt eclipse-mylyn-2.0.0-9.fc8 (build/make) overholt emelfm2-0.3.5-2.fc8 (build/make) cwickert enblend-3.0-6.fc8 (build/make) bpostle,jspaleta epylog-1.0.3-5.fc7 (build/make) icon erlang-R11B-5.3.fc8 (build/make) gemi esc-1.0.1-7.fc8 (build/make) jmagne evolution-brutus-1.1.28.7-2.fc8 (build/make) bpepple evolution-sharp-0.15.1-1.fc9 (build/make) mbarnes fetchmail-6.3.8-3.fc8 (build/make) vcrhonek fluxstyle-1.0.1-2.fc7 (build/make) errr fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig fpc-2.2.0-10.fc8 (build/make) joost freetennis-0.4.8-6.fc7 (build/make) rjones fwfstab-0.02-2.fc9 (build/make) firewing gcl-2.6.7-15.fc8 (build/make) gemi gdal-1.4.2-3.fc8 (build/make) cbalint gdmap-0.7.5-6.fc6 (build/make) splinux gedit-plugins-2.18.0-2.fc7 (build/make) trondd genchemlab-1.0-5.fc6 (build/make) pfj gfa-0.4.1-4.fc7 (build/make) splinux gg2-2.3.0-3.fc8 (build/make) rathann gjots2-2.3.4-7.fc7 (build/make) rvokal glipper-0.95.1-2.fc7 (build/make) splinux gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak gnome-applets-2.21.1-1.fc9 (build/make) rstrode gnome-specimen-0.3-1.fc8 (build/make) splinux gnomescan-0.4.0.2-1.fc7 (build/make) deji gnubg-20061119-13.fc8 (build/make) limb gquilt-0.20-1.fc7 (build/make) jwboyer gstm-1.2-6.fc7 (build/make) splinux gtk-qt-engine-0.70-6.20070811svn.fc8 (build/make) rdieter gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog haddock-0.8-1.fc7 (build/make) petersen,bos happy-1.16-2.fc7 (build/make) bos,petersen ht2html-2.0-5.fc6 (build/make) ifoox htop-0.6.5-1.fc7 (build/make) gajownik httpd-2.2.6-3 (build/make) jorton hunspell-ar-0.20060208-1.fc8 (build/make) danken hunt-1.5-6.fc6 (build/make) ensc inkscape-0.45.1-1.fc7 (needs_popt-devel) denis ip-sentinel-0.12-10.fc7 (build/make) ensc ipsec-tools-0.7-3.fc8 (build/make) sconklin jd-1.9.8-0.1.svn1570.fc9 (build/make) mtasaka jfbterm-0.4.7-12.fc8 (build/make) mtasaka jgroups-2.2.9.2-3jpp.2 (build/make) vivekl junitperf-1.9.1-2jpp.1.fc7 (build/make) mwringe kalgebra-0.5-4.fc8 (build/make) chitlesh katapult-0.3.2.1-2.fc8 (build/make) chitlesh kbackup-0.5.2-1.fc8 (build/make) dionysos kbibtex-0.1.5.52-10.fc7 (build/make) noltec kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede kbiof-0.3-1.fc8 (build/make) oddsocks kchmviewer-3.0-2.fc7 (build/make) pertusus,jpo kcometen3-1.1-5.fc8 (build/make) oddsocks kdebase4-3.96.0-4.fc9 (build/make) kkofler,rdieter,than kdelibs-3.5.8-7.fc8 (build/make) than,rdieter,kkofler kdesdk-3.5.8-2.fc8 (build/make) than,rdieter,kkofler kdesvn-0.14.1-1.fc9 (build/make) orion kdevelop-3.5.0-4.fc8 (build/make) than,rdieter,kkofler kdiff3-0.9.92-10.fc9 (build/make) nbecker kdirstat-2.5.3-6.fc8 (build/make) chitlesh kdissert-1.0.7-1.fc7 (build/make) icon kdmtheme-1.2.1-1.fc9 (buildroot) chitlesh kdocker-1.3-9.fc8 (build/make) rdieter keurocalc-0.9.7-3.fc8 (build/make) chitlesh kexec-tools-1.102pre-2.fc8 (build/make) nhorman kgtk-0.8-2.fc7 (build/make) faucamp kid3-0.9-2.fc8 (build/make) scop kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4 kio_resources-0.2-3.fc8 (build/make) chitlesh klamav-0.41.1-6.fc9 (build/make) andriy klibido-0.2.5-8.fc8 (build/make) faucamp knetstats-1.6.1-4.fc8 (build/make) chitlesh komparator-0.8-1.fc8 (build/make) nbecker koverartist-0.5-8.fc8 (build/make) svahl kpolynome-0.1.2-10.fc8 (build/make) chitlesh kreetingkard-0.7.1-2.fc9 (build/make) mtasaka krename-3.0.14-2.fc8 (build/make) ecik kshutdown-1.0.1-1.fc8 (build/make) chitlesh ksirk-1.7-3.fc8 (build/make) jwrdegoede ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,chitlesh ksynaptics-0.3.3-2.fc8 (build/make) orion ktechlab-0.3.69-5.fc8 (build/make) chitlesh ktorrent-2.2.4-1.fc9 (build/make) liquidat,rdieter kyum-0.7.5-9.fc8 (build/make) s4504kr ladspa-1.12-8.fc7 (build/make) thomasvs lat-1.2.3-1.fc8 (build/make) pghmcfc ldapjdk-4.17-1jpp.7 (build/make) vivekl libXxf86dga-1.0.1-4.fc8 (build/make) ssp libapreq2-2.09-0.rc2.11.fc9 (build/make) bojan libchewing-0.3.0-8.fc8 (open_missing_mode) cchance libevent-1.3b-1.fc7 (build/make) steved,ertzing libgdamm-2.9.8-1.fc8 (build/make) spot libkexiv2-0.1.6-2.fc9 (build/make) rdieter,mgarski libopensync-plugin-kdepim-0.22-2.fc8 (build/make) awjb libprelude-0.9.13-1.fc7 (build/make) tscherf libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf libsvm-2.84-6.fc8 (build/make) dchen licq-1.3.4-8.fc9 (build/make) jmoskovc lilypond-doc-2.10.13-1.fc7 (build/make) qspencer lineak-kdeplugins-0.9-2.fc6 (build/make) xris ltrace-0.5-9.45svn.fc8 (build/make) pmachata lyx-1.5.2-1.fc8 (build/make) rdieter,jamatos maniadrive-1.2-5.fc9 (build/make) jwrdegoede maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe maxima-5.13.0-10.fc9 (build/make) rdieter,jamatos mbuffer-20070502-1.fc7 (open_missing_mode) adalloz mod_perl-2.0.3-14 (build/make) jorton module-init-tools-3.4-2.fc8 (build/make) jcm monodevelop-0.17-4.fc9 (build/make) pfj moto4lin-0.3-6.fc7 (build/make) jafo museek+-0.1.13-1.fc8 (build/make) belegdol mx4j-3.0.1-6jpp.4 (build/make) fnasser nabi-0.18-7.fc8 (build/make) sbehera,petersen nant-0.85-17.fc9 (build/make) pfj nemiver-0.4.0-1.fc8 (build/make) pgordon nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb ntfs-config-1.0-0.5.rc5.fc8 (build/make) laxathom ogre-1.4.5-3.fc9 (build/make) jwrdegoede openais-0.80.1-6 (open_missing_mode) sdake,sdake openssh-4.7p1-4.fc9 (build/make) tmraz openvrml-0.16.7-1.fc9 (build/make) braden orange-0.3-5.cvs20051118.fc8 (build/make) awjb orpie-1.4.3-5.fc6 (build/make) xris ots-0.4.2-11.fc7 (build/make) pgordon pam_abl-0.2.3-3.fc7 (build/make) adalloz pari-2.3.0-5.fc7 (build/make) gemi pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo pdfedit-0.3.2-2.fc8 (build/make) bjohnson perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,perl-sig,ghenry perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,perl-sig perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,perl-sig perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,perl-sig perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,perl-sig perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,perl-sig perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,perl-sig perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,perl-sig perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,perl-sig perl-DateTime-Set-0.25-4.fc7 (build/make) steve,perl-sig perl-Devel-Caller-0.11-1.fc7 (build/make) steve,perl-sig perl-Email-Date-1.102-3.fc8 (build/make) spot,perl-sig perl-Email-Reply-1.202-1.fc8 (build/make) spot,perl-sig perl-Exception-Class-1.23-3.fc7 (build/make) steve,perl-sig perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,perl-sig,laxathom perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,perl-sig perl-File-Type-0.22-4.fc7 (build/make) steve,perl-sig perl-GSSAPI-0.24-1.fc7 (build/make) steve,perl-sig perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,perl-sig perl-IO-All-0.38-1.fc7 (build/make) steve,perl-sig perl-Imager-0.60-1.fc8 (build/make) steve,ghenry perl-Kwiki-0.39-1.fc7 (build/make) steve,perl-sig perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,perl-sig perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,perl-sig perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,perl-sig perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,perl-sig perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig perl-Log-Message-0.01-3.fc7 (build/make) steve,perl-sig perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,perl-sig perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig perl-Module-Install-0.67-1.fc8 (build/make) steve,perl-sig perl-Module-Loaded-0.01-3.fc7 (build/make) steve,perl-sig perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,perl-sig perl-MooseX-Getopt-0.05-1.fc8 (build/make) cweyl,perl-sig perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,perl-sig perl-Object-Accessor-0.32-2.fc7 (build/make) steve,perl-sig perl-OpenFrame-3.05-6.fc7 (build/make) steve,perl-sig perl-PDL-2.4.3-4.fc8 (build/make) rnorwood perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,perl-sig perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig perl-PPI-Tester-0.06-2.fc6 (build/make) spot,perl-sig perl-Package-Constants-0.01-3.fc7 (build/make) steve,perl-sig perl-Params-Check-0.26-1.fc7 (build/make) steve,perl-sig perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,perl-sig perl-Perl-MinimumVersion-0.15-1.fc9 (build/make) corsepiu,perl-sig perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig perl-Pipeline-3.12-4.fc7 (build/make) steve,perl-sig perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig perl-SUPER-1.16-1.fc7 (build/make) cweyl,perl-sig perl-Set-Infinite-0.61-3.fc7 (build/make) steve,perl-sig perl-Spiffy-0.30-7.fc7 (build/make) steve,perl-sig perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig perl-Test-Expect-0.30-1.fc6 (build/make) cweyl,perl-sig perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,perl-sig perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,perl-sig perl-Tk-804.027-12.fc8 (build/make) awjb,perl-sig perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) spot,perl-sig perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver pexpect-2.1-5.fc8 (build/make) robert piklab-0.15.0-1.fc9 (build/make) chitlesh,dionysos pikloops-0.2.5-1.fc9 (build/make) dionysos plague-0.4.4.1-4.fc7 (build/make) dcbw polyester-1.0.2-1.fc8 (build/make) svahl poppler-0.6.2-2.fc9 (build/make) krh powerpc-utils-papr-1.0.4-2.fc9 (build/make) dwmw2 ppc64-utils-0.13-1.fc9 (build/make) dcantrel,dwmw2,pnasrat prelink-0.4.0-1 (build/make) jakub prewikka-0.9.8-1.fc7 (build/make) tscherf python-boto-0.9b-1.fc8 (build/make) robert python-chm-0.8.4-1.fc7 (build/make) pertusus python-docs-2.5.1-1.fc8 (build/make) james,katzj python-durus-3.5-3.fc7 (build/make) shahms python-psyco-1.5.1-5.fc7 (build/make) shahms python-pycurl-7.16.4-1.fc8 (build/make) jcollie python-quixote-2.4-5.fc7 (build/make) shahms python-reportlab-2.1-1.fc8 (build/make) bpepple python-simpletal-4.1-5.fc7 (build/make) shahms python-tag-0.91-5 (build/make) thias python-tpg-3.1.0-4.fc7 (build/make) shahms python-urljr-1.0.1-1.fc7 (build/make) jcollie pyzor-0.4.0-11.fc7 (build/make) ixs qa-assistant-0.4.90.5-2.fc6 (build/make) toshio qcomicbook-0.3.4-1.fc7 (build/make) muerte qpidc-0.2-5.fc7 (build/make) aconway,nsantos qpxtool-0.6.1-6.fc8 (build/make) drago01 qscintilla-1.7.1-3.fc8 (build/make) rdieter qstars-0.4-3.fc8 (build/make) oddsocks qsynth-0.2.5-6.fc6 (build/make) nando qt-qsa-1.1.5-3.fc9 (build/make) belegdol qtparted-0.4.5-15.fc8 (build/make) steve quadkonsole-2.0.2-1.fc7 (build/make) nomis80 qwtplot3d-0.2.7-4.fc8 (build/make) chitlesh raidem-0.3.1-7.fc8 (build/make) jwrdegoede rapidsvn-0.9.4-6.fc8 (build/make) timj rekall-2.4.5-6.fc8.1 (build/make) spot rhm-0.1-3.fc7 (build/make) aconway,nsantos rkward-0.4.8-2.fc9 (build/make) pingou rosegarden4-1.5.1-1.fc7.1 (build/make) seg rsibreak-0.8.0-2.fc8 (build/make) liquidat,rdieter ruby-bdb-0.6.0-1.fc7 (build/make) errr ruby-gnome2-0.16.0-16.fc9 (build/make) allisson s3switch-0.0-9.20020912.fc6 (build/make) pwouters scons-0.97-2.fc8 (build/make) gemi scorched3d-41.1-1.fc9 (build/make) jwrdegoede sdljava-0.9.1-6.fc9 (build/make) jwrdegoede seahorse-1.0.1-9.fc8 (build/make) skvidal six-0.5.3-6.fc8 (build/make) rafalzaq smart-0.52-51.fc9 (build/make) athimm,scop sobby-0.4.4-1.fc8 (build/make) lmacken subversion-1.4.4-7 (build/make) jorton svnmailer-1.0.8-3.fc7 (build/make) mfleming 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) spot,pvrabec tastymenu-0.8.2-2.fc8 (build/make) nixaff4 taxipilot-0.9.2-3.fc9 (build/make) jwrdegoede tclabc-1.0.9-1.fc7 (build/make) gemi tecnoballz-0.91-6.fc8 (build/make) musuruan tellico-1.2.14-2.fc8 (build/make) jamatos tetex-3.0-50.fc9 (build/make) jnovy tideEditor-1.4.1-1.fc8.3 (build/make) mtasaka twinkle-1.1-3.fc8 (build/make) kevin unison-2.13.16-3.fc6 (build/make) gemi ustr-1.0.1-6.fc8 (build/make) james vbetool-0.7-3.fc9 (build/make) till,pknirsch vnc-4.1.2-23.fc9 (build/make) atkac vtk-5.0.3-20.fc8 (build/make) athimm wesnoth-1.2.8-3.fc9 (build/make) bpepple xaos-3.2.3-1.fc7 (build/make) gemi xdaliclock-2.23-3.fc6 (build/make) kaboom xdrawchem-1.9.9-6.fc8 (build/make) rathann xfce4-battery-plugin-0.5.0-2.fc7 (build/make) cwickert 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-acecad-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-apm-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-ark-0.6.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-ast-0.81.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-chips-1.1.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-cirrus-1.1.0-5.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-glint-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-i128-1.2.1-1.fc8 (build/make) xgl-maint xorg-x11-drv-i740-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-magellan-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-mga-1.4.6.1-6.fc8 (build/make) xgl-maint xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-openchrome-0.2.900-7.fc9 (build/make) xavierb xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-rendition-4.1.3-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3-0.5.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3virge-1.9.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-savage-2.1.3-1.fc8 (build/make) xgl-maint xorg-x11-drv-siliconmotion-1.5.1-3.fc8 (build/make) xgl-maint xorg-x11-drv-sis-0.9.3-4.fc8 (build/make) xgl-maint xorg-x11-drv-spaceorb-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-tdfx-1.3.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-trident-1.2.3-6.fc8 (build/make) xgl-maint xorg-x11-drv-tseng-1.1.0-7.fc8 (build/make) xgl-maint xorg-x11-drv-vga-4.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-via-0.2.2-4.fc8 (build/make) xgl-maint xorg-x11-drv-vmware-10.15.2-1.fc8 (build/make) xgl-maint xorg-x11-drv-voodoo-1.1.1-1.fc8 (build/make) xgl-maint xorg-x11-server-1.4.99.1-0.10.fc9 (build/make) xgl-maint xsupplicant-1.2.8-4.fc9.4 (build/make) spot yelp-2.20.0-8.fc9 (build/make) mbarnes zaptel-1.4.6-1.fc9 (build/make) 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 Sun Dec 2 13:57:52 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 2 Dec 2007 07:57:52 -0600 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 Message-ID: <20071202075752.A16094@humbolt.us.dell.com> This is a full top-to-bottom rebuild of rawhide using mock 0.8.10 running on 7 Fedora 8 builders. The rpmdiff results have been enhanced to ignore dist tag mismatches, so every package now has an rpmdiff comparsison against it's corresponding binary RPM in rawhide, even if the dist tag has changed to .fc9 in this rebuild. libunwind.i386 failed to complete build in 6 hours and was timed out by mock. I believe this is a failure in its testsuite - it was consuming 100% CPU that whole time. Fedora Rawhide-in-Mock Build Results for i386 Sat Dec 1 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5038 Number failed to build: 379 Number expected to fail due to ExclusiveArch or ExcludeArch: 13 Leaving: 366 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 366 ---------------------------------- BackupPC-3.1.0-1.fc9 (build/make) trasher,, GtkAda-2.8.0-7.fc7 (build/make) gemi,, LabPlot-1.5.1.6-4.fc8 (build/make) chitlesh,, Miro-0.9.9.9-1.fc9 (build/make) tscherf,,alexlan MyPasswordSafe-0.6.7-1.20061216.fc8 (build/make) ertzing,, NetworkManager-openvpn-0.7.0-3.svn3047.fc9 (build/make) timn,, OpenSceneGraph-2.2.0-3.fc9 (build/make) corsepiu,, QuantLib-0.8.1-4.fc9 (build/make) spot,, R-waveslim-1.6-4.fc8 (build/make) jamatos,, agistudio-1.2.3-4.fc8 (build/make) limb,, airsnort-0.2.7e-11.fc7 (build/make) awjb,, alex-2.1.0-5.fc8 (build/make) bos,,petersen alliance-5.0-10.20070718snap.fc8 (build/make) chitlesh,, amarokFS-0.5-1.fc7 (build/make) faucamp,, amsn-0.96-7.fc7 (build/make) tjikkun,, apmd-3.2.2-6 (build/make) zprikryl,, athcool-0.3.11-5.fc6 (build/make) gajownik,, audacious-docklet-0.1.1-2.fc7 (build/make) avr-binutils-2.17-4.fc8 (build/make) jwrdegoede,, avr-libc-1.4.6-4.fc8 (build/make) jwrdegoede,, awesfx-0.5.0d-4.fc7 (build/make) stransky,, bacula-2.0.3-11.fc8 (build/make) ixs,,mmcgrath beagle-0.2.18-1.fc8 (build/make) alexl,, binutils-2.17.50.0.18-1 (build/make) jakub,, blitz-0.9-3.fc8 (build/make) sergiopr,, blogtk-1.1-8.fc7 (build/make) pfrields,, bluecurve-kde-theme-1.0.0-1.fc8 (build/make) rstrode,,rdieter,davidz,than,kkofler bluecurve-kwin-theme-1.0.0-1.fc8 (build/make) rstrode,,rdieter,davidz,kkofler bolzplatz2006-1.0.3-3.fc9 (build/make) jwrdegoede,, bouml-3.3.3-1.fc9 (build/make) rishi,, callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2,, camstream-0.26.3-12.fc8 (open_missing_mode) nomis80,, castor-0.9.5-1jpp.7 (build/make) pcheung,, chkfontpath-1.10.1-2.fc8 (build/make) krh,,fonts-sig clips-6.24-22.fc7 (build/make) rvinyard,, clisp-2.43-3.fc9 (build/make) gemi,, cmucl-19d-5.fc8 (build/make) rdieter,, compat-erlang-R10B-10.7.fc7 (build/make) gemi,, compiz-0.6.2-4.fc9 (build/make) krh,, compizconfig-backend-kconfig-0.6.0-1.fc9 (build/make) izhar,,izhar conexus-0.5.3-2.fc8 (build/make) rvinyard,, cryptix-asn1-20011119-7jpp.2 (build/make) vivekl,, crystal-1.0.5-1.fc8 (build/make) chitlesh,, cvs-1.11.22-12.fc8 (build/make) jmoskovc,, cyrus-sasl-2.1.22-9.fc9 (build/make) sconklin,, d3lphin-0.9.2-2.fc8 (build/make) chitlesh,, d4x-2.5.7.1-3.fc7 (build/make) thias,, dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus,, darcs-1.0.9-6.fc8 (build/make) jjh,,petersen dekorator-0.3-3.fc7 (build/make) faucamp,, eclipse-3.3.1.1-11.fc9 (build/make) overholt,,oliver,overholt eclipse-emf-2.2.2-1.fc7 (build/make) overholt,, eclipse-mylyn-2.0.0-9.fc8 (build/make) overholt,, emelfm2-0.3.5-2.fc8 (build/make) cwickert,, epylog-1.0.3-5.fc7 (build/make) icon,, erlang-R11B-5.3.fc8 (build/make) gemi,, esc-1.0.1-7.fc8 (build/make) jmagne,, evolution-brutus-1.1.28.7-2.fc8 (build/make) bpepple,, evolution-sharp-0.15.1-1.fc9 (build/make) mbarnes,, fetchmail-6.3.8-3.fc8 (build/make) vcrhonek,, fluxstyle-1.0.1-2.fc7 (build/make) errr,, fontypython-0.2.0-6.fc7 (build/make) cr33dog,,fonts-sig freetennis-0.4.8-6.fc7 (build/make) rjones,, gcl-2.6.7-15.fc8 (build/make) gemi,, gdal-1.4.2-3.fc8 (build/make) cbalint,, gdmap-0.7.5-6.fc6 (build/make) splinux,, gedit-plugins-2.18.0-2.fc7 (build/make) trondd,, genchemlab-1.0-5.fc6 (build/make) pfj,, gfa-0.4.1-4.fc7 (build/make) splinux,, gg2-2.3.0-3.fc8 (build/make) rathann,, gjots2-2.3.4-7.fc7 (build/make) rvokal,, glipper-0.95.1-2.fc7 (build/make) splinux,, gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak,, gnome-applets-2.21.1-1.fc9 (build/make) rstrode,, gnomescan-0.4.0.2-1.fc7 (build/make) deji,, gnubg-20061119-13.fc8 (build/make) limb,, gquilt-0.20-1.fc7 (build/make) jwboyer,, gstm-1.2-6.fc7 (build/make) splinux,, gtk-qt-engine-0.70-6.20070811svn.fc8 (build/make) rdieter,, gtk-sharp-1.0.10-12.fc7 (build/make) pfj,, gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog,, haddock-0.8-1.fc7 (build/make) petersen,,bos happy-1.16-2.fc7 (build/make) bos,,petersen ht2html-2.0-5.fc6 (build/make) ifoox,, htop-0.6.5-1.fc7 (build/make) gajownik,, httpd-2.2.6-3 (build/make) jorton,, hunspell-ar-0.20060208-1.fc8 (build/make) danken,, inkscape-0.45.1-1.fc7 (needs_popt-devel) denis,, ip-sentinel-0.12-10.fc7 (build/make) ensc,, ipsec-tools-0.7-3.fc8 (build/make) sconklin,, jd-1.9.8-0.1.svn1570.fc9 (build/make) mtasaka,, jfbterm-0.4.7-12.fc8 (build/make) mtasaka,, jgroups-2.2.9.2-3jpp.2 (build/make) vivekl,, kalgebra-0.5-4.fc8 (build/make) chitlesh,, katapult-0.3.2.1-2.fc8 (build/make) chitlesh,, kbackup-0.5.2-1.fc8 (build/make) dionysos,, kbibtex-0.1.5.52-10.fc7 (build/make) noltec,, kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede,, kbiof-0.3-1.fc8 (build/make) oddsocks,, kchmviewer-3.0-2.fc7 (build/make) pertusus,,jpo kcometen3-1.1-5.fc8 (build/make) oddsocks,, kdebase4-3.96.0-4.fc9 (build/make) kkofler,,rdieter,than kdelibs-3.5.8-7.fc8 (build/make) than,,rdieter,kkofler kdesdk-3.5.8-2.fc8 (build/make) than,,rdieter,kkofler kdesvn-0.14.1-1.fc9 (build/make) orion,, kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler kdiff3-0.9.92-10.fc9 (build/make) nbecker,, kdirstat-2.5.3-6.fc8 (build/make) chitlesh,, kdissert-1.0.7-1.fc7 (build/make) icon,, kdmtheme-1.2.1-1.fc9 (build/make) chitlesh,, kdocker-1.3-9.fc8 (build/make) rdieter,, keurocalc-0.9.7-3.fc8 (build/make) chitlesh,, kexec-tools-1.102pre-2.fc8 (build/make) nhorman,, kgtk-0.8-2.fc7 (build/make) faucamp,, kid3-0.9-2.fc8 (build/make) scop,, kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4,, kio_resources-0.2-3.fc8 (build/make) chitlesh,, klamav-0.41.1-6.fc9 (build/make) andriy,, klibido-0.2.5-8.fc8 (build/make) faucamp,, knetstats-1.6.1-4.fc8 (build/make) chitlesh,, komparator-0.8-1.fc8 (build/make) nbecker,, koverartist-0.5-8.fc8 (build/make) svahl,, kpolynome-0.1.2-10.fc8 (build/make) chitlesh,, kreetingkard-0.7.1-2.fc9 (build/make) mtasaka,, krename-3.0.14-2.fc8 (build/make) ecik,, kshutdown-1.0.1-1.fc8 (build/make) chitlesh,, ksirk-1.7-3.fc8 (build/make) jwrdegoede,, ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,,chitlesh ksynaptics-0.3.3-2.fc8 (build/make) orion,, ktechlab-0.3.69-5.fc8 (build/make) chitlesh,, ktorrent-2.2.4-1.fc9 (build/make) liquidat,,rdieter kyum-0.7.5-9.fc8 (build/make) s4504kr,, ladspa-1.12-8.fc7 (build/make) thomasvs,, lat-1.2.3-1.fc8 (build/make) pghmcfc,, ldapjdk-4.17-1jpp.7 (build/make) vivekl,, libXxf86dga-1.0.1-4.fc8 (build/make) ssp,, libapreq2-2.09-0.rc2.11.fc9 (build/make) bojan,, libchewing-0.3.0-8.fc8 (open_missing_mode) cchance,, libevent-1.3b-1.fc7 (build/make) steved,,ertzing libkexiv2-0.1.6-2.fc9 (build/make) rdieter,,mgarski libopensync-plugin-kdepim-0.22-2.fc8 (build/make) awjb,, libprelude-0.9.13-1.fc7 (build/make) tscherf,, libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf,, libsvm-2.84-6.fc8 (build/make) dchen,, libunwind-0.99-0.1.frysk20070405cvs.fc7 (build/make) jkratoch,, licq-1.3.4-8.fc9 (build/make) jmoskovc,, lilypond-doc-2.10.13-1.fc7 (build/make) qspencer,, lineak-kdeplugins-0.9-2.fc6 (build/make) xris,, ltrace-0.5-9.45svn.fc8 (build/make) pmachata,, lyx-1.5.2-1.fc8 (build/make) rdieter,,jamatos maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe,, maxima-5.13.0-10.fc9 (build/make) rdieter,,jamatos mbuffer-20070502-1.fc7 (open_missing_mode) adalloz,, mod_perl-2.0.3-14 (build/make) jorton,, module-init-tools-3.4-2.fc8 (build/make) jcm,, monodevelop-0.17-4.fc9 (build/make) pfj,, mosml-2.01-9.fc7 (build/make) gemi,, moto4lin-0.3-6.fc7 (build/make) jafo,, museek+-0.1.13-1.fc8 (build/make) belegdol,, mx4j-3.0.1-6jpp.4 (build/make) fnasser,, nemiver-0.4.0-1.fc8 (build/make) pgordon,, nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb,, ogre-1.4.5-3.fc9 (build/make) jwrdegoede,, openais-0.80.1-6 (open_missing_mode) sdake,,sdake openssh-4.7p1-4.fc9 (build/make) tmraz,, openvrml-0.16.7-1.fc9 (build/make) braden,, orange-0.3-5.cvs20051118.fc8 (build/make) awjb,, orpie-1.4.3-5.fc6 (build/make) xris,, ots-0.4.2-11.fc7 (build/make) pgordon,, pam_abl-0.2.3-3.fc7 (build/make) adalloz,, pari-2.3.0-5.fc7 (build/make) gemi,, pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo,, pdfedit-0.3.2-2.fc8 (build/make) bjohnson,, perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,,perl-sig,ghenry perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,,perl-sig perl-CGI-Session-4.20-2.fc7 (build/make) ixs,,perl-sig perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,,perl-sig perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,,perl-sig perl-Class-Observable-1.04-2.fc7 (build/make) ixs,,perl-sig perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,,perl-sig perl-Data-Password-1.07-1.fc7 (build/make) ixs,,perl-sig perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,,perl-sig perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,,perl-sig perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,,perl-sig perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,,perl-sig perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,,perl-sig perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,,perl-sig perl-DateTime-Set-0.25-4.fc7 (build/make) steve,,perl-sig perl-Devel-Caller-0.11-1.fc7 (build/make) steve,,perl-sig perl-Email-Date-1.102-3.fc8 (build/make) spot,,perl-sig perl-Email-Reply-1.202-1.fc8 (build/make) spot,,perl-sig perl-Exception-Class-1.23-3.fc7 (build/make) steve,,perl-sig perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,,perl-sig,laxathom perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,,perl-sig perl-File-Type-0.22-4.fc7 (build/make) steve,,perl-sig perl-GSSAPI-0.24-1.fc7 (build/make) steve,,perl-sig perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,,perl-sig perl-IO-All-0.38-1.fc7 (build/make) steve,,perl-sig perl-Imager-0.60-1.fc8 (build/make) steve,,ghenry perl-Kwiki-0.39-1.fc7 (build/make) steve,,perl-sig perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,,perl-sig perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,,perl-sig perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,,perl-sig perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,,perl-sig perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,,perl-sig perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,,perl-sig perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,,perl-sig perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,,perl-sig perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,,perl-sig perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,,perl-sig perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,,perl-sig perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,,perl-sig perl-Log-Message-0.01-3.fc7 (build/make) steve,,perl-sig perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,,perl-sig perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,,perl-sig perl-Module-Build-0.2808-1.fc8 (build/make) steve,,perl-sig perl-Module-Install-0.67-1.fc8 (build/make) steve,,perl-sig perl-Module-Loaded-0.01-3.fc7 (build/make) steve,,perl-sig perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,,perl-sig perl-MooseX-Getopt-0.05-1.fc8 (build/make) cweyl,,perl-sig perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,,perl-sig perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,,perl-sig perl-Object-Accessor-0.32-2.fc7 (build/make) steve,,perl-sig perl-OpenFrame-3.05-6.fc7 (build/make) steve,,perl-sig perl-PDL-2.4.3-4.fc8 (build/make) rnorwood,, perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,,perl-sig perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,,perl-sig perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,,perl-sig perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,,perl-sig perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,,perl-sig perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,,perl-sig perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,,perl-sig perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,,perl-sig perl-PPI-Tester-0.06-2.fc6 (build/make) spot,,perl-sig perl-Package-Constants-0.01-3.fc7 (build/make) steve,,perl-sig perl-Params-Check-0.26-1.fc7 (build/make) steve,,perl-sig perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,,perl-sig perl-Perl-MinimumVersion-0.15-1.fc9 (build/make) corsepiu,,perl-sig perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,,perl-sig perl-Pipeline-3.12-4.fc7 (build/make) steve,,perl-sig perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,,perl-sig perl-SUPER-1.16-1.fc7 (build/make) cweyl,,perl-sig perl-Set-Infinite-0.61-3.fc7 (build/make) steve,,perl-sig perl-Spiffy-0.30-7.fc7 (build/make) steve,,perl-sig perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,,perl-sig,mpeters perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,,perl-sig perl-Test-Expect-0.30-1.fc6 (build/make) cweyl,,perl-sig perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,,perl-sig perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,,perl-sig perl-Tk-804.027-12.fc8 (build/make) awjb,,perl-sig perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) spot,,perl-sig perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,,perl-sig perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,,perl-sig perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,,perl-sig perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,,perl-sig,oliver piklab-0.15.0-1.fc9 (build/make) chitlesh,,dionysos pikloops-0.2.5-1.fc9 (build/make) dionysos,, plague-0.4.4.1-4.fc7 (build/make) dcbw,, polyester-1.0.2-1.fc8 (build/make) svahl,, powerpc-utils-papr-1.0.4-2.fc9 (build/make) dwmw2,, ppc64-utils-0.13-1.fc9 (build/make) dcantrel,,dwmw2,pnasrat prelink-0.4.0-1 (build/make) jakub,, proftpd-1.3.1-1.fc8 (build/make) thias,, python-chm-0.8.4-1.fc7 (build/make) pertusus,, python-docs-2.5.1-1.fc8 (build/make) james,,katzj python-durus-3.5-3.fc7 (build/make) shahms,, python-psyco-1.5.1-5.fc7 (build/make) shahms,, python-pycurl-7.16.4-1.fc8 (build/make) jcollie,, python-quixote-2.4-5.fc7 (build/make) shahms,, python-simpletal-4.1-5.fc7 (build/make) shahms,, python-tag-0.91-5 (build/make) thias,, python-tpg-3.1.0-4.fc7 (build/make) shahms,, python-urljr-1.0.1-1.fc7 (build/make) jcollie,, pyzor-0.4.0-11.fc7 (build/make) ixs,, qa-assistant-0.4.90.5-2.fc6 (build/make) toshio,, qpidc-0.2-5.fc7 (build/make) aconway,,nsantos qpxtool-0.6.1-6.fc8 (build/make) drago01,, qscintilla-1.7.1-3.fc8 (build/make) rdieter,, qstars-0.4-3.fc8 (build/make) oddsocks,, qsynth-0.2.5-6.fc6 (build/make) nando,, qt-qsa-1.1.5-3.fc9 (build/make) belegdol,, qtparted-0.4.5-15.fc8 (build/make) steve,, quadkonsole-2.0.2-1.fc7 (build/make) nomis80,, qwtplot3d-0.2.7-4.fc8 (build/make) chitlesh,, rapidsvn-0.9.4-6.fc8 (build/make) timj,, rekall-2.4.5-6.fc8.1 (build/make) spot,, rhm-0.1-3.fc7 (build/make) aconway,,nsantos rkward-0.4.8-2.fc9 (build/make) pingou,, rosegarden4-1.5.1-1.fc7.1 (build/make) seg,, rsibreak-0.8.0-2.fc8 (build/make) liquidat,,rdieter ruby-bdb-0.6.0-1.fc7 (build/make) errr,, ruby-gnome2-0.16.0-16.fc9 (build/make) allisson,, sblim-cmpi-base-1.5.4-7.fc7 (build/make) hamzy,, scons-0.97-2.fc8 (build/make) gemi,, sdcc-2.6.0-10.fc7 (build/make) trondd,,jwrdegoede sdljava-0.9.1-6.fc9 (build/make) jwrdegoede,, seahorse-1.0.1-9.fc8 (build/make) skvidal,, six-0.5.3-6.fc8 (build/make) rafalzaq,, smart-0.52-51.fc9 (build/make) athimm,,scop subversion-1.4.4-7 (build/make) jorton,, svnmailer-1.0.8-3.fc7 (build/make) mfleming,, 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) spot,,pvrabec tastymenu-0.8.2-2.fc8 (build/make) nixaff4,, taxipilot-0.9.2-3.fc9 (build/make) jwrdegoede,, tclabc-1.0.9-1.fc7 (build/make) gemi,, tecnoballz-0.91-6.fc8 (build/make) musuruan,, tellico-1.2.14-2.fc8 (build/make) jamatos,, tetex-3.0-50.fc9 (build/make) jnovy,, tideEditor-1.4.1-1.fc8.3 (build/make) mtasaka,, tre-0.7.5-2.fc8 (build/make) rathann,, twinkle-1.1-3.fc8 (build/make) kevin,, unison-2.13.16-3.fc6 (build/make) gemi,, ustr-1.0.1-6.fc8 (build/make) james,, vbetool-0.7-3.fc9 (build/make) till,,pknirsch vnc-4.1.2-23.fc9 (build/make) atkac,, vtk-5.0.3-20.fc8 (build/make) athimm,, wesnoth-1.2.8-3.fc9 (build/make) bpepple,, xaos-3.2.3-1.fc7 (build/make) gemi,, xdaliclock-2.23-3.fc6 (build/make) kaboom,, xdrawchem-1.9.9-6.fc8 (build/make) rathann,, xfce4-battery-plugin-0.5.0-2.fc7 (build/make) cwickert,, 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-acecad-1.1.0-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-amd-0.0-22.20070625.fc8 (build/make) xgl-maint,, xorg-x11-drv-apm-1.1.1-7.fc8 (build/make) xgl-maint,, xorg-x11-drv-ark-0.6.0-6.fc8 (build/make) xgl-maint,, xorg-x11-drv-ast-0.81.0-6.fc8 (build/make) xgl-maint,, xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-chips-1.1.1-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-cirrus-1.1.0-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint,, xorg-x11-drv-cyrix-1.1.0-5.fc8 (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-glint-1.1.1-7.fc8 (build/make) xgl-maint,, xorg-x11-drv-i128-1.2.1-1.fc8 (build/make) xgl-maint,, xorg-x11-drv-i740-1.1.0-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-magellan-1.1.0-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-mga-1.4.6.1-6.fc8 (build/make) xgl-maint,, xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint,, xorg-x11-drv-neomagic-1.1.1-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-openchrome-0.2.900-7.fc9 (build/make) xavierb,, xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint,, xorg-x11-drv-rendition-4.1.3-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-s3-0.5.0-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-s3virge-1.9.1-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-savage-2.1.3-1.fc8 (build/make) xgl-maint,, xorg-x11-drv-siliconmotion-1.5.1-3.fc8 (build/make) xgl-maint,, xorg-x11-drv-sis-0.9.3-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-spaceorb-1.1.0-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-tdfx-1.3.0-6.fc8 (build/make) xgl-maint,, xorg-x11-drv-trident-1.2.3-6.fc8 (build/make) xgl-maint,, xorg-x11-drv-tseng-1.1.0-7.fc8 (build/make) xgl-maint,, xorg-x11-drv-vermilion-1.0.0-2.fc8 (build/make) xgl-maint,, xorg-x11-drv-vga-4.1.0-5.fc8 (build/make) xgl-maint,, xorg-x11-drv-via-0.2.2-4.fc8 (build/make) xgl-maint,, xorg-x11-drv-vmware-10.15.2-1.fc8 (build/make) xgl-maint,, xorg-x11-drv-voodoo-1.1.1-1.fc8 (build/make) xgl-maint,, xorg-x11-server-1.4.99.1-0.10.fc9 (build/make) xgl-maint,, xsupplicant-1.2.8-4.fc9.4 (build/make) spot,, yelp-2.20.0-8.fc9 (build/make) mbarnes,, zaptel-1.4.6-1.fc9 (build/make) jcollie,, With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dominik at greysector.net Sun Dec 2 14:28:55 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 2 Dec 2007 15:28:55 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <20071202142855.GC2974@ryvius.greysector.net> On Sunday, 02 December 2007 at 14:57, Matt Domsch wrote: > This is a full top-to-bottom rebuild of rawhide using mock 0.8.10 > running on 7 Fedora 8 builders. The rpmdiff results have been > enhanced to ignore dist tag mismatches, so every package now has an > rpmdiff comparsison against it's corresponding binary RPM in rawhide, > even if the dist tag has changed to .fc9 in this rebuild. [...] > tre-0.7.5-2.fc8 (build/make) rathann,, Can't fix. glibc bug: https://bugzilla.redhat.com/show_bug.cgi?id=371711 By the way, it would be nice if you sent only the relevant info in private mails to the maintainers. 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 shadowjksp at yahoo.se Sun Dec 2 14:37:27 2007 From: shadowjksp at yahoo.se (Jan Knutar) Date: Sun, 02 Dec 2007 16:37:27 +0200 Subject: mounting removable media never seems to work References: <474C5BA3.2070702@andrei.myip.org> Message-ID: <7isa25-fju.ln1@ludicrous.enivax.net> Florin Andrei wrote: > seems to stop working randomly, whenever the packages update to jour > changes something in the system. Package updates seem to kill hald on my Fedora install, with the most obvious symptom being that removable media stops mounting. Check whether hal and udev are running, and start with '/etc/init.d/haldaemon start' if it's not. From bloch at verdurin.com Sun Dec 2 13:58:14 2007 From: bloch at verdurin.com (Adam Huffman) Date: Sun, 2 Dec 2007 13:58:14 +0000 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <1196551547.9577.21.camel@localhost> References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> <1196551547.9577.21.camel@localhost> Message-ID: <20071202135814.GA9706@asus.config> On Sat, 01 Dec 2007, Callum Lerwick wrote: > > On Sat, 2007-12-01 at 22:11 +0000, Martin Ebourne wrote: > > I agree with you completely about the memory usage of Fedora 8, it has > > got VERY bloated recently. > > I remember when I popped 512mb into my system back around 2002. Was > running Red Hat 8 as I recall. I never, ever got the thing to use more > than half of it. No matter how many tabs I opened in Mozilla, no matter > how many kernels I compiled, I had a good 256mb worth of disk cache at > all times, and it never hit swap. I remember losing entire 100mb files > because that machine was a bit flaky and would hang sometimes, with the > file never being written to disk. I got into a habit of typing 'sync' a > few times after doing anything important, a habit I still have to this > day. > > So now I'm sitting on a laptop with 512mb, running Fedora 8. I'm running > Galeon and Evolution, and they're eating up 304M RAM and 428M swap. > I recently upgraded a 3 1/2 year old laptop with 512MiB to Fedora 8 and the level of memory usage when running nothing but Firefox seemed to cause frequent stalls when it was completely unresponsive for 30 seconds at a time. Admittedly this is only anecdotal evidence, but this doesn't happen on a newer one with 2GiB. From ml at deadbabylon.de Sun Dec 2 14:50:52 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 2 Dec 2007 15:50:52 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <200712021551.06091.ml@deadbabylon.de> Am So 2.Dezember 2007 schrieb Matt Domsch: > kalgebra-0.5-4.fc8 (build/make) chitlesh,, > katapult-0.3.2.1-2.fc8 (build/make) chitlesh,, > kbackup-0.5.2-1.fc8 (build/make) dionysos,, > kbibtex-0.1.5.52-10.fc7 (build/make) noltec,, > kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede,, > kbiof-0.3-1.fc8 (build/make) oddsocks,, > kchmviewer-3.0-2.fc7 (build/make) pertusus,,jpo > kcometen3-1.1-5.fc8 (build/make) oddsocks,, > kdesdk-3.5.8-2.fc8 (build/make) than,,rdieter,kkofler > kdesvn-0.14.1-1.fc9 (build/make) orion,, > kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler > kdiff3-0.9.92-10.fc9 (build/make) nbecker,, > kdirstat-2.5.3-6.fc8 (build/make) chitlesh,, > kdissert-1.0.7-1.fc7 (build/make) icon,, > kdmtheme-1.2.1-1.fc9 (build/make) chitlesh,, > kdocker-1.3-9.fc8 (build/make) rdieter,, > keurocalc-0.9.7-3.fc8 (build/make) chitlesh,, > kexec-tools-1.102pre-2.fc8 (build/make) nhorman,, > kgtk-0.8-2.fc7 (build/make) faucamp,, > kid3-0.9-2.fc8 (build/make) scop,, > kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4,, > kio_resources-0.2-3.fc8 (build/make) chitlesh,, > klamav-0.41.1-6.fc9 (build/make) andriy,, > klibido-0.2.5-8.fc8 (build/make) faucamp,, > knetstats-1.6.1-4.fc8 (build/make) chitlesh,, > komparator-0.8-1.fc8 (build/make) nbecker,, > koverartist-0.5-8.fc8 (build/make) svahl,, > kpolynome-0.1.2-10.fc8 (build/make) chitlesh,, > kreetingkard-0.7.1-2.fc9 (build/make) mtasaka,, > krename-3.0.14-2.fc8 (build/make) ecik,, > kshutdown-1.0.1-1.fc8 (build/make) chitlesh,, > ksirk-1.7-3.fc8 (build/make) jwrdegoede,, > ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,,chitlesh > ksynaptics-0.3.3-2.fc8 (build/make) orion,, > ktechlab-0.3.69-5.fc8 (build/make) chitlesh,, > ktorrent-2.2.4-1.fc9 (build/make) liquidat,,rdieter > kyum-0.7.5-9.fc8 (build/make) s4504kr,, There seems to be a change in newer mock versions: /etc/profile/qt.sh isn't sourced anymore and so the qt includes would not be found. It's still working in koji (with an older mock version?) I've only looked in some of the packages, they are not using this scriplet: unset QTDIR || : ; source /etc/profile.d/qt.sh At least my package (koverartist) builds again if I insert this scriplet. But IMHO this shouldn't be needed. Sebastian -------------- 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 Sun Dec 2 15:27:46 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 02 Dec 2007 16:27:46 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021551.06091.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> Message-ID: <4752CEF2.3000709@hhs.nl> Sebastian Vahl wrote: > Am So 2.Dezember 2007 schrieb Matt Domsch: >> kalgebra-0.5-4.fc8 (build/make) chitlesh,, >> katapult-0.3.2.1-2.fc8 (build/make) chitlesh,, >> kbackup-0.5.2-1.fc8 (build/make) dionysos,, >> kbibtex-0.1.5.52-10.fc7 (build/make) noltec,, >> kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede,, >> kbiof-0.3-1.fc8 (build/make) oddsocks,, >> kchmviewer-3.0-2.fc7 (build/make) pertusus,,jpo >> kcometen3-1.1-5.fc8 (build/make) oddsocks,, >> kdesdk-3.5.8-2.fc8 (build/make) than,,rdieter,kkofler >> kdesvn-0.14.1-1.fc9 (build/make) orion,, >> kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler >> kdiff3-0.9.92-10.fc9 (build/make) nbecker,, >> kdirstat-2.5.3-6.fc8 (build/make) chitlesh,, >> kdissert-1.0.7-1.fc7 (build/make) icon,, >> kdmtheme-1.2.1-1.fc9 (build/make) chitlesh,, >> kdocker-1.3-9.fc8 (build/make) rdieter,, >> keurocalc-0.9.7-3.fc8 (build/make) chitlesh,, >> kexec-tools-1.102pre-2.fc8 (build/make) nhorman,, >> kgtk-0.8-2.fc7 (build/make) faucamp,, >> kid3-0.9-2.fc8 (build/make) scop,, >> kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4,, >> kio_resources-0.2-3.fc8 (build/make) chitlesh,, >> klamav-0.41.1-6.fc9 (build/make) andriy,, >> klibido-0.2.5-8.fc8 (build/make) faucamp,, >> knetstats-1.6.1-4.fc8 (build/make) chitlesh,, >> komparator-0.8-1.fc8 (build/make) nbecker,, >> koverartist-0.5-8.fc8 (build/make) svahl,, >> kpolynome-0.1.2-10.fc8 (build/make) chitlesh,, >> kreetingkard-0.7.1-2.fc9 (build/make) mtasaka,, >> krename-3.0.14-2.fc8 (build/make) ecik,, >> kshutdown-1.0.1-1.fc8 (build/make) chitlesh,, >> ksirk-1.7-3.fc8 (build/make) jwrdegoede,, >> ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,,chitlesh >> ksynaptics-0.3.3-2.fc8 (build/make) orion,, >> ktechlab-0.3.69-5.fc8 (build/make) chitlesh,, >> ktorrent-2.2.4-1.fc9 (build/make) liquidat,,rdieter >> kyum-0.7.5-9.fc8 (build/make) s4504kr,, > > There seems to be a change in newer mock versions: /etc/profile/qt.sh isn't > sourced anymore and so the qt includes would not be found. It's still working > in koji (with an older mock version?) > > I've only looked in some of the packages, they are not using this scriplet: > unset QTDIR || : ; source /etc/profile.d/qt.sh > > At least my package (koverartist) builds again if I insert this scriplet. But > IMHO this shouldn't be needed. > Are you sure this what is happening? rawhide has kde4 now, so for kde3 based apps you need to change BR kdelibs-devel to kdelibs3-devel, have you done that? Regards, Hans From ndbecker2 at gmail.com Sun Dec 2 15:28:52 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 02 Dec 2007 10:28:52 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> <4752CEF2.3000709@hhs.nl> Message-ID: Hans de Goede wrote: > Sebastian Vahl wrote: >> Am So 2.Dezember 2007 schrieb Matt Domsch: >>> kalgebra-0.5-4.fc8 (build/make) chitlesh,, >>> katapult-0.3.2.1-2.fc8 (build/make) chitlesh,, >>> kbackup-0.5.2-1.fc8 (build/make) dionysos,, >>> kbibtex-0.1.5.52-10.fc7 (build/make) noltec,, >>> kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede,, >>> kbiof-0.3-1.fc8 (build/make) oddsocks,, >>> kchmviewer-3.0-2.fc7 (build/make) pertusus,,jpo >>> kcometen3-1.1-5.fc8 (build/make) oddsocks,, >>> kdesdk-3.5.8-2.fc8 (build/make) than,,rdieter,kkofler >>> kdesvn-0.14.1-1.fc9 (build/make) orion,, >>> kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler >>> kdiff3-0.9.92-10.fc9 (build/make) nbecker,, >>> kdirstat-2.5.3-6.fc8 (build/make) chitlesh,, >>> kdissert-1.0.7-1.fc7 (build/make) icon,, >>> kdmtheme-1.2.1-1.fc9 (build/make) chitlesh,, >>> kdocker-1.3-9.fc8 (build/make) rdieter,, >>> keurocalc-0.9.7-3.fc8 (build/make) chitlesh,, >>> kexec-tools-1.102pre-2.fc8 (build/make) nhorman,, >>> kgtk-0.8-2.fc7 (build/make) faucamp,, >>> kid3-0.9-2.fc8 (build/make) scop,, >>> kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4,, >>> kio_resources-0.2-3.fc8 (build/make) chitlesh,, >>> klamav-0.41.1-6.fc9 (build/make) andriy,, >>> klibido-0.2.5-8.fc8 (build/make) faucamp,, >>> knetstats-1.6.1-4.fc8 (build/make) chitlesh,, >>> komparator-0.8-1.fc8 (build/make) nbecker,, >>> koverartist-0.5-8.fc8 (build/make) svahl,, >>> kpolynome-0.1.2-10.fc8 (build/make) chitlesh,, >>> kreetingkard-0.7.1-2.fc9 (build/make) mtasaka,, >>> krename-3.0.14-2.fc8 (build/make) ecik,, >>> kshutdown-1.0.1-1.fc8 (build/make) chitlesh,, >>> ksirk-1.7-3.fc8 (build/make) jwrdegoede,, >>> ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,,chitlesh >>> ksynaptics-0.3.3-2.fc8 (build/make) orion,, >>> ktechlab-0.3.69-5.fc8 (build/make) chitlesh,, >>> ktorrent-2.2.4-1.fc9 (build/make) liquidat,,rdieter >>> kyum-0.7.5-9.fc8 (build/make) s4504kr,, >> >> There seems to be a change in newer mock versions: /etc/profile/qt.sh >> isn't sourced anymore and so the qt includes would not be found. It's >> still working in koji (with an older mock version?) >> >> I've only looked in some of the packages, they are not using this >> scriplet: unset QTDIR || : ; source /etc/profile.d/qt.sh >> >> At least my package (koverartist) builds again if I insert this scriplet. >> But IMHO this shouldn't be needed. >> > > Are you sure this what is happening? rawhide has kde4 now, so for kde3 > based apps you need to change BR kdelibs-devel to kdelibs3-devel, have you > done that? > > > Regards, > > Hans > Yes, I'm sure that's what's happening to my kdiff3 package. From ml at deadbabylon.de Sun Dec 2 15:40:04 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 2 Dec 2007 16:40:04 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <4752CEF2.3000709@hhs.nl> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> <4752CEF2.3000709@hhs.nl> Message-ID: <200712021640.10646.ml@deadbabylon.de> Am So 2.Dezember 2007 schrieb Hans de Goede: > Sebastian Vahl wrote: > > Am So 2.Dezember 2007 schrieb Matt Domsch: > >> kalgebra-0.5-4.fc8 (build/make) chitlesh,, > >> katapult-0.3.2.1-2.fc8 (build/make) chitlesh,, > >> kbackup-0.5.2-1.fc8 (build/make) dionysos,, > >> kbibtex-0.1.5.52-10.fc7 (build/make) noltec,, > >> kbilliards-0.8.7b-4.fc8 (build/make) jwrdegoede,, > >> kbiof-0.3-1.fc8 (build/make) oddsocks,, > >> kchmviewer-3.0-2.fc7 (build/make) pertusus,,jpo > >> kcometen3-1.1-5.fc8 (build/make) oddsocks,, > >> kdesdk-3.5.8-2.fc8 (build/make) than,,rdieter,kkofler > >> kdesvn-0.14.1-1.fc9 (build/make) orion,, > >> kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler > >> kdiff3-0.9.92-10.fc9 (build/make) nbecker,, > >> kdirstat-2.5.3-6.fc8 (build/make) chitlesh,, > >> kdissert-1.0.7-1.fc7 (build/make) icon,, > >> kdmtheme-1.2.1-1.fc9 (build/make) chitlesh,, > >> kdocker-1.3-9.fc8 (build/make) rdieter,, > >> keurocalc-0.9.7-3.fc8 (build/make) chitlesh,, > >> kexec-tools-1.102pre-2.fc8 (build/make) nhorman,, > >> kgtk-0.8-2.fc7 (build/make) faucamp,, > >> kid3-0.9-2.fc8 (build/make) scop,, > >> kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4,, > >> kio_resources-0.2-3.fc8 (build/make) chitlesh,, > >> klamav-0.41.1-6.fc9 (build/make) andriy,, > >> klibido-0.2.5-8.fc8 (build/make) faucamp,, > >> knetstats-1.6.1-4.fc8 (build/make) chitlesh,, > >> komparator-0.8-1.fc8 (build/make) nbecker,, > >> koverartist-0.5-8.fc8 (build/make) svahl,, > >> kpolynome-0.1.2-10.fc8 (build/make) chitlesh,, > >> kreetingkard-0.7.1-2.fc9 (build/make) mtasaka,, > >> krename-3.0.14-2.fc8 (build/make) ecik,, > >> kshutdown-1.0.1-1.fc8 (build/make) chitlesh,, > >> ksirk-1.7-3.fc8 (build/make) jwrdegoede,, > >> ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,,chitlesh > >> ksynaptics-0.3.3-2.fc8 (build/make) orion,, > >> ktechlab-0.3.69-5.fc8 (build/make) chitlesh,, > >> ktorrent-2.2.4-1.fc9 (build/make) liquidat,,rdieter > >> kyum-0.7.5-9.fc8 (build/make) s4504kr,, > > > > There seems to be a change in newer mock versions: /etc/profile/qt.sh > > isn't sourced anymore and so the qt includes would not be found. It's > > still working in koji (with an older mock version?) > > > > I've only looked in some of the packages, they are not using this > > scriplet: unset QTDIR || : ; source /etc/profile.d/qt.sh > > > > At least my package (koverartist) builds again if I insert this scriplet. > > But IMHO this shouldn't be needed. > > Are you sure this what is happening? rawhide has kde4 now, so for kde3 > based apps you need to change BR kdelibs-devel to kdelibs3-devel, have you > done that? Not yet for my package, you're right. But the QTDIR problem isn't affected by this. Maybe some of the packages above failed because of the BR change. But I'm not sure if this report is alreally affected by the kde4 inclusion (it's in rawhide since today). Sebastian -------------- 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 Sun Dec 2 15:44:05 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 2 Dec 2007 09:44:05 -0600 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021640.10646.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> <4752CEF2.3000709@hhs.nl> <200712021640.10646.ml@deadbabylon.de> Message-ID: <20071202154405.GA5917@auslistsprd01.us.dell.com> On Sun, Dec 02, 2007 at 04:40:04PM +0100, Sebastian Vahl wrote: > > Are you sure this what is happening? rawhide has kde4 now, so for kde3 > > based apps you need to change BR kdelibs-devel to kdelibs3-devel, have you > > done that? > > Not yet for my package, you're right. But the QTDIR problem isn't affected by > this. > Maybe some of the packages above failed because of the BR change. But I'm not > sure if this report is alreally affected by the kde4 inclusion (it's in > rawhide since today). These builds happened with a rawhide tree starting Friday. All failures were erased and rebuilt using Saturday's tree, so no, the KDE 3->4 conversion hadn't happened yet for this run. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ml at deadbabylon.de Sun Dec 2 15:44:30 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 2 Dec 2007 16:44:30 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021640.10646.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <4752CEF2.3000709@hhs.nl> <200712021640.10646.ml@deadbabylon.de> Message-ID: <200712021644.30344.ml@deadbabylon.de> Am So 2.Dezember 2007 schrieb Sebastian Vahl: > Not yet for my package, you're right. But the QTDIR problem isn't affected > by this. Or to be clear: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/koverartist-0.5-8.fc8.src.rpm/result/build.log checking for Qt... configure: error: Qt (>= Qt 3.2) (headers and libraries) not found. Please check your installation! For more details about this problem, look at the end of config.log. error: Bad exit status from /var/tmp/rpm-tmp.65393 (%build) Sebastian -------------- 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 ml at deadbabylon.de Sun Dec 2 15:54:17 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 2 Dec 2007 16:54:17 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021644.30344.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021640.10646.ml@deadbabylon.de> <200712021644.30344.ml@deadbabylon.de> Message-ID: <200712021654.17912.ml@deadbabylon.de> Am So 2.Dezember 2007 schrieb Sebastian Vahl: > Am So 2.Dezember 2007 schrieb Sebastian Vahl: > > Not yet for my package, you're right. But the QTDIR problem isn't > > affected by this. > > Or to be clear: > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/ >koverartist-0.5-8.fc8.src.rpm/result/build.log > > checking for Qt... configure: error: Qt (>= Qt 3.2) (headers and libraries) > not found. Please check your installation! > For more details about this problem, look at the end of config.log. > error: Bad exit status from /var/tmp/rpm-tmp.65393 (%build) > > > Sebastian The mail was send accidentally to early, sry. The missing parts: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/koverartist-0.5-8.fc8.src.rpm/result/build.log 2007-12-01 23:52:35,218 - DEBUG util.py, Line: 234: qt i386 1:3.3.8-11.fc9 fedora 3.5 M 2007-12-01 23:52:35,218 - DEBUG util.py, Line: 234: qt-devel i386 1:3.3.8-11.fc9 fedora 11 M -------------- 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 opensource at till.name Sun Dec 2 15:58:39 2007 From: opensource at till.name (Till Maas) Date: Sun, 02 Dec 2007 16:58:39 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <200712021658.50278.opensource@till.name> On So Dezember 2 2007, Matt Domsch wrote: > vbetool-0.7-3.fc9 (build/make) till,,pknirsch This is fixed now, but imho in the user list "ajax" is missing, he has commit and watchcommits rights for devel: https://admin.fedoraproject.org/pkgdb/packages/name/vbetool 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 andy at smile.org.ua Sun Dec 2 16:16:40 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Sun, 2 Dec 2007 18:16:40 +0200 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021551.06091.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> Message-ID: <20071202161640.GC32513@serv.smile.org.ua> Hi Sebastian Vahl! On Sun, Dec 02, 2007 at 03:50:52PM +0100, Sebastian Vahl wrote next: > > kdevelop-3.5.0-4.fc8 (build/make) than,,rdieter,kkofler > > There seems to be a change in newer mock versions: /etc/profile/qt.sh isn't > sourced anymore and so the qt includes would not be found. It's still working > in koji (with an older mock version?) > > I've only looked in some of the packages, they are not using this scriplet: > unset QTDIR || : ; source /etc/profile.d/qt.sh > > At least my package (koverartist) builds again if I insert this scriplet. But > IMHO this shouldn't be needed. 16:41 < _andy> rdieter, Did I miss heads-up? 16:41 < rdieter> apparently. we sent notices to fedora-devel, fedora-devel-announce, fedora-testers 16:42 < _andy> Could I use kdelibs3-devel in F-8 and/or F-7 ? 16:42 < rdieter> _andy: yes. 16:42 < _andy> rdieter, thnx 16:43 < rdieter> _andy: see "kde4 notice of rawhide doom" http://rdieter.livejournal.com/ for more references. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From j.w.r.degoede at hhs.nl Sun Dec 2 16:21:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 02 Dec 2007 17:21:51 +0100 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075642.A15743@humbolt.us.dell.com> References: <20071202075642.A15743@humbolt.us.dell.com> Message-ID: <4752DB9F.3070909@hhs.nl> Matt Domsch wrote: > This is a full top-to-bottom rebuild of rawhide using mock 0.8.10 > running on 7 Fedora 8 builders. The rpmdiff results have been > enhanced to ignore dist tag mismatches, so every package now has an > rpmdiff comparsison against it's corresponding binary RPM in rawhide, > even if the dist tag has changed to .fc9 in this rebuild. > First, let me stress how much I appreciate this effort, its a great service, I always check these to make sure all my 180 packages keep building, so that when its time for a mass rebuild I have a relatively easy job. With that said, could you please fix your scripts to do something smart when the build fails in such a way that there are no relevant results? These 5 have an almost emtpy build.log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/maniadrive-1.2-4.fc8.src.rpm/result/build.log http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/TnL-071111-1.fc9.src.rpm/result/build.log http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/raidem-0.3.1-7.fc8.src.rpm/result/build.log http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/scorched3d-41.1-1.fc9.src.rpm/result/build.log http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/sdljava-0.9.1-6.fc9.src.rpm/result/build.log They have in common that there seem to have been 2 attempts, one with an older version and one with the version linked to above, the builds with the older version have a completely empty result dir. Also interesting is bolzplatz2006, that is in your list of packages which failed to build, but it is not listed here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/ Most likely this is due to a race condition in your scripts, bolzplatz got added to rawhide around the time you did the rebuilts (and it built fine). Thanks & Regards, Hans From fedora at leemhuis.info Sun Dec 2 17:09:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 02 Dec 2007 18:09:58 +0100 Subject: ata and scsi modules in initrd (was: Re: Bootup speed for F8) In-Reply-To: <1196595060.4121.16.camel@oneill.fubar.dk> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> Message-ID: <4752E6E6.8020507@leemhuis.info> On 02.12.2007 12:31, David Zeuthen wrote: > > There's a host of other problems with mkinitrd that I won't go into > here. There is something about mkinitrd I'd like to bring up while we're discussing its problems here. Fedora afaics normally has a "hardware should just work" approach (which is a good thing). But why do we have only the modules in the initrd which are strictly needed on the system where the initrd was created? Shouldn't we put the most important ones into the inird and load them on demand if the root-fs could not be found with the default module? Sure, with the current approach the initrd is small. But if you take the harddisk and connect it to another storage controller or an motherboard with a different chipset vendor then in most cases Fedora won't boot there (ahci will hopefully solve that sooner or later, but that's a different topic). Heck, it's even worse: on those popular Intel chipsets (ICH5 and later) you can configure the integrated storage controller in different ways through the BIOS Setup. As you need different drivers depending on the settings you might run into situations like this sometimes: * you get your new computer where somebody enabled ahci in the BIOS Setup for you * you install F8 during which an initrd with the ahci module gets created * you have problems with the system and do a BIOS update (during which its settings from the BIOS Setup normally get reseted; thus ahci is off again and the storage controller gets a different PCI-ID) * you try to boot F8 and it won't find the root filesystem, because the module (ata_piix) with drives the chipsets storage controller in its default mode is missing in the initrd -> trouble that a lot of our users are unable to solve Cu knurd From Lam at Lam.pl Sun Dec 2 18:16:49 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 2 Dec 2007 19:16:49 +0100 Subject: ata and scsi modules in initrd (was: Re: Bootup speed for F8) In-Reply-To: <4752E6E6.8020507@leemhuis.info> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> Message-ID: <20071202191649.080d3e51@pensja.lam.pl> Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis napisa?(a): > * you try to boot F8 and it won't find the root filesystem, because the > module (ata_piix) with drives the chipsets storage controller in its > default mode is missing in the initrd -> trouble that a lot of our users > are unable to solve Happened to me after a BIOS upgrade, as well, but come on, the website specifically said something like "don't upgrade the BIOS yourself" and "don't mess with the BIOS unless you're sure the upgrade will fix something". And it took me 15 seconds to switch to AHCI mode and boot Fedora again. And it's probably not a problem for new users of the chipset, because they'll never have to switch to AHCI in order to install Fedora (which was the case some time ago). On the other hand, the answer to many of such problems is simply "use rescue image". You can try to run kudzu from there or something. It's not THAT hard. To summarize, it's not a big deal, and I can't imagine having EVERY storage driver in the initrd just in case someone replugs the disk between two very rare controllers. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Sun Dec 2 18:21:51 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 2 Dec 2007 11:21:51 -0700 Subject: [Fedora-legal-list] DJB's software components In-Reply-To: <475266F0.5030902@codewiz.org> References: <1196432626.9238.1.camel@localhost.localdomain> <1196440081.9238.7.camel@localhost.localdomain> <475266F0.5030902@codewiz.org> Message-ID: <20071202112151.74407895@ghistelwchlohm.scrye.com> On Sun, 02 Dec 2007 03:04:00 -0500 bernie at codewiz.org (Bernardo Innocenti) wrote: > Tom "spot" Callaway wrote: > > > And the answer is that we are fine to pick these up. Hold lifted. > > Nice! Is anyone working on packaging qmail already? I have a set of qmail src.rpms that I was thinking of polishing off and submitting. I'm not sure how many people really are interested in it at this point though... qmail has some pretty bad behavior for a modern MTA, like not having ability to reject invalid recipients at SMTP time and instead generating a bounce message for each. I suppose if no one beats me to it I could submit my packages so they are available for anyone interested in them. 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 Dec 2 18:39:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 2 Dec 2007 13:39:31 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202110544.GC3312@free.fr> References: <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: <20071202133931.69c7e322@redhat.com> On Sun, 2 Dec 2007 12:05:44 +0100 Patrice Dumas wrote: > End-users also expect a package install not to drag in packages that > are not useful. Especially system administrator end-users who care > about avoiding bloat. Installing everything may be confusing too, not > for a user who just don't care about what is installed on his > computer but for a user who want to keep control. The problem is that "not useful" is subjective, extremely so. Since we don't have smolt sending brainwave signatures so that we can tap in and determine what you really need at install time, we make "best guesses" and err on the side of usability rather than the alternatives where you have to constantly play the game of "oh, you want to do /that/ with your app, you need to install this subpackage, that subpackage, this other seemingly unrelated package, and that over there 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 fedora at leemhuis.info Sun Dec 2 18:50:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 02 Dec 2007 19:50:36 +0100 Subject: ata and scsi modules in initrd In-Reply-To: <20071202191649.080d3e51@pensja.lam.pl> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> Message-ID: <4752FE7C.5080406@leemhuis.info> On 02.12.2007 19:16, Leszek Matok wrote: > Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis > napisa?(a): > >> * you try to boot F8 and it won't find the root filesystem, because the >> module (ata_piix) with drives the chipsets storage controller in its >> default mode is missing in the initrd -> trouble that a lot of our users >> are unable to solve > Happened to me after a BIOS upgrade, as well, but come on, the website > specifically said something like "don't upgrade the BIOS yourself" and "don't > mess with the BIOS unless you're sure the upgrade will fix something". Sure, but there are good reasons to update the BIOS now and then. > And it took me 15 seconds to switch to AHCI mode and boot Fedora again. If you know about it. What do ordinary users do that don't know about such things that got told by a "good" friend to update the BIOS? > [...] > On the other hand, the answer to many of such problems is simply "use rescue > image". You can try to run kudzu from there or something. It's not THAT hard. I want it to just work. Isn't that what we aim for normally? The reason why we install drivers or firmware for nearly all hardware by default, even if it consumes a disk space? > To summarize, it's not a big deal, and I can't imagine having EVERY storage > driver in the initrd just in case someone replugs the disk between two very > rare controllers. I didn't say we should have all modules in the initrd. But having the most common would IMHO a good thing. Cu knurd From drago01 at gmail.com Sun Dec 2 19:03:20 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 2 Dec 2007 20:03:20 +0100 Subject: ata and scsi modules in initrd In-Reply-To: <4752FE7C.5080406@leemhuis.info> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: [..] > I didn't say we should have all modules in the initrd. But having the > most common would IMHO a good thing. +1 for having all pata/sata drivers in the initrd by default. From ville.skytta at iki.fi Sun Dec 2 19:04:56 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 2 Dec 2007 21:04:56 +0200 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <200712021551.06091.ml@deadbabylon.de> References: <20071202075752.A16094@humbolt.us.dell.com> <200712021551.06091.ml@deadbabylon.de> Message-ID: <200712022104.57160.ville.skytta@iki.fi> On Sunday 02 December 2007, Sebastian Vahl wrote: > I've only looked in some of the packages, they are not using this scriplet: > unset QTDIR || : ; source /etc/profile.d/qt.sh > > At least my package (koverartist) builds again if I insert this scriplet. > But IMHO this shouldn't be needed. How so? profile.d snippets pulled in through build dependencies need to be explicitly sourced in specfiles to take effect for the build, that has always been the case and I don't know how it could be sanely avoided. From packages at amiga-hardware.com Sun Dec 2 19:17:39 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 02 Dec 2007 19:17:39 +0000 Subject: ata and scsi modules in initrd In-Reply-To: <4752FE7C.5080406@leemhuis.info> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: <475304D3.6000903@amiga-hardware.com> Thorsten Leemhuis wrote: >> To summarize, it's not a big deal, and I can't imagine having EVERY storage >> driver in the initrd just in case someone replugs the disk between two very >> rare controllers. > > I didn't say we should have all modules in the initrd. But having the > most common would IMHO a good thing. Imaging would be another thing that would benefit from this. We like to have identical images even though the hardware can vary quite considerably. 99% of the time this isn't an issue because the hardware is detected dynamically and largely requires no manual intervention, but this is one minor area that sometimes requires a bit of manual intervention. A work around at the moment is to add an alias in /etc/modprobe.conf on the master image for every disk controller type we use, when the kernel is installed it pulls in the appropriate modules so that it doesn't matter what controller the target is using. -- Ian Chapman. From jdieter at gmail.com Sun Dec 2 19:24:31 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 02 Dec 2007 21:24:31 +0200 Subject: ata and scsi modules in initrd In-Reply-To: References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: <1196623471.5074.2.camel@jndwidescreen.lesbg.loc> On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote: > [..] > > I didn't say we should have all modules in the initrd. But having the > > most common would IMHO a good thing. > > +1 for having all pata/sata drivers in the initrd by default. > The whole kernel/drivers/ata directory is 1.2MB for 2.6.23.1-49.fc8. My initrd is already 3.6MB. Another 1.2MB won't hurt. +1 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 christoph.wickert at nurfuerspam.de Sun Dec 2 19:38:36 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sun, 02 Dec 2007 20:38:36 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <1196624316.3966.12.camel@wicktop.localdomain> Am Sonntag, den 02.12.2007, 07:57 -0600 schrieb Matt Domsch: > Of those expected to have worked... > Without a bug filed: 366 > ---------------------------------- ... > emelfm2-0.3.5-2.fc8 (build/make) cwickert,, fixed now in 0.3.6. 0.3.5 wasn't compatible with gtk2 2.12 Christoph From louisg00 at bellsouth.net Sun Dec 2 19:55:36 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sun, 02 Dec 2007 14:55:36 -0500 Subject: firefox vs epiphany Message-ID: <1196625336.2547.4.camel@tiger> What is the reasoning for making firefox the default instead of epiphany for the gnome desktop? Does epiphany lack certain features? -Thanks From pertusus at free.fr Sun Dec 2 20:06:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 2 Dec 2007 21:06:44 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202133931.69c7e322@redhat.com> References: <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> <20071202133931.69c7e322@redhat.com> Message-ID: <20071202200644.GA3177@free.fr> On Sun, Dec 02, 2007 at 01:39:31PM -0500, Jesse Keating wrote: > On Sun, 2 Dec 2007 12:05:44 +0100 > Patrice Dumas wrote: > > > End-users also expect a package install not to drag in packages that > > are not useful. Especially system administrator end-users who care > > about avoiding bloat. Installing everything may be confusing too, not > > for a user who just don't care about what is installed on his > > computer but for a user who want to keep control. > > > The problem is that "not useful" is subjective, extremely so. Since we > don't have smolt sending brainwave signatures so that we can tap in and > determine what you really need at install time, we make "best guesses" > and err on the side of usability rather than the alternatives where you > have to constantly play the game of "oh, you want to do /that/ with > your app, you need to install this subpackage, that subpackage, this > other seemingly unrelated package, and that over there too." I am not saying that we want fine grained split for every package, I say that it has merits in term of avoiding bloat. And also that there are may categories of end-users, some that want to avoid selecting packages, other who prefer selecting packages. And that in the end it is up to the packager. -- Pat From jima at beer.tclug.org Sun Dec 2 20:52:04 2007 From: jima at beer.tclug.org (Jima) Date: Sun, 2 Dec 2007 14:52:04 -0600 (CST) Subject: Guidelines for creating subpackages? In-Reply-To: <20071202110544.GC3312@free.fr> References: <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: On Sun, 2 Dec 2007, Patrice Dumas wrote: > End-users also expect a package install not to drag in packages that are > not useful. Especially system administrator end-users who care about > avoiding bloat. Installing everything may be confusing too, not for a > user who just don't care about what is installed on his computer but for > a user who want to keep control. Man. We have such a rough job. "Fedora doesn't install enough packages! You're being mean to sysadmins!" "Fedora installs too many packages! You're being mean to sysadmins!" What's worse is that we haven't changed _anything_ between these two complaints. I guess it goes to show that whatever we do, someone's going to be unhappy. Jima (Oops, forgot to send this earlier.) From bojan at rexursive.com Sun Dec 2 21:11:35 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 03 Dec 2007 08:11:35 +1100 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <1196629895.15509.46.camel@shrek.rexursive.com> On Sun, 2007-12-02 at 07:57 -0600, Matt Domsch wrote: > libapreq2-2.09-0.rc2.11.fc9 (build/make) bojan,, This failed to build due to a bug introduced in apr-util-1.2.12-1 by yours truly (MySQL libraries were part of APRUTIL_LDFLAGS). 1.2.12-2 is being built now, with a proper fix, hopefully. I'm guessing there will be other packages that failed similarly. Apologies... :-( -- Bojan From promac at gmail.com Sun Dec 2 21:22:22 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 2 Dec 2007 19:22:22 -0200 Subject: mock 0.8.9 Message-ID: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> I am trying to use mock 0.8. Executing a simple man mock, gives me: SYNTAX mock [options] --rebuild SRPM [SRPM...] mock [options] --chroot mock [options] {--init|clean|shell} mock [options] --installdeps {SRPM|RPM} mock [options] --install PACKAGE ---------------------------------------------------------- In fact, mock -r fedora-8-i386 --init does not work at all. It must be: mock -r fedora-8-i386 init Therefore, I think that an update for man mock (0.8.9) is in order, right? It was this way in mock 0.7. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkundrak at redhat.com Sun Dec 2 21:40:27 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 02 Dec 2007 22:40:27 +0100 Subject: firefox vs epiphany In-Reply-To: <1196625336.2547.4.camel@tiger> References: <1196625336.2547.4.camel@tiger> Message-ID: <1196631627.15639.10.camel@localhost.localdomain> On Sun, 2007-12-02 at 14:55 -0500, Louis E Garcia II wrote: > What is the reasoning for making firefox the default instead of epiphany > for the gnome desktop? Does epiphany lack certain features? It does. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Sun Dec 2 21:41:37 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 02 Dec 2007 22:41:37 +0100 Subject: mock 0.8.9 In-Reply-To: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> Message-ID: <1196631697.15639.12.camel@localhost.localdomain> On Sun, 2007-12-02 at 19:22 -0200, Paulo Cavalcanti wrote: > In fact, > > mock -r fedora-8-i386 --init > > does not work at all. It must be: > > mock -r fedora-8-i386 init Certainly a bug. > Therefore, I think that an update for man mock (0.8.9) is in order, > right? Right. Please open a bug report in bugzilla: http://bugzilla.redhat.com/ Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From martin.sourada at seznam.cz Sun Dec 2 21:41:01 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 02 Dec 2007 22:41:01 +0100 Subject: firefox vs epiphany In-Reply-To: <1196625336.2547.4.camel@tiger> References: <1196625336.2547.4.camel@tiger> Message-ID: <1196631661.3350.5.camel@pc-notebook.kolej.mff.cuni.cz> On Sun, 2007-12-02 at 20:55 +0100, Louis E Garcia II wrote: > What is the reasoning for making firefox the default instead of epiphany > for the gnome desktop? Does epiphany lack certain features? > > -Thanks > I believe that as epiphany requires firefox it is saner to have firefox as default. This could however IMHO change once the epiphany will be built against xulrunner. IMHO, if it will be smaller than firefox, as in how much MB will it need, we should use it at least in the desktop live spin. At least for me the only functionality it lacks is absence of sane session saving (you need to killall epiphany to make it remember the session). Martin From lsof at nodata.co.uk Sun Dec 2 22:28:33 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 02 Dec 2007 23:28:33 +0100 Subject: firefox vs epiphany In-Reply-To: <1196631627.15639.10.camel@localhost.localdomain> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> Message-ID: <1196634513.2849.0.camel@sb-home> Am Sonntag, den 02.12.2007, 22:40 +0100 schrieb Lubomir Kundrak: > On Sun, 2007-12-02 at 14:55 -0500, Louis E Garcia II wrote: > > What is the reasoning for making firefox the default instead of epiphany > > for the gnome desktop? Does epiphany lack certain features? > > It does. > > -- > Lubomir Kundrak (Red Hat Security Response Team) Care to enlighten us? From lkundrak at redhat.com Sun Dec 2 22:37:22 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 02 Dec 2007 23:37:22 +0100 Subject: firefox vs epiphany In-Reply-To: <1196634513.2849.0.camel@sb-home> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> Message-ID: <1196635042.15639.14.camel@localhost.localdomain> On Sun, 2007-12-02 at 23:28 +0100, nodata wrote: > Am Sonntag, den 02.12.2007, 22:40 +0100 schrieb Lubomir Kundrak: > > On Sun, 2007-12-02 at 14:55 -0500, Louis E Garcia II wrote: > > > What is the reasoning for making firefox the default instead of epiphany > > > for the gnome desktop? Does epiphany lack certain features? > > > > It does. > > > > -- > > Lubomir Kundrak (Red Hat Security Response Team) > > Care to enlighten us? No. There is enough documentation available. -- Lubomir Kundrak (Red Hat Security Response Team) From alan at redhat.com Sun Dec 2 23:06:18 2007 From: alan at redhat.com (Alan Cox) Date: Sun, 2 Dec 2007 18:06:18 -0500 Subject: firefox vs epiphany In-Reply-To: <1196635042.15639.14.camel@localhost.localdomain> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> Message-ID: <20071202230618.GA30301@devserv.devel.redhat.com> On Sun, Dec 02, 2007 at 11:37:22PM +0100, Lubomir Kundrak wrote: > > Care to enlighten us? > No. > There is enough documentation available. That strikes me as rude, and inappropriate. It's also not the way to win a discussion point. Alan From tonynelson at georgeanelson.com Sun Dec 2 23:15:24 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sun, 2 Dec 2007 18:15:24 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: <20071202110544.GC3312@free.fr> References: <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: At 12:05 PM +0100 12/2/07, Patrice Dumas wrote: >On Sun, Dec 02, 2007 at 11:51:27AM +0100, Denis Leroy wrote: >> >> I feel the most important thing must remain ease of installation for >> end-users. If you "yum install foo", you expect foo to be fully working >> after installation (and how many dependencies it pulls is not necessarily >> important if you're using yum directly). Remember we don't really have a >> mechanism in place to say "since you just installed foo, you should really >> consider installing foo-extras, foo-extensions and foo-plugins as well. > >End-users also expect a package install not to drag in packages that are >not useful. Especially system administrator end-users who care about >avoiding bloat. Installing everything may be confusing too, not for a >user who just don't care about what is installed on his computer but for >a user who want to keep control. Perhaps if there were a new form of dependency, where a package would be installed iff all packages that, umm, "co-require" it were installed. So then (pulling a bogus example out of my rear) Python bindings for GTK2 would only be installed if both Python and GTK2 were installed, and yum would install it when installing the last of the co-dependent packages. This new thing would require much package splitting and tweaking of co-requires to be useful. In the case of -devel packages (though I don't personally mind very much when such a package pulls in other packages), would it be reasonable in most cases to just not have them require any other packages? Most of them are headers, which will be useful during compilation whether or not the resulting binary can run, but the source that uses them probably already pulls in whatever of those other packages it actually needs. I would think. (Anyway, co-requires will save me here!) -- ____________________________________________________________________ TonyN.:' ' From lordmorgul at gmail.com Sun Dec 2 23:43:00 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 02 Dec 2007 15:43:00 -0800 Subject: What's your opinion on using alternatives for mesa-libGL(U)? In-Reply-To: <1196529544.3587.9.camel@Diffingo.localdomain> References: <1196529544.3587.9.camel@Diffingo.localdomain> Message-ID: <47534304.3050508@gmail.com> Stewart Adam wrote: > Hi, > > I'm wondering what you're opinions/arguments for or against using > alternatives to symlink the libraries of mesa-libGL and mesa-libGLU. I think changing anything in regard to libraries should only be done for 'good reason' and with MAJOR PR to make sure people know. The symlink plan has been working fine for a long time, with massive amounts of help forums, faqs, etc, out there for people. The proprietary ati/nvidia drivers currently install that way, and the packaged versions others have done (livna) are the same. -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From loupgaroublond at gmail.com Sun Dec 2 23:44:10 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 2 Dec 2007 18:44:10 -0500 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201121141.GB3017@free.fr> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: <7f692fec0712021544k26cb53edhdc0b1fb7f97c0ad4@mail.gmail.com> On Dec 2, 2007 6:15 PM, Tony Nelson wrote: > Perhaps if there were a new form of dependency, where a package would be > installed iff all packages that, umm, "co-require" it were installed. So > then (pulling a bogus example out of my rear) Python bindings for GTK2 > would only be installed if both Python and GTK2 were installed, and yum > would install it when installing the last of the co-dependent packages. > This new thing would require much package splitting and tweaking of > co-requires to be useful. +1 > In the case of -devel packages (though I don't personally mind very much > when such a package pulls in other packages), would it be reasonable in > most cases to just not have them require any other packages? Most of them > are headers, which will be useful during compilation whether or not the > resulting binary can run, but the source that uses them probably already > pulls in whatever of those other packages it actually needs. I would > think. (Anyway, co-requires will save me here!) Why shouldn't devel packages pull in a boatload of requirements? If i make a graphical wrapper around say gnome-devel, it would make my life easier writing a spec file to just say 'gnome-devel' and know everything is included. IMHO, build environments tend to be very heavy, and require alot of resources anyways. -Yaakov From lordmorgul at gmail.com Mon Dec 3 00:00:03 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 02 Dec 2007 16:00:03 -0800 Subject: Guidelines for creating subpackages? In-Reply-To: <47528E2F.1050203@poolshark.org> References: <20071201081729.62750@gmx.net> <20071201121141.GB3017@free.fr> <20071201133311.73550516@pensja.lam.pl> <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> Message-ID: <47534703.8030006@gmail.com> Denis Leroy wrote: > I feel the most important thing must remain ease of installation for > end-users. If you "yum install foo", you expect foo to be fully working > after installation (and how many dependencies it pulls is not > necessarily important if you're using yum directly). Remember we don't > really have a mechanism in place to say "since you just installed foo, > you should really consider installing foo-extras, foo-extensions and > foo-plugins as well. Creation of dummy metadata packages (i.e. payload-less packages that simply have requires and provides metadata) works as is... the package maintainer for foo could simply create a 'foo-complete' package that has all the others required. But at the same time, the user who wants only foo and foo-extensions could get them if they choose. > And then there's installing from pirut. If I want to install clamav, I > open up pirut and search for "clamav". I get 17 packages. Which one do I > have to install to have a sufficient setup ? Splitting packages to make > dependencies easier to manager is a good idea, but first we may want to > think about ways to make this less confusing to the end user. When I > search for clamav, I'd like to see a big red line for the main clamav > installation line (with all the dependencies it will pull hidden from > view), and a side panel with a list of optional packages (plugins and > al) with descriptions. Do we have enough metadata right now to produce > something like this ? The metadata is certainly there, with the packages that require the one you're trying to install, or require something it provides (i.e. clamav). The issue is development of those frontend UIs that handle these things sanely... and with more features, options, views, and sub-lists. To make it happen right now would probably require more dependency handling/processing time though, making the applications even slower. -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Mon Dec 3 00:13:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 02 Dec 2007 19:13:34 -0500 Subject: firefox vs epiphany In-Reply-To: <20071202230618.GA30301@devserv.devel.redhat.com> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> Message-ID: <1196640814.3665.0.camel@localhost.localdomain> On Sun, 2007-12-02 at 18:06 -0500, Alan Cox wrote: > On Sun, Dec 02, 2007 at 11:37:22PM +0100, Lubomir Kundrak wrote: > > > Care to enlighten us? > > No. > > There is enough documentation available. > > That strikes me as rude, and inappropriate. It's also not the way to win > a discussion point. It is also not the reason for firefox being the default. From jon.nettleton at gmail.com Mon Dec 3 00:51:14 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 02 Dec 2007 19:51:14 -0500 Subject: firefox vs epiphany In-Reply-To: <1196640814.3665.0.camel@localhost.localdomain> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> <1196640814.3665.0.camel@localhost.localdomain> Message-ID: <1196643074.26642.11.camel@averatec> On Sun, 2007-12-02 at 19:13 -0500, Matthias Clasen wrote: > On Sun, 2007-12-02 at 18:06 -0500, Alan Cox wrote: > > On Sun, Dec 02, 2007 at 11:37:22PM +0100, Lubomir Kundrak wrote: > > > > Care to enlighten us? > > > No. > > > There is enough documentation available. > > > > That strikes me as rude, and inappropriate. It's also not the way to win > > a discussion point. > > It is also not the reason for firefox being the default. > I will try to add something constructive here. I think the main point of contention people have with epiphany is that, a) it lacks the brand recognition of firefox and b) it doesn't easily support firefox plugins/extensions. I switched to epiphany for F7 and personally I have no interest in going back. Everything that it lacks is trumped by the integration with the gnome desktop. I will say that my acceptance and enlightenment was only achieved through patience. I think using epiphany as a default for the desktop spin should be re-evaluated once it can be backended by either xulrunner or webkit. Really I think that decisions like this will be won by the community providing re-spins that offer alternatives. Jon From seg at haxxed.com Mon Dec 3 01:10:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Dec 2007 19:10:40 -0600 Subject: ata and scsi modules in initrd In-Reply-To: References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: <1196644240.16569.22.camel@localhost> On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote: > [..] > > I didn't say we should have all modules in the initrd. But having the > > most common would IMHO a good thing. > > +1 for having all pata/sata drivers in the initrd by default. One of the things that used to make Linux superior to Windows is the fact that you could pop out a hard drive and plug it into an entirely different machine, and it would Just Work. Well, except for X. Stupid X. But at least you could boot it, switch the X driver and be done with it. But then initrds were introduced, and now we're baking in system specifics into it. Now I have all kinds of trouble with drivers not being found, and volume groups not being found. Only solution is to boot a rescue disk and rebuild the initrd, using an incredibly arcane series of commands. I pity the n00b who tries to upgrade their system. And Windows has gotten worse in this regard too. Back in the days of Win95/98, you could ALWAYS, at the very least, boot the system into rescue mode, go into the device manager, select the PCI bus and remove it. This forced it to rescan and reload all the drivers. 5-10 reboots later, bam, you're done. But now with Windows XP, if you change the motherboard out from under it, its quite likely to not boot. At all. Not even rescue mode. You're screwed. You have to re-install from scratch. Supposedly there's a way to "reseal" Windows XP, but you have to do it *before* you switch the board. I was unaware of this method until it was too late so I didn't get a chance to try it. And no, I'm even using a copy of XP Pro which is free of activation bullshit. I pity the fool who buys a legitimate XP. (And no, I do in fact have a legitimate XP Pro license, it came stuck to the bottom of my (used) laptop :) http://www.motherboard.windowsreinstall.com/winxp.htm#Solution%204:% 20Microsoft%20SYSPREP%A0 -------------- 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 Dec 3 01:16:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 2 Dec 2007 20:16:54 -0500 Subject: firefox vs epiphany In-Reply-To: <1196643074.26642.11.camel@averatec> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> <1196640814.3665.0.camel@localhost.localdomain> <1196643074.26642.11.camel@averatec> Message-ID: <20071202201654.0a86d17b@redhat.com> On Sun, 02 Dec 2007 19:51:14 -0500 Jon Nettleton wrote: > Everything that it lacks is trumped by the integration with the > gnome desktop. I had the exact opposite. I tried epiphany and I could find no compelling reason to continue using it. I couldn't find one single thing that it brought to the table that I either already got with Firefox, or just plain didn't find useful. What do you mean by "integration" in this context, particularly beyond what FF gets us. -- 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 Mon Dec 3 01:22:19 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 02 Dec 2007 20:22:19 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075642.A15743@humbolt.us.dell.com> References: <20071202075642.A15743@humbolt.us.dell.com> Message-ID: <1196644939.3665.9.camel@localhost.localdomain> On Sun, 2007-12-02 at 07:56 -0600, Matt Domsch wrote: > alacarte-0.11.3-4.fc8 (build/make) rstrode,jpmahowa,sindrepb Hmm, the package has a BR against python, but the build log says: sh: /usr/bin/python: No such file or directory From wtogami at redhat.com Mon Dec 3 02:01:30 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 02 Dec 2007 21:01:30 -0500 Subject: ata and scsi modules in initrd In-Reply-To: References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: <4753637A.20900@redhat.com> dragoran wrote: > [..] >> I didn't say we should have all modules in the initrd. But having the >> most common would IMHO a good thing. > > +1 for having all pata/sata drivers in the initrd by default. > Has anyone checked how much larger this would make a typical initrd image? The experimental bash-branch of mkinitrd has a simple for loop to load all available kernel modules matching available PCI devices, so we could possibly load the drivers dynamically. But then actually using the devices that appear to boot might be more challenging, unless the device names haven't changed since mkinitrd time. Warren Togami wtogami at redhat.com From jon.nettleton at gmail.com Mon Dec 3 02:23:21 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 02 Dec 2007 21:23:21 -0500 Subject: firefox vs epiphany In-Reply-To: <20071202201654.0a86d17b@redhat.com> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> <1196640814.3665.0.camel@localhost.localdomain> <1196643074.26642.11.camel@averatec> <20071202201654.0a86d17b@redhat.com> Message-ID: <1196648601.26642.29.camel@averatec> On Sun, 2007-12-02 at 20:16 -0500, Jesse Keating wrote: > On Sun, 02 Dec 2007 19:51:14 -0500 > Jon Nettleton wrote: > > > Everything that it lacks is trumped by the integration with the > > gnome desktop. > > I had the exact opposite. I tried epiphany and I could find no > compelling reason to continue using it. I couldn't find one single > thing that it brought to the table that I either already got with > Firefox, or just plain didn't find useful. > > What do you mean by "integration" in this context, particularly beyond > what FF gets us. Let me clarify, in no particular order 1) Visual integration. Epiphany always matches the rest of my desktops applications. Some people might say "eh", but I find it much nicer. 2) When I am not connected to a network Epiphany goes to offline mode. 3) Right clicking and choosing view image launches eog where I can actually zoom in and see the image. I mean how useless is this feature in firefox? Select view image and it opens another enormous window showing the image at exactly the same size. 4) Possibly the thing that I love more than anything is the "Most Visited" topic pull-down. I bookmark sites, and the browser automatically keeps track of what I connect to most and gives me a nice pull down list. Don't get me wrong, I still use Firefox for serious development and the like. I just find the simplicity of epiphany quite nice for day to day browsing. Jon From peter at thecodergeek.com Mon Dec 3 03:34:44 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 02 Dec 2007 19:34:44 -0800 Subject: firefox vs epiphany In-Reply-To: <1196635042.15639.14.camel@localhost.localdomain> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> Message-ID: <1196652884.982.6.camel@tuxhugs> On Sun, 2007-12-02 at 23:37 +0100, Lubomir Kundrak wrote: > > Care to enlighten us? > No. > > There is enough documentation available. Therein lies your problem. An argument which lacks evidence is inherently an incorrect one; and as the source of that argument, the burden of proof lies with you and you alone. What feature(s) does Epiphany not have which Firefox does? -- 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 Mon Dec 3 04:00:32 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 2 Dec 2007 23:00:32 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <1196644939.3665.9.camel@localhost.localdomain> References: <20071202075642.A15743@humbolt.us.dell.com> <1196644939.3665.9.camel@localhost.localdomain> Message-ID: <20071203040032.GH8224@psilocybe.teonanacatl.org> Matthias Clasen wrote: > > On Sun, 2007-12-02 at 07:56 -0600, Matt Domsch wrote: > >> alacarte-0.11.3-4.fc8 (build/make) rstrode,jpmahowa,sindrepb > > Hmm, the package has a BR against python, but the build log > says: > > sh: /usr/bin/python: No such file or directory (After checking in irc that I wasn't totally missing the obvious...) This is just a red herring caused by rpm evaluating the python_sitelib define at the top of the spec file to rebuild the srpm prior to installing the build deps. Mock rebuilds the srpm in the chroot, then uses that srpm to parse the build deps and install them before doing the actual build. (If I have that grossly wrong, hopefully I'll be corrected. :) Anyway, the more important failure with the alacart build is at the tail end of the build.log: RPM build errors: File not found: /var/tmp/alacarte-0.11.3-4.fc9-root-mockbuild/usr/lib/python2.5/site-packages/Alacarte Installed (but unpackaged) file(s) found: /usr/lib64/python2.5/site-packages/Alacarte/MainWindow.py [...] -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Years ago fairy tales all began with "Once upon a time...", now we know they all begin with, "If I am elected..." -- Carolyn Warner -------------- 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 Mon Dec 3 04:19:33 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 2 Dec 2007 23:19:33 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071203040032.GH8224@psilocybe.teonanacatl.org> References: <20071202075642.A15743@humbolt.us.dell.com> <1196644939.3665.9.camel@localhost.localdomain> <20071203040032.GH8224@psilocybe.teonanacatl.org> Message-ID: <20071203041932.GI8224@psilocybe.teonanacatl.org> > Anyway, the more important failure with the alacart build is at the > tail end of the build.log: > > RPM build errors: > File not found: /var/tmp/alacarte-0.11.3-4.fc9-root-mockbuild/usr/lib/python2.5/site-packages/Alacarte > Installed (but unpackaged) file(s) found: > /usr/lib64/python2.5/site-packages/Alacarte/MainWindow.py > [...] Looking closer, the alacarte package defines python_sitelib, which will be /usr/lib/python2.5/site-packages, while the alacarte source installs to $(pyexedir), which is /usr/lib64... I'm not sure if there is a good reason for the install to be in the arch dependent dir. It looks to me like that may be an upstream Makefile.am bug. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pick battles big enough to matter, yet small enough to win. --Jonathan Kozol -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From mharris at mharris.ca Mon Dec 3 04:24:27 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Sun, 02 Dec 2007 23:24:27 -0500 Subject: firefox vs epiphany In-Reply-To: <1196652884.982.6.camel@tuxhugs> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> Message-ID: <475384FB.7070809@mharris.ca> Peter Gordon wrote: > On Sun, 2007-12-02 at 23:37 +0100, Lubomir Kundrak wrote: >>> Care to enlighten us? >> No. >> >> There is enough documentation available. > Therein lies your problem. An argument which lacks evidence is > inherently an incorrect one; and as the source of that argument, the > burden of proof lies with you and you alone. What feature(s) does > Epiphany not have which Firefox does? Not picking any sides here, but I find this "conclusion" kindof funny. Epiphany it seems to me from briefly experimenting with it a few times, and from watching discussions about it over time - seems to be intended on having the look and feel of the GNOME desktop, including the minimalistic nature of most GNOME applications. The "KISS" principle seems to be part of the design. Firefox on the other hand has quite a few features built into it, and does not seem to be developed with minimalistic design goals per se. I honestly don't think someone really needs to prove a statement like was given above, simply because anyone can simply run both epiphany and firefox side by side, peruse the pulldown menus of both applications, and go through the preferences dialogs of both applications on a 'feature quest' per se. and see everything for themselves very easily. I'd be surprised if the mozilla.org website for firefox doesn't list a 'feature list', and equally surprised if the GNOME website for epiphany didn't list a feature list. So, while I can't give specific proof either way to someone that firefox has more features than epiphany, nor vice versa, my understanding is that epiphany intends to be a simpler browser than firefox and by definition wont have the full rich set of features firefox has. The burden of proof for such statements doesn't really lay on the person making the statements, but rather on who wants to know bad enough to go do the research themselves. ;o) I just poked around with epiphany a few minutes ago before writing this, and found it lacks various features that I would consider "must have" for my own personal use, which firefox has, and that's ignoring the plethora of existing firefox plugins I use currently. If I add the firefox plugins I use, epiphany becomes much less attractive to me. Mind you, in no way am I trying to "prove" anything to anyone else in saying so, nor do I feel the need to. I'm perfectly happy just continuing to use that which works best for me, and which meets my own needs, and avoiding epiphany, which very much does not meet my needs, and I figure the original poster above probably feels the same way. ;o) Ultimately, which browser should be the default depends on the overall goals of the distribution, and should take into account all sorts of criteria. Said "criteria" is going to be coming from very different groups of users with very very different goals and requirements. There will never be one solution that is going to please everybody really. The browser usage statistics freely available over the net more or less speak for themselves though IMHO. -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From david at lovesunix.net Mon Dec 3 04:38:32 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 03 Dec 2007 05:38:32 +0100 Subject: firefox vs epiphany In-Reply-To: <475384FB.7070809@mharris.ca> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> Message-ID: <1196656712.4386.9.camel@Watson.lovesunix.net> s?n, 02 12 2007 kl. 23:24 -0500, skrev Mike A. Harris: > The browser usage statistics freely available over the net more or less > speak for themselves though IMHO. So we should be using IE? It's the most used browser afterall, and this argument only helps to keep Firefox on the basis that it's always been in the lead of the open source browsers so it must be best. I use Epiphany, it does what I need without looking out of place, it integrates nicely and it launches much faster. It lacks a few things but it also leverages a lot of nice features (seemless integration with GNOME, adopts theme, icons. Has more consistent translations which don't break with version upgrades) and it has a powerful plugin system so we can expand it in interesting ways. - David From michel.sylvan at gmail.com Mon Dec 3 04:44:28 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 2 Dec 2007 23:44:28 -0500 Subject: firefox vs epiphany In-Reply-To: <1196625336.2547.4.camel@tiger> References: <1196625336.2547.4.camel@tiger> Message-ID: On 02/12/2007, Louis E Garcia II wrote: > What is the reasoning for making firefox the default instead of epiphany > for the gnome desktop? Does epiphany lack certain features? > No one has brought it up, but as far as I know, mugshot (part of the upcoming GNOME Online Desktop) depends on Firefox. I'm not sure if this is still the case, the RPM does not seem to declare a dependency on any libraries supplied by Firefox. Regards, -- Michel Salim http://hircus.jaiku.com/ From loupgaroublond at gmail.com Mon Dec 3 04:47:28 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 2 Dec 2007 23:47:28 -0500 Subject: firefox vs epiphany In-Reply-To: <1196625336.2547.4.camel@tiger> References: <1196625336.2547.4.camel@tiger> Message-ID: <7f692fec0712022047nb71b51bib5b3eae93e0ceab0@mail.gmail.com> On Dec 2, 2007 2:55 PM, Louis E Garcia II wrote: > What is the reasoning for making firefox the default instead of epiphany > for the gnome desktop? Does epiphany lack certain features? 125 million users can't be wrong ;) http://john.jubjubs.net/2007/11/27/mozilla-firefox-market-share/ -Yaakov From the.masch at gmail.com Mon Dec 3 04:53:43 2007 From: the.masch at gmail.com (masch) Date: Sun, 2 Dec 2007 23:53:43 -0500 Subject: Proposal for Fedora 9 - Games-Emulator-Snes Message-ID: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> Hi! What about games on Fedora? Is it possible to include ZSnes emulator en fedora repos.? The home pages it's: http://www.zsnes.com/ and the program it's hosted in soundforge i'm think there is not problem with legal issues. Salu2... From seg at haxxed.com Mon Dec 3 04:57:06 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Dec 2007 22:57:06 -0600 Subject: firefox vs epiphany In-Reply-To: <1196656712.4386.9.camel@Watson.lovesunix.net> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> Message-ID: <1196657826.17392.10.camel@localhost> On Mon, 2007-12-03 at 05:38 +0100, David Nielsen wrote: > I use Epiphany, it does what I need without looking out of place, it > integrates nicely and it launches much faster. It lacks a few things but > it also leverages a lot of nice features (seemless integration with > GNOME, adopts theme, icons. Has more consistent translations which don't > break with version upgrades) and it has a powerful plugin system so we > can expand it in interesting ways. Epiphany can't seem to block cookies like Galeon can. I have it set so it accepts session cookies, but blocks all long term cookies. This keeps most sites functional. From there I can easily white list sites that I *want* to be able to store cookies with a single click, i.e. all the sites I actually log in to. Keeps my disk untainted by doubleclick bugs and whatnot, while not hurting usability on the sites I actually use. And I'm not constantly nagged about accepting cookies. Galeon is clearly the superior browser. I demand it be made default! I AM THE COMMUNITY! -------------- 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 jdieter at gmail.com Mon Dec 3 05:04:05 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 03 Dec 2007 07:04:05 +0200 Subject: firefox vs epiphany In-Reply-To: <1196631661.3350.5.camel@pc-notebook.kolej.mff.cuni.cz> References: <1196625336.2547.4.camel@tiger> <1196631661.3350.5.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <1196658245.5074.10.camel@jndwidescreen.lesbg.loc> On Sun, 2007-12-02 at 22:41 +0100, Martin Sourada wrote: > I believe that as epiphany requires firefox it is saner to have firefox > as default. This could however IMHO change once the epiphany will be > built against xulrunner. IMHO, if it will be smaller than firefox, as in > how much MB will it need, we should use it at least in the desktop live > spin. > > At least for me the only functionality it lacks is absence of sane > session saving (you need to killall epiphany to make it remember the > session). On our school system, we offer both firefox and epiphany (with epiphany being the default). In Sabayon (Gnome's user profile editor), Firefox integration leaves much to be desired. Any attempts to set bookmarks don't get properly saved and you are also unable to save whether or not certain toolbars are shown (does anyone actually *use* the Bookmarks toolbar). Firefox also takes a relatively long time to start and it's awkward to use when students are logged into more than one computer at a time. On the flip side, Epiphany is missing the search window and all Firefox extensions, which means that I really prefer Firefox for my use. If Epiphany would include the search window, that would probably be enough for me to use it for everyday things. 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 loupgaroublond at gmail.com Mon Dec 3 05:09:38 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 3 Dec 2007 00:09:38 -0500 Subject: Proposal for Fedora 9 - Games-Emulator-Snes In-Reply-To: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> References: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> Message-ID: <7f692fec0712022109g6ba839fcp7b196a328757c5b7@mail.gmail.com> On Dec 2, 2007 11:53 PM, masch wrote: > Hi! > What about games on Fedora? Is it possible to include ZSnes emulator > en fedora repos.? > The home pages it's: http://www.zsnes.com/ and the program it's hosted > in soundforge i'm think there is not problem with legal issues. I am not in charge of these decisions, so I can't give you an answer, but I can give you a few questions that might help you. 1) Is the code entirely unencumbered by patents in the US. That is to say, by emulating an aspect of the SNES system, it emulates a patented algorithm that is verboten. 2) Are there any ROMs that are likewise patent and copyright unencumbered that can also be distributed with Fedora? If there aren't, it's hard to see why Z-SNES would be usable in Fedora. If you can't answer yes to both of these questions, I would say the best place to look to package zsnes would be 'that other repository'. (I'll give you a hint, it's name is Livna). They package many things that can't go into Fedora directly. If you live outside of the US, you personally will likely have no legal issues to worry about. -Yaakov From ericsbinaryworld at gmail.com Mon Dec 3 05:09:42 2007 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Mon, 03 Dec 2007 00:09:42 -0500 Subject: firefox vs epiphany In-Reply-To: <7f692fec0712022047nb71b51bib5b3eae93e0ceab0@mail.gmail.com> References: <1196625336.2547.4.camel@tiger> <7f692fec0712022047nb71b51bib5b3eae93e0ceab0@mail.gmail.com> Message-ID: <47538F96.5000802@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yaakov Nemoy wrote: > On Dec 2, 2007 2:55 PM, Louis E Garcia II > wrote: >> What is the reasoning for making firefox the default instead of >> epiphany for the gnome desktop? Does epiphany lack certain >> features? > > 125 million users can't be wrong ;) > > http://john.jubjubs.net/2007/11/27/mozilla-firefox-market-share/ > > -Yaakov > I think what makes the most sense is to have Firefox as the default as that's all the newbies will care about. Can you imagine. "This linux distro doesn't even have Firefox? What kind of lame distro is this!" There's nothing to stop anyone who knows better from installing Epiphany. I started using it a while back and I love it. In fact, it had "Places" way before Firefox 3. It also appears to load a lot faster and not bog down my computer as much as Firefox. I'm also not an add-on junkie. The latest extensions for Epiphany in Fedora 8, which includes GreaseMonkey, should probably cover most people. However, if you're heavy on the extension use, you should not use Epiphany. Like any other choice in FOSS, it comes down to you using whatever you want. That's the beauty of the overwhelming number of choices. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHU4+WPvU+8ApmWXIRAur9AKCmIvvBR3MBCrrn4mKrxVPwV91EkACcC5kl hWUr13idCA4DzjhnkI+2eMI= =GBwt -----END PGP SIGNATURE----- From ericsbinaryworld at gmail.com Mon Dec 3 05:11:10 2007 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Mon, 03 Dec 2007 00:11:10 -0500 Subject: Proposal for Fedora 9 - Games-Emulator-Snes In-Reply-To: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> References: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> Message-ID: <47538FEE.3090105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 masch wrote: > Hi! What about games on Fedora? Is it possible to include ZSnes > emulator en fedora repos.? The home pages it's: > http://www.zsnes.com/ and the program it's hosted in soundforge i'm > think there is not problem with legal issues. > > > Salu2... > There is a repository that includes all the emulators you could ever want. I'm too lazy to look it up now, but you can just add it and it has Zsnes. I use it with a Fedora 8 machine hooked up to my tv. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHU4/tPvU+8ApmWXIRAiThAKCCrQ9BM5NSRfQJjVBVvgGEtvGQ2ACgyPVZ a3r6dZOqadhIOogr0EDluX4= =ZsBg -----END PGP SIGNATURE----- From seg at haxxed.com Mon Dec 3 05:36:23 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Dec 2007 23:36:23 -0600 Subject: Proposal for Fedora 9 - Games-Emulator-Snes In-Reply-To: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> References: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> Message-ID: <1196660183.17392.17.camel@localhost> On Sun, 2007-12-02 at 23:53 -0500, masch wrote: > Hi! > What about games on Fedora? Is it possible to include ZSnes emulator > en fedora repos.? > The home pages it's: http://www.zsnes.com/ and the program it's hosted > in soundforge i'm think there is not problem with legal issues. Last I checked zsnes was written in 99% i386 assembly. Not a showstopper, I guess, but something to be aware of. Its not cross-platform. But its fast. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Michael_E_Brown at dell.com Mon Dec 3 06:11:46 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 00:11:46 -0600 Subject: mock 0.8.9 In-Reply-To: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> Message-ID: <20071203061145.GF4039@humbolt.us.dell.com> On Sun, Dec 02, 2007 at 07:22:22PM -0200, Paulo Cavalcanti wrote: > I am trying to use mock 0.8. > > Executing a simple man mock, gives me: > > SYNTAX > mock [options] --rebuild SRPM [SRPM...] > > mock [options] --chroot > > mock [options] {--init|clean|shell} > > mock [options] --installdeps {SRPM|RPM} > > mock [options] --install PACKAGE > > ---------------------------------------------------------- > > In fact, > > mock -r fedora-8-i386 --init > > does not work at all. It must be: > > mock -r fedora-8-i386 init > > Therefore, I think that an update for man mock (0.8.9) is in order, right? > It was this way in mock 0.7. This was something I overlooked and it is fixed in 0.8.10 already, which should be making its way to testing repos. -- Michael From chris.stone at gmail.com Mon Dec 3 06:15:16 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 2 Dec 2007 22:15:16 -0800 Subject: Proposal for Fedora 9 - Games-Emulator-Snes In-Reply-To: <47538FEE.3090105@gmail.com> References: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> <47538FEE.3090105@gmail.com> Message-ID: On Dec 2, 2007 9:11 PM, Eric Mesa wrote: > There is a repository that includes all the emulators you could ever > want. I'm too lazy to look it up now, but you can just add it and it > has Zsnes. I use it with a Fedora 8 machine hooked up to my tv. http://fedoranews.org/mediawiki/index.php/Fedora_Weekly_News_Issue_62#Announcing_Dribble_a_new_addon_repo From mharris at mharris.ca Mon Dec 3 06:45:08 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 03 Dec 2007 01:45:08 -0500 Subject: firefox vs epiphany In-Reply-To: <1196656712.4386.9.camel@Watson.lovesunix.net> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> Message-ID: <4753A5F4.8010109@mharris.ca> David Nielsen wrote: > s?n, 02 12 2007 kl. 23:24 -0500, skrev Mike A. Harris: > >> The browser usage statistics freely available over the net more or less >> speak for themselves though IMHO. > > So we should be using IE? It's the most used browser afterall, and this > argument only helps to keep Firefox on the basis that it's always been > in the lead of the open source browsers so it must be best. IE is not an open source web browser, nor is it available for Linux, so there are two important reasons why IE is not feasible for use as the default web browser in Fedora. Not sure why you think IE should be the default for Fedora, but I've seen people suggest stranger things so... > I use Epiphany, it does what I need without looking out of place, it > integrates nicely and it launches much faster. It lacks a few things but > it also leverages a lot of nice features (seemless integration with > GNOME, adopts theme, icons. Has more consistent translations which don't > break with version upgrades) and it has a powerful plugin system so we > can expand it in interesting ways. I think it is great that Epiphany meets your needs, and I encourage you to use it if you find it to your preference. -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From the.masch at gmail.com Mon Dec 3 06:54:02 2007 From: the.masch at gmail.com (masch) Date: Mon, 3 Dec 2007 01:54:02 -0500 Subject: Proposal for Fedora 9 - Games-Emulator-Snes In-Reply-To: References: <93d66b780712022053g14998272o6f4754947912a771@mail.gmail.com> <47538FEE.3090105@gmail.com> Message-ID: <93d66b780712022254h6b4fbfe0l2d1c937a80fc2fe1@mail.gmail.com> Woooow!.. Thanks so much...this is what i'm looking for!... Thanks! Salu2... On Dec 3, 2007 1:15 AM, Christopher Stone wrote: > On Dec 2, 2007 9:11 PM, Eric Mesa wrote: > > There is a repository that includes all the emulators you could ever > > want. I'm too lazy to look it up now, but you can just add it and it > > has Zsnes. I use it with a Fedora 8 machine hooked up to my tv. > > http://fedoranews.org/mediawiki/index.php/Fedora_Weekly_News_Issue_62#Announcing_Dribble_a_new_addon_repo > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mharris at mharris.ca Mon Dec 3 06:54:28 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 03 Dec 2007 01:54:28 -0500 Subject: firefox vs epiphany In-Reply-To: <1196657826.17392.10.camel@localhost> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> Message-ID: <4753A824.6090006@mharris.ca> Callum Lerwick wrote: > On Mon, 2007-12-03 at 05:38 +0100, David Nielsen wrote: >> I use Epiphany, it does what I need without looking out of place, it >> integrates nicely and it launches much faster. It lacks a few things but >> it also leverages a lot of nice features (seemless integration with >> GNOME, adopts theme, icons. Has more consistent translations which don't >> break with version upgrades) and it has a powerful plugin system so we >> can expand it in interesting ways. > > Epiphany can't seem to block cookies like Galeon can. I have it set so > it accepts session cookies, but blocks all long term cookies. This keeps > most sites functional. From there I can easily white list sites that I > *want* to be able to store cookies with a single click, i.e. all the > sites I actually log in to. I use the "Cookie Safe" plugin for Firefox for cookie management, which is pretty cool. It puts a nice icon in the firefox status bar which you can use to easily allow cookies on a site temporily, for session, or permanently, or revoke it at any time at the click of a mouse button or so, as well as the ability to view/remove individual cookies, and various other useful things. While Cookie Safe is very flexible and powerful, and is very easy to use mind you, the overwhelming majority of users out there probably never need this level of functionality - but then that's why it's an addon, and not built right in to firefox I guess. ;o) Unsure how it adds up to what is available for Galeon or Epiphany though. > Keeps my disk untainted by doubleclick bugs and whatnot, while not > hurting usability on the sites I actually use. And I'm not constantly > nagged about accepting cookies. Yup, I use AdBlock Plus to get rid of all the ad-noise online, and also as a side effect for web browser stability because a lot of the advertising out there is flash based and causes browser crashes whenever flash does something bad. With Cookie Safe, I have browser cookies totally disabled by default everywhere, and when I find a site that I actually *want* to set cookies on, I just click on the cookiesafe icon in the status bar, and then click on "Allow cookies from foo.com", or if it is a site that requires cookies, but which I don't want to just allow it always, I will choose "Allow cookies temporarily for foo.com", and when I'm done I usually go back and deny them again rather than waiting for session end. It's much easier to do it right there while looking at the page, than it is to go into Firefox's default cookie management which is buried deep in the preferences dialog hierarchy. I'm quite an anti-cookie junkie though too, and I suspect most users just accept them by default and aren't concerned about their privacy or whether they're being tracked by big evil advertising corporations, etc. > Galeon is clearly the superior browser. I demand it be made default! I > AM THE COMMUNITY! Hehe. I always liked Galeon. It's small and cute and pretty quick. I use it once in a while for some things, but it could never be my primary browser per se. -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From lordmorgul at gmail.com Mon Dec 3 06:58:01 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 02 Dec 2007 22:58:01 -0800 Subject: Bootup speed for F8 In-Reply-To: <1196556618.31181.7.camel@Diffingo.localdomain> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <1196523133.5807.3.camel@Diffingo.localdomain> <1196556618.31181.7.camel@Diffingo.localdomain> Message-ID: <4753A8F9.8010807@gmail.com> Stewart Adam wrote: > On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote: >> Depends on how you define boot time. If you say boot is done when the >> system is interactive, you cut several seconds. >> >> "Other OS:es" obviously use this approach, the perceptual being what >> matters. >> >> Surely, this must be fixable, it'd be such a boost.. >> >> Linus > That's exactly what I mean - An early login can make the boot seem to > boot much faster even if it really isn't. Waiting is what makes things > seem long; the faster the user interacts, the faster things seem. > > Stewart Sure thats true, but perception is also just a fake improvement, and once the user gets used to seeing the login earlier... they'll get more and more discontent with how long it takes to be usable after they logged in (afterall they *already logged in*). For a great example of why this can be frustrating, install a copy of Vista; its 'boot time' is great, but you login and wait... and wait... and wait. When you do see the desktop you still can't do anything useful with it because the system is still so heavily loaded with background processes starting. Its much the same with xp, but vista made it even worse, while the 'boot time' is even lower. I have always appreciated the fact that a machine thats STARTED in linux can be logged into quickly and be useful with minimal delay. The general case with windows which delays many background processes until login is that you can boot your system and walk away to get coffee... but when you come back you'll still sit there waiting after login before you can work. I'm only bringing up the windows comparison for contrast, because MS has been working hard to bring about this same early login illusion. Making the system *actually usable* sooner is where development time and effort should be spent rather than spending time to fake it. If a valid argument can be made for a method to get desktop software to begin processing earlier due to early login then lets talk about that. If its nothing more than login without letting CPU cycles go toward the desktop startup then why bother? -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mharris at mharris.ca Mon Dec 3 07:09:27 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 03 Dec 2007 02:09:27 -0500 Subject: firefox vs epiphany In-Reply-To: <1196658245.5074.10.camel@jndwidescreen.lesbg.loc> References: <1196625336.2547.4.camel@tiger> <1196631661.3350.5.camel@pc-notebook.kolej.mff.cuni.cz> <1196658245.5074.10.camel@jndwidescreen.lesbg.loc> Message-ID: <4753ABA7.6060507@mharris.ca> Jonathan Dieter wrote: > On Sun, 2007-12-02 at 22:41 +0100, Martin Sourada wrote: >> I believe that as epiphany requires firefox it is saner to have firefox >> as default. This could however IMHO change once the epiphany will be >> built against xulrunner. IMHO, if it will be smaller than firefox, as in >> how much MB will it need, we should use it at least in the desktop live >> spin. >> >> At least for me the only functionality it lacks is absence of sane >> session saving (you need to killall epiphany to make it remember the >> session). > > On our school system, we offer both firefox and epiphany (with epiphany > being the default). In Sabayon (Gnome's user profile editor), Firefox > integration leaves much to be desired. Any attempts to set bookmarks > don't get properly saved and you are also unable to save whether or not > certain toolbars are shown (does anyone actually *use* the Bookmarks > toolbar). Firefox also takes a relatively long time to start and it's > awkward to use when students are logged into more than one computer at a > time. Ever since Netscape acquired the Personal Bookmark Toolbar, I have created hierarchial folders of bookmarks, with the primary categories of bookmarks being directly on the personal toolbar. I do not ever create any bookmarks that are not on the toolbar or subfolders of the toolbar, and I've often wondered if anyone else out there ever set bookmarks outside of the bookmark toolbar. ;o) I just assumed everyone used the bookmark toolbar exclusively (in any web browser) by default for ages now due to the great utility it provides. Perhaps I was wrong, and there's one person out there who doesn't use it. Doh! ;o) Using the "Foxmarks" firefox addon, I synchronize my firefox bookmarks to a local ftp server (http and https also supported), and share bookmarks between all of my computers running firefox, including sharing between operating systems. So my bookmark toolbar is unified throughout the house. Works great. > On the flip side, Epiphany is missing the search window and all Firefox > extensions, which means that I really prefer Firefox for my use. If > Epiphany would include the search window, that would probably be enough > for me to use it for everyday things. Yeah, if Epiphany could use all firefox extensions, and include all of the features firefox has which I use that Epiphany doesn't have, it'd probably be something I could try using for everyday productivity. ;o) Mind you, Epiphany is great for doing a quick search online, or for reading a recipe while preparing a meal, with less memory overhead than firefox. That leaves a lot more memory for nautilus to gobble up rather than having to wait a bit longer for swap thrashing while nautilus gets swapped out when firefox loads. ;o) -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From nicu_fedora at nicubunu.ro Mon Dec 3 07:44:21 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 03 Dec 2007 09:44:21 +0200 Subject: firefox vs epiphany In-Reply-To: <475384FB.7070809@mharris.ca> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> Message-ID: <4753B3D5.1090102@nicubunu.ro> Mike A. Harris wrote: > I just poked around with epiphany a few minutes ago before writing this, > and found it lacks various features that I would consider "must have" > for my own personal use, which firefox has, and that's ignoring the > plethora of existing firefox plugins I use currently. If I add the > firefox plugins I use, epiphany becomes much less attractive to me. Mind > you, in no way am I trying to "prove" anything to anyone else in saying > so, nor do I feel the need to. I'm perfectly happy just continuing to > use that which works best for me, and which meets my own needs, and > avoiding epiphany, which very much does not meet my needs, and I figure > the original poster above probably feels the same way. ;o) > > Ultimately, which browser should be the default depends on the overall > goals of the distribution, and should take into account all sorts of > criteria. Said "criteria" is going to be coming from very different > groups of users with very very different goals and requirements. There > will never be one solution that is going to please everybody really. While I *really* try to migrate from Firefox to Epiphany with each GNOME/Fedora release and fail each time, going back to FF for whatever missing feature, I think this is a discuss worth having: for other cases (like BitTorrent, where the default was changed to Transmission, which I absolutely love) we have by default the simpler, "less featured", but better integrated and easier to use application, leaving for the expert user, who need the extra-features, to change the default. -- 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 leemhuis.info Mon Dec 3 07:58:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 08:58:05 +0100 Subject: What's your opinion on using alternatives for mesa-libGL(U)? In-Reply-To: <47534304.3050508@gmail.com> References: <1196529544.3587.9.camel@Diffingo.localdomain> <47534304.3050508@gmail.com> Message-ID: <4753B70D.1050702@leemhuis.info> On 03.12.2007 00:43, Andrew Farris wrote: > Stewart Adam wrote: >> I'm wondering what you're opinions/arguments for or against using >> alternatives to symlink the libraries of mesa-libGL and mesa-libGLU. > I think changing anything in regard to libraries should only be done for 'good > reason' and with MAJOR PR to make sure people know. Well, "making it just work" is IMHO a very good reason, because there are some apps out there that only with with LD_PRELOAD hacks (which livna/generally should be avoided for reasons I can't remember right now) because the apps have a rpath to /usr/lib/libGL.so.1 hardcoded, thus the livna tricks with shipping the amd/ati or nvidia libGL in a different path and adjusting the dynamic linker search patch via /etc/ld.so.conf.d doesn't work. > The symlink plan has been > working fine for a long time, with massive amounts of help forums, faqs, etc, > out there for people. What do you mean with "symlink plan"? > The proprietary ati/nvidia drivers currently install that > way, ati/nvidia last time I checked replaced the /usr/lib/libGL.so.* files; thus if the package mesa-libGL from fedora gets updated it will break, as it will overwrite that stuff. > and the packaged versions others have done (livna) are the same. Livna doesn't touch /usr/lib/libGL.so.* ; see above for what livna does right now. Cu knurd From fedora at leemhuis.info Mon Dec 3 08:43:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 09:43:30 +0100 Subject: ata and scsi modules in initrd In-Reply-To: <1196644240.16569.22.camel@localhost> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <1196644240.16569.22.camel@localhost> Message-ID: <4753C1B2.6020901@leemhuis.info> On 03.12.2007 02:10, Callum Lerwick wrote: > On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote: >> [..] >>> I didn't say we should have all modules in the initrd. But having the >>> most common would IMHO a good thing. >> +1 for having all pata/sata drivers in the initrd by default. > One of the things that used to make Linux superior to Windows is the > fact that you could pop out a hard drive and plug it into an entirely > different machine, and it would Just Work. strong +1 > Well, except for X. Stupid X. Which is getting fixed afaik, so it should "just work" in the future as well. > [...] > But then initrds were introduced, and now we're baking in system > specifics into it. Now I have all kinds of trouble with drivers not > being found, and volume groups not being found. Only solution is to boot > a rescue disk and rebuild the initrd, using an incredibly arcane series > of commands. I pity the n00b who tries to upgrade their system. +1 -- for us here on the list it's no big deal, but for ordinary users its a PITA that often leads them to reinstall linux, which leads to "Linux is complicated" statements. CU knurd From promac at gmail.com Mon Dec 3 08:45:23 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Mon, 3 Dec 2007 06:45:23 -0200 Subject: mock 0.8.9 In-Reply-To: <20071203061145.GF4039@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203061145.GF4039@humbolt.us.dell.com> Message-ID: <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> On Dec 3, 2007 4:11 AM, Michael E Brown wrote: > On Sun, Dec 02, 2007 at 07:22:22PM -0200, Paulo Cavalcanti wrote: > > I am trying to use mock 0.8. > > > > Executing a simple man mock, gives me: > > > > SYNTAX > > mock [options] --rebuild SRPM [SRPM...] > > > > mock [options] --chroot > > > > mock [options] {--init|clean|shell} > > > > mock [options] --installdeps {SRPM|RPM} > > > > mock [options] --install PACKAGE > > > > ---------------------------------------------------------- > > > > In fact, > > > > mock -r fedora-8-i386 --init > > > > does not work at all. It must be: > > > > mock -r fedora-8-i386 init > > > > Therefore, I think that an update for man mock (0.8.9) is in order, > right? > > It was this way in mock 0.7. > > This was something I overlooked and it is fixed in 0.8.10 already, which > should be making its way to testing repos. > Thanks. I filed a bug report anyway. Just a curiosity, what is the reason for the change? mock is written in python, and it would have been simpler to parse the arguments keeping the "--". Another thing is that in version 0.7 I could open a mock shell and check the installed rpms or install an rpm (rpm -ivh). If I try this in version 0.8 I get an error. I know I can use mock install outside the mock shell, but via shell should still work in my opinion. Finally, how do I pass an argument for building via mock, --define or --with something? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Mon Dec 3 08:42:37 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 03 Dec 2007 09:42:37 +0100 Subject: firefox vs epiphany In-Reply-To: <1196657826.17392.10.camel@localhost> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> Message-ID: <4753C17D.2090702@poolshark.org> Callum Lerwick wrote: > On Mon, 2007-12-03 at 05:38 +0100, David Nielsen wrote: >> I use Epiphany, it does what I need without looking out of place, it >> integrates nicely and it launches much faster. It lacks a few things but >> it also leverages a lot of nice features (seemless integration with >> GNOME, adopts theme, icons. Has more consistent translations which don't >> break with version upgrades) and it has a powerful plugin system so we >> can expand it in interesting ways. > > Epiphany can't seem to block cookies like Galeon can. I have it set so > it accepts session cookies, but blocks all long term cookies. This keeps > most sites functional. From there I can easily white list sites that I > *want* to be able to store cookies with a single click, i.e. all the > sites I actually log in to. > > Keeps my disk untainted by doubleclick bugs and whatnot, while not > hurting usability on the sites I actually use. And I'm not constantly > nagged about accepting cookies. > > Galeon is clearly the superior browser. I demand it be made default! I > AM THE COMMUNITY! Nope you're not, galeon is my primary browser too :-). And it quits when I type 'Ctrl-Q'. And it uses my Gnome font and proxy settings. And it loads about 10 times faster than firefox. (Seriously, firefox is slower to start than gimp). From fedora at leemhuis.info Mon Dec 3 08:56:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 09:56:29 +0100 Subject: ata and scsi modules in initrd In-Reply-To: <4753637A.20900@redhat.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> Message-ID: <4753C4BD.507@leemhuis.info> On 03.12.2007 03:01, Warren Togami wrote: > dragoran wrote: >> [..] >>> I didn't say we should have all modules in the initrd. But having the >>> most common would IMHO a good thing. >> +1 for having all pata/sata drivers in the initrd by default. > Has anyone checked how much larger this would make a typical initrd image? $ du /lib/modules/2.6.23.8-63.fc8/kernel/drivers/{ata,scsi}/ --max-depth\=0 1604 /lib/modules/2.6.23.8-63.fc8/kernel/drivers/ata/ 4004 /lib/modules/2.6.23.8-63.fc8/kernel/drivers/scsi/ Not sure if the SCSI drivers (and their firmware) should get included as well, but it might make sense. At least including the most common ones makes sense -- the space that was confused by the initrd is free later, isn't it? > The experimental bash-branch of mkinitrd has a simple for loop [...] I didn't look into the bash-branch. The idea sounds nice, but well, getting a bash prompt if the root-device was not found isn't much of a help if you don't have the different storage drivers available, because one of the top reasons why the root device does not get mounted are missing drivers for the storage controller. CU knurd From panemade at gmail.com Mon Dec 3 08:58:01 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 3 Dec 2007 14:28:01 +0530 Subject: koji build rootlog errors with python using packages Message-ID: Hi, Today I did 2 koji builds with are having BR:python-devel and In their root.log I saw sh: /usr/bin/python: No such file or directory I got confused on why root.log is showing above error. Koji builds http://koji.fedoraproject.org/koji/getfile?taskID=270902&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=270886&name=root.log Any one knows the reason? Regards, Parag. From alexl at users.sourceforge.net Mon Dec 3 09:19:52 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 03 Dec 2007 02:19:52 -0700 Subject: firefox vs epiphany In-Reply-To: <4753C17D.2090702@poolshark.org> (Denis Leroy's message of "Mon\, 03 Dec 2007 09\:42\:37 +0100") References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> <4753C17D.2090702@poolshark.org> Message-ID: >>>>> "DL" == Denis Leroy writes: [...] >> Galeon is clearly the superior browser. I demand it be made >> default! I AM THE COMMUNITY! DL> Nope you're not, galeon is my primary browser too :-). And it DL> quits when I type 'Ctrl-Q'. And it uses my Gnome font and proxy DL> settings. And it loads about 10 times faster than DL> firefox. (Seriously, firefox is slower to start than gimp). I, too, am a long-time galeon user and firefox is definitely not a good replacement for a true GNOME browser. Actually, major galeon development has ceased upstream (although they continue to maintain the package and fix bugs), and all galeon features are, in theory, supposed to be merged into epiphany: http://live.gnome.org/Epiphany/GaleonIssues (The original epiphany fork from galeon was very unfortunate and set back the development of a good GNOME webbrowser by several years, and could have been resolved by introducing a plugin system in galeon, rather than forking into epiphany, but that's ancient history now.) In any case, this seems like a good idea in the long-run because it means there is more developer mind-share on a single GNOME browser Although I'm not sure how active this project is these days, more's the pity (that page has only been edited twice in 2007, and it was created back in late 2005). Last time I checked epiphany still doesn't have the fine-grained handling of cookies that I continue to rely on in galeon. Once that it is done, I'd be happy to switch to epiphany. Alex From pertusus at free.fr Mon Dec 3 09:25:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 3 Dec 2007 10:25:59 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: <20071203092559.GA3795@free.fr> On Sun, Dec 02, 2007 at 02:52:04PM -0600, Jima wrote: > On Sun, 2 Dec 2007, Patrice Dumas wrote: >> End-users also expect a package install not to drag in packages that are >> not useful. Especially system administrator end-users who care about >> avoiding bloat. Installing everything may be confusing too, not for a >> user who just don't care about what is installed on his computer but for >> a user who want to keep control. > > Man. We have such a rough job. > "Fedora doesn't install enough packages! You're being mean to sysadmins!" > "Fedora installs too many packages! You're being mean to sysadmins!" > What's worse is that we haven't changed _anything_ between these two > complaints. I guess it goes to show that whatever we do, someone's going > to be unhappy. Exactly. So this is to be packager judgement depending on how he thinks package users care about bloat or completeness, and how he is ready to make complex packaging. -- Pat From pertusus at free.fr Mon Dec 3 09:31:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 3 Dec 2007 10:31:18 +0100 Subject: Guidelines for creating subpackages? In-Reply-To: References: <20071201210306.79152152@redhat.com> <7f692fec0712011820i2c01aaebx1682b45bcba35ed8@mail.gmail.com> <47528E2F.1050203@poolshark.org> <20071202110544.GC3312@free.fr> Message-ID: <20071203093118.GB3795@free.fr> On Sun, Dec 02, 2007 at 06:15:24PM -0500, Tony Nelson wrote: > > Perhaps if there were a new form of dependency, where a package would be > installed iff all packages that, umm, "co-require" it were installed. So > then (pulling a bogus example out of my rear) Python bindings for GTK2 > would only be installed if both Python and GTK2 were installed, and yum > would install it when installing the last of the co-dependent packages. > This new thing would require much package splitting and tweaking of > co-requires to be useful. That adds a lot of complexity and 'magic' in the system, in my opinion, for few gains. Not a bad idea, but, still in my opinion th eincreased complexity is not worth the trouble. > In the case of -devel packages (though I don't personally mind very much > when such a package pulls in other packages), would it be reasonable in > most cases to just not have them require any other packages? Most of them > are headers, which will be useful during compilation whether or not the > resulting binary can run, but the source that uses them probably already > pulls in whatever of those other packages it actually needs. I would > think. (Anyway, co-requires will save me here!) No, development packages needs to allow for linking, too, and the .so links are in the devel packages. So they need to pull in all the dependent libraries (and it is the issue in case of vtk, since there is a python-linked library and a qt-linked library pulled in). And in case headers include other headers, the devel packages are to be installed too. -- Pat From atkac at redhat.com Mon Dec 3 09:39:03 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 3 Dec 2007 10:39:03 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support Message-ID: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> Hi all, dhcdbd package has been removed and replaced by NetworkManager but NM doesn't implement dhcdbd functionality. We have some patches in Fedora whose makes named capable to get forwarders from dhcdbd but now they are completely unusable. I'm going to drop all related patches because they are unusable. I'm interested how many people used this feature and if I should try develop this again. If no users exist (or very limited number) I'm going to completely drop this feature because it doesn't make sence spend time with something what noone uses. Regards, Adam -- Adam Tkac, Red Hat, Inc. From fedora at camperquake.de Mon Dec 3 09:45:18 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 3 Dec 2007 10:45:18 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> Message-ID: <20071203104518.00e1ac88@dhcp03.addix.net> Hi. On Mon, 3 Dec 2007 10:39:03 +0100, Adam Tkac wrote: > dhcdbd package has been removed and replaced by > NetworkManager but NM doesn't implement dhcdbd functionality. We > have some patches in Fedora whose makes named capable to get > forwarders from dhcdbd but now they are completely unusable. I'm > going to drop all related patches because they are unusable. I'm > interested how many people used this feature and if I should try > develop this again. If no users exist (or very limited number) I'm > going to completely drop this feature because it doesn't make sence > spend time with something what noone uses. Personally, I am very interested in a way to set DNS related stuff over dbus (be it forwarders, local domain names or other stuff). This is not exactly bind related, but I'd like it to work with bind, too. From nicolas.mailhot at laposte.net Mon Dec 3 09:55:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Dec 2007 10:55:00 +0100 (CET) Subject: firefox vs epiphany Message-ID: <1259.192.54.193.53.1196675700.squirrel@rousalka.dyndns.org> Le Lun 3 d?cembre 2007 08:09, Mike A. Harris a ?crit : > I just assumed everyone used the bookmark toolbar exclusively (in any > web browser) by default for ages now due to the great utility it > provides. Perhaps I was wrong, and there's one person out there who > doesn't use it. Doh! ;o) I don't use the bookmark toolbar, it's a space waster, every other Firefox version I check if firefox will finaly let me delete the personnal toolbar folder in by bookmarks -- Nicolas Mailhot From nphilipp at redhat.com Mon Dec 3 09:58:20 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 03 Dec 2007 10:58:20 +0100 Subject: Development Docs (Rhythmbox, in particular) In-Reply-To: <1196457398.17157.16.camel@localhost6.localdomain6> References: <1196457398.17157.16.camel@localhost6.localdomain6> Message-ID: <1196675900.17342.27.camel@wombat.tiptoe.de> On Fri, 2007-11-30 at 14:16 -0700, Richi Plana wrote: > Now that we have a Developer spin, perhaps package maintainers can give > some thought to packaging development docs as well. Rhythmbox, > specifically, deletes all the gtk-doc files. Perhaps now we can package > them in rhythmbox-devel-doc or something as well as sample plugin code? > Things that developers would find useful. Seems worthwhile, would you care opening a bug for it? 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 atkac at redhat.com Mon Dec 3 10:00:27 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 3 Dec 2007 11:00:27 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203104518.00e1ac88@dhcp03.addix.net> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> Message-ID: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> On Mon, Dec 03, 2007 at 10:45:18AM +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 3 Dec 2007 10:39:03 +0100, Adam Tkac wrote: > > > dhcdbd package has been removed and replaced by > > NetworkManager but NM doesn't implement dhcdbd functionality. We > > have some patches in Fedora whose makes named capable to get > > forwarders from dhcdbd but now they are completely unusable. I'm > > going to drop all related patches because they are unusable. I'm > > interested how many people used this feature and if I should try > > develop this again. If no users exist (or very limited number) I'm > > going to completely drop this feature because it doesn't make sence > > spend time with something what noone uses. > > Personally, I am very interested in a way to set DNS related stuff over > dbus (be it forwarders, local domain names or other stuff). This is > not exactly bind related, but I'd like it to work with bind, too. For clarify what exactly discussed feature did (nothing more). When you get nameservers from DHCP dhcdbd tells to named through DBUS that named should use them as forwarders and NetworkManager sets 127.0.0.1 as default nameserver in resolv.conf. So you could use named as caching-nameserver on laptops and you don't have to edit named.conf always when you move to different network. I think it makes sence add this feature to some light DNS server but not into named. It's simply too heavy-weight solution. Also upstream will never accept such feature because this is not primary BIND mission. Domain name modification should be done with nsupdate utility through DDNS update message which is part of DNS protocol. Adam -- Adam Tkac, Red Hat, Inc. From pertusus at free.fr Mon Dec 3 10:06:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 3 Dec 2007 11:06:44 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> Message-ID: <20071203100644.GE3795@free.fr> On Mon, Dec 03, 2007 at 11:00:27AM +0100, Adam Tkac wrote: > > For clarify what exactly discussed feature did (nothing more). When you get > nameservers from DHCP dhcdbd tells to named through DBUS that named > should use them as forwarders and NetworkManager sets 127.0.0.1 as > default nameserver in resolv.conf. So you could use named as > caching-nameserver on laptops and you don't have to edit named.conf > always when you move to different network. I think it makes sence add > this feature to some light DNS server but not into named. It's simply > too heavy-weight solution. Also upstream will never accept such feature > because this is not primary BIND mission. Domain name modification > should be done with nsupdate utility through DDNS update message which > is part of DNS protocol. If there is a design flaw, as you seem to be implying, dropping it as soon as possible is, in my opinion, the best thing to do (at least in fedora ;-), to ease as much as possible the transition path. -- Pat From bnocera at redhat.com Mon Dec 3 10:40:45 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 03 Dec 2007 10:40:45 +0000 Subject: Development Docs (Rhythmbox, in particular) In-Reply-To: <1196457398.17157.16.camel@localhost6.localdomain6> References: <1196457398.17157.16.camel@localhost6.localdomain6> Message-ID: <1196678445.3227.195.camel@cookie.hadess.net> On Fri, 2007-11-30 at 14:16 -0700, Richi Plana wrote: > Hi, > > Now that we have a Developer spin, perhaps package maintainers can give > some thought to packaging development docs as well. Rhythmbox, > specifically, deletes all the gtk-doc files. Perhaps now we can package > them in rhythmbox-devel-doc or something as well as sample plugin code? > Things that developers would find useful. File a bug. It was removed because it was useless. Not that it got any better (there's nothing documented), but at least it shows you the exported functionality... Cheers From lordmorgul at gmail.com Mon Dec 3 11:14:59 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 03 Dec 2007 03:14:59 -0800 Subject: What's your opinion on using alternatives for mesa-libGL(U)? In-Reply-To: <4753B70D.1050702@leemhuis.info> References: <1196529544.3587.9.camel@Diffingo.localdomain> <47534304.3050508@gmail.com> <4753B70D.1050702@leemhuis.info> Message-ID: <4753E533.8010108@gmail.com> Thorsten Leemhuis wrote: > What do you mean with "symlink plan"? > >> The proprietary ati/nvidia drivers currently install that >> way, I meant these installers *do* replace symlinks to the files, but afaik they no longer destroy the lib itself (libGL.so.1.2) as they did very early on, now just changing the symlink to the other (e.g. libGL.so.100.14.19). This works but as you comment does have a problem in that updates destroy the symlinks, something that cannot be easily prevented. > ati/nvidia last time I checked replaced the /usr/lib/libGL.so.* files; > thus if the package mesa-libGL from fedora gets updated it will break, > as it will overwrite that stuff. What it really should do is overwrite the updated file but not change the symlink if it already exists, leaving libGL.so.1 pointing wherever it does. >> and the packaged versions others have done (livna) are the same. > Livna doesn't touch /usr/lib/libGL.so.* ; see above for what livna does > right now. I stand corrected... I had not looked into how the livna package was handling this in some time I guess; when they began relocating the libraries it was also placing the symlinks to the correctly moved library. It seems that is no longer being done. -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From fedora at leemhuis.info Mon Dec 3 11:49:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 12:49:39 +0100 Subject: EPEL report week 48 2007 Message-ID: <4753ED53.8070400@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week48 = Weekly EPEL Summary = Week 48/2007 == Most important happenings == * [:ThorstenLeemhuis:knurd] pushed a lot of packaged from EPEL4/testing to the proper EPEL repo (some were omitted due to broke deps). See these mails for details: * https://www.redhat.com/archives/epel-devel-list/2007-November/msg00131.html * https://www.redhat.com/archives/epel-devel-list/2007-November/msg00134.html == Mailing list == === Noteworthy discussions === None == Meeting == === Next Meeting === 20071205 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === None scheduled. == Stats == === General === Number of EPEL Contributors: 141 === EPEL 5 === Number of source packages: 828 Number of binary packages: 1534 There are 9 new Packages: * libident | New LibIdent C library * libnss-mysql | NSS library for MySQL * osslsigncode | Tool for Authenticode signing of EXE/CAB files * perl-CGI-Session | Persistent session data in CGI applications * perl-Crypt-SmbHash | Pure-perl Lanman and NT MD4 hash functions * perl-Digest-MD4 | Perl interface to the MD4 Algorithm * php-eaccelerator | PHP accelerator, optimizer, encoder and dynamic content cacher * php-pear-Crypt-CHAP | Class to generate CHAP packets * xalan-c | Xalan XSLT processor for C === EPEL 4 === Number of source packages: 458 Number of binary packages: 910 There are 11 new Packages: * libident | New LibIdent C library * libnss-mysql | NSS library for MySQL * osslsigncode | Tool for Authenticode signing of EXE/CAB files * perl-Crypt-SmbHash | Pure-perl Lanman and NT MD4 hash functions * perl-Digest-MD4 | Perl interface to the MD4 Algorithm * perl-FreezeThaw | Convert Perl structures to strings and back * perl-IO-Socket-SSL | Perl library for transparent SSL * perl-MLDBM | Store multi-level hash structure in single level tied hash * perl-Net-SSLeay | Perl extension for using OpenSSL * php-eaccelerator | PHP accelerator, optimizer, encoder and dynamic content cacher * xalan-c | Xalan XSLT processor for C ---- ["CategoryEPELReports"] From oliver at linux-kernel.at Mon Dec 3 12:19:36 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 03 Dec 2007 13:19:36 +0100 Subject: Public Domain License Message-ID: <4753F458.9090809@linux-kernel.at> H guys! Looking at http://fedoraproject.org/wiki/Licensing I see Public Domain listed as FSF free and GPLv2 compat. GPLv3 is not filled out. However. Looking at fsf.org I see this: "Public domain material is compatible with the GNU GPL." So what's the truth now? :-) Is it compatible and might it be linked with GPL licensed software or not? -of From oliver at linux-kernel.at Mon Dec 3 12:21:01 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 03 Dec 2007 13:21:01 +0100 Subject: Public Domain License In-Reply-To: <4753F458.9090809@linux-kernel.at> References: <4753F458.9090809@linux-kernel.at> Message-ID: <4753F4AD.10302@linux-kernel.at> On 12/03/2007 01:19 PM, Oliver Falk wrote: > H guys! > > Looking at http://fedoraproject.org/wiki/Licensing I see Public Domain > listed as FSF free and GPLv2 compat. GPLv3 is not filled out. > > However. Looking at fsf.org I see this: > > "Public domain material is compatible with the GNU GPL." > > So what's the truth now? :-) Is it compatible and might it be linked > with GPL licensed software or not? Sorry. My mistake. Forget it :-) It is of course. -of From jnovy at redhat.com Mon Dec 3 12:21:32 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 3 Dec 2007 13:21:32 +0100 Subject: TeXLive is in rawhide Message-ID: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Hi all, I come with good news for TeX users in Fedora. TeXLive is now finally imported and built in rawhide since today. Enjoy, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From mcepl at redhat.com Mon Dec 3 12:29:10 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Dec 2007 13:29:10 +0100 Subject: DJB's software components References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> Message-ID: On Sat, 01 Dec 2007 07:18:34 +0000, Kevin Kofler scripst: > Believe it or not, in most European countries, you can't place anything > in the public domain, especially not after you claimed copyright for it Better to be said -- in most of the European, there is no such thing as public domain de iure. There is a public domain de facto, but it looks slightly differently from the US public domain. Let lawyers deal with junk like this. > In addition, there may be rights which cannot even be licensed, for > example in France, you can't use a work in a way which hurts the > author's image/reputation (and I believe that part of a French > copyright doesn't even expire); That's pretty common all over Europe (knowing only the Czech copyright law though). > (Of course all this is not legal advice, I am not a lawyer, laws may > vary wildly between countries in Europe, and the above paragraph may > contain mistakes. But disclaimers aside, I hope I got the general idea > across. ;-) ) I was a lawyer, but I haven't practice copyright law for years, so IANAL for purposes of this thread as well. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From debarshi.ray at gmail.com Mon Dec 3 12:42:41 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 3 Dec 2007 18:12:41 +0530 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal Message-ID: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> Few days ago I removed the dist tag from the bouml-doc (NEVRA: bouml-doc-3.0-2) package, and found that I can not separately build and create an update for the different Fedora branches using Koji and Bodhi respectively. I built it for Fedora 7 (cd bouml-doc/F-7 && make build), but need some help to make it appear on the Fedora 8 and the Rawhide repositories. Trying to create an update for Fedora 8 using Bodhi throws: "bouml-doc-3.0-2 build is not tagged with dist-f8-updates-candidate". Currently I can't find it on ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/development/i386/os/Packages/ Bodhi: https://admin.fedoraproject.org/updates/F7/FEDORA-2007-3842 Koji: //koji.fedoraproject.org/koji/buildinfo?buildID=25548 Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mcepl at redhat.com Mon Dec 3 12:32:30 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Dec 2007 13:32:30 +0100 Subject: DJB's software components References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> <20071201140913.GA9617@devserv.devel.redhat.com> Message-ID: On Sat, 01 Dec 2007 09:09:13 -0500, Alan Cox scripst: > On Sat, Dec 01, 2007 at 07:18:34AM +0000, Kevin Kofler wrote: >> Believe it or not, in most European countries, you can't place anything >> in the public domain, especially not after you claimed copyright for it >> first. Under such a system, you can only license your rights (e.g. >> under a BSD-style > > There are quite a few you don't want to. Don't assume that "public > domain" has any attached liability waivers Which was the reason I was shocked DJB released qmail under public domain and why I would always prefer at least MIT/X/BSD-no-appropriation/CC-au always. IIRC, sqlite is the only substantial software which is under public domain and there is a reason for that. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From buildsys at redhat.com Mon Dec 3 12:58:09 2007 From: buildsys at redhat.com (Build System) Date: Mon, 3 Dec 2007 07:58:09 -0500 Subject: rawhide report: 20071203 changes Message-ID: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> New package perl-Net-SSH2 Support for the SSH 2 protocol via libSSH2 New package texlive-texmf Architecture independent parts of the TeX formatting system New package texlive-texmf-errata Errata for texlive-texmf Removed package gnomescan Updated Packages: Pound-2.4-0.1.e.fc9 ------------------- apr-util-1.2.12-2.fc9 --------------------- * Mon Dec 03 2007 Jesse Keating - 1.2.12-2 - remove all instances of MySQL flags being added to APRUTIL_LDFLAGS avr-binutils-2.17-5.fc9 ----------------------- * Sun Dec 02 2007 Hans de Goede 2.17-5 - Fix building with texinfo version > 4.9 (4.11 for example) awstats-6.7-2.fc9 ----------------- * Sun Dec 02 2007 Aurelien Bompard 6.7-2 - awstats does not actually require httpd (bug 406901) beagle-0.2.18-2.fc9 ------------------- * Sun Dec 02 2007 Matthias Clasen - 0.2.18-2 - Add BuildRequires for desktop-file-utils - Fix up license field cfengine-2.2.3-2.fc9 -------------------- * Sun Dec 02 2007 Jeff Sheltren 2.2.3-2 - fix libdir regex in files section, don't include debug files (#407881) dia-1:0.96.1-5.fc9 ------------------ * Sun Dec 02 2007 Hans de Goede 1:0.96.1-5 - Do not put dia in both the Office and the Graphics application menus (bz 408041) drivel-2.1.1-0.2.20071130svn.fc9 -------------------------------- * Sun Dec 02 2007 Paul W. Frields - 2.1.1-0.2.20071130svn - Fix some BuildRequires - Patch .desktop file to meet standards * Fri Nov 30 2007 Paul W. Frields - 2.1.1-0.1.20071130svn - Update to latest SVN - Use OpenSSL library instead of beecrypt for MD5 - Patch proxy URI behavior emelfm2-0.3.6-1.fc9 ------------------- * Sun Dec 02 2007 Christoph Wickert - 0.3.6.1-1 - Update 0.3.6 with upstream's e2-0.3.6-07-12-01.patch - Enable the ACL plugin fbreader-0.8.8-1.fc9 -------------------- * Sun Dec 02 2007 Michel Salim - 0.8.8-1 - Update to 0.8.8 fvwm-2.5.24-1.fc9 ----------------- * Sun Dec 02 2007 Adam Goode - 2.5.24-1 - New upstream release - Fixes segfault (#382321) gcc-4.1.2-35 ------------ * Sun Dec 02 2007 Jakub Jelinek 4.1.2-35 - two ctor preevaluation fixes (Olivier Hainque, Eric Botcazou, #407281) - slightly weaken diagnostics for declared, but undefined static data members in anon ns classes (#402521, PR c++/34238) - consider static data members and static member functions in anon ns classes to be external for C++ linkage type handling (PR c++/34213) - handle OBJ_TYPE_REF in C++ diagnostics (PR c++/34275) gnome-vfs2-2.20.1-2.fc9 ----------------------- * Mon Dec 03 2007 Matthias Clasen - 2.20.1-2 - Build the mime.cache handling code * Mon Nov 12 2007 Matthias Clasen - 2.20.1-1 - Update to 2.20.1 (fixes a dns-sd crash) * Tue Oct 23 2007 Matthias Clasen - 2.20.0-4 - Rebuild against new dbus-glib gpart-0.1h-8.fc9 ---------------- * Sat Dec 01 2007 David Cantrell - 0.1h-8 - Merge review (#225853) gtk-xfce-engine-2.4.2-1.fc9 --------------------------- * Sun Nov 18 2007 Kevin Fenzi - 2.4.2-1 - Update to 2.4.2 inkscape-0.45.1-4.fc9 --------------------- * Sun Dec 02 2007 Lubomir Kundrak - 0.45.1-4 - Added missing dependencies for modules (#301881) kbilliards-0.8.7b-5.fc9 ----------------------- * Sun Dec 02 2007 Hans de Goede 0.8.7b-5 - BuildRequire kdelibs3-devel instead of kdelibs-devel as that now is kde4 based, and we need kde 3 kdiff3-0.9.92-11.fc9 -------------------- * Sun Dec 02 2007 Neal Becker - 0.9.92-11 - BR qt-devel - source /etc/profile.d/qt.sh for mock kid3-0.10-2.fc9 --------------- * Mon Dec 03 2007 Ville Skytt?? - 0.10-2 - Use xdg-open as the default browser. * Sun Dec 02 2007 Ville Skytt?? - 0.10-1 - 0.10, desktop entry patch applied upstream. - Build for KDE4 in F9+, KDE3 in earlier. * Sun Dec 02 2007 Ville Skytt?? - 0.9-3 - BuildRequire libvorbis-devel, and kdelibs3-devel instead of kdelibs-devel. klamav-0.41.1-7.fc9 ------------------- * Sun Dec 02 2007 Andy Shevchenko 0.41.1-7 - build with kdelibs3-devel (http://www.redhat.com/archives/fedora-devel-announce/2007-November/msg00005.html) komparator-0.8-2.fc9 -------------------- * Sun Dec 02 2007 Neal Becker - 0.8-2 - Fix mock build - BR kdebase -> kdebase3 libxfce4mcs-4.4.2-1.fc9 ----------------------- * Sun Nov 18 2007 Kevin Fenzi - 4.4.2-1 - Update to 4.4.2 libxfce4util-4.4.2-1.fc9 ------------------------ * Sun Dec 02 2007 Kevin Fenzi - 4.4.2-1 - Update to 4.4.2 libxfcegui4-4.4.2-1.fc9 ----------------------- * Sun Nov 18 2007 Kevin Fenzi - 4.4.2-1 - Update to 4.4.2 liferea-1.4.9-2.fc9 ------------------- * Sun Dec 02 2007 Brian Pepple - 1.4.9-2 - Update feed patch. * Sun Dec 02 2007 Brian Pepple - 1.4.9-1 - Update to 1.4.9. openoffice.org-1:2.3.1-9.6.fc9 ------------------------------ * Sat Dec 01 2007 Caolan McNamara - 1:2.3.1-9.6 - add workspace.cmcfixes39.patch for ooo#83751 and use system writer2latex * Thu Nov 29 2007 Caolan McNamara - 1:2.3.1-9.5 - split out thesauri - move autocorrect files into langpacks and make appropiate aliases - allow "import uno" to just work out of the box * Sat Nov 24 2007 Caolan McNamara - 1:2.3.1-9.4 - Resolves: rhbz#384391 add openoffice.org-2.3.1.ooo83930.sw.flushanchors.patch - split out libhyphen and hyphenators - add openoffice.org-2.3.1.ooo84001.slideshow.gccisaprick.patch coz gcc hates us - drop openoffice.org-2.3.1.83876.unopkg.avoida11y.patch coz upstream won't do it policycoreutils-2.0.32-2.fc9 ---------------------------- * Sun Dec 02 2007 Dan Walsh 2.0.32-2 - Fix handling of disable selinux button in gui * Mon Nov 19 2007 Dan Walsh 2.0.32-1 - Upgrade from NSA * load_policy initial load option from Chad Sellers. poppler-0.6.2-3.fc9 ------------------- * Sun Dec 02 2007 Matthias Clasen - 0.6.2-3 - Fix the qt3 checks some more powerpc-utils-1.0.6-2.fc9 ------------------------- qt4-4.3.2-6.fc9 --------------- * Sun Dec 02 2007 Rex Dieter 4.3.2-6 - move qdbus to main pkg (#407861) qt4-theme-quarticurve-0.0-0.9.beta6.fc9 --------------------------------------- * Mon Dec 03 2007 Kevin Kofler - 0.0-0.9.beta6 - Update to beta 6: - Use system (rather than builtin Qt) icons in Qt 4 dialogs also in KDE 4 apps recordmydesktop-0.3.6-2.fc9 --------------------------- * Sun Dec 02 2007 Sindre Pedersen Bj??rdal - 0.3.6-2 - Add jack support seamonkey-1.1.7-2.fc9 --------------------- * Sun Dec 02 2007 Kai Engert - 1.1.7-2 - SeaMonkey 1.1.7 selinux-policy-3.2.1-2.fc9 -------------------------- * Sun Dec 02 2007 Dan Walsh 3.2.1-2 * Fri Nov 30 2007 Dan Walsh 3.2.1-1 - Remove user based home directory separation smart-0.52-52.fc9 ----------------- * Sun Dec 02 2007 Ville Skytt?? - 0.52-52 - BuildRequire kdelibs3-devel instead of kdelibs-devel. - Explicitly source qt profile.d snippet during build. * Wed Oct 24 2007 Ville Skytt?? - 0.52-51 - Re-remove dropped and no longer needed autofs5 patch. * Sun Oct 07 2007 Axel Thimm - 0.52-50 - Update to 0.52. - Fix pam stack type detection. soprano-1.98.0-1.fc9 -------------------- * Sun Dec 02 2007 Kevin Kofler 1.98.0-1 - soprano-1.98.0 (soprano 2 rc 1) - update glibc/open patch taxipilot-0.9.2-4.fc9 --------------------- * Sun Dec 02 2007 Hans de Goede 0.9.2-4 - BuildRequire kdelibs3-devel (and kdemultimedia3-devel) instead of kdelibs-devel as that now is kde4 based, and we need kde 3 vbetool-0.7-4.fc9 ----------------- * Sun Dec 02 2007 Till Maas - 0.7-4 - libz.a is now in a -static subpackage, add to BR xfce-mcs-manager-4.4.2-1.fc9 ---------------------------- * Sun Nov 18 2007 Kevin Fenzi - 4.4.2-1 - Update to 4.4.2 - Remove unneeded patch Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5 beagle - 0.2.18-2.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.i386 requires gecko-libs = 0:1.8.1.9 seamonkey - 1.1.7-2.fc9.i386 requires nss >= 0:3.12.0 seamonkey - 1.1.7-2.fc9.i386 requires nspr >= 0:4.7.0 sysprof - 1.0.8-2.fc8.i386 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.i386 requires libntfs.so.9 xfce4-panel-devel - 4.4.1-4.fc8.i386 requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.i386 requires libxfcegui4-devel = 0:4.4.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit) beagle - 0.2.18-2.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 seamonkey - 1.1.7-2.fc9.x86_64 requires nss >= 0:3.12.0 seamonkey - 1.1.7-2.fc9.x86_64 requires nspr >= 0:4.7.0 sysprof - 1.0.8-2.fc8.x86_64 requires kmod-sysprof >= 0:1.0.8 testdisk - 6.8-1.fc8.x86_64 requires libntfs.so.9()(64bit) xfce4-panel-devel - 4.4.1-4.fc8.x86_64 requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.x86_64 requires libxfcegui4-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.i386 requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.i386 requires libxfcegui4-devel = 0:4.4.1 Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5 beagle - 0.2.18-2.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 monodevelop - 0.17-4.fc9.ppc requires boo openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.ppc requires gecko-libs = 0:1.8.1.9 seamonkey - 1.1.7-2.fc9.ppc requires nss >= 0:3.12.0 seamonkey - 1.1.7-2.fc9.ppc requires nspr >= 0:4.7.0 testdisk - 6.8-1.fc8.ppc requires libntfs.so.9 xfce4-panel-devel - 4.4.1-4.fc8.ppc64 requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.ppc64 requires libxfcegui4-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.ppc requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.ppc requires libxfcegui4-devel = 0:4.4.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.9.9-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 ruby-gtkmozembed - 0.16.0-16.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 seamonkey - 1.1.7-2.fc9.ppc64 requires nss >= 0:3.12.0 seamonkey - 1.1.7-2.fc9.ppc64 requires nspr >= 0:4.7.0 testdisk - 6.8-1.fc8.ppc64 requires libntfs.so.9()(64bit) xfce4-panel-devel - 4.4.1-4.fc8.ppc64 requires libxfce4util-devel = 0:4.4.1 xfce4-panel-devel - 4.4.1-4.fc8.ppc64 requires libxfcegui4-devel = 0:4.4.1 From mcepl at redhat.com Mon Dec 3 12:57:34 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Dec 2007 13:57:34 +0100 Subject: firefox vs epiphany References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> Message-ID: On Sun, 02 Dec 2007 23:24:27 -0500, Mike A. Harris scripst: > I just poked around with epiphany a few minutes ago before writing this, > and found it lacks various features that I would consider "must have" > for my own personal use, which firefox has, and that's ignoring the > plethora of existing firefox plugins I use currently. Would you care to list at least few of these? I don't want to get into any religious war on the subject, but if you are interested we may help you to see the light and find the missing functionality in Epiphany. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From opensource at till.name Mon Dec 3 13:12:21 2007 From: opensource at till.name (Till Maas) Date: Mon, 03 Dec 2007 14:12:21 +0100 Subject: koji build rootlog errors with python using packages In-Reply-To: References: Message-ID: <200712031412.33660.opensource@till.name> On Mo Dezember 3 2007, Parag N(????) wrote: > Today I did 2 koji builds with are having BR:python-devel and In > their root.log I saw > sh: /usr/bin/python: No such file or directory > I got confused on why root.log is showing above error. > > Koji builds > http://koji.fedoraproject.org/koji/getfile?taskID=270902&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=270886&name=root.log > > Any one knows the reason? The srpm is once rebuilt with ignoring the dependencies (see the next previous line that starts with "Executing"). Therefore all defines that use %(/usr/bin/python ...) will fail with above message. 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 mcepl at redhat.com Mon Dec 3 13:01:15 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Dec 2007 14:01:15 +0100 Subject: firefox vs epiphany References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> <1196640814.3665.0.camel@localhost.localdomain> <1196643074.26642.11.camel@averatec> <20071202201654.0a86d17b@redhat.com> Message-ID: On Sun, 02 Dec 2007 20:16:54 -0500, Jesse Keating scripst: > I had the exact opposite. I tried epiphany and I could find no > compelling reason to continue using it. I couldn't find one single Aside from Gnome intergration (I know that's subjective), there are just two words: Python plugins. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mike at miketc.com Mon Dec 3 13:21:21 2007 From: mike at miketc.com (Mike Chambers) Date: Mon, 03 Dec 2007 07:21:21 -0600 Subject: firefox vs epiphany In-Reply-To: <4753ABA7.6060507@mharris.ca> References: <1196625336.2547.4.camel@tiger> <1196631661.3350.5.camel@pc-notebook.kolej.mff.cuni.cz> <1196658245.5074.10.camel@jndwidescreen.lesbg.loc> <4753ABA7.6060507@mharris.ca> Message-ID: <1196688081.20169.1.camel@scrappy.miketc.com> On Mon, 2007-12-03 at 02:09 -0500, Mike A. Harris wrote: > Ever since Netscape acquired the Personal Bookmark Toolbar, I have > created hierarchial folders of bookmarks, with the primary categories > of > bookmarks being directly on the personal toolbar. I do not ever > create > any bookmarks that are not on the toolbar or subfolders of the > toolbar, > and I've often wondered if anyone else out there ever set bookmarks > outside of the bookmark toolbar. ;o) H!!!!! Hrm, not sure if I do that or not, care to supply/point to a screenshot to see wutcha talking about? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From j.w.r.degoede at hhs.nl Mon Dec 3 13:01:28 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 03 Dec 2007 14:01:28 +0100 Subject: rawhide report: 20071203 changes In-Reply-To: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> Message-ID: <4753FE28.7040900@hhs.nl> Build System wrote: > vbetool-0.7-4.fc9 > ----------------- > * Sun Dec 02 2007 Till Maas - 0.7-4 > - libz.a is now in a -static subpackage, add to BR Why is this using a static libz.a? Thats just plain bad! Regards, Hans From nicolas.mailhot at laposte.net Mon Dec 3 13:22:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Dec 2007 14:22:26 +0100 (CET) Subject: Public Domain License Message-ID: <60762.192.54.193.53.1196688146.squirrel@rousalka.dyndns.org> Le Lun 3 d?cembre 2007 13:19, Oliver Falk a ?crit : > So what's the truth now? :-) Is it compatible and might it be linked > with GPL licensed software or not? It is compatible in the sense the result is effectively GPLv3 -- Nicolas Mailhot From opensource at till.name Mon Dec 3 14:00:42 2007 From: opensource at till.name (Till Maas) Date: Mon, 03 Dec 2007 15:00:42 +0100 Subject: rawhide report: 20071203 changes In-Reply-To: <4753FE28.7040900@hhs.nl> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> <4753FE28.7040900@hhs.nl> Message-ID: <200712031500.47100.opensource@till.name> On Mo Dezember 3 2007, Hans de Goede wrote: > Build System wrote: > > vbetool-0.7-4.fc9 > > ----------------- > > * Sun Dec 02 2007 Till Maas - 0.7-4 > > - libz.a is now in a -static subpackage, add to BR > > Why is this using a static libz.a? Thats just plain bad! I do not know, maybe Peter Jones does, he wrote a patch[1] for vbetool regarding libz.a. Maybe Phil Knirsch or Adam Jackson know more, too. In case it can be changed, I will apply any patch that does change this, but I do not know how to write it. Regards, Till [1] https://cvs.fedoraproject.org/viewcvs/rpms/vbetool/devel/vbetool-libz.patch?rev=1.1&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 dcbw at redhat.com Mon Dec 3 14:13:01 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 03 Dec 2007 09:13:01 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203100644.GE3795@free.fr> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203100644.GE3795@free.fr> Message-ID: <1196691181.2819.28.camel@localhost.localdomain> On Mon, 2007-12-03 at 11:06 +0100, Patrice Dumas wrote: > On Mon, Dec 03, 2007 at 11:00:27AM +0100, Adam Tkac wrote: > > > > For clarify what exactly discussed feature did (nothing more). When you get > > nameservers from DHCP dhcdbd tells to named through DBUS that named > > should use them as forwarders and NetworkManager sets 127.0.0.1 as > > default nameserver in resolv.conf. So you could use named as > > caching-nameserver on laptops and you don't have to edit named.conf > > always when you move to different network. I think it makes sence add > > this feature to some light DNS server but not into named. It's simply > > too heavy-weight solution. Also upstream will never accept such feature > > because this is not primary BIND mission. Domain name modification > > should be done with nsupdate utility through DDNS update message which > > is part of DNS protocol. > > If there is a design flaw, as you seem to be implying, dropping it as > soon as possible is, in my opinion, the best thing to do (at least in > fedora ;-), to ease as much as possible the transition path. Yeah, I think that's probably the best; if upstream won't take D-Bus bits _and_ they provide an alternate method for updating the caching-only nameserver, that's probably the better choice in the long run. Plus I'm pretty sure that the named D-Bus code was really, really icky. dan From jkeating at redhat.com Mon Dec 3 14:58:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Dec 2007 09:58:02 -0500 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> Message-ID: <20071203095802.6541646a@redhat.com> On Mon, 3 Dec 2007 18:12:41 +0530 "Debarshi 'Rishi' Ray" wrote: > Trying to create an update for Fedora 8 using > Bodhi throws: "bouml-doc-3.0-2 build is not tagged with > dist-f8-updates-candidate". It's now tagged for this. I apologize for the delay. -- 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 walters at redhat.com Mon Dec 3 15:09:52 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 03 Dec 2007 10:09:52 -0500 Subject: firefox vs epiphany In-Reply-To: References: <1196625336.2547.4.camel@tiger> Message-ID: <1196694592.4398.9.camel@space-ghost.verbum.private> On Sun, 2007-12-02 at 23:44 -0500, Michel Salim wrote: > On 02/12/2007, Louis E Garcia II wrote: > > What is the reasoning for making firefox the default instead of epiphany > > for the gnome desktop? Does epiphany lack certain features? > > > No one has brought it up, but as far as I know, mugshot (part of the > upcoming GNOME Online Desktop) Mugshot is a separate thing from the online desktop conceptually. But right now we do have some things in common packages and code. > depends on Firefox. We do have a Firefox extension for Mugshot (not related to the Online Desktop), and have been doing some other Firefox related work, but these are not strong dependencies. From walters at redhat.com Mon Dec 3 15:13:21 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 03 Dec 2007 10:13:21 -0500 Subject: firefox vs epiphany In-Reply-To: <1196643074.26642.11.camel@averatec> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <20071202230618.GA30301@devserv.devel.redhat.com> <1196640814.3665.0.camel@localhost.localdomain> <1196643074.26642.11.camel@averatec> Message-ID: <1196694801.4398.13.camel@space-ghost.verbum.private> On Sun, 2007-12-02 at 19:51 -0500, Jon Nettleton wrote: > I switched to epiphany for F7 and personally I have no interest in going > back. Everything that it lacks is trumped by the integration with the > gnome desktop. Firefox 3 will also include better integration with the GNOME desktop; I blogged about this here: http://cgwalters.livejournal.com/11319.html Longer term, this kind of work should enable us to not have to choose between features and platform integration, but to get both. From caillon at redhat.com Mon Dec 3 15:16:11 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 03 Dec 2007 16:16:11 +0100 Subject: firefox vs epiphany In-Reply-To: <1196625336.2547.4.camel@tiger> References: <1196625336.2547.4.camel@tiger> Message-ID: <47541DBB.1070402@redhat.com> On 12/02/2007 08:55 PM, Louis E Garcia II wrote: > What is the reasoning for making firefox the default instead of epiphany > for the gnome desktop? Does epiphany lack certain features? The main reasons are: * Firefox has better brand global recognition. Chances are higher that a random user will expect Firefox to be the default than other browsers. More advanced users will have heard of different browsers and can install them if preferred. * Traditionally, other applications required firefox to be installed. Namely yelp, devhelp, epiphany (and once upon a time evolution). * Firefox has more extensions available. * Much to my dismay, many web authors will look for only IE or Firefox. There are websites that actually STOP WORKING if the browser is not Firefox (or IE). Firefox CVS HEAD builds recently stopped reporting "Firefox" in the useragent string for example which made many sites[1] break. [1] https://bugzilla.mozilla.org/showdependencytree.cgi?id=334967&hide_resolved=1 From lkundrak at redhat.com Mon Dec 3 15:22:59 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 03 Dec 2007 16:22:59 +0100 Subject: firefox vs epiphany In-Reply-To: <1196635042.15639.14.camel@localhost.localdomain> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> Message-ID: <1196695379.15639.29.camel@localhost.localdomain> On Sun, 2007-12-02 at 23:37 +0100, Lubomir Kundrak wrote: > On Sun, 2007-12-02 at 23:28 +0100, nodata wrote: > > Am Sonntag, den 02.12.2007, 22:40 +0100 schrieb Lubomir Kundrak: > > > On Sun, 2007-12-02 at 14:55 -0500, Louis E Garcia II wrote: > > > > What is the reasoning for making firefox the default instead of epiphany > > > > for the gnome desktop? Does epiphany lack certain features? > > > > > > It does. > > > > > > -- > > > Lubomir Kundrak (Red Hat Security Response Team) > > > > Care to enlighten us? > > No. > > There is enough documentation available. Replying to my own message -- numerous people told me that they consider my reply unprofessional and rude. I definitely didn't mean to be rude or offensive towards anyone, and I apologize if I was. I'd like to give a better answer, but I think that in the first place I shouldn't have replied at all. I assumed that if you compare Firefox and Epiphany, the feature differencies must be obvioust at the first glance. Probably it is not true for users that don't use both browsers. So examples of features I would lack in Epiphany is the bookmarks sidebar, Firefox plugins (well, maybe these can be enabled somehow, still not as comfortably as in Ferefox). Good point I agree with was given in one of replies to this thread -- number of features is not the only fact that decides about a tool being more suitable as a default one. I did not mean to say that Epiphany should not be the default browser -- it makes some sense to me, still I would not use it, so I don't really care. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From david at fubar.dk Mon Dec 3 15:23:21 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Dec 2007 10:23:21 -0500 Subject: firefox vs epiphany In-Reply-To: <47541DBB.1070402@redhat.com> References: <1196625336.2547.4.camel@tiger> <47541DBB.1070402@redhat.com> Message-ID: <1196695401.7278.74.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 16:16 +0100, Christopher Aillon wrote: > On 12/02/2007 08:55 PM, Louis E Garcia II wrote: > > What is the reasoning for making firefox the default instead of epiphany > > for the gnome desktop? Does epiphany lack certain features? > > The main reasons are: > > * Firefox has better brand global recognition. Chances are higher that > a random user will expect Firefox to be the default than other browsers. Here's a funny story: Ironically enough up until F8 we used the generic Web Browser icon on the panel on a default install. The icon looked like planet earth with what looked like a mouse with a cable tied around it. It was Bluecurve style. Fortunately mclasen fixed this for F8 such that the correct icon on the panel for the default browser is chosen. It's a bit funny we didn't fix this earlier; either we don't really care as much as we should about brand recognition.. or we're not very good at polishing. Something to keep in mind and learn from. David From david at fubar.dk Mon Dec 3 15:34:43 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Dec 2007 10:34:43 -0500 Subject: ata and scsi modules in initrd In-Reply-To: <4753637A.20900@redhat.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> Message-ID: <1196696083.7278.86.camel@oneill.fubar.dk> On Sun, 2007-12-02 at 21:01 -0500, Warren Togami wrote: > dragoran wrote: > > [..] > >> I didn't say we should have all modules in the initrd. But having the > >> most common would IMHO a good thing. > > > > +1 for having all pata/sata drivers in the initrd by default. > > > > Has anyone checked how much larger this would make a typical initrd image? > > The experimental bash-branch of mkinitrd has a simple for loop to load > all available kernel modules matching available PCI devices, so we could > possibly load the drivers dynamically. ?Code in the initramfs shouldn't have to be modified just because you throw extra kernel modules in. Seriously. The initramfs isn't hard, it's a solved problem [0], it goes like this - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that will create a /dev/root symlink to said device - include other udev rules such as /etc/udev/rules.d/80-drivers.rules This will automagically load kernel modules in the initramfs if they are there. And only the modules that match the hardware will be loaded. - Do the equivalent of /sbin/start_udev (notably this one can be replaced by a three line shell script or so. That's what the upstream udev maintainer says anyway) - Once /sbin/start_udev is done, see if you have a /dev/root symlink; if not, drop to a shell. If you do, mount rootfs, delete yourself and exec /sbin/init on the real rootfs If you're saying that our current initramfs as generated by mkinitrd can't even do this, just another reason to find and apply the cluebat. [0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot, whatever etc. that isn't really interesting and not really hard either since most of this can also be driven by one-line udev rules. ?[1] : Or device name though it should never ever be necessary to use device names. > But then actually using the > devices that appear to boot might be more challenging, unless the device > names haven't changed since mkinitrd time. I'm not sure what this means. One should always use UUID, if that's not available use LABEL. All but exotic file systems (jffs2 - hi dwmw2!) supports this. Of course if you change LABEL / UUID then it's your own fault. ? David From mattdm at mattdm.org Mon Dec 3 15:43:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 3 Dec 2007 10:43:32 -0500 Subject: network manager command-line control? Message-ID: <20071203154332.GA13878@jadzia.bu.edu> I want to make sure I'm not missing something before I file an RFE. I'd like to be able to enable/disable wireless (or wired, for that matter) networking from scripts. The nm-tool program seems like the logical place for this functionality, but it doesn't appear to actually have it at this point. Specifically, my laptop generates a custom Sony ACPI button event when the wireless antenna is switched on or off -- I'd like to automatically enable or disable wireless networking correspondingly. Is there an easy way to do this that I'm just not seeing? Thanks. (Also, is there a way to supress the pop-up messages about changes in connections status? I find them more obtrusive and distracting than helpful.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mschwendt.tmp0701.nospam at arcor.de Mon Dec 3 15:57:55 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 3 Dec 2007 16:57:55 +0100 Subject: Broken BuildRequires in rawhide Message-ID: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> These are broken BuildRequires in the rawhide src.rpms: package: Miro - 0.9.9.9-1.fc9.src from fedora-development-source unresolved deps: gecko-devel = 0:1.8.1.9 package: orange - 0.3-5.cvs20051118.fc8.src from fedora-development-source unresolved deps: synce-devel package: perl-Perl-MinimumVersion - 0.15-1.fc9.src from fedora-development-source unresolved deps: perl(version) >= 0:0.7203 package: ruby-gnome2 - 0.16.0-16.fc9.src from fedora-development-source unresolved deps: gecko-devel = 0:1.8.1.9 package: synce-software-manager - 0.9.0-7.fc6.src from fedora-development-source unresolved deps: synce-devel package: synce-trayicon - 0.9.0-8.fc6.src from fedora-development-source unresolved deps: synce-devel From mjs at CLEMSON.EDU Mon Dec 3 16:05:20 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Mon, 03 Dec 2007 11:05:20 -0500 Subject: TeXLive is in rawhide In-Reply-To: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Message-ID: <1196697920.3341.14.camel@vincent52.localdomain> On Mon, 2007-12-03 at 13:21 +0100, Jindrich Novy wrote: > Hi all, > > I come with good news for TeX users in Fedora. TeXLive is now finally > imported and built in rawhide since today. Can the rawhide version be used as is in F8 or are there F8 RPMs that we can test? > > Enjoy, > Jindrich > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From xjakub at fi.muni.cz Mon Dec 3 16:13:38 2007 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Mon, 03 Dec 2007 17:13:38 +0100 Subject: TeXLive is in rawhide In-Reply-To: <1196697920.3341.14.camel@vincent52.localdomain> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> Message-ID: <47542B32.8020405@fi.muni.cz> Matthew Saltzman napsal(a): > On Mon, 2007-12-03 at 13:21 +0100, Jindrich Novy wrote: >> Hi all, >> >> I come with good news for TeX users in Fedora. TeXLive is now finally >> imported and built in rawhide since today. > > Can the rawhide version be used as is in F8 or are there F8 RPMs that we > can test? I use TexLive (instead of TeTex) from the following repository (created by Jindrich Novy) on F8 without any problems: [texlive] name=TeXLive 2007 for Fedora Core $releasever - $basearch baseurl=http://people.redhat.com/jnovy/files/texlive/$basearch enabled=1 gpgcheck=0 Regards, Milos Jakubicek > >> Enjoy, >> Jindrich >> From cra at WPI.EDU Mon Dec 3 16:15:00 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 3 Dec 2007 11:15:00 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> Message-ID: <20071203161500.GC19857@angus.ind.WPI.EDU> On Mon, Dec 03, 2007 at 11:00:27AM +0100, Adam Tkac wrote: > always when you move to different network. I think it makes sence add > this feature to some light DNS server but not into named. It's simply > too heavy-weight solution. Also upstream will never accept such feature > because this is not primary BIND mission. Domain name modification > should be done with nsupdate utility through DDNS update message which > is part of DNS protocol. Perhaps dnsmasq instead of BIND? From lesmikesell at gmail.com Mon Dec 3 16:23:26 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 03 Dec 2007 10:23:26 -0600 Subject: ata and scsi modules in initrd In-Reply-To: <1196696083.7278.86.camel@oneill.fubar.dk> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> <1196696083.7278.86.camel@oneill.fubar.dk> Message-ID: <47542D7E.6010007@gmail.com> David Zeuthen wrote: > ?Code in the initramfs shouldn't have to be modified just because you > throw extra kernel modules in. Seriously. The initramfs isn't hard, it's > a solved problem [0], it goes like this > > - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that > will create a /dev/root symlink to said device [...] > ?[1] : Or device name though it should never ever be necessary to use > device names. How do you get the UUID or LABEL or filesystem on the device without knowing the device name? -- Les Mikesell lesmikesell at gmail.com From katzj at redhat.com Mon Dec 3 16:24:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 03 Dec 2007 11:24:31 -0500 Subject: network manager command-line control? In-Reply-To: <20071203154332.GA13878@jadzia.bu.edu> References: <20071203154332.GA13878@jadzia.bu.edu> Message-ID: <1196699071.3300.32.camel@localhost.localdomain> On Mon, 2007-12-03 at 10:43 -0500, Matthew Miller wrote: > I want to make sure I'm not missing something before I file an RFE. I'd like > to be able to enable/disable wireless (or wired, for that matter) networking > from scripts. The nm-tool program seems like the logical place for this > functionality, but it doesn't appear to actually have it at this point. While I can see a use for this functionality in general... > Specifically, my laptop generates a custom Sony ACPI button event when the > wireless antenna is switched on or off -- I'd like to automatically enable > or disable wireless networking correspondingly. Is there an easy way to do > this that I'm just not seeing? Thanks. The right fix for this is for the kernel to hook the ACPI event properly into generating a kill switch event rather than piling on hacks ;) Jeremy From david at fubar.dk Mon Dec 3 16:27:46 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Dec 2007 11:27:46 -0500 Subject: ata and scsi modules in initrd In-Reply-To: <47542D7E.6010007@gmail.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> <1196696083.7278.86.camel@oneill.fubar.dk> <47542D7E.6010007@gmail.com> Message-ID: <1196699266.7278.96.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 10:23 -0600, Les Mikesell wrote: > David Zeuthen wrote: > > > ?Code in the initramfs shouldn't have to be modified just because you > > throw extra kernel modules in. Seriously. The initramfs isn't hard, it's > > a solved problem [0], it goes like this > > > > - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that > > will create a /dev/root symlink to said device > [...] > > > ?[1] : Or device name though it should never ever be necessary to use > > device names. > > How do you get the UUID or LABEL or filesystem on the device without > knowing the device name? You know it at initramfs generation time and you include that information in the initramfs image. David From dcbw at redhat.com Mon Dec 3 16:37:50 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 03 Dec 2007 11:37:50 -0500 Subject: network manager command-line control? In-Reply-To: <20071203154332.GA13878@jadzia.bu.edu> References: <20071203154332.GA13878@jadzia.bu.edu> Message-ID: <1196699870.2447.4.camel@localhost.localdomain> On Mon, 2007-12-03 at 10:43 -0500, Matthew Miller wrote: > I want to make sure I'm not missing something before I file an RFE. I'd like > to be able to enable/disable wireless (or wired, for that matter) networking > from scripts. The nm-tool program seems like the logical place for this > functionality, but it doesn't appear to actually have it at this point. All the functionality is currently available with dbus-send. However, since that's the case, it would be nice to have a CLI tool that interfaces in a nicer manner than dbus-send. I'd like to have something like that too, but haven't had time to look into it. It would be a great opportunity for somebody to jump in. > Specifically, my laptop generates a custom Sony ACPI button event when the > wireless antenna is switched on or off -- I'd like to automatically enable > or disable wireless networking correspondingly. Is there an easy way to do > this that I'm just not seeing? Thanks. Jeremy has an excellent answer to this question :) There's already an rfkill framework in the kernel, your upstream Sony ACPI kernel module needs to hook into that. In the short term, if you _really_ don't want to make the world a better place by pressuring upstream Sony ACPI module authors to do the right thing, look at dbus-send, use the D-Bus property interface on the base NetworkManager object, and set the WirelessEnabled property to true/false depending on what the custom events say. By doing this and not making upstream better, you agree to sacrifice 3 small, adorable, mewing kittens each time you flip the rfkill switch. > (Also, is there a way to supress the pop-up messages about changes in > connections status? I find them more obtrusive and distracting than > helpful.) We could add an option to the applet to disable them, yes. Dan From ajackson at redhat.com Mon Dec 3 17:18:48 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 03 Dec 2007 12:18:48 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075752.A16094@humbolt.us.dell.com> References: <20071202075752.A16094@humbolt.us.dell.com> Message-ID: <1196702328.2303.9.camel@localhost.localdomain> On Sun, 2007-12-02 at 07:57 -0600, Matt Domsch wrote: > libXxf86dga-1.0.1-4.fc8 (build/make) ssp,, Fixed. > xorg-x11-drv-acecad-1.1.0-5.fc8 (build/make) xgl-maint,, [etc] These are all expected, don't flip out yet. - ajax From bnocera at redhat.com Mon Dec 3 16:53:52 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 03 Dec 2007 16:53:52 +0000 Subject: firefox vs epiphany In-Reply-To: <47541DBB.1070402@redhat.com> References: <1196625336.2547.4.camel@tiger> <47541DBB.1070402@redhat.com> Message-ID: <1196700832.3227.222.camel@cookie.hadess.net> On Mon, 2007-12-03 at 16:16 +0100, Christopher Aillon wrote: > * Much to my dismay, many web authors will look for only IE or Firefox. > There are websites that actually STOP WORKING if the browser is not > Firefox (or IE). Firefox CVS HEAD builds recently stopped reporting > "Firefox" in the useragent string for example which made many sites[1] > break. Which is a good thing. Stupid sites check for Firefox instead of checking for Gecko... From opensource at till.name Mon Dec 3 16:55:04 2007 From: opensource at till.name (Till Maas) Date: Mon, 03 Dec 2007 17:55:04 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203161500.GC19857@angus.ind.WPI.EDU> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203161500.GC19857@angus.ind.WPI.EDU> Message-ID: <200712031755.14234.opensource@till.name> On Mo Dezember 3 2007, Chuck Anderson wrote: > On Mon, Dec 03, 2007 at 11:00:27AM +0100, Adam Tkac wrote: > > always when you move to different network. I think it makes sence add > > this feature to some light DNS server but not into named. It's simply > Perhaps dnsmasq instead of BIND? dnsmasq has already supports setting forwarders via d-bus: view /usr/share/doc/dnsmasq-*/DBus-interface 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 ajackson at redhat.com Mon Dec 3 17:29:15 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 03 Dec 2007 12:29:15 -0500 Subject: Bootup speed for F8 In-Reply-To: <4750A487.3050901@codewiz.org> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196445465.22277.60.camel@localhost.localdomain> <4750A487.3050901@codewiz.org> Message-ID: <1196702955.2303.17.camel@localhost.localdomain> On Fri, 2007-11-30 at 19:02 -0500, Bernardo Innocenti wrote: > Adam Jackson wrote: > > I hit most of the low-hanging fruit for X startup performance already in > > rawhide. The rest is... harder. > > What did you actually do? http://cgit.freedesktop.org/xorg/xserver/commit/?id=f01e149d1af14ef9ee0e8a6743ab6a08f3bb677c http://cgit.freedesktop.org/xorg/xserver/commit/?id=22f0e3a8b04e574047a51c8f928a007787303294 http://cgit.freedesktop.org/xorg/xserver/commit/?id=cecac794451b793871f297b91a11d3b52eeb6d1b http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/commit/?id=b139da4553e71896689e8f522e5cff58f5bb7674 http://cgit.freedesktop.org/xorg/driver/xf86-input-mouse/commit/?id=76a2231f87551f7c1943df18bc537b9b15987562 I haven't looked at evdev yet, I'm sure there's disasters there too. - ajax From notting at redhat.com Mon Dec 3 17:08:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Dec 2007 12:08:03 -0500 Subject: ata and scsi modules in initrd In-Reply-To: <1196696083.7278.86.camel@oneill.fubar.dk> References: <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> <1196696083.7278.86.camel@oneill.fubar.dk> Message-ID: <20071203170803.GB1706@nostromo.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > [0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot, > whatever etc. that isn't really interesting and not really hard either > since most of this can also be driven by one-line udev rules. Aside from the rest of it, if you've got a one line udev rule that can mount a nfs loopback device, I'm all for seeing it. :) (Similarly, unless udev has grown a block device daemon to assemble raid/lvm/etc....) Bill From jnovy at redhat.com Mon Dec 3 17:11:56 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 3 Dec 2007 18:11:56 +0100 Subject: TeXLive is in rawhide In-Reply-To: <47542B32.8020405@fi.muni.cz> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> Message-ID: <20071203171156.GA2996@dhcp-lab-186.brq.redhat.com> On Mon, Dec 03, 2007 at 05:13:38PM +0100, Milos Jakubicek wrote: > Matthew Saltzman napsal(a): >> On Mon, 2007-12-03 at 13:21 +0100, Jindrich Novy wrote: >>> Hi all, >>> >>> I come with good news for TeX users in Fedora. TeXLive is now finally >>> imported and built in rawhide since today. >> >> Can the rawhide version be used as is in F8 or are there F8 RPMs that we >> can test? > > I use TexLive (instead of TeTex) from the following repository (created by > Jindrich Novy) on F8 without any problems: > > [texlive] > name=TeXLive 2007 for Fedora Core $releasever - $basearch > baseurl=http://people.redhat.com/jnovy/files/texlive/$basearch > enabled=1 > gpgcheck=0 Yes, it should work fine because rawhide doesn't differ from F8 too much yet. I'll keep this repo for a while so that F8 users could use TeXLive on F8. Jindrich > > Regards, > Milos Jakubicek > >> >>> Enjoy, >>> Jindrich >>> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy http://people.redhat.com/jnovy/ From paul at xelerance.com Mon Dec 3 17:20:58 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 3 Dec 2007 12:20:58 -0500 (EST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> Message-ID: On Mon, 3 Dec 2007, Adam Tkac wrote: > For clarify what exactly discussed feature did (nothing more). When you get > nameservers from DHCP dhcdbd tells to named through DBUS that named > should use them as forwarders and NetworkManager sets 127.0.0.1 as > default nameserver in resolv.conf. So you could use named as > caching-nameserver on laptops and you don't have to edit named.conf > always when you move to different network. I think it makes sence add > this feature to some light DNS server but not into named. It's simply > too heavy-weight solution. But if you are running DNSSEC on your local laptop, and the network only allows dns to their forwarding nameservers, it is quite useful.... > Also upstream will never accept such feature > because this is not primary BIND mission. Domain name modification > should be done with nsupdate utility through DDNS update message which > is part of DNS protocol. But I don't think nsupdate can modify the forwarders configured right? Paul From jonathan.underwood at gmail.com Mon Dec 3 17:27:02 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 3 Dec 2007 17:27:02 +0000 Subject: TeXLive is in rawhide In-Reply-To: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Message-ID: <645d17210712030927g7f13ceb2h57ef0445fb4b954b@mail.gmail.com> On 03/12/2007, Jindrich Novy wrote: > Hi all, > > I come with good news for TeX users in Fedora. TeXLive is now finally > imported and built in rawhide since today. > > Enjoy, > Jindrich Jindrich, many thanks for this, looking at the spec files, one can really appreciate what a monumental packaging feat this is. Is the plan to keep tetex in rawhide for a transitional period? Moving to TeXlive means some packaging renaming (did that tex-foo guideline ever get past the packaging committee?) and some adjusting of BuildRequires and Requires. (and some Obsoletes and Provides too). From atkac at redhat.com Mon Dec 3 17:37:04 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 3 Dec 2007 18:37:04 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> Message-ID: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> On Mon, Dec 03, 2007 at 12:20:58PM -0500, Paul Wouters wrote: > On Mon, 3 Dec 2007, Adam Tkac wrote: > > > For clarify what exactly discussed feature did (nothing more). When you get > > nameservers from DHCP dhcdbd tells to named through DBUS that named > > should use them as forwarders and NetworkManager sets 127.0.0.1 as > > default nameserver in resolv.conf. So you could use named as > > caching-nameserver on laptops and you don't have to edit named.conf > > always when you move to different network. I think it makes sence add > > this feature to some light DNS server but not into named. It's simply > > too heavy-weight solution. > > But if you are running DNSSEC on your local laptop, and the network only > allows dns to their forwarding nameservers, it is quite useful.... Yes, DNSSEC. I thought that someone come here with this argument. Current situation is bad. When dhcdbd package doesn't exist someone has to write support on NetworkManager side (not sure how much work it needs but from discussion with NM people it needs some development) and I (or someone else) have to write support into named nearly from scratch. I'm ready to do it on named side and try put it to upstream (or keep it downstream). Not sure what Dan Williams (or someone else from NM) thinks about this. > > > Also upstream will never accept such feature > > because this is not primary BIND mission. Domain name modification > > should be done with nsupdate utility through DDNS update message which > > is part of DNS protocol. > > But I don't think nsupdate can modify the forwarders configured right? > Yes you're right. I point that idea about configuring DNS RRs through D-Bus is completely wrong. Adam -- Adam Tkac, Red Hat, Inc. From david at fubar.dk Mon Dec 3 17:38:03 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Dec 2007 12:38:03 -0500 Subject: ata and scsi modules in initrd In-Reply-To: <20071203170803.GB1706@nostromo.devel.redhat.com> References: <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> <1196696083.7278.86.camel@oneill.fubar.dk> <20071203170803.GB1706@nostromo.devel.redhat.com> Message-ID: <1196703483.7278.111.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 12:08 -0500, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > [0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot, > > whatever etc. that isn't really interesting and not really hard either > > since most of this can also be driven by one-line udev rules. > > Aside from the rest of it, if you've got a one line udev rule that can > mount a nfs loopback device, I'm all for seeing it. :) If you think I'm suggesting to use udev like that you're misguieded. I'm not suggesting to use udev for that; that'd be like using a screwdriver for nails. Of course, nfsroot just another path in the initramfs. News at 11. > (Similarly, unless udev has grown a block device daemon to assemble > raid/lvm/etc....) Uhm, no, no daemon is needed; ffs, this is just handling events. Look e.g. here https://launchpad.net/ubuntu/+source/mdadm/ and see [1] for excerpt. Seriously, the point of my messages in this subthread is to fix user space instead of keep pretending the world isn't event driven. The other distros are doing this already. Fedora not participating in this means just that.. not participating. Meaning we will have little influence to fix things once someone realizes that our current course of action was a mistake. Instead, as Fedora, we should be the one leading this effort and rally all the distros around a common toolset. It's just frakking amazing how people working for Red Hat, in 2007, still don't understand why it's important to do their work upstream. Just mind boggling. And, in my view, also inexcusable. Not participating also means that doing things like LTSP is just going to get harder and harder; ask Warren about that http://wtogami.livejournal.com/20047.html David [1] : * md activation: - We now have a single udev rule for both the real system and the initramfs, since doing things differently there will only result in bugs and confusion. - This rule runs "mdadm --assemble --scan --no-degraded", automatically activating any non-degraded device as their components are detected. - Drop the mdadm-raid init script, since this does the same thing. - Also drop mdadm-startall which uses the mdadm-raid init script, and its associated sgml file (thus dropping the build-dep on docbook-to-man) - Simplify the configuration, since we always autostart all devices so do not need to specify any required root devices, etc. - Drop the deprecated mdrun entirely. - Since udev autostarts arrays, much of the initramfs script can be dropped. From david at fubar.dk Mon Dec 3 17:38:03 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Dec 2007 12:38:03 -0500 Subject: ata and scsi modules in initrd In-Reply-To: <20071203170803.GB1706@nostromo.devel.redhat.com> References: <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> <4753637A.20900@redhat.com> <1196696083.7278.86.camel@oneill.fubar.dk> <20071203170803.GB1706@nostromo.devel.redhat.com> Message-ID: <1196703483.7278.111.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 12:08 -0500, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > [0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot, > > whatever etc. that isn't really interesting and not really hard either > > since most of this can also be driven by one-line udev rules. > > Aside from the rest of it, if you've got a one line udev rule that can > mount a nfs loopback device, I'm all for seeing it. :) If you think I'm suggesting to use udev like that you're misguieded. I'm not suggesting to use udev for that; that'd be like using a screwdriver for nails. Of course, nfsroot just another path in the initramfs. News at 11. > (Similarly, unless udev has grown a block device daemon to assemble > raid/lvm/etc....) Uhm, no, no daemon is needed; ffs, this is just handling events. Look e.g. here https://launchpad.net/ubuntu/+source/mdadm/ and see [1] for excerpt. Seriously, the point of my messages in this subthread is to fix user space instead of keep pretending the world isn't event driven. The other distros are doing this already. Fedora not participating in this means just that.. not participating. Meaning we will have little influence to fix things once someone realizes that our current course of action was a mistake. Instead, as Fedora, we should be the one leading this effort and rally all the distros around a common toolset. It's just frakking amazing how people working for Red Hat, in 2007, still don't understand why it's important to do their work upstream. Just mind boggling. And, in my view, also inexcusable. Not participating also means that doing things like LTSP is just going to get harder and harder; ask Warren about that http://wtogami.livejournal.com/20047.html David [1] : * md activation: - We now have a single udev rule for both the real system and the initramfs, since doing things differently there will only result in bugs and confusion. - This rule runs "mdadm --assemble --scan --no-degraded", automatically activating any non-degraded device as their components are detected. - Drop the mdadm-raid init script, since this does the same thing. - Also drop mdadm-startall which uses the mdadm-raid init script, and its associated sgml file (thus dropping the build-dep on docbook-to-man) - Simplify the configuration, since we always autostart all devices so do not need to specify any required root devices, etc. - Drop the deprecated mdrun entirely. - Since udev autostarts arrays, much of the initramfs script can be dropped. From dcbw at redhat.com Mon Dec 3 17:56:28 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 03 Dec 2007 12:56:28 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> Message-ID: <1196704588.21151.10.camel@localhost.localdomain> On Mon, 2007-12-03 at 18:37 +0100, Adam Tkac wrote: > On Mon, Dec 03, 2007 at 12:20:58PM -0500, Paul Wouters wrote: > > On Mon, 3 Dec 2007, Adam Tkac wrote: > > > > > For clarify what exactly discussed feature did (nothing more). When you get > > > nameservers from DHCP dhcdbd tells to named through DBUS that named > > > should use them as forwarders and NetworkManager sets 127.0.0.1 as > > > default nameserver in resolv.conf. So you could use named as > > > caching-nameserver on laptops and you don't have to edit named.conf > > > always when you move to different network. I think it makes sence add > > > this feature to some light DNS server but not into named. It's simply > > > too heavy-weight solution. > > > > But if you are running DNSSEC on your local laptop, and the network only > > allows dns to their forwarding nameservers, it is quite useful.... > > Yes, DNSSEC. I thought that someone come here with this argument. Current > situation is bad. When dhcdbd package doesn't exist someone has to write > support on NetworkManager side (not sure how much work it needs but from > discussion with NM people it needs some development) and I (or someone > else) have to write support into named nearly from scratch. I'm ready > to do it on named side and try put it to upstream (or keep it downstream). > Not sure what Dan Williams (or someone else from NM) thinks about this. NM is going to have to export the DHCP information in any case; the best option is a pull model where clients can query NM for the DHCP information they want based on what the current connection is. In the future, connections may span devices due to bonding/bridging/connection-sharing or whatever, and the connection is the thing that gets brought up, not the interface. And since DNS information is global to the machine (not specific to the interface but can be tweaked based on _routes_) this requires that programs that want to know about the DHCP information will need to ask first for the list of active connections, and second for the DHCP information (if any!) associated with that connection. When NM gets multiple active device support, there may be more than one active connection, and each connection may have DHCP information. Not sure how named would want to handle those cases. Dan > > > > > Also upstream will never accept such feature > > > because this is not primary BIND mission. Domain name modification > > > should be done with nsupdate utility through DDNS update message which > > > is part of DNS protocol. > > > > But I don't think nsupdate can modify the forwarders configured right? > > > > Yes you're right. I point that idea about configuring DNS RRs through > D-Bus is completely wrong. > > Adam > > -- > Adam Tkac, Red Hat, Inc. > From bernie at codewiz.org Mon Dec 3 18:02:05 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 03 Dec 2007 13:02:05 -0500 Subject: Bootup speed for F8 In-Reply-To: <1196702955.2303.17.camel@localhost.localdomain> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196445465.22277.60.camel@localhost.localdomain> <4750A487.3050901@codewiz.org> <1196702955.2303.17.camel@localhost.localdomain> Message-ID: <4754449D.3040905@codewiz.org> Adam Jackson wrote: > I haven't looked at evdev yet, I'm sure there's disasters there too. I had a look, and I'm still recovering :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From databasearia at yahoo.com Mon Dec 3 18:05:21 2007 From: databasearia at yahoo.com (Nevruz Mesut Sahin) Date: Mon, 3 Dec 2007 10:05:21 -0800 (PST) Subject: I have a problem with Courier Imap Message-ID: <829000.38711.qm@web32604.mail.mud.yahoo.com> I have problem with installing Courier Imap . when I try to install courier-imap-pop3-1.5.3-5.i386.rpm but it conflicts Cyrus Sasl and needs courier-imap-common. then I tried to install courier-imap-common but this time it needs rc-scripts then I tried to install rc-scripts but it gives errors bellow. please help me how can I install courier-imap error: Failed dependencies: bdflush is needed by rc-scripts-0.3.1-13.i686 iproute2 is needed by rc-scripts-0.3.1-13.i686 initscripts < 4.26 conflicts with setup-2.5.49-1.noarch initscripts <= 5.30-1 conflicts with chkconfig-1.3.29-1.i386 initscripts < 6.55 conflicts with psacct-6.3.2-41.i386 initscripts < 7.84 conflicts with udev-084-13.fc5.2.i386 initscripts < 7.23 conflicts with kernel-smp-2.6.20-1.2312.fc5.i686 initscripts < 7.23 conflicts with kernel-2.6.20-1.2312.fc5.i586 initscripts < 7.23 conflicts with kernel-2.6.20-1.2319.fc5.i586 initscripts < 7.23 conflicts with kernel-smp-2.6.20-1.2319.fc5.i686 initscripts < 7.23 conflicts with (installed) kernel-smp-2.6.20-1.2312.fc5.i686 initscripts < 7.23 conflicts with (installed) kernel-2.6.20-1.2312.fc5.i586 initscripts < 7.23 conflicts with (installed) kernel-2.6.20-1.2319.fc5.i586 initscripts < 7.23 conflicts with (installed) kernel-smp-2.6.20-1.2319.fc5.i686 /sbin/service is needed by (installed) distcache-1.4.5-13.i386 /sbin/service is needed by (installed) cyrus-sasl-2.1.21-10.i386 /sbin/service is needed by (installed) postfix-2.2.8-1.2.i386 /sbin/service is needed by (installed) bluez-utils-2.25-4.i386 /sbin/service is needed by (installed) irqbalance-1.12-1.25.i386 /sbin/service is needed by (installed) rng-utils-2.0-1.11.i386 /sbin/service is needed by (installed) xinetd-2.3.13-6.2.1.i386 /sbin/service is needed by (installed) acpid-1.0.4-2.i386 /sbin/service is needed by (installed) rp-pppoe-3.5-31.i386 /sbin/service is needed by (installed) cpuspeed-1.2.1-1.36.fc5.i386 /sbin/service is needed by (installed) yum-2.6.1-0.fc5.noarch /sbin/service is needed by (installed) vixie-cron-4.1-58.fc5.i386 /sbin/service is needed by (installed) vnc-4.1.1-39.fc5.i386 /sbin/service is needed by (installed) smartmontools-5.36-fc5.1.i386 /sbin/service is needed by (installed) proftpd-1.3.0a-3.fc5.i386 /sbin/service is needed by (installed) cyrus-imapd-2.3.1-2.8.fc5.i386 --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayvd at bludgeon.org Mon Dec 3 18:06:42 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 3 Dec 2007 10:06:42 -0800 Subject: [Fedora-legal-list] DJB's software components In-Reply-To: <475266F0.5030902@codewiz.org> References: <1196432626.9238.1.camel@localhost.localdomain> <1196440081.9238.7.camel@localhost.localdomain> <475266F0.5030902@codewiz.org> Message-ID: <20071203180640.GA31149@bludgeon.org> On Sun, Dec 02, 2007 at 03:04:00AM -0500, Bernardo Innocenti wrote: > Tom "spot" Callaway wrote: > > > And the answer is that we are fine to pick these up. Hold lifted. > > Nice! Is anyone working on packaging qmail already? Might be worth looking and possibly reusing some of qmailtoaster's work on this (they have src RPM's with many patches as well). Ray From buildsys at fedoraproject.org Mon Dec 3 18:21:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 3 Dec 2007 13:21:37 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-03 Message-ID: <20071203182137.EFB4415212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 3 NEW blitz-0.9-3.fc6 : C++ class library for matrix scientific computing fvwm-2.5.24-1.fc6 wcstools-3.7.0-1.fc6 Changes in Fedora Extras 6: blitz-0.9-3.fc6 --------------- * Wed Oct 17 2007 Sergio Pascual 0.9-3 - Removed macro in changelog - Description updated fvwm-2.5.24-1.fc6 ----------------- * Sun Dec 02 2007 Adam Goode - 2.5.24-1 - New upstream release - Fixes segfault (#382321) * Tue Oct 02 2007 Adam Goode - 2.5.23-3 - Change htmlview to xdg-open (thanks, Ville Skytt? !) * 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 * Tue Aug 21 2007 Adam Goode - 2.5.21-5 - Update license tag - Rebuild for buildid wcstools-3.7.0-1.fc6 -------------------- * Wed Sep 05 2007 Sergio Pascual 3.7.0-1 - New upstream source 3.7.0 * Mon Aug 27 2007 Sergio Pascual 3.6.8-2.1 - Rebuild for Fedora 8 to get the build-id From ndbecker2 at gmail.com Mon Dec 3 18:30:07 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 03 Dec 2007 13:30:07 -0500 Subject: texlive conflicts References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> <20071203171156.GA2996@dhcp-lab-186.brq.redhat.com> Message-ID: Jindrich Novy wrote: > On Mon, Dec 03, 2007 at 05:13:38PM +0100, Milos Jakubicek wrote: >> Matthew Saltzman napsal(a): >>> On Mon, 2007-12-03 at 13:21 +0100, Jindrich Novy wrote: >>>> Hi all, >>>> >>>> I come with good news for TeX users in Fedora. TeXLive is now finally >>>> imported and built in rawhide since today. >>> >>> Can the rawhide version be used as is in F8 or are there F8 RPMs that we >>> can test? >> >> I use TexLive (instead of TeTex) from the following repository (created >> by Jindrich Novy) on F8 without any problems: >> >> [texlive] >> name=TeXLive 2007 for Fedora Core $releasever - $basearch >> baseurl=http://people.redhat.com/jnovy/files/texlive/$basearch >> enabled=1 >> gpgcheck=0 > > Yes, it should work fine because rawhide doesn't differ from F8 too > much yet. I'll keep this repo for a while so that F8 users could > use TeXLive on F8. > > Jindrich > >> >> Regards, >> Milos Jakubicek >> >>> >>>> Enjoy, >>>> Jindrich >>>> >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > transaction Check Error: file /usr/share/texmf/doc/ptex/ptex-src/Changes.txt from install of texlive-2007-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 file /usr/share/texmf/doc/mendexk/COPYRIGHT.jis from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 file /usr/share/texmf/doc/mendexk/ChangeLog from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 file /usr/share/texmf/doc/mendexk/README from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 From debarshi.ray at gmail.com Mon Dec 3 18:48:04 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Dec 2007 00:18:04 +0530 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <20071203095802.6541646a@redhat.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> Message-ID: <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> > It's now tagged for this. I apologize for the delay. Thank you. :-) However, trying to create an update for Fedora 8 from Bodhi says that an update for bouml-doc-3.0-2 already exists. It is obviously colliding with the update that I earlier created for Fedora 7. So does this require me to do anything, or the tagging will cause things to happen automagically? Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jkeating at redhat.com Mon Dec 3 19:02:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Dec 2007 14:02:31 -0500 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> Message-ID: <20071203140231.4f1f4fb2@redhat.com> On Tue, 4 Dec 2007 00:18:04 +0530 "Debarshi 'Rishi' Ray" wrote: > Thank you. :-) > > However, trying to create an update for Fedora 8 from Bodhi says that > an update for bouml-doc-3.0-2 already exists. It is obviously > colliding with the update that I earlier created for Fedora 7. So does > this require me to do anything, or the tagging will cause things to > happen automagically? Oh right, that's why i didn't do it before. I was waiting for you to push your F7 update to final, which would make it show up in the F8 and rawhide collections automatically. Please push your F7 to final, and I'll clear the way for inheritance to make it show up elsewhere. -- 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 Mon Dec 3 19:17:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 3 Dec 2007 14:17:30 -0500 Subject: network manager command-line control? In-Reply-To: <1196699071.3300.32.camel@localhost.localdomain> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699071.3300.32.camel@localhost.localdomain> Message-ID: <20071203191730.GA2263@jadzia.bu.edu> On Mon, Dec 03, 2007 at 11:24:31AM -0500, Jeremy Katz wrote: > > Specifically, my laptop generates a custom Sony ACPI button event when the > > wireless antenna is switched on or off -- I'd like to automatically enable > > or disable wireless networking correspondingly. Is there an easy way to do > > this that I'm just not seeing? Thanks. > The right fix for this is for the kernel to hook the ACPI event properly > into generating a kill switch event rather than piling on hacks ;) Yup, but that's unlikely to actually happen anytime soon, particularly for this model of laptop. Having a general interface lets one work around all sorts of similar cases, some of which may not be associated with ACPI events. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Dec 3 19:24:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 3 Dec 2007 14:24:07 -0500 Subject: network manager command-line control? In-Reply-To: <1196699870.2447.4.camel@localhost.localdomain> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699870.2447.4.camel@localhost.localdomain> Message-ID: <20071203192407.GB2263@jadzia.bu.edu> On Mon, Dec 03, 2007 at 11:37:50AM -0500, Dan Williams wrote: > All the functionality is currently available with dbus-send. However, > since that's the case, it would be nice to have a CLI tool that > interfaces in a nicer manner than dbus-send. I'd like to have something > like that too, but haven't had time to look into it. It would be a > great opportunity for somebody to jump in. Is there somewhere where all of the messages that can be sent are documented? It's a bit daunting.... > Jeremy has an excellent answer to this question :) There's already an > rfkill framework in the kernel, your upstream Sony ACPI kernel module > needs to hook into that. In the short term, if you _really_ don't want > to make the world a better place by pressuring upstream Sony ACPI module > authors to do the right thing, look at dbus-send, use the D-Bus property Guilt trip, eh? :) > interface on the base NetworkManager object, and set the WirelessEnabled > property to true/false depending on what the custom events say. By > doing this and not making upstream better, you agree to sacrifice 3 > small, adorable, mewing kittens each time you flip the rfkill switch. Ooooh, now *there's* the guilt trip. maybe I can do *both*. I'll go read up on rfkill now. > > (Also, is there a way to supress the pop-up messages about changes in > > connections status? I find them more obtrusive and distracting than > > helpful.) > We could add an option to the applet to disable them, yes. That would make me oh-so-happy. I'll sacrifice *any number* of kittens for you if you'll do this. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mjs at CLEMSON.EDU Mon Dec 3 20:06:12 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Mon, 03 Dec 2007 15:06:12 -0500 Subject: texlive conflicts In-Reply-To: References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> <20071203171156.GA2996@dhcp-lab-186.brq.redhat.com> Message-ID: <1196712372.12824.2.camel@vincent52.localdomain> On Mon, 2007-12-03 at 13:30 -0500, Neal Becker wrote: > Jindrich Novy wrote: > > Yes, it should work fine because rawhide doesn't differ from F8 too > > much yet. I'll keep this repo for a while so that F8 users could > > use TeXLive on F8. Thanks from me as well for all your work in this. > transaction Check Error: > file /usr/share/texmf/doc/ptex/ptex-src/Changes.txt from install of texlive-2007-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/COPYRIGHT.jis from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/ChangeLog from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/README from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 Also, the tetex-prosper package is not replaced by anything in the texlive repo. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From tmraz at redhat.com Mon Dec 3 20:10:34 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 03 Dec 2007 21:10:34 +0100 Subject: Beecrypt retired Message-ID: <1196712634.3037.29.camel@vespa.kabelta.loc> Nobody stepped up to maintain this crypto library which is no longer used by rpm or anything else in Fedora. So the next logical step is to retire this package from rawhide (dist-f9). I will do that tomorrow. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dakingun at gmail.com Mon Dec 3 20:16:46 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 3 Dec 2007 15:16:46 -0500 Subject: texlive conflicts In-Reply-To: <1196712372.12824.2.camel@vincent52.localdomain> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> <20071203171156.GA2996@dhcp-lab-186.brq.redhat.com> <1196712372.12824.2.camel@vincent52.localdomain> Message-ID: On Dec 3, 2007 3:06 PM, Matthew Saltzman wrote: > > > Also, the tetex-prosper package is not replaced by anything in the > texlive repo. > tetex-prosper is a separate, external tetex addon package. It is not a sub-package of tetex. Deji > -- > Matthew Saltzman > > Clemson University Math Sciences > mjs AT clemson DOT edu > http://www.math.clemson.edu/~mjs > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pertusus at free.fr Mon Dec 3 20:29:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 3 Dec 2007 21:29:27 +0100 Subject: TeXLive is in rawhide In-Reply-To: <645d17210712030927g7f13ceb2h57ef0445fb4b954b@mail.gmail.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <645d17210712030927g7f13ceb2h57ef0445fb4b954b@mail.gmail.com> Message-ID: <20071203202927.GA2671@free.fr> On Mon, Dec 03, 2007 at 05:27:02PM +0000, Jonathan Underwood wrote: > On 03/12/2007, Jindrich Novy wrote: > > Hi all, > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > imported and built in rawhide since today. > > > > Enjoy, > > Jindrich > > Jindrich, many thanks for this, looking at the spec files, one can > really appreciate what a monumental packaging feat this is. > > Is the plan to keep tetex in rawhide for a transitional period? Moving > to TeXlive means some packaging renaming (did that tex-foo guideline > ever get past the packaging committee?) and some adjusting of Yes, the tex-foo naming is now the guideline. But I think that the package renaming issue is orthogonal to the tex dependencies issues. > BuildRequires and Requires. (and some Obsoletes and Provides too). Texlive Provides and Obsoletes tetex, so it seems to me that, currently requiring tetex is still right. Once/if the virtual provides, like TeX and LaTeX are added (Jindrich was ok with that) it will become better to switch to that provide, in my opinion, for new stuff, and make sure that it is in RHEL 6 for EPEL. -- Pat From pertusus at free.fr Mon Dec 3 20:31:09 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 3 Dec 2007 21:31:09 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Message-ID: <20071203203109.GB2671@free.fr> On Mon, Dec 03, 2007 at 01:21:32PM +0100, Jindrich Novy wrote: > Hi all, > > I come with good news for TeX users in Fedora. TeXLive is now finally > imported and built in rawhide since today. There are still some potential issues regarding post scripts, since it is not sure that post scripts that should be run once everything is there (like updmap) are run at the right time. If somebody can tell if things are right or wrong it would be nice. -- Pat From Michael_E_Brown at dell.com Mon Dec 3 20:59:26 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 14:59:26 -0600 Subject: mock 0.8.9 In-Reply-To: <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203061145.GF4039@humbolt.us.dell.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> Message-ID: <20071203205926.GA14186@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 06:45:23AM -0200, Paulo Cavalcanti wrote: > On Dec 3, 2007 4:11 AM, Michael E Brown wrote: > > > On Sun, Dec 02, 2007 at 07:22:22PM -0200, Paulo Cavalcanti wrote: > > > I am trying to use mock 0.8. > > > > > > Executing a simple man mock, gives me: > > > > > > SYNTAX > > > mock [options] --rebuild SRPM [SRPM...] > > > > > > mock [options] --chroot > > > > > > mock [options] {--init|clean|shell} > > > > > > mock [options] --installdeps {SRPM|RPM} > > > > > > mock [options] --install PACKAGE > > > > > > ---------------------------------------------------------- > > > > > > In fact, > > > > > > mock -r fedora-8-i386 --init > > > > > > does not work at all. It must be: > > > > > > mock -r fedora-8-i386 init > > > > > > Therefore, I think that an update for man mock (0.8.9) is in order, > > right? > > > It was this way in mock 0.7. > > > > This was something I overlooked and it is fixed in 0.8.10 already, which > > should be making its way to testing repos. > > > > Thanks. I filed a bug report anyway. > > Just a curiosity, what is the reason for the change? > mock is written in python, and it would have been simpler > to parse the arguments keeping the "--". Actually, this was the change that was made. Old way: "rebuild", new way: "--rebuild". I've tried to keep backwards compatibility for people using the old method and dont intend to drop that. > > Another thing is that in version 0.7 I could open a mock shell > and check the installed rpms or install an rpm (rpm -ivh). If I try this > in version 0.8 I get an error. I know I can use mock install outside > the mock shell, but via shell should still work in my opinion. It would be easier to debug given the actual error output. New mock provides "mock --install REPOPKG" if you want to install an RPM from one of the configured repos. > Finally, how do I pass an argument for building via mock, > > --define or --with something? you can pass it in the .rpmmacros file by editing the mock config file. Look in /etc/mock/defaults.cfg for information, see the config_opts['macros'] line. You can put this directive in the chroot config file or the defaults.cfg file. -- Michael From lsof at nodata.co.uk Mon Dec 3 21:08:25 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 03 Dec 2007 22:08:25 +0100 Subject: Bootup speed for F8 In-Reply-To: <4753A8F9.8010807@gmail.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <1196523133.5807.3.camel@Diffingo.localdomain> <1196556618.31181.7.camel@Diffingo.localdomain> <4753A8F9.8010807@gmail.com> Message-ID: <1196716105.2913.2.camel@sb-home> Am Sonntag, den 02.12.2007, 22:58 -0800 schrieb Andrew Farris: > Stewart Adam wrote: > > On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote: > >> Depends on how you define boot time. If you say boot is done when the > >> system is interactive, you cut several seconds. > >> > >> "Other OS:es" obviously use this approach, the perceptual being what > >> matters. > >> > >> Surely, this must be fixable, it'd be such a boost.. > >> > >> Linus > > That's exactly what I mean - An early login can make the boot seem to > > boot much faster even if it really isn't. Waiting is what makes things > > seem long; the faster the user interacts, the faster things seem. > > > > Stewart > > Sure thats true, but perception is also just a fake improvement, and once the > user gets used to seeing the login earlier... I want to login more quickly and start gnome-terminal, sometimes Firefox. What do other people want to do? > they'll get more and more > discontent with how long it takes to be usable after they logged in (afterall Better stay away from that slippery slope of progress then! > they *already logged in*). For a great example of why this can be frustrating, > install a copy of Vista; its 'boot time' is great, Yep. It's really fast, versus Fedora which takes a couple of minutes. > but you login and wait... and > wait... and wait. When you do see the desktop you still can't do anything > useful I can load putty or Firefox. That's quite useful. > with it because the system is still so heavily loaded with background > processes starting. Its much the same with xp, but vista made it even worse, > while the 'boot time' is even lower. Works for me. Resume takes just a few seconds too. > I have always appreciated the fact that a machine thats STARTED in linux can be > logged into quickly and be useful with minimal delay. The general case with > windows which delays many background processes until login is that you can boot > your system and walk away to get coffee... but when you come back you'll still > sit there waiting after login before you can work. > > I'm only bringing up the windows comparison for contrast, because MS has been > working hard to bring about this same early login illusion. > > Making the system *actually usable* sooner is where development time and effort > should be spent rather than spending time to fake it. If a valid argument can > be made for a method to get desktop software to begin processing earlier due to > early login then lets talk about that. If its nothing more than login without > letting CPU cycles go toward the desktop startup then why bother? > > -- > Andrew Farris > gpg 0xC99B1DF3 at pgp.mit.edu > > No one now has, and no one will ever again get, the big picture. - Daniel Geer > ---- ---- > From dcbw at redhat.com Mon Dec 3 21:14:25 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 03 Dec 2007 16:14:25 -0500 Subject: network manager command-line control? In-Reply-To: <20071203191730.GA2263@jadzia.bu.edu> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699071.3300.32.camel@localhost.localdomain> <20071203191730.GA2263@jadzia.bu.edu> Message-ID: <1196716465.31607.8.camel@localhost.localdomain> On Mon, 2007-12-03 at 14:17 -0500, Matthew Miller wrote: > On Mon, Dec 03, 2007 at 11:24:31AM -0500, Jeremy Katz wrote: > > > Specifically, my laptop generates a custom Sony ACPI button event when the > > > wireless antenna is switched on or off -- I'd like to automatically enable > > > or disable wireless networking correspondingly. Is there an easy way to do > > > this that I'm just not seeing? Thanks. > > The right fix for this is for the kernel to hook the ACPI event properly > > into generating a kill switch event rather than piling on hacks ;) > > Yup, but that's unlikely to actually happen anytime soon, particularly for > this model of laptop. Well, if somebody doesn't do it, it's going to get harder and harder to use that functionality then with newer releases of the kernel or other parts. > Having a general interface lets one work around all sorts of similar cases, > some of which may not be associated with ACPI events. The general interface for rfkill switches _is_ the rfkill layer in the kernel. It doesn't just hook into the ACPI layer. It hooks into ACPI, the drivers themselves, and the normal input layer. Macs don't have ACPI, and their drivers can hook in just fine. The point is that if you hook into the rfkill layer, you no longer have to "work around all sorts of similar cases", because there arent any cases anymore, they all conform to the standard interface and Just Work. Dan From ville.skytta at iki.fi Mon Dec 3 21:46:55 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 3 Dec 2007 23:46:55 +0200 Subject: mock 0.8.9 In-Reply-To: <20071203205926.GA14186@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> <20071203205926.GA14186@humbolt.us.dell.com> Message-ID: <200712032346.55800.ville.skytta@iki.fi> On Monday 03 December 2007, Michael E Brown wrote: > On Mon, Dec 03, 2007 at 06:45:23AM -0200, Paulo Cavalcanti wrote: > > > Finally, how do I pass an argument for building via mock, > > > > --define or --with something? > > you can pass it in the .rpmmacros file by editing the mock config file. > Look in /etc/mock/defaults.cfg for information, see the > config_opts['macros'] line. > > You can put this directive in the chroot config file or the defaults.cfg > file. mach can do that from the command line. I suppose the mock and mach code bases are pretty different nowadays but this feature could be an easy one to bring back from mach (or reimplement) - I think it's an important one. From poelstra at redhat.com Mon Dec 3 21:52:35 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 03 Dec 2007 13:52:35 -0800 Subject: TeXLive is in rawhide In-Reply-To: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Message-ID: <47547AA3.2030000@redhat.com> Jindrich Novy said the following on 12/03/2007 04:21 AM Pacific Time: > Hi all, > > I come with good news for TeX users in Fedora. TeXLive is now finally > imported and built in rawhide since today. > > Enjoy, > Jindrich > Excellent. Does that mean this page can be updated http://fedoraproject.org/wiki/Releases/FeatureTexLive If "yes", please update :) Thanks, John From Michael_E_Brown at dell.com Mon Dec 3 22:08:41 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 16:08:41 -0600 Subject: mock 0.8.9 In-Reply-To: <200712032346.55800.ville.skytta@iki.fi> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> <20071203205926.GA14186@humbolt.us.dell.com> <200712032346.55800.ville.skytta@iki.fi> Message-ID: <20071203220840.GB14186@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 11:46:55PM +0200, Ville Skytt? wrote: > On Monday 03 December 2007, Michael E Brown wrote: > > On Mon, Dec 03, 2007 at 06:45:23AM -0200, Paulo Cavalcanti wrote: > > > > > Finally, how do I pass an argument for building via mock, > > > > > > --define or --with something? > > > > you can pass it in the .rpmmacros file by editing the mock config file. > > Look in /etc/mock/defaults.cfg for information, see the > > config_opts['macros'] line. > > > > You can put this directive in the chroot config file or the defaults.cfg > > file. > > mach can do that from the command line. I suppose the mock and mach code > bases are pretty different nowadays but this feature could be an easy one to > bring back from mach (or reimplement) - I think it's an important one. Patches welcome. -- Michael From chasd at silveroaks.com Mon Dec 3 22:18:14 2007 From: chasd at silveroaks.com (chasd) Date: Mon, 3 Dec 2007 16:18:14 -0600 Subject: InstantMirror-0.2 Release In-Reply-To: <20071122071558.4210573F9D@hormel.redhat.com> References: <20071122071558.4210573F9D@hormel.redhat.com> Message-ID: > http://fedorapeople.org/~wtogami/temp/InstantMirror-release/ > InstantMirror-0.2-0.fc8.src.rpm Runs on F7 too. Thank you for this, it works well in our small business environment where conserving bandwidth to the internet is important. > We still don't have a hosted.fp.org project setup yet so the above is > only the temporary location. Until we have that permanent project > setup, please report bugs and make suggestions for improvement here in > this thread. The included InstantMirror.conf file that goes into /etc/httpd/ conf.d/ stomps on any other configuration you may have set up. Because the file name starts with an upper case "eye" it is loaded first by the Include conf.d/*.conf directive. It becomes the _default_ host for everything on port 80. You can check how that works by /usr/sbin/httpd -S mv /etc/httpd/conf.d/InstantMirror.conf /etc/httpd/conf.d/ zInstantMirror.conf /usr/sbin/httpd -S ( move it back if you prefer the stomping behavior ) From > Main host goes away > > If you are adding virtual hosts to an existing web server, you must > also create a block for the existing host. The > ServerName and DocumentRoot included in this virtual host should be > the same as the global ServerName and DocumentRoot. List this > virtual host first in the configuration file so that it will act as > the default host. This directive NameVirtualHost *:80 should be uncommented in /etc/httpd/conf/httpd.conf and a directive should be set up for the default web content, and should be loaded before the InstantMirror.conf file. I have something that works with my test system, but I'm still not in a position to make a bomb-proof generalized config file recommendation. It seems using VirtualHost is the best way to create the Instant Mirror, but integrating that into an existing apache conf needs to be handled with a bit more care. This could be communicated with better comments or additional commented out directives in the provided InstantMirror.conf file. I use several files in conf.d to create aliases and WebDAV collections for calendaring and file sharing on our main server. I haven't tested yet with all those conf files mixed in. Also, I think separating the logging is a good thing to do with directives such as ErrorLog logs/mirror-error_log CustomLog logs/mirror-access_log within the InstantMirror virtual host block. That way when the python script throws a hissy fit about file permissions, it is easier to find. Thanks again for InstantMirror, Charles Dostale From seg at haxxed.com Mon Dec 3 22:19:04 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 03 Dec 2007 16:19:04 -0600 Subject: DJB's software components In-Reply-To: References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> <20071201140913.GA9617@devserv.devel.redhat.com> Message-ID: <1196720344.18776.7.camel@localhost> On Mon, 2007-12-03 at 13:32 +0100, Matej Cepl wrote: > Which was the reason I was shocked DJB released qmail under public domain > and why I would always prefer at least MIT/X/BSD-no-appropriation/CC-au > always. IIRC, sqlite is the only substantial software which is under > public domain and there is a reason for that. IANAL, but doesn't this mean he's effectively released it under *every* license ever written? :) Are we going to have GPL and BSD forks battling it out now? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From s.adam at diffingo.com Mon Dec 3 22:22:59 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Mon, 03 Dec 2007 17:22:59 -0500 Subject: Bootup speed for F8 In-Reply-To: <4753A8F9.8010807@gmail.com> References: <1196375699.3036.9.camel@dimi.lattica.com> <474F40C0.6050102@redhat.com> <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <1196523133.5807.3.camel@Diffingo.localdomain> <1196556618.31181.7.camel@Diffingo.localdomain> <4753A8F9.8010807@gmail.com> Message-ID: <1196720579.4648.6.camel@Diffingo.localdomain> - Stewart Adam Diffingo Solutions Inc. Tel: 450.447.2758 Web: www.diffingo.com On Sun, 2007-12-02 at 22:58 -0800, Andrew Farris wrote: > Sure thats true, but perception is also just a fake improvement, and once the > user gets used to seeing the login earlier... they'll get more and more > discontent with how long it takes to be usable after they logged in (afterall > they *already logged in*). For a great example of why this can be frustrating, > install a copy of Vista; its 'boot time' is great, but you login and wait... and > wait... and wait. When you do see the desktop you still can't do anything > useful with it because the system is still so heavily loaded with background > processes starting. Its much the same with xp, but vista made it even worse, > while the 'boot time' is even lower. > > I have always appreciated the fact that a machine thats STARTED in linux can be > logged into quickly and be useful with minimal delay. The general case with > windows which delays many background processes until login is that you can boot > your system and walk away to get coffee... but when you come back you'll still > sit there waiting after login before you can work. > > I'm only bringing up the windows comparison for contrast, because MS has been > working hard to bring about this same early login illusion. > > Making the system *actually usable* sooner is where development time and effort > should be spent rather than spending time to fake it. If a valid argument can > be made for a method to get desktop software to begin processing earlier due to > early login then lets talk about that. If its nothing more than login without > letting CPU cycles go toward the desktop startup then why bother? I agree, but the point I'm trying to bring up is let's do both in moderation. Hacking to reduce boot time can only shorten it by so much; At one point, there will be nothing left to shorten. An early login can also only do so much before annoying the users (because like you say do it too much and it makes the login unresponsive). But the two put together and you get a quick and responsive boot up. Stewart From bojan at rexursive.com Mon Dec 3 23:52:47 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 04 Dec 2007 10:52:47 +1100 Subject: Mock busted? Message-ID: <1196725967.15509.206.camel@shrek.rexursive.com> Is mock busted in Koji right now? I'm getting failures like this: ------------------------ /etc/profile: line 38: /bin/hostname: No such file or directory sh: /usr/sbin/apxs: No such file or directory ------------------------ My package (libapreq2) has httpd-devel as a dependency, so apxs should be there. Also: ------------------------ Error: Missing Dependency: libldap-2.3.so.0()(64bit) is needed by package mod_perl Error: Missing Dependency: liblber-2.3.so.0()(64bit) is needed by package mod_perl Error: Missing Dependency: libldap-2.3.so.0()(64bit) is needed by package apr-util Error: Missing Dependency: liblber-2.3.so.0()(64bit) is needed by package apr-util Error: Missing Dependency: liblber-2.3.so.0()(64bit) is needed by package httpd Error: Missing Dependency: libldap-2.3.so.0()(64bit) is needed by package httpd Error: Missing Dependency: libldap-2.3.so.0()(64bit) is needed by package httpd-tools Error: Missing Dependency: libssl.so.6()(64bit) is needed by package httpd-tools Error: Missing Dependency: liblber-2.3.so.0()(64bit) is needed by package httpd-tools Error: Missing Dependency: libcrypto.so.6()(64bit) is needed by package httpd-tools ------------------------ -- Bojan From tcallawa at redhat.com Tue Dec 4 00:07:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 04 Dec 2007 05:37:04 +0530 Subject: Broken BuildRequires in rawhide In-Reply-To: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> References: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1196726824.3338.51.camel@localhost.localdomain> On Mon, 2007-12-03 at 16:57 +0100, Michael Schwendt wrote: > package: perl-Perl-MinimumVersion - 0.15-1.fc9.src from > fedora-development-source > unresolved deps: > perl(version) >= 0:0.7203 This is broken because perl(version) likes to play stupid games with its versioning, and we have to use epoch to keep ordering sane. It is currently at 2:0.74, but the perl(FOO) provides don't reflect epoch... so: [spot at localhost ~]$ rpm -q perl-version --provides perl(version) = 0.74 perl(version::vxs) = 0.74 vxs.so()(64bit) perl-version = 2:0.74-1.fc9 That should help the Perl::MinimumVersion maintainer fix the BR. ~spot From tcallawa at redhat.com Tue Dec 4 00:18:24 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 04 Dec 2007 05:48:24 +0530 Subject: DJB's software components In-Reply-To: <1196720344.18776.7.camel@localhost> References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> <20071201140913.GA9617@devserv.devel.redhat.com> <1196720344.18776.7.camel@localhost> Message-ID: <1196727504.3338.53.camel@localhost.localdomain> On Mon, 2007-12-03 at 16:19 -0600, Callum Lerwick wrote: > On Mon, 2007-12-03 at 13:32 +0100, Matej Cepl wrote: > > Which was the reason I was shocked DJB released qmail under public domain > > and why I would always prefer at least MIT/X/BSD-no-appropriation/CC-au > > always. IIRC, sqlite is the only substantial software which is under > > public domain and there is a reason for that. > > IANAL, but doesn't this mean he's effectively released it under *every* > license ever written? :) Are we going to have GPL and BSD forks battling > it out now? Its possible, but Public Domain means something closer to "no license" than "every license". We could see forks battling it out, but somehow, I doubt this will happen. ~spot From razvan.vilt at linux360.ro Tue Dec 4 00:24:48 2007 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. VILT) Date: Tue, 04 Dec 2007 02:24:48 +0200 Subject: Sun releases APOC Message-ID: <1196727888.2814.17.camel@fedora.buh.htpassport.net> While stuff released by Sun Microsystems is not really what fedora-devel is usually about, this little piece of technology, with a design simple enough for every admin to understand, does change a lot in enterprise deployment, and seems to be a natural complement to the FreeIPA project. What it is all about is rather simple: Having a "centralized storage for application and desktop configuration". In APOC's case it's a LDAP server. I can only dream of the day in which my GAIM and Evolution settings can be loaded on a PDA (say N800) or another new workstation from the LDAP server, as well as imposing settings for my users. While the first one can be solved by a NFS or CIFS mount, the second one is not really that elegantly solved. >From my point of view it's the most elegant approach to this problem and I hope that the Fedora Project plans to include it's wonderful functionality into future versions of the distribution. I am aware of the fact that everything that APOC does can be replicated using some other mechanisms, but none is as elegant as storing everything in a LDAP server, and it obviously makes more sense to do so considering that FreeIPA and Samba4 and many other projects base their data storage on LDAP. With stuff like this, easily manageable UNIX desktops seem to be closer every day. I am rather curious on what you guys think. Cheers, Razvan P.S.: Before you ask, YES it's GPL 2.0 (dual-licensed with CDDL) and it's hosted at freedesktop.org ( http://apoc.freedesktop.org/wiki/ to be more exact) From debarshi.ray at gmail.com Tue Dec 4 02:00:12 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Dec 2007 07:30:12 +0530 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <20071203140231.4f1f4fb2@redhat.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> <20071203140231.4f1f4fb2@redhat.com> Message-ID: <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> > Please push your F7 to final, and > I'll clear the way for inheritance to make it show up elsewhere. I just marked it as stable for Fedora 7. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From the.masch at gmail.com Tue Dec 4 02:32:14 2007 From: the.masch at gmail.com (masch) Date: Mon, 3 Dec 2007 21:32:14 -0500 Subject: Proposal for Fedora - "GKSUDO" Message-ID: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> Hi! Is it possible to include any utility link in Ubuntu gksu, gksudo, gnomesu or gnomesudo?? It's really usefully for some scripts Thanks Salu2... From mattdm at mattdm.org Tue Dec 4 02:36:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 3 Dec 2007 21:36:32 -0500 Subject: network manager command-line control? In-Reply-To: <1196716465.31607.8.camel@localhost.localdomain> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699071.3300.32.camel@localhost.localdomain> <20071203191730.GA2263@jadzia.bu.edu> <1196716465.31607.8.camel@localhost.localdomain> Message-ID: <20071204023632.GA5847@jadzia.bu.edu> On Mon, Dec 03, 2007 at 04:14:25PM -0500, Dan Williams wrote: > > Yup, but that's unlikely to actually happen anytime soon, particularly > > for this model of laptop. > Well, if somebody doesn't do it, it's going to get harder and harder to > use that functionality then with newer releases of the kernel or other > parts. The sonypi controller in this particular laptop (a Vaio U101) is somehow odd. Perhaps something's not getting initialized right, or something else is wrong... worked fine in Windows, but under Linux, many of the buttons send identical events. I worked with the driver maintainer a whole ago but we couldn't get it figured out. The wireless switch seems to be one of the things that at least sends a unique event, but I can't promise that it's something that's generally useful. Hence my hesitation. > > > Having a general interface lets one work around all sorts of similar cases, > > some of which may not be associated with ACPI events. > The general interface for rfkill switches _is_ the rfkill layer in the I meant a general interface to control NetworkManager -- not just disabling wireless, but an easily scriptable way to do anything one can do by clicking. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From loupgaroublond at gmail.com Tue Dec 4 02:42:59 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 3 Dec 2007 21:42:59 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> Message-ID: <7f692fec0712031842g53967202l16bcebd1dc47b23e@mail.gmail.com> On Dec 3, 2007 9:32 PM, masch wrote: > Hi! > Is it possible to include any utility link in Ubuntu gksu, gksudo, > gnomesu or gnomesudo?? > It's really usefully for some scripts AFAIU (as far as i understand) PolicyKit is going to handle those sorts of details. It's far more ideal, because then for some users, they can never escalate their privileges, some users can only escalate with a root password, and some with their own password. It's this understanding that it will be here "any time soon" that's kept me from complaining about the obvious lack of gksudo. -Yaakov From peter at thecodergeek.com Tue Dec 4 03:57:51 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 03 Dec 2007 19:57:51 -0800 Subject: firefox vs epiphany In-Reply-To: <4753A824.6090006@mharris.ca> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> <4753A824.6090006@mharris.ca> Message-ID: <1196740671.9268.15.camel@tuxhugs> On Mon, 2007-12-03 at 01:54 -0500, Mike A. Harris wrote: > Yup, I use AdBlock Plus to get rid of all the ad-noise online, and also > as a side effect for web browser stability because a lot of the > advertising out there is flash based and causes browser crashes whenever > flash does something bad. The AdBlocker Epiphany extension works similarly, but far more easily (IMHO). When installed, it defaults to a blacklist based on Graham Pierce's FilterSet.G listing. This means that after installation, with absolutely *no configuration whatsoever* ads on the web are a thing of the past. :) > Hehe. I always liked Galeon. It's small and cute and pretty quick. I > use it once in a while for some things, but it could never be my primary > browser per se. Not sure about Galeon, actually. My understanding has been that the Galeon folks are recently working to merge their efforts back into Epiphany proper. Are they still wanting to keep it separate? Who knows... :) -- 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 peter at thecodergeek.com Tue Dec 4 04:18:03 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 03 Dec 2007 20:18:03 -0800 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-12-01 In-Reply-To: <20071202075642.A15743@humbolt.us.dell.com> References: <20071202075642.A15743@humbolt.us.dell.com> Message-ID: <1196741883.9268.20.camel@tuxhugs> On Sun, 2007-12-02 at 07:56 -0600, Matt Domsch wrote: > nemiver-0.4.0-1.fc8 (build/make) pgordon Unfortunately this is due to a compile error which I won't have time to look deeply into until this weekend due to crunch-time in preparing for final exams and whatnot. I believe the fix for this is already in upstream SVN; but I am not certain. If someone wants to cook up and commit a nice patch before then, feel free to do so. Otherwise, I'll take care of it by early next week. =) Thanks, and regards. -- 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 loupgaroublond at gmail.com Tue Dec 4 04:28:49 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 3 Dec 2007 23:28:49 -0500 Subject: firefox vs epiphany In-Reply-To: <1196740671.9268.15.camel@tuxhugs> References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> <4753A824.6090006@mharris.ca> <1196740671.9268.15.camel@tuxhugs> Message-ID: <7f692fec0712032028h3e37ff5fp61b5f0381cb60c14@mail.gmail.com> On Dec 3, 2007 10:57 PM, Peter Gordon wrote: > On Mon, 2007-12-03 at 01:54 -0500, Mike A. Harris wrote: > > Yup, I use AdBlock Plus to get rid of all the ad-noise online, and also > > as a side effect for web browser stability because a lot of the > > advertising out there is flash based and causes browser crashes whenever > > flash does something bad. > > The AdBlocker Epiphany extension works similarly, but far more easily > (IMHO). When installed, it defaults to a blacklist based on Graham > Pierce's FilterSet.G listing. This means that after installation, with > absolutely *no configuration whatsoever* ads on the web are a thing of > the past. :) Or you install the Filterset.G extension as well, that updates AdBlock Plus -Yaakov From alexl at users.sourceforge.net Tue Dec 4 04:38:12 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 03 Dec 2007 21:38:12 -0700 Subject: firefox vs epiphany In-Reply-To: <1196740671.9268.15.camel@tuxhugs> (Peter Gordon's message of "Mon\, 03 Dec 2007 19\:57\:51 -0800") References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> <1196657826.17392.10.camel@localhost> <4753A824.6090006@mharris.ca> <1196740671.9268.15.camel@tuxhugs> Message-ID: >>>>> "PG" == Peter Gordon writes: [...] PG> Not sure about Galeon, actually. My understanding has been that PG> the Galeon folks are recently working to merge their efforts back PG> into Epiphany proper. Are they still wanting to keep it separate? PG> Who knows... :) -- Peter Gordon (codergeek42) That was the plan (circa late 2005), but it seems to be a dormant project (I have tried pinging people on #epiphany and #galeon on this subject, but no response as yet). Perhaps you also missed my previous e-mail on this subject: http://www.redhat.com/archives/fedora-devel-list/2007-December/msg00143.html Alex From Matt_Domsch at dell.com Tue Dec 4 05:10:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 3 Dec 2007 23:10:45 -0600 Subject: DJB's software components In-Reply-To: <1196727504.3338.53.camel@localhost.localdomain> References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> <20071201140913.GA9617@devserv.devel.redhat.com> <1196720344.18776.7.camel@localhost> <1196727504.3338.53.camel@localhost.localdomain> Message-ID: <20071204051045.GB4865@auslistsprd01.us.dell.com> On Tue, Dec 04, 2007 at 05:48:24AM +0530, Tom spot Callaway wrote: > > On Mon, 2007-12-03 at 16:19 -0600, Callum Lerwick wrote: > > On Mon, 2007-12-03 at 13:32 +0100, Matej Cepl wrote: > > > Which was the reason I was shocked DJB released qmail under public domain > > > and why I would always prefer at least MIT/X/BSD-no-appropriation/CC-au > > > always. IIRC, sqlite is the only substantial software which is under > > > public domain and there is a reason for that. > > > > IANAL, but doesn't this mean he's effectively released it under *every* > > license ever written? :) Are we going to have GPL and BSD forks battling > > it out now? > > Its possible, but Public Domain means something closer to "no license" > than "every license". We could see forks battling it out, but somehow, I > doubt this will happen. Right - really "no license". Public Domain means anyone is free to take it and use it however they want - including pulling into another app and re-licensing it. One of the ways people can contribute to GNU projects is to explicitly assign copyright of code to the FSF. The other way is to disclaim your work into the public domain, at which point the GNU project maintainer may pick it up and include it in a GNU-licensed application. Changes to the code will carry the FSF copyright, and the whole will carry the GNU license. (see parted/libparted/labels/gpt.c for such an example if you're curious). -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From myfedora at richip.dhs.org Tue Dec 4 05:14:44 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 03 Dec 2007 22:14:44 -0700 Subject: Sun releases APOC In-Reply-To: <1196727888.2814.17.camel@fedora.buh.htpassport.net> References: <1196727888.2814.17.camel@fedora.buh.htpassport.net> Message-ID: <1196745284.23776.5.camel@localhost6.localdomain6> On Tue, 2007-12-04 at 02:24 +0200, Razvan Corneliu C.R. VILT wrote: > I am rather curious on what you guys think. > > P.S.: Before you ask, YES it's GPL 2.0 (dual-licensed with CDDL) and > it's hosted at freedesktop.org ( http://apoc.freedesktop.org/wiki/ to be > more exact) Personally, I'm interested in it. Thanks for pointing it out. It seems to have a similar bent to part of the Gnome Online Desktop venture. I heard that the Mugshot project could also host Desktop configuration, but I could just be pulling that out of thin air. Personally, I like this approach since LDAP is a great technology that needs a lot more exposure and adoption. The Fedora DS project seems to be doing well in that regard, and APOC could be a great complement. It seems to be the next step in the evolution process (first directory services, then authorization, and then finally down to the configuration). They already have GConf adapters, too. I'll play around with it and see about making a package. -- Richi Plana From michel.sylvan at gmail.com Tue Dec 4 06:16:12 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 4 Dec 2007 01:16:12 -0500 Subject: BuildRootOverrides request: devhelp (for vala-0.1.5) Message-ID: Hello, Could a CVS admin make devhelp available as a BuildRootOverrides? https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3962 Vala has a soft BR on devhelp -- the documentation files don't get installed if devhelp is not detected at configure time, and everytime there is a Firefox update, devhelp lags behind by days, so it will be nice to have it permanently whitelisted. Thanks, -- Michel Salim http://hircus.jaiku.com/ From nathanael at gnat.ca Tue Dec 4 06:46:48 2007 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 03 Dec 2007 23:46:48 -0700 Subject: InstantMirror-0.2 Release In-Reply-To: References: <20071122071558.4210573F9D@hormel.redhat.com> Message-ID: <4754F7D8.3010400@gnat.ca> chasd wrote: >> http://fedorapeople.org/~wtogami/temp/InstantMirror-release/InstantMirror-0.2-0.fc8.src.rpm >> > > Runs on F7 too. > Thank you for this, it works well in our small business environment > where conserving bandwidth to the internet is important. > >> We still don't have a hosted.fp.org project setup yet so the above is >> only the temporary location. Until we have that permanent project >> setup, please report bugs and make suggestions for improvement here in >> this thread. > > The included InstantMirror.conf file that goes into /etc/httpd/conf.d/ > stomps on any other configuration you may have set up. > Because the file name starts with an upper case "eye" it is loaded first > by the > > Include conf.d/*.conf > > directive. It becomes the _default_ host for everything on port 80. > You can check how that works by > > /usr/sbin/httpd -S > mv /etc/httpd/conf.d/InstantMirror.conf > /etc/httpd/conf.d/zInstantMirror.conf > /usr/sbin/httpd -S > ( move it back if you prefer the stomping behavior ) > > From > >> Main host goes away >> >> If you are adding virtual hosts to an existing web server, you must >> also create a block for the existing host. The >> ServerName and DocumentRoot included in this virtual host should be >> the same as the global ServerName and DocumentRoot. List this virtual >> host first in the configuration file so that it will act as the >> default host. > > This directive > > NameVirtualHost *:80 > > should be uncommented in /etc/httpd/conf/httpd.conf > and a directive should be set up for the default web > content, and should be loaded before the InstantMirror.conf file. > > I have something that works with my test system, but I'm still not in a > position to make a bomb-proof generalized config file recommendation. It > seems using VirtualHost is the best way to create the Instant Mirror, > but integrating that into an existing apache conf needs to be handled > with a bit more care. This could be communicated with better comments or > additional commented out directives in the provided InstantMirror.conf > file. > > I use several files in conf.d to create aliases and WebDAV collections > for calendaring and file sharing on our main server. I haven't tested > yet with all those conf files mixed in. > > Also, I think separating the logging is a good thing to do with > directives such as > > ErrorLog logs/mirror-error_log > CustomLog logs/mirror-access_log > > within the InstantMirror virtual host block. > That way when the python script throws a hissy fit about file > permissions, it is easier to find. Just recently I setup a new system, previously I had all my virtual hosts in one virtual.conf that I included by doing a include conf/virtual.conf from the httpd.conf. I just switched it to multiple files, one for each virtual host, they are now included by doing include virtual.d/*conf Perhaps if httpd were re-tooled to setup virtual hosts in that manner? or should I have put my virtual hosts in the conf.d directory? I just seemed cleaner to separate sites from what seemed like modular configs.. Anyway the point of this rambling is if we had something like that, system that use httpd/apache could add a virtual host config to httpd/virtual.d/ and not step on each others toes. -- Nathanael D. Noblet From nicolas.mailhot at laposte.net Tue Dec 4 07:05:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Dec 2007 08:05:33 +0100 Subject: Sun releases APOC In-Reply-To: <1196745284.23776.5.camel@localhost6.localdomain6> References: <1196727888.2814.17.camel@fedora.buh.htpassport.net> <1196745284.23776.5.camel@localhost6.localdomain6> Message-ID: <1196751933.5981.0.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 22:14 -0700, Richi Plana a ?crit : > On Tue, 2007-12-04 at 02:24 +0200, Razvan Corneliu C.R. VILT wrote: > > I am rather curious on what you guys think. > > > > P.S.: Before you ask, YES it's GPL 2.0 (dual-licensed with CDDL) and > > it's hosted at freedesktop.org ( http://apoc.freedesktop.org/wiki/ to be > > more exact) > > Personally, I'm interested in it. Thanks for pointing it out. This is probably something for the freeipa guys -- 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 lkundrak at redhat.com Tue Dec 4 07:32:55 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Tue, 04 Dec 2007 08:32:55 +0100 Subject: Mock busted? In-Reply-To: <1196725967.15509.206.camel@shrek.rexursive.com> References: <1196725967.15509.206.camel@shrek.rexursive.com> Message-ID: <1196753576.15639.44.camel@localhost.localdomain> On Tue, 2007-12-04 at 10:52 +1100, Bojan Smojver wrote: > Is mock busted in Koji right now? > > I'm getting failures like this: > ------------------------ > /etc/profile: line 38: /bin/hostname: No such file or directory > sh: /usr/sbin/apxs: No such file or directory > ------------------------ > > My package (libapreq2) has httpd-devel as a dependency, so apxs should > be there. Please point to the ID if the build that failed. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From braden at endoframe.com Tue Dec 4 07:40:27 2007 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 04 Dec 2007 02:40:27 -0500 Subject: Mock busted? In-Reply-To: <1196753576.15639.44.camel@localhost.localdomain> References: <1196725967.15509.206.camel@shrek.rexursive.com> <1196753576.15639.44.camel@localhost.localdomain> Message-ID: <1196754027.30193.15.camel@hinge.endoframe.net> On Tue, 2007-12-04 at 08:32 +0100, Lubomir Kundrak wrote: > On Tue, 2007-12-04 at 10:52 +1100, Bojan Smojver wrote: > > Is mock busted in Koji right now? > > > > I'm getting failures like this: > > ------------------------ > > /etc/profile: line 38: /bin/hostname: No such file or directory > > sh: /usr/sbin/apxs: No such file or directory > > ------------------------ > > > > My package (libapreq2) has httpd-devel as a dependency, so apxs should > > be there. > > Please point to the ID if the build that failed. I'm seeing this, too. 25776, for instance. -- Braden McDaniel e-mail: Jabber: From tmraz at redhat.com Tue Dec 4 08:10:54 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 04 Dec 2007 09:10:54 +0100 Subject: Heads up: openldap and openssl changed in devel Message-ID: <1196755854.3037.48.camel@vespa.kabelta.loc> There are new versions of OpenLDAP (2.4.6) and OpenSSL (0.9.8g) with different soname in rawhide. Please rebuild your packages, which depend on openldap and openssl. Jan Safranek & Tomas Mraz From mharris at mharris.ca Tue Dec 4 08:20:43 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 04 Dec 2007 03:20:43 -0500 Subject: firefox vs epiphany In-Reply-To: <1196695401.7278.74.camel@oneill.fubar.dk> References: <1196625336.2547.4.camel@tiger> <47541DBB.1070402@redhat.com> <1196695401.7278.74.camel@oneill.fubar.dk> Message-ID: <47550DDB.1040707@mharris.ca> David Zeuthen wrote: > Here's a funny story: Ironically enough up until F8 we used the generic > Web Browser icon on the panel on a default install. The icon looked like > planet earth with what looked like a mouse with a cable tied around it. > It was Bluecurve style. Fortunately mclasen fixed this for F8 such that > the correct icon on the panel for the default browser is chosen. > > It's a bit funny we didn't fix this earlier; either we don't really care > as much as we should about brand recognition.. or we're not very good at > polishing. Something to keep in mind and learn from. Ah, that's what happened... I always wondered about that and thought perhaps there were trademark issues or something. I got in the habit of hunting through /usr/share to find the firefox icon proper, and replace the default earth icon. Didn't remember doing it in Fedora 8 though. ;) One reason it kindof annoyed me, was I had recommended giving Fedora a whirl to various friends over time, and some who installed it mentioned to me they couldn't find the firefox icon. They were looking for the standard firefox icon visually, not finding it and aborting the mission. ;o) -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From laurent.rineau__fedora at normalesup.org Tue Dec 4 08:27:09 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 4 Dec 2007 09:27:09 +0100 Subject: Upstream package splitted into sub-packages: ipe, figtoipe. Message-ID: <200712040927.10168@rineau.tsetse> Hi, One of my packages, ipe, has been splitted upstream into two sub-packages. ipe-6.0pre28 was shipping the tool "figtoipe", and as for ipe-6.0pre30 figtoipe is now another tarball. What could I do? 1-?I?can use two sources to build my package, and let the package ipe-6.0-0.23.pre30 ship figtoipe. 2-?I can make figtoipe be a sub-package. 3-?I can submit a review request for figtoipe, as it is an external tool. What is the best solution? figoipe-20071004.tar.gz is a very small tarball: 11KB. See http://luaforge.net/frs/?group_id=305 Anyway, if I split ipe into two packages, or two sub-packages, how can I provide an upgrade path for users that assume that /usr/bin/figtoipe is provided by ipe, without adding a hard-coded Requires? I?am not sure that a solution exists. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From nphilipp at redhat.com Tue Dec 4 08:38:09 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 04 Dec 2007 09:38:09 +0100 Subject: Upstream package splitted into sub-packages: ipe, figtoipe. In-Reply-To: <200712040927.10168@rineau.tsetse> References: <200712040927.10168@rineau.tsetse> Message-ID: <1196757489.4189.6.camel@wombat.tiptoe.de> On Tue, 2007-12-04 at 09:27 +0100, Laurent Rineau wrote: > Anyway, if I split ipe into two packages, or two sub-packages, how can I > provide an upgrade path for users that assume that /usr/bin/figtoipe is > provided by ipe, without adding a hard-coded Requires? I am not sure that a > solution exists. Let both (sub-)packages do this: Obsoletes: ipe < 6.0-0.23.pre30 Conflicts: ipe < 6.0-0.23.pre30 I hope your package isn't multilib, in this case current yum in F8 (I have yum-3.2.7-1.fc8) would install both architectures even if originally only one was installed. 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 bojan at rexursive.com Tue Dec 4 08:43:36 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 4 Dec 2007 08:43:36 +0000 (UTC) Subject: Mock busted? References: <1196725967.15509.206.camel@shrek.rexursive.com> <1196753576.15639.44.camel@localhost.localdomain> Message-ID: Lubomir Kundrak redhat.com> writes: > Please point to the ID if the build that failed. 26574 -- Bojan From laurent.rineau__fedora at normalesup.org Tue Dec 4 08:46:55 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 4 Dec 2007 09:46:55 +0100 Subject: Upstream package splitted into sub-packages: ipe, figtoipe. In-Reply-To: <1196757489.4189.6.camel@wombat.tiptoe.de> References: <200712040927.10168@rineau.tsetse> <1196757489.4189.6.camel@wombat.tiptoe.de> Message-ID: <200712040946.55445@rineau.tsetse> On Tuesday 04 December 2007 09:38:09 Nils Philippsen wrote: > On Tue, 2007-12-04 at 09:27 +0100, Laurent Rineau wrote: > > Anyway, if I split ipe into two packages, or two sub-packages, how can I > > provide an upgrade path for users that assume that /usr/bin/figtoipe is > > provided by ipe, without adding a hard-coded Requires? I am not sure that > > a solution exists. > > Let both (sub-)packages do this: > > Obsoletes: ipe < 6.0-0.23.pre30 > Conflicts: ipe < 6.0-0.23.pre30 Ok, i see the point. > I hope your package isn't multilib, in this case current yum in F8 (I > have yum-3.2.7-1.fc8) would install both architectures even if > originally only one was installed. Well... ipe has a ipe-devel sub-packages, to let users create plugins (named ipelets). That makes ipe be a multilib package, as far as I know. Is there an extra trick to avoid the issue you have spotted? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From ffesti at redhat.com Tue Dec 4 08:48:53 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 04 Dec 2007 09:48:53 +0100 Subject: Upstream package splitted into sub-packages: ipe, figtoipe. In-Reply-To: <1196757489.4189.6.camel@wombat.tiptoe.de> References: <200712040927.10168@rineau.tsetse> <1196757489.4189.6.camel@wombat.tiptoe.de> Message-ID: <47551475.3040205@redhat.com> Nils Philippsen wrote: > On Tue, 2007-12-04 at 09:27 +0100, Laurent Rineau wrote: > >> Anyway, if I split ipe into two packages, or two sub-packages, how can I >> provide an upgrade path for users that assume that /usr/bin/figtoipe is >> provided by ipe, without adding a hard-coded Requires? I am not sure that a >> solution exists. > > Let both (sub-)packages do this: > > Obsoletes: ipe < 6.0-0.23.pre30 > Conflicts: ipe < 6.0-0.23.pre30 > > I hope your package isn't multilib, in this case current yum in F8 (I > have yum-3.2.7-1.fc8) would install both architectures even if > originally only one was installed. This is fixed in yum 3.2.8 which should be available as a Fedora update soon (Upstream release was yesterday). Florian From mharris at mharris.ca Tue Dec 4 08:50:42 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 04 Dec 2007 03:50:42 -0500 Subject: PROJECT BLACKHAT In-Reply-To: <20071126164202.f2942a86.mschwendt.tmp0701.nospam@arcor.de> References: <474ACCE5.60508@mharris.ca> <20071126164202.f2942a86.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <475514E2.10106@mharris.ca> Michael Schwendt wrote: > On Mon, 26 Nov 2007 08:40:53 -0500, Mike A. Harris wrote: > >> You could still keep a similar theme of "$color $something", just don't >> use "Red" or "Hat" or any other word that means "hat" or is a type of >> hat, and you're probably ok. In the past, there have been "Blue Sky >> Linux", "Green Frog Linux", "Yellowdog Linux", "Black Flag Linux", "Pink >> Tie Linux", and "White Box Linux" that I'm aware of, and probably a >> number of others as well. As far as I recall those names were all ok, >> although as I said above, IANAL. ;o) > > "Red Flag Linux" is available, too. ;) > > http://www.redflag-linux.com/eindex.html Yes, communist China does not tend to care too much about the world's intellectual property laws. I wouldn't recommend them as an example for others to follow however. -- Mike A. Harris Come and join us on the #fedora8 IRC help forum on irc.freenode.net From nicolas.mailhot at laposte.net Tue Dec 4 08:52:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 4 Dec 2007 09:52:11 +0100 (CET) Subject: Upstream package splitted into sub-packages: ipe, figtoipe. Message-ID: <14709.192.54.193.53.1196758331.squirrel@rousalka.dyndns.org> Le Mar 4 d?cembre 2007 09:27, Laurent Rineau a ?crit : > 1-?I?can use two sources to build my package, and let the package > ipe-6.0-0.23.pre30 ship figtoipe. Eek please no. Users appreciate modularity > 2-?I can make figtoipe be a sub-package. Eek #2 > 3-?I can submit a review request for figtoipe, as it is an external > tool. That is the right solution > Anyway, if I split ipe into two packages, or two sub-packages, how can > I > provide an upgrade path for users that assume that /usr/bin/figtoipe > is > provided by ipe, without adding a hard-coded Requires? I?am not sure > that a > solution exists. I'll assume figtoipe makes no sense without ipe The solution then is probably something like making separate figtoipe depend on ipe > last_bundled_version, and have it obsolete ipe <= last_bundled_version Regards, -- Nicolas Mailhot From mtasaka at ioa.s.u-tokyo.ac.jp Tue Dec 4 09:46:49 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 04 Dec 2007 18:46:49 +0900 Subject: Mock busted? In-Reply-To: <1196725967.15509.206.camel@shrek.rexursive.com> References: <1196725967.15509.206.camel@shrek.rexursive.com> Message-ID: <47552209.4020206@ioa.s.u-tokyo.ac.jp> Bojan Smojver wrote, at 12/04/2007 08:52 AM +9:00: > Is mock busted in Koji right now? > > I'm getting failures like this: > ------------------------ > /etc/profile: line 38: /bin/hostname: No such file or directory > sh: /usr/sbin/apxs: No such file or directory > ------------------------ > > My package (libapreq2) has httpd-devel as a dependency, so apxs should > be there. > > Also: > ------------------------ > Error: Missing Dependency: libldap-2.3.so.0()(64bit) is needed by > package mod_perl > Error: Missing Dependency: liblber-2.3.so.0()(64bit) is needed by package mod_perl This is due to openssl soname bump. https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00239.html Regards, Mamoru From nphilipp at redhat.com Tue Dec 4 09:48:54 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 04 Dec 2007 10:48:54 +0100 Subject: Upstream package splitted into sub-packages: ipe, figtoipe. In-Reply-To: <14709.192.54.193.53.1196758331.squirrel@rousalka.dyndns.org> References: <14709.192.54.193.53.1196758331.squirrel@rousalka.dyndns.org> Message-ID: <1196761734.4189.10.camel@wombat.tiptoe.de> On Tue, 2007-12-04 at 09:52 +0100, Nicolas Mailhot wrote: > I'll assume figtoipe makes no sense without ipe > > The solution then is probably something like making separate figtoipe > depend on ipe > last_bundled_version, and have it obsolete ipe <= > last_bundled_version You'll need "Obsoletes: ipe <= ..." anyway otherwise the upgrade will leave the user without the figtoipe tool. 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 tmz at pobox.com Tue Dec 4 10:37:53 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 4 Dec 2007 05:37:53 -0500 Subject: mock 0.8.9 In-Reply-To: <20071203220840.GB14186@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> <20071203205926.GA14186@humbolt.us.dell.com> <200712032346.55800.ville.skytta@iki.fi> <20071203220840.GB14186@humbolt.us.dell.com> Message-ID: <20071204103753.GA3755@psilocybe.teonanacatl.org> Michael E Brown wrote: > Patches welcome. Here's one. This adds a --define option, which may be used multiple times. Usage is pretty much like the rpm --define option: $ mock --define="with_extra_cheese 1" --define="packager Monkey" ... Rather than pass the define options directly to rpmbuild, they are added to the .rpmmacros file in the chroot. I'm not sure if there's much difference in practice. If anyone knows differently, please speak up. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Giving a politician access to your wallet is like giving a dog access to your refrigerator. -- Tim Barber -------------- next part -------------- diff --git a/docs/mock.1 b/docs/mock.1 index 3adc047..17b5081 100644 --- a/docs/mock.1 +++ b/docs/mock.1 @@ -56,6 +56,11 @@ Dont clean chroot after building. If automatic cleanup is enabled, use this to d \fB\-\-arch=\fR\fIARCH\fP Specify target build arch. .TP +\fB\-\-define=\fR"\fIMACRO EXPR\fP" +Specify macro definitions used for the build. This option may be used multiple times, just as the rpmbuild \-\-define option can be. For example: + +\fB\-\-define="with_extra_cheese 1" \-\-define="packager Monkey"\fR +.TP \fB\-\-resultdir=\fR\fIRESULTDIR\fP Change directory where resulting files (RPMs and build logs) are written. Resultdir can contain python-string substitutions for any variable in the chroot config. For example: diff --git a/py/mock.py b/py/mock.py index bb5df8c..b78d37a 100755 --- a/py/mock.py +++ b/py/mock.py @@ -104,6 +104,9 @@ def command_parse(config_opts): " cleanup is enabled, use this to disable.", ) parser.add_option("--arch", action ="store", dest="arch", default=None, help="target build arch") + parser.add_option("--define", action="append", dest="rpmmacros", + default=[], type="string", metavar="'MACRO EXPR'", + help="define an rpm macro (may be used more than once)") parser.add_option("--resultdir", action="store", type="string", default=None, help="path for resulting files to be put") parser.add_option("--uniqueext", action="store", type="string", @@ -222,6 +225,17 @@ def set_config_opts_per_cmdline(config_opts, options): if not options.clean: config_opts['clean'] = options.clean + for macro in options.rpmmacros: + try: + k, v = macro.split(" ", 1) + if not k.startswith('%'): + k = '%%%s' % k + config_opts['macros'].update({k: v}) + except: + raise mock.exception.BadCmdline( + "Bad option for '--define' (%s). Use --define 'macro expr'" + % macro) + if options.resultdir: config_opts['resultdir'] = os.path.expanduser(options.resultdir) if options.uniqueext: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From pertusus at free.fr Tue Dec 4 10:38:47 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 4 Dec 2007 11:38:47 +0100 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> Message-ID: <20071204103847.GD28178@free.fr> On Mon, Dec 03, 2007 at 09:32:14PM -0500, masch wrote: > Hi! > Is it possible to include any utility link in Ubuntu gksu, gksudo, > gnomesu or gnomesudo?? Unless there is something special for these pieces of code, anybody can submit those packages to fedora through the usual review process. -- Pat From jnovy at redhat.com Tue Dec 4 10:42:20 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 11:42:20 +0100 Subject: texlive conflicts In-Reply-To: References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> <20071203171156.GA2996@dhcp-lab-186.brq.redhat.com> Message-ID: <20071204104220.GA3336@dhcp-lab-186.brq.redhat.com> On Mon, Dec 03, 2007 at 01:30:07PM -0500, Neal Becker wrote: > transaction Check Error: > file /usr/share/texmf/doc/ptex/ptex-src/Changes.txt from install of texlive-2007-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/COPYRIGHT.jis from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/ChangeLog from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > file /usr/share/texmf/doc/mendexk/README from install of mendexk-2.6e-0.17.fc9.x86_64 conflicts with file from package tetex-doc-3.0-44.3.fc8.x86_64 > Should be fixed in 0.18 -> please try again now. It is caused by the fact that I don't have texlive-doc (~120MB) in the p.r.c. repository and I hadn't tetex-doc installed while testing tetex -> texlive upgrade. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Dec 4 11:02:42 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 12:02:42 +0100 Subject: TeXLive is in rawhide In-Reply-To: <47547AA3.2030000@redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <47547AA3.2030000@redhat.com> Message-ID: <20071204110242.GA3918@dhcp-lab-186.brq.redhat.com> On Mon, Dec 03, 2007 at 01:52:35PM -0800, John Poelstra wrote: > Jindrich Novy said the following on 12/03/2007 04:21 AM Pacific Time: >> Hi all, >> >> I come with good news for TeX users in Fedora. TeXLive is now finally >> imported and built in rawhide since today. >> >> Enjoy, >> Jindrich >> > > Excellent. > > Does that mean this page can be updated > http://fedoraproject.org/wiki/Releases/FeatureTexLive > > If "yes", please update :) > updated. /me doesn't like writing novels ;) Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From alexl at users.sourceforge.net Tue Dec 4 11:54:58 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 04 Dec 2007 04:54:58 -0700 Subject: Broken BuildRequires in rawhide In-Reply-To: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> (Michael Schwendt's message of "Mon\, 3 Dec 2007 16\:57\:55 +0100") References: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: >>>>> "-" == Michael Schwendt writes: -> These are broken BuildRequires in the rawhide src.rpms: package: -> Miro - 0.9.9.9-1.fc9.src from fedora-development-source unresolved -> deps: gecko-devel = 0:1.8.1.9 [...] -> package: ruby-gnome2 - 0.16.0-16.fc9.src from -> fedora-development-source unresolved deps: gecko-devel = 0:1.8.1.9 These packages don't rebuild yet against the new xulrunner package (which provides gecko-devel: 1.9), work in fixing these packages to rebuild against xulrnner is in progress here: http://fedoraproject.org/wiki/Releases/FeatureXULRunner#head-dfcf813a6229d3b644b691df960c2d6716f2447c Alex From jkeating at redhat.com Tue Dec 4 11:58:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 06:58:13 -0500 Subject: BuildRootOverrides request: devhelp (for vala-0.1.5) In-Reply-To: References: Message-ID: <20071204065813.2b0fc1cb@redhat.com> On Tue, 4 Dec 2007 01:16:12 -0500 "Michel Salim" wrote: > Could a CVS admin make devhelp available as a BuildRootOverrides? > > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3962 > > Vala has a soft BR on devhelp -- the documentation files don't get > installed if devhelp is not detected at configure time, and everytime > there is a Firefox update, devhelp lags behind by days, so it will be > nice to have it permanently whitelisted. There isn't a method to make a "permanent" whitelist. Why does your app have to be built against a very specific version of devhelp? -- 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 caillon at redhat.com Tue Dec 4 12:06:19 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 04 Dec 2007 13:06:19 +0100 Subject: Broken BuildRequires in rawhide In-Reply-To: References: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <475542BB.6060005@redhat.com> On 12/04/2007 12:54 PM, Alex Lancaster wrote: >>>>>> "-" == Michael Schwendt writes: > > -> These are broken BuildRequires in the rawhide src.rpms: package: > > -> Miro - 0.9.9.9-1.fc9.src from fedora-development-source unresolved > -> deps: gecko-devel = 0:1.8.1.9 > > [...] > > -> package: ruby-gnome2 - 0.16.0-16.fc9.src from > -> fedora-development-source unresolved deps: gecko-devel = 0:1.8.1.9 > > These packages don't rebuild yet against the new xulrunner package > (which provides gecko-devel: 1.9), work in fixing these packages to > rebuild against xulrnner is in progress here: So rebuild against gecko-devel = 1.8.1.10 (which comes from firefox) in the meantime. From paskalis at di.uoa.gr Tue Dec 4 12:30:43 2007 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Tue, 4 Dec 2007 14:30:43 +0200 Subject: TeXLive is in rawhide In-Reply-To: <47542B32.8020405@fi.muni.cz> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> Message-ID: <20071204123043.GA20227@gallagher.di.uoa.gr> On Mon, Dec 03, 2007 at 05:13:38PM +0100, Milos Jakubicek wrote: > Matthew Saltzman napsal(a): >> On Mon, 2007-12-03 at 13:21 +0100, Jindrich Novy wrote: >>> Hi all, >>> >>> I come with good news for TeX users in Fedora. TeXLive is now finally >>> imported and built in rawhide since today. >> >> Can the rawhide version be used as is in F8 or are there F8 RPMs that we >> can test? > > I use TexLive (instead of TeTex) from the following repository (created by > Jindrich Novy) on F8 without any problems: > > [texlive] > name=TeXLive 2007 for Fedora Core $releasever - $basearch > baseurl=http://people.redhat.com/jnovy/files/texlive/$basearch > enabled=1 > gpgcheck=0 http://people.redhat.com/jnovy/files/texlive/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: texlive. Please verify its path and try again Please enable the repodata for those of us not on x86_64 yet. Thanks, -- Sarantis From jnovy at redhat.com Tue Dec 4 12:56:29 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 13:56:29 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071204123043.GA20227@gallagher.di.uoa.gr> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196697920.3341.14.camel@vincent52.localdomain> <47542B32.8020405@fi.muni.cz> <20071204123043.GA20227@gallagher.di.uoa.gr> Message-ID: <20071204125629.GA4147@dhcp-lab-186.brq.redhat.com> On Tue, Dec 04, 2007 at 02:30:43PM +0200, Sarantis Paskalis wrote: > http://people.redhat.com/jnovy/files/texlive/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Not Found > Trying other mirror. > Error: Cannot retrieve repository metadata (repomd.xml) for repository: > texlive. Please verify its path and try again > > Please enable the repodata for those of us not on x86_64 yet. > Done. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From ndbecker2 at gmail.com Tue Dec 4 13:04:14 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 04 Dec 2007 08:04:14 -0500 Subject: texlive cm-lgc problem? Message-ID: Tried processing one of my old lyx files, got this: pplatex: Process input file 1lyxpreview.dvi pplatex: Copy data to 1lyxpreview.dvi kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+216/300 --dpi 516 fcmr8r mktexpk: don't know how to create bitmap font for fcmr8r. kpathsea: Appending font creation commands to missfont.log. dvipng warning: font fcmr8r at 516 dpi not found, characters will be left blank kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+113/300 --dpi 413 fctr8r mktexpk: don't know how to create bitmap font for fctr8r. dvipng warning: font fctr8r at 413 dpi not found, characters will be left blank There seems to be cm-lgc in /usr/share/texmf, any ideas what's wrong? From wolfy at nobugconsulting.ro Tue Dec 4 13:10:17 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 04 Dec 2007 15:10:17 +0200 Subject: ata and scsi modules in initrd In-Reply-To: <4752FE7C.5080406@leemhuis.info> References: <1196375699.3036.9.camel@dimi.lattica.com> <20071130161846.GA6497@nostromo.devel.redhat.com> <1196474800.4645.3.camel@dimi.lattica.com> <200711302150.16122.jbarnes@virtuousgeek.org> <1196490189.6750.38.camel@oneill.fubar.dk> <20071202025215.GC31160@redhat.com> <1196595060.4121.16.camel@oneill.fubar.dk> <4752E6E6.8020507@leemhuis.info> <20071202191649.080d3e51@pensja.lam.pl> <4752FE7C.5080406@leemhuis.info> Message-ID: <475551B9.6020009@nobugconsulting.ro> Thorsten Leemhuis wrote: > On 02.12.2007 19:16, Leszek Matok wrote: > >> Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis >> napisa?(a): >> >> >>> * you try to boot F8 and it won't find the root filesystem, because the >>> module (ata_piix) with drives the chipsets storage controller in its >>> default mode is missing in the initrd -> trouble that a lot of our users >>> are unable to solve >>> >> Happened to me after a BIOS upgrade, as well, but come on, the website >> specifically said something like "don't upgrade the BIOS yourself" and "don't >> mess with the BIOS unless you're sure the upgrade will fix something". >> > > Sure, but there are good reasons to update the BIOS now and then. > > >> And it took me 15 seconds to switch to AHCI mode and boot Fedora again. >> > > If you know about it. What do ordinary users do that don't know about > such things that got told by a "good" friend to update the BIOS? > When I've told my girl friend to press DEL to enter the BIOS in order to do a change (-> load safe defaults), the reply was "press what ?", followed by "what's a BIOS?" And she is actively using a computer daily for several (6+) years. From atkac at redhat.com Tue Dec 4 13:20:31 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 4 Dec 2007 14:20:31 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196704588.21151.10.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> Message-ID: <20071204132031.GA3250@traged.englab.brq.redhat.com> On Mon, Dec 03, 2007 at 12:56:28PM -0500, Dan Williams wrote: > > NM is going to have to export the DHCP information in any case; the best > option is a pull model where clients can query NM for the DHCP > information they want based on what the current connection is. In the > future, connections may span devices due to > bonding/bridging/connection-sharing or whatever, and the connection is > the thing that gets brought up, not the interface. And since DNS > information is global to the machine (not specific to the interface but > can be tweaked based on _routes_) this requires that programs that want > to know about the DHCP information will need to ask first for the list > of active connections, and second for the DHCP information (if any!) > associated with that connection. When NM gets multiple active device > support, there may be more than one active connection, and each > connection may have DHCP information. Not sure how named would want to > handle those cases. > > Dan > I'm not sure what you mean. NM has to write something into /etc/resolv.conf, right? This decision has to be done on NM side and number of active devices (or connections) has nothing related to that. And this information is exactly what named needs (nameserver statement from resolv.conf). Nothing more (except some notifies when resolv.conf is changed). Adam -- Adam Tkac, Red Hat, Inc. From jnovy at redhat.com Tue Dec 4 13:17:34 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 14:17:34 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071203202927.GA2671@free.fr> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <645d17210712030927g7f13ceb2h57ef0445fb4b954b@mail.gmail.com> <20071203202927.GA2671@free.fr> Message-ID: <20071204131734.GB4147@dhcp-lab-186.brq.redhat.com> On Mon, Dec 03, 2007 at 09:29:27PM +0100, Patrice Dumas wrote: > On Mon, Dec 03, 2007 at 05:27:02PM +0000, Jonathan Underwood wrote: > > On 03/12/2007, Jindrich Novy wrote: > > > Hi all, > > > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > > imported and built in rawhide since today. > > > > > > Enjoy, > > > Jindrich > > > > Jindrich, many thanks for this, looking at the spec files, one can > > really appreciate what a monumental packaging feat this is. > > > > Is the plan to keep tetex in rawhide for a transitional period? Moving > > to TeXlive means some packaging renaming (did that tex-foo guideline > > ever get past the packaging committee?) and some adjusting of > > Yes, the tex-foo naming is now the guideline. But I think that the > package renaming issue is orthogonal to the tex dependencies issues. > > > BuildRequires and Requires. (and some Obsoletes and Provides too). > > Texlive Provides and Obsoletes tetex, so it seems to me that, currently > requiring tetex is still right. Once/if the virtual provides, like TeX and > LaTeX are added (Jindrich was ok with that) it will become better to > switch to that provide, in my opinion, for new stuff, and make sure that > it is in RHEL 6 for EPEL. > Could you please file a bz so that we can track completion of the pure TeX/LaTeX/etc. virtual provides in TeXLive? Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From alexl at users.sourceforge.net Tue Dec 4 13:22:56 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 04 Dec 2007 06:22:56 -0700 Subject: Broken BuildRequires in rawhide In-Reply-To: <475542BB.6060005@redhat.com> (Christopher Aillon's message of "Tue\, 04 Dec 2007 13\:06\:19 +0100") References: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> <475542BB.6060005@redhat.com> Message-ID: <5caboq7fwv.fsf@allele2.eebweb.arizona.edu> >>>>> "CA" == Christopher Aillon writes: [...] >> These packages don't rebuild yet against the new xulrunner package >> (which provides gecko-devel: 1.9), work in fixing these packages to >> rebuild against xulrnner is in progress here: CA> So rebuild against gecko-devel = 1.8.1.10 (which comes from CA> firefox) in the meantime. OK, I didn't know that was still an option. (Just for clarification, I'm just the co-maintainer for Miro, although I have occasionally bumped the ruby-gnome2 package for dep breakage in the past). Alex From jon.nettleton at gmail.com Tue Dec 4 13:35:27 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Tue, 04 Dec 2007 08:35:27 -0500 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <20071202135814.GA9706@asus.config> References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> <1196551547.9577.21.camel@localhost> <20071202135814.GA9706@asus.config> Message-ID: <1196775327.24449.20.camel@averatec> On Sun, 2007-12-02 at 13:58 +0000, Adam Huffman wrote: > On Sat, 01 Dec 2007, Callum Lerwick wrote: > > > > > On Sat, 2007-12-01 at 22:11 +0000, Martin Ebourne wrote: > > > I agree with you completely about the memory usage of Fedora 8, it has > > > got VERY bloated recently. > > > > I remember when I popped 512mb into my system back around 2002. Was > > running Red Hat 8 as I recall. I never, ever got the thing to use more > > than half of it. No matter how many tabs I opened in Mozilla, no matter > > how many kernels I compiled, I had a good 256mb worth of disk cache at > > all times, and it never hit swap. I remember losing entire 100mb files > > because that machine was a bit flaky and would hang sometimes, with the > > file never being written to disk. I got into a habit of typing 'sync' a > > few times after doing anything important, a habit I still have to this > > day. > > > > So now I'm sitting on a laptop with 512mb, running Fedora 8. I'm running > > Galeon and Evolution, and they're eating up 304M RAM and 428M swap. > > > > I recently upgraded a 3 1/2 year old laptop with 512MiB to Fedora 8 and > the level of memory usage when running nothing but Firefox seemed to > cause frequent stalls when it was completely unresponsive for 30 seconds > at a time. > > Admittedly this is only anecdotal evidence, but this doesn't happen on a > newer one with 2GiB. Thank you guys for jogging my memory. Can you please try adding these lines to your sysctl.conf and reboot. vm.swappiness = 40 vm.vfs_cache_pressure = 120 I was forced down to 512 on my laptop while I am getting my 1GB chip replaced and saw the same problem as you. Currently I am running metacity with compositing, avant-window-navigator, epiphany, evolution, xchat-gnome, pidgin, a couple of gnome-terminals, pida and this is my output from free. total used free shared buffers cached Mem: 450192 444532 5660 0 884 97688 -/+ buffers/cache: 345960 104232 Swap: 1933304 94372 1838932 I actually only have 450MB of memory because the rest is used for my IGP video memory. Just to be consistent here is also my output from ps_mem.py 4.5 MiB + 5.1 MiB = 9.6 MiB metacity 3.4 MiB + 7.9 MiB = 11.3 MiB avant-window-navigator 4.3 MiB + 8.1 MiB = 12.4 MiB gnome-terminal 3.6 MiB + 9.5 MiB = 13.2 MiB mixer_applet2 4.1 MiB + 9.9 MiB = 14.0 MiB gweather-applet-2 6.0 MiB + 9.6 MiB = 15.6 MiB python (2) 5.5 MiB + 10.8 MiB = 16.2 MiB xchat-gnome 6.8 MiB + 10.4 MiB = 17.2 MiB gnome-panel 8.8 MiB + 8.8 MiB = 17.6 MiB nautilus 9.1 MiB + 12.3 MiB = 21.4 MiB intlclock-applet 10.6 MiB + 11.9 MiB = 22.5 MiB pidgin 16.5 MiB + 8.7 MiB = 25.2 MiB tomboy 63.3 MiB + 14.7 MiB = 78.0 MiB epiphany 83.0 MiB + 16.6 MiB = 99.5 MiB evolution If that doesn't help e-mail me offline because I would love to work with you to find the difference between my setup and yours. Jon From ndbecker2 at gmail.com Tue Dec 4 13:54:48 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 04 Dec 2007 08:54:48 -0500 Subject: texlive crash in lyx preview Message-ID: Since installing texlive in f8, lyx crashes in preview: (14681)/ EPSHandler::read: kimgio EPS: starting... (14681)/ seekToCodeStart: kimgio EPS: normal EPS file (14681)/ bbox: kimgio EPS BBOX: 40 51 722 576 Fatal error: you need to have a KComponentData object before you do anything that requires it! Examples of this are config objects, standard directories or translations. lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction and send us a bug report, if necessary. Thanks ! Bye. Not sure who's to blame. From jonathan.underwood at gmail.com Tue Dec 4 14:01:23 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 4 Dec 2007 14:01:23 +0000 Subject: TeXLive is in rawhide In-Reply-To: <20071204131734.GB4147@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <645d17210712030927g7f13ceb2h57ef0445fb4b954b@mail.gmail.com> <20071203202927.GA2671@free.fr> <20071204131734.GB4147@dhcp-lab-186.brq.redhat.com> Message-ID: <645d17210712040601o784a89a0k269aa3bb9cd04e06@mail.gmail.com> On 04/12/2007, Jindrich Novy wrote: > Could you please file a bz so that we can track completion of the pure > TeX/LaTeX/etc. virtual provides in TeXLive? > https://bugzilla.redhat.com/show_bug.cgi?id=410401 From paskalis at di.uoa.gr Tue Dec 4 14:12:02 2007 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Tue, 4 Dec 2007 16:12:02 +0200 Subject: texlive cm-lgc problem? In-Reply-To: References: Message-ID: <20071204141201.GA1702@gallagher.di.uoa.gr> On Tue, Dec 04, 2007 at 08:04:14AM -0500, Neal Becker wrote: > Tried processing one of my old lyx files, got this: > > pplatex: Process input file 1lyxpreview.dvi > pplatex: Copy data to 1lyxpreview.dvi > kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+216/300 --dpi 516 fcmr8r > mktexpk: don't know how to create bitmap font for fcmr8r. > kpathsea: Appending font creation commands to missfont.log. > dvipng warning: font fcmr8r at 516 dpi not found, characters will be left blank kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+113/300 --dpi 413 fctr8r > mktexpk: don't know how to create bitmap font for fctr8r. > dvipng warning: font fctr8r at 413 dpi not found, characters will be left blank I think you have tetex-font-cm-lgc installed. It needs to run the update scripts in texlive again. Try to uninstall and reinstall it and see if this fixes things. (yum remove tetex-font-cm-lgc; yum install tetex-font-cm-lgc) Thanks, -- Sarantis From ssorce at redhat.com Tue Dec 4 14:16:48 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Dec 2007 09:16:48 -0500 Subject: Sun releases APOC In-Reply-To: <1196727888.2814.17.camel@fedora.buh.htpassport.net> References: <1196727888.2814.17.camel@fedora.buh.htpassport.net> Message-ID: <1196777808.17681.19.camel@localhost.localdomain> On Tue, 2007-12-04 at 02:24 +0200, Razvan Corneliu C.R. VILT wrote: > While stuff released by Sun Microsystems is not really what fedora-devel > is usually about, this little piece of technology, with a design simple > enough for every admin to understand, does change a lot in enterprise > deployment, and seems to be a natural complement to the FreeIPA project. It seem indeed a natural match ... now if it only didn't require one to sign the SCA[1] before being able to contribute upstream :-( Simo. [1]: http://www.sun.com/software/opensource/contributor_agreement.jsp -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jnovy at redhat.com Tue Dec 4 14:25:23 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 15:25:23 +0100 Subject: texlive cm-lgc problem? In-Reply-To: <20071204141201.GA1702@gallagher.di.uoa.gr> References: <20071204141201.GA1702@gallagher.di.uoa.gr> Message-ID: <20071204142523.GC4147@dhcp-lab-186.brq.redhat.com> On Tue, Dec 04, 2007 at 04:12:02PM +0200, Sarantis Paskalis wrote: > On Tue, Dec 04, 2007 at 08:04:14AM -0500, Neal Becker wrote: > > Tried processing one of my old lyx files, got this: > > > > pplatex: Process input file 1lyxpreview.dvi > > pplatex: Copy data to 1lyxpreview.dvi > > kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+216/300 --dpi 516 fcmr8r > > mktexpk: don't know how to create bitmap font for fcmr8r. > > kpathsea: Appending font creation commands to missfont.log. > > dvipng warning: font fcmr8r at 516 dpi not found, characters will be left blank kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+113/300 --dpi 413 fctr8r > > mktexpk: don't know how to create bitmap font for fctr8r. > > dvipng warning: font fctr8r at 413 dpi not found, characters will be left blank > > I think you have tetex-font-cm-lgc installed. It needs to run the > update scripts in texlive again. Try to uninstall and reinstall it and > see if this fixes things. > (yum remove tetex-font-cm-lgc; yum install tetex-font-cm-lgc) > > Thanks, > Or maybe try to run updmap-sys as root to regenerate map files first. HTH, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From ndbecker2 at gmail.com Tue Dec 4 14:28:07 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 04 Dec 2007 09:28:07 -0500 Subject: texlive cm-lgc problem? References: <20071204141201.GA1702@gallagher.di.uoa.gr> Message-ID: Sarantis Paskalis wrote: > On Tue, Dec 04, 2007 at 08:04:14AM -0500, Neal Becker wrote: >> Tried processing one of my old lyx files, got this: >> >> pplatex: Process input file 1lyxpreview.dvi >> pplatex: Copy data to 1lyxpreview.dvi >> kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+216/300 --dpi >> 516 fcmr8r mktexpk: don't know how to create bitmap font for fcmr8r. >> kpathsea: Appending font creation commands to missfont.log. >> dvipng warning: font fcmr8r at 516 dpi not found, characters will be left >> blank kpathsea: Running mktexpk --mfmode cx --bdpi 300 --mag 1+113/300 >> --dpi 413 fctr8r mktexpk: don't know how to create bitmap font for >> fctr8r. dvipng warning: font fctr8r at 413 dpi not found, characters will >> be left blank > > I think you have tetex-font-cm-lgc installed. It needs to run the > update scripts in texlive again. Try to uninstall and reinstall it and > see if this fixes things. > (yum remove tetex-font-cm-lgc; yum install tetex-font-cm-lgc) > > Thanks, > > -- Sarantis > I got it fixed. Not sure what fixed it though. I have 2 machines, one had a problem and one didn't. rsyncing various dirs from the good machine, and running updmap-sys seems to have fixed it. From limb at jcomserv.net Tue Dec 4 14:34:12 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 4 Dec 2007 08:34:12 -0600 (CST) Subject: Orphaning packages Message-ID: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> > >> >>> Hi, >>> >>> Just to let you know that other than the mono packages I currently >>> maintain, >>> I'm going to have to drop the other packages I have down for me. >>> >>> For ease, if it's a mono or mono-related package (such as mono-develop, >>> libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll >>> update >>> the wiki and the owners lists as soon as I can. >>> >>> Basically, it's the old problem of time.... >> >> I'll take genchemlab and gonvert. > > Which you'll need to orphan in pkgdb, BTW. In case you forgot. I know I > would. :) Is there someone In rel-eng or cvsadmin or thereabouts that should assist with this, if Paul hasn't the time? I feel bad making more demands on his time in order to help him lessen the demands on his time. :) >>> TTFN >>> >>> Paul >>> >>> -- >>> Get your free @ukpost.com account now >>> http://www.ukpost.com/ >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> >> -- >> novus ordo absurdum >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > -- > novus ordo absurdum > -- novus ordo absurdum From jkeating at redhat.com Tue Dec 4 15:00:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 10:00:55 -0500 Subject: Orphaning packages In-Reply-To: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> Message-ID: <20071204100055.14e736cc@redhat.com> On Tue, 4 Dec 2007 08:34:12 -0600 (CST) "Jon Ciesla" wrote: > Is there someone In rel-eng or cvsadmin or thereabouts that should > assist with this, if Paul hasn't the time? I feel bad making more > demands on his time in order to help him lessen the demands on his > time. :) I marked these as orphans in pkgdb 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 michel.sylvan at gmail.com Tue Dec 4 15:34:27 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 4 Dec 2007 10:34:27 -0500 Subject: BuildRootOverrides request: devhelp (for vala-0.1.5) In-Reply-To: <20071204065813.2b0fc1cb@redhat.com> References: <20071204065813.2b0fc1cb@redhat.com> Message-ID: On 04/12/2007, Jesse Keating wrote: > On Tue, 4 Dec 2007 01:16:12 -0500 > "Michel Salim" wrote: > > > Could a CVS admin make devhelp available as a BuildRootOverrides? > > > > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3962 > > > > Vala has a soft BR on devhelp -- the documentation files don't get > > installed if devhelp is not detected at configure time, and everytime > > there is a Firefox update, devhelp lags behind by days, so it will be > > nice to have it permanently whitelisted. > > > There isn't a method to make a "permanent" whitelist. Why does your > app have to be built against a very specific version of devhelp? > It does not have to. The problem is that the (rather frequent) Firefox security fixes, and that devhelp is not whitelisted, means that at any moment in time, it is quite probable that the newer version of Firefox is already available in Koji, but the matching version of devhelp is not. The question should be the other way around -- why is devhelp dependent on a specific version of Firefox, such that a security bugfix breaks it. Hopefully xulrunner will solve it. Any package that depends on devhelp would not be buildable from time to time, because Koji would refuse to install devhelp, period. Solution would be to either 1. Keep the previous version of Firefox available purely for satisfying transitive dependencies like vala -> devhelp -> firefox 2. Always BRO devhelp as soon as Firefox is rebuilt Thanks, -- Michel Salim http://hircus.jaiku.com/ From caillon at redhat.com Tue Dec 4 15:41:00 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 04 Dec 2007 16:41:00 +0100 Subject: BuildRootOverrides request: devhelp (for vala-0.1.5) In-Reply-To: References: <20071204065813.2b0fc1cb@redhat.com> Message-ID: <4755750C.7050404@redhat.com> On 12/04/2007 04:34 PM, Michel Salim wrote: > On 04/12/2007, Jesse Keating wrote: >> On Tue, 4 Dec 2007 01:16:12 -0500 >> "Michel Salim" wrote: >> >>> Could a CVS admin make devhelp available as a BuildRootOverrides? >>> >>> https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3962 >>> >>> Vala has a soft BR on devhelp -- the documentation files don't get >>> installed if devhelp is not detected at configure time, and everytime >>> there is a Firefox update, devhelp lags behind by days, so it will be >>> nice to have it permanently whitelisted. >> >> There isn't a method to make a "permanent" whitelist. Why does your >> app have to be built against a very specific version of devhelp? >> > It does not have to. The problem is that the (rather frequent) Firefox > security fixes, and that devhelp is not whitelisted, means that at any > moment in time, it is quite probable that the newer version of Firefox > is already available in Koji, but the matching version of devhelp is > not. Actually, the problem existed because of the override from last time. If the override did not exist, you would be able to build against the correct version. (Try again now.) % koji latest-pkg dist-f8-build devhelp Build Tag Built by ---------------------------------------- -------------------- ---------------- devhelp-0.16.1-3.fc8 dist-f8-override stransky % koji latest-pkg dist-f8-updates devhelp Build Tag Built by ---------------------------------------- -------------------- ---------------- devhelp-0.16.1-4.fc8 dist-f8-updates caillon From limb at jcomserv.net Tue Dec 4 15:47:23 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 4 Dec 2007 09:47:23 -0600 (CST) Subject: Orphaning packages Message-ID: <49903.63.85.68.164.1196783243.squirrel@mail.jcomserv.net> > On Tue, 4 Dec 2007 08:34:12 -0600 (CST) > "Jon Ciesla" wrote: > >> Is there someone In rel-eng or cvsadmin or thereabouts that should >> assist with this, if Paul hasn't the time? I feel bad making more >> demands on his time in order to help him lessen the demands on his >> time. :) > > I marked these as orphans in pkgdb for you. Thanks Jesse! > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From paul at city-fan.org Tue Dec 4 16:05:00 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Dec 2007 16:05:00 +0000 Subject: mock 0.8.9 In-Reply-To: <20071204103753.GA3755@psilocybe.teonanacatl.org> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> <20071203205926.GA14186@humbolt.us.dell.com> <200712032346.55800.ville.skytta@iki.fi> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> Message-ID: <47557AAC.30002@city-fan.org> Todd Zullinger wrote: > Michael E Brown wrote: >> Patches welcome. > > Here's one. This adds a --define option, which may be used multiple > times. Usage is pretty much like the rpm --define option: > > $ mock --define="with_extra_cheese 1" --define="packager Monkey" ... > > Rather than pass the define options directly to rpmbuild, they are > added to the .rpmmacros file in the chroot. I'm not sure if there's > much difference in practice. If anyone knows differently, please > speak up. Anything written to the buildroot might get cached, mightn't it? Paul. From chasd at silveroaks.com Tue Dec 4 16:22:51 2007 From: chasd at silveroaks.com (chasd) Date: Tue, 4 Dec 2007 10:22:51 -0600 Subject: InstantMirror-0.2 Release In-Reply-To: <20071204070618.86E2273167@hormel.redhat.com> References: <20071204070618.86E2273167@hormel.redhat.com> Message-ID: <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> > Perhaps if httpd were re-tooled to setup virtual hosts in that manner? > or should I have put my virtual hosts in the conf.d directory? I just > seemed cleaner to separate sites from what seemed like modular > configs.. > > Anyway the point of this rambling is if we had something like that, > system that use httpd/apache could add a virtual host config to > httpd/virtual.d/ and not step on each others toes. > > -- > Nathanael D. Noblet If it was expected that InstantMirror was to be very popular, or there was a large number of other packages that would make use of directives, it might make sense to modify the default apache configuration to be more "virtual host friendly." As it stands, I think some prudent suggestions in the provided InstantMirror.conf file ( and perhaps renaming it ) is the best plan. "Persoanl File Sharing" aka gnome-user-share would be the only other "popular" package that might benefit from a "virtual host friendly" apache, but it spawns apache from a completely separate configuration, so it shouldn't be considered here. However I might not be aware of other packages in "Everything" that _should_ be considered. Anyway, I was able to test my suggestions on two different servers with two different sets of configuration files in conf.d, and my recommendations seem to work well in both cases. I guess that means this package is thoroughly tested ;) If I could make one other suggestion about InstantMirror, it would be to include a sample.repo file in /usr/share/doc/InstantMirror-x/ or throw it into /etc/yum.repos.d/ with enabled=0. Experienced admins should really know this config file stuff, but I run into a lot of generally competent computer people that are new to Linux and need a bit a of hand-holding -- hand-holding such as well commented sample configuration files. Sensible defaults, right ? BTW, InstantMirror is much simpler, lighter weight and easier to use than WSUS. Although WSUS has other abilities, InstantMirror has a good 50% of the functionality of WSUS. This package may seem innocuous, if you mentioned WSUS in the same breath as InstantMirror, it might warrant a mention as a feature, at least targeted at some new-to-Linux admins. Charles Dostale From ville.skytta at iki.fi Tue Dec 4 16:27:33 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 4 Dec 2007 18:27:33 +0200 Subject: mock 0.8.9 In-Reply-To: <20071204103753.GA3755@psilocybe.teonanacatl.org> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> Message-ID: <200712041827.34181.ville.skytta@iki.fi> On Tuesday 04 December 2007, Todd Zullinger wrote: > Michael E Brown wrote: > > Patches welcome. > > Here's one. This adds a --define option, which may be used multiple > times. Usage is pretty much like the rpm --define option: > > $ mock --define="with_extra_cheese 1" --define="packager Monkey" ... That's nice, but even better IMHO would be something that could be used to pass arbitrary options (or at least -D, --define, --with, --without and --target) as-is to rpmbuild, for example everything after a "--", like mock rebuild foo.src.rpm -- --define="foo bar" --target=i686 --with foo --without bar --define 'quux baz' mach can do that (without the -- though; it passes everything after the src.rpm names to rpmbuild). From zcerza at redhat.com Tue Dec 4 16:59:04 2007 From: zcerza at redhat.com (Zack Cerza) Date: Tue, 04 Dec 2007 11:59:04 -0500 Subject: firefox vs epiphany In-Reply-To: <47541DBB.1070402@redhat.com> References: <1196625336.2547.4.camel@tiger> <47541DBB.1070402@redhat.com> Message-ID: <47558758.7010704@redhat.com> Christopher Aillon wrote: > * Much to my dismay, many web authors will look for only IE or Firefox. > There are websites that actually STOP WORKING if the browser is not > Firefox (or IE). Firefox CVS HEAD builds recently stopped reporting > "Firefox" in the useragent string for example which made many sites[1] > break. > > [1] > https://bugzilla.mozilla.org/showdependencytree.cgi?id=334967&hide_resolved=1 Hey, at least they're checking for Firefox now. So we're making (awkward, slow) progress. Zack From jkeating at redhat.com Tue Dec 4 16:54:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 11:54:55 -0500 Subject: TeXLive is in rawhide In-Reply-To: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> Message-ID: <20071204115455.7f2985ec@redhat.com> On Mon, 3 Dec 2007 13:21:32 +0100 Jindrich Novy wrote: > Hi all, > > I come with good news for TeX users in Fedora. TeXLive is now finally > imported and built in rawhide since today. This is causing conflicts and failing builds. http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log Something needs to 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 Michael_E_Brown at dell.com Tue Dec 4 16:59:50 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 4 Dec 2007 10:59:50 -0600 Subject: mock 0.8.9 In-Reply-To: <47557AAC.30002@city-fan.org> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712030045t3f41b402gb8d80637a9c7d120@mail.gmail.com> <20071203205926.GA14186@humbolt.us.dell.com> <200712032346.55800.ville.skytta@iki.fi> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> <47557AAC.30002@city-fan.org> Message-ID: <20071204165950.GA24532@humbolt.us.dell.com> On Tue, Dec 04, 2007 at 04:05:00PM +0000, Paul Howarth wrote: > Todd Zullinger wrote: > >Michael E Brown wrote: > >>Patches welcome. > > > >Here's one. This adds a --define option, which may be used multiple > >times. Usage is pretty much like the rpm --define option: > > > >$ mock --define="with_extra_cheese 1" --define="packager Monkey" ... > > > >Rather than pass the define options directly to rpmbuild, they are > >added to the .rpmmacros file in the chroot. I'm not sure if there's > >much difference in practice. If anyone knows differently, please > >speak up. > > Anything written to the buildroot might get cached, mightn't it? Excellent thought. In this case, it is safe. The .rpmmacros file is written from scratch in init() every time, so there is no possibility of an old .rpmmacros file hanging around. -- Michael From Michael_E_Brown at dell.com Tue Dec 4 17:06:33 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 4 Dec 2007 11:06:33 -0600 Subject: mock 0.8.9 In-Reply-To: <200712041827.34181.ville.skytta@iki.fi> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> <200712041827.34181.ville.skytta@iki.fi> Message-ID: <20071204170633.GB24532@humbolt.us.dell.com> On Tue, Dec 04, 2007 at 06:27:33PM +0200, Ville Skytt? wrote: > On Tuesday 04 December 2007, Todd Zullinger wrote: > > Michael E Brown wrote: > > > Patches welcome. > > > > Here's one. This adds a --define option, which may be used multiple > > times. Usage is pretty much like the rpm --define option: > > > > $ mock --define="with_extra_cheese 1" --define="packager Monkey" ... > > That's nice, but even better IMHO would be something that could be used to > pass arbitrary options (or at least -D, --define, --with, --without > and --target) as-is to rpmbuild, for example everything after a "--", like > > mock rebuild foo.src.rpm -- --define="foo bar" --target=i686 --with > foo --without bar --define 'quux baz' --target is already passed to rpmbuild. Its value depends on "target_arch" setting in the chroot config file. file:///usr/share/doc/rpm-4.4.2.2/conditionalbuilds ===================================== For example, when rpm is invoked as \verbatim rpm ... --with ldap ... \endverbatim then the popt aliases will cause the options to be rewritten as \verbatim rpm ... --define "_with_ldap --with-ldap" ... \endverbatim which causes a "%_with_ldap" macro to be defined with value "--with-ldap" during a build. ===================================== So, we could probably easily implement --with{,out} using this code as a base. -- Michael From jonathan.underwood at gmail.com Tue Dec 4 17:08:11 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 4 Dec 2007 17:08:11 +0000 Subject: TeXLive is in rawhide In-Reply-To: <20071204115455.7f2985ec@redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <20071204115455.7f2985ec@redhat.com> Message-ID: <645d17210712040908s2bd01691t2b87d823cd1a6f4@mail.gmail.com> On 04/12/2007, Jesse Keating wrote: > On Mon, 3 Dec 2007 13:21:32 +0100 > Jindrich Novy wrote: > > > Hi all, > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > imported and built in rawhide since today. > > > This is causing conflicts and failing builds. > http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log > > Something needs to happen. Simple solution would be to pull tetex out of the repos. Presumably that's the long term plan? anyway. From mclasen at redhat.com Tue Dec 4 17:12:26 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 04 Dec 2007 12:12:26 -0500 Subject: TeXLive is in rawhide In-Reply-To: <645d17210712040908s2bd01691t2b87d823cd1a6f4@mail.gmail.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <20071204115455.7f2985ec@redhat.com> <645d17210712040908s2bd01691t2b87d823cd1a6f4@mail.gmail.com> Message-ID: <1196788346.2898.8.camel@localhost.localdomain> On Tue, 2007-12-04 at 17:08 +0000, Jonathan Underwood wrote: > On 04/12/2007, Jesse Keating wrote: > > On Mon, 3 Dec 2007 13:21:32 +0100 > > Jindrich Novy wrote: > > > > > Hi all, > > > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > > imported and built in rawhide since today. > > > > > > This is causing conflicts and failing builds. > > http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log > > > > Something needs to happen. > > Simple solution would be to pull tetex out of the repos. Presumably > that's the long term plan? anyway. For upgrades, you still need to have an Obsoletes. From tmraz at redhat.com Tue Dec 4 17:17:25 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 04 Dec 2007 18:17:25 +0100 Subject: TeXLive is in rawhide In-Reply-To: <1196788346.2898.8.camel@localhost.localdomain> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <20071204115455.7f2985ec@redhat.com> <645d17210712040908s2bd01691t2b87d823cd1a6f4@mail.gmail.com> <1196788346.2898.8.camel@localhost.localdomain> Message-ID: <1196788645.3037.95.camel@vespa.kabelta.loc> On Tue, 2007-12-04 at 12:12 -0500, Matthias Clasen wrote: > On Tue, 2007-12-04 at 17:08 +0000, Jonathan Underwood wrote: > > On 04/12/2007, Jesse Keating wrote: > > > On Mon, 3 Dec 2007 13:21:32 +0100 > > > Jindrich Novy wrote: > > > > > > > Hi all, > > > > > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > > > imported and built in rawhide since today. > > > > > > > > > This is causing conflicts and failing builds. > > > http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log > > > > > > Something needs to happen. > > > > Simple solution would be to pull tetex out of the repos. Presumably > > that's the long term plan? anyway. > > For upgrades, you still need to have an Obsoletes. There are, but perhaps incorrect? There is 'Obsoletes: tetex <= 3.0' and others. How unspecified release counts? Is it completely ignored in the comparsion or does it count as empty? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From opensource at till.name Tue Dec 4 17:26:58 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 18:26:58 +0100 Subject: TeXLive is in rawhide In-Reply-To: <1196788645.3037.95.camel@vespa.kabelta.loc> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196788346.2898.8.camel@localhost.localdomain> <1196788645.3037.95.camel@vespa.kabelta.loc> Message-ID: <200712041827.07319.opensource@till.name> On Di Dezember 4 2007, Tomas Mraz wrote: > There is 'Obsoletes: tetex <= 3.0' and others. > How unspecified release counts? Is it completely ignored in the > comparsion or does it count as empty? tetex <= 3.0 is wrong, because tetex-3.0-50.fc9 is newer that tetex-3.0. In case there won't be any tetex release bumps, Obsoletes: tetex < 3.0-51 should 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 SteveD at redhat.com Tue Dec 4 17:28:55 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 04 Dec 2007 12:28:55 -0500 Subject: Heads up: openldap and openssl changed in devel In-Reply-To: <1196755854.3037.48.camel@vespa.kabelta.loc> References: <1196755854.3037.48.camel@vespa.kabelta.loc> Message-ID: <47558E57.3070000@RedHat.com> Tomas Mraz wrote: > There are new versions of OpenLDAP (2.4.6) and OpenSSL (0.9.8g) with > different soname in rawhide. Please rebuild your packages, which depend > on openldap and openssl. How do you get the new versions installed? I just updated a kvm client to the latest rawhide and I'm only getting openldap-2.3.39-1.fc9 tia, steved. From myfedora at richip.dhs.org Tue Dec 4 17:30:15 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Dec 2007 10:30:15 -0700 Subject: Package/System-specific repoquery Message-ID: <1196789415.7213.7.camel@localhost6.localdomain6> Hi, I asked this at JPackage.org, but this is probably a better place to query. Is there a way to do the equivalent of "repoquery --whatprovides " Java? As in "repoquery --whatprovides com.netscape.sasl.Sasl"? I mean, the information is there. Is the semantics and the smarts available in repoquery? -- Richi Plana From ssorce at redhat.com Tue Dec 4 17:32:29 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Dec 2007 12:32:29 -0500 Subject: Heads up: openldap and openssl changed in devel In-Reply-To: <1196755854.3037.48.camel@vespa.kabelta.loc> References: <1196755854.3037.48.camel@vespa.kabelta.loc> Message-ID: <1196789549.17681.27.camel@localhost.localdomain> On Tue, 2007-12-04 at 09:10 +0100, Tomas Mraz wrote: > There are new versions of OpenLDAP (2.4.6) and OpenSSL (0.9.8g) with > different soname in rawhide. Please rebuild your packages, which depend > on openldap and openssl. I really would like to rebuild samba packages, unfortunately KDE and its problems with GPLv3) is still blocking the new samba packages... Is there any news from Trolltech about KDE libraries licensing? Can we disable libsmbclient support in KDE while we wait ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jkeating at redhat.com Tue Dec 4 17:34:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 12:34:56 -0500 Subject: Package/System-specific repoquery In-Reply-To: <1196789415.7213.7.camel@localhost6.localdomain6> References: <1196789415.7213.7.camel@localhost6.localdomain6> Message-ID: <20071204123456.7d2f9633@redhat.com> On Tue, 04 Dec 2007 10:30:15 -0700 Richi Plana wrote: > Is there a way to do the equivalent of "repoquery --whatprovides > " Java? As in "repoquery --whatprovides > com.netscape.sasl.Sasl"? I mean, the information is there. Is the > semantics and the smarts available in repoquery? The package itself would have to Provide it, either manually or automatically (and doing automatic provides such as these seems like it would bloat the provides list pretty fast, but we have some history with perl packages.) -- 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 overholt at redhat.com Tue Dec 4 17:44:33 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 04 Dec 2007 12:44:33 -0500 Subject: Package/System-specific repoquery In-Reply-To: <20071204123456.7d2f9633@redhat.com> References: <1196789415.7213.7.camel@localhost6.localdomain6> <20071204123456.7d2f9633@redhat.com> Message-ID: <47559201.7050205@redhat.com> Jesse Keating wrote: > On Tue, 04 Dec 2007 10:30:15 -0700 > Richi Plana wrote: > >> Is there a way to do the equivalent of "repoquery --whatprovides >> " Java? As in "repoquery --whatprovides >> com.netscape.sasl.Sasl"? I mean, the information is there. Is the >> semantics and the smarts available in repoquery? > > The package itself would have to Provide it, either manually or > automatically (and doing automatic provides such as these seems like > it would bloat the provides list pretty fast, but we have some history > with perl packages.) We tried to do this with OSGi "provides" information. I'm not sure about the status of that, though. The person who wrote the rpm macro to scrape the information went back to school and I haven't had time to see why it's not working. Andrew From myfedora at richip.dhs.org Tue Dec 4 17:49:13 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Dec 2007 10:49:13 -0700 Subject: Package/System-specific repoquery In-Reply-To: <20071204123456.7d2f9633@redhat.com> References: <1196789415.7213.7.camel@localhost6.localdomain6> <20071204123456.7d2f9633@redhat.com> Message-ID: <1196790553.7213.13.camel@localhost6.localdomain6> On Tue, 2007-12-04 at 12:34 -0500, Jesse Keating wrote: > On Tue, 04 Dec 2007 10:30:15 -0700 > Richi Plana wrote: > > > Is there a way to do the equivalent of "repoquery --whatprovides > > " Java? As in "repoquery --whatprovides > > com.netscape.sasl.Sasl"? I mean, the information is there. Is the > > semantics and the smarts available in repoquery? > > The package itself would have to Provide it, either manually or > automatically (and doing automatic provides such as these seems like > it would bloat the provides list pretty fast, but we have some history > with perl packages.) It's actually pretty important meta-info ... perhaps not for desktop or server users, but developers could use that info. I understand that RPM or rpmbuild examines the contents of JAR files. Again, it boils down to what kind of metainfo structure RPM/Yum has and the query language it supports. RPM has been multiplexing info in the package filename and Provides: field for a while and it's straining things both on the utilities end and the users' end. I guess when/if the time comes that metainfo/query is reconsidered, I'll bring this up again. Thanks! -- Richi Plana From jnovy at redhat.com Tue Dec 4 17:52:29 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 4 Dec 2007 18:52:29 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071204115455.7f2985ec@redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <20071204115455.7f2985ec@redhat.com> Message-ID: <20071204175229.GA2906@dhcp-lab-186.brq.redhat.com> On Tue, Dec 04, 2007 at 11:54:55AM -0500, Jesse Keating wrote: > On Mon, 3 Dec 2007 13:21:32 +0100 > Jindrich Novy wrote: > > > Hi all, > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > imported and built in rawhide since today. > > > This is causing conflicts and failing builds. > http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log > > Something needs to happen. > The Provides/Obsoletes are now modified from: Obsoletes: tetex <= 3.0 Provides: tetex = 3.1 to: Obsoletes: tetex < 3.0-99 Provides: tetex = 3.0-99 Hopefully it's fixed now. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From overholt at redhat.com Tue Dec 4 18:02:23 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 04 Dec 2007 13:02:23 -0500 Subject: Package/System-specific repoquery In-Reply-To: <1196790553.7213.13.camel@localhost6.localdomain6> References: <1196789415.7213.7.camel@localhost6.localdomain6> <20071204123456.7d2f9633@redhat.com> <1196790553.7213.13.camel@localhost6.localdomain6> Message-ID: <4755962F.7050808@redhat.com> Richi Plana wrote: > On Tue, 2007-12-04 at 12:34 -0500, Jesse Keating wrote: >> On Tue, 04 Dec 2007 10:30:15 -0700 >> Richi Plana wrote: >> >>> Is there a way to do the equivalent of "repoquery --whatprovides >>> " Java? As in "repoquery --whatprovides >>> com.netscape.sasl.Sasl"? I mean, the information is there. Is the >>> semantics and the smarts available in repoquery? >> The package itself would have to Provide it, either manually or >> automatically (and doing automatic provides such as these seems like >> it would bloat the provides list pretty fast, but we have some history >> with perl packages.) > > It's actually pretty important meta-info ... perhaps not for desktop or > server users, but developers could use that info. I understand that RPM > or rpmbuild examines the contents of JAR files. IMO, without a module system this is less useful. That's why I wanted to do it for OSGi provides and not the general case (well, that and it's easier and useful to me as an Eclipse developer and packager :). Andrew From smooge at gmail.com Tue Dec 4 18:18:24 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 4 Dec 2007 11:18:24 -0700 Subject: DJB's software components In-Reply-To: <20071204051045.GB4865@auslistsprd01.us.dell.com> References: <1196432626.9238.1.camel@localhost.localdomain> <12572.1196491917@sss.pgh.pa.us> <20071201140913.GA9617@devserv.devel.redhat.com> <1196720344.18776.7.camel@localhost> <1196727504.3338.53.camel@localhost.localdomain> <20071204051045.GB4865@auslistsprd01.us.dell.com> Message-ID: <80d7e4090712041018i687b7faat2db28123f9bd957d@mail.gmail.com> On Dec 3, 2007 10:10 PM, Matt Domsch wrote: > On Tue, Dec 04, 2007 at 05:48:24AM +0530, Tom spot Callaway wrote: > > > > On Mon, 2007-12-03 at 16:19 -0600, Callum Lerwick wrote: > > > On Mon, 2007-12-03 at 13:32 +0100, Matej Cepl wrote: > > > > Which was the reason I was shocked DJB released qmail under public domain > > > > and why I would always prefer at least MIT/X/BSD-no-appropriation/CC-au > > > > always. IIRC, sqlite is the only substantial software which is under > > > > public domain and there is a reason for that. > > > > > > IANAL, but doesn't this mean he's effectively released it under *every* > > > license ever written? :) Are we going to have GPL and BSD forks battling > > > it out now? > > > > Its possible, but Public Domain means something closer to "no license" > > than "every license". We could see forks battling it out, but somehow, I > > doubt this will happen. > > Right - really "no license". > > Public Domain means anyone is free to take it and use it however they > want - including pulling into another app and re-licensing it. > > One of the ways people can contribute to GNU projects is to explicitly > assign copyright of code to the FSF. The other way is to disclaim > your work into the public domain, at which point the GNU project > maintainer may pick it up and include it in a GNU-licensed > application. Changes to the code will carry the FSF copyright, and > the whole will carry the GNU license. (see > parted/libparted/labels/gpt.c for such an example if you're curious). > Oh dear god.. there is the nightmare of my tech support life.. gqmail.. -- 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 pertusus at free.fr Tue Dec 4 18:18:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 4 Dec 2007 19:18:24 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071204115455.7f2985ec@redhat.com> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <20071204115455.7f2985ec@redhat.com> Message-ID: <20071204181824.GB2789@free.fr> On Tue, Dec 04, 2007 at 11:54:55AM -0500, Jesse Keating wrote: > On Mon, 3 Dec 2007 13:21:32 +0100 > Jindrich Novy wrote: > > > Hi all, > > > > I come with good news for TeX users in Fedora. TeXLive is now finally > > imported and built in rawhide since today. > > > This is causing conflicts and failing builds. > http://koji.fedoraproject.org/koji/getfile?taskID=273763&name=root.log > > Something needs to happen. In my recalling this was fixed. Maybe waiting for some builds. There are nasty build dependency loops. -- Pat From tcallawa at redhat.com Tue Dec 4 18:38:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 05 Dec 2007 00:08:48 +0530 Subject: Heads up: openldap and openssl changed in devel In-Reply-To: <1196789549.17681.27.camel@localhost.localdomain> References: <1196755854.3037.48.camel@vespa.kabelta.loc> <1196789549.17681.27.camel@localhost.localdomain> Message-ID: <1196793528.3231.3.camel@localhost.localdomain> On Tue, 2007-12-04 at 12:32 -0500, Simo Sorce wrote: > On Tue, 2007-12-04 at 09:10 +0100, Tomas Mraz wrote: > > There are new versions of OpenLDAP (2.4.6) and OpenSSL (0.9.8g) with > > different soname in rawhide. Please rebuild your packages, which depend > > on openldap and openssl. > > I really would like to rebuild samba packages, unfortunately KDE and its > problems with GPLv3) is still blocking the new samba packages... > > Is there any news from Trolltech about KDE libraries licensing? Not yet, but it has not been 3-4 weeks yet. Be patient. :) ~spot From rdieter at math.unl.edu Tue Dec 4 18:47:36 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Dec 2007 12:47:36 -0600 Subject: Heads up: openldap and openssl changed in devel References: <1196755854.3037.48.camel@vespa.kabelta.loc> <1196789549.17681.27.camel@localhost.localdomain> Message-ID: Simo Sorce wrote: > I really would like to rebuild samba packages, unfortunately KDE and its > problems with GPLv3) is still blocking the new samba packages... ... > Can we disable libsmbclient support in KDE while we wait ? done. -- Rex From ssorce at redhat.com Tue Dec 4 18:54:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Dec 2007 13:54:52 -0500 Subject: Heads up: openldap and openssl changed in devel In-Reply-To: References: <1196755854.3037.48.camel@vespa.kabelta.loc> <1196789549.17681.27.camel@localhost.localdomain> Message-ID: <1196794492.17681.33.camel@localhost.localdomain> On Tue, 2007-12-04 at 12:47 -0600, Rex Dieter wrote: > Simo Sorce wrote: > > > I really would like to rebuild samba packages, unfortunately KDE and its > > problems with GPLv3) is still blocking the new samba packages... > ... > > Can we disable libsmbclient support in KDE while we wait ? > > done. Thanks. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From ssorce at redhat.com Tue Dec 4 18:55:49 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Dec 2007 13:55:49 -0500 Subject: Heads up: openldap and openssl changed in devel In-Reply-To: <1196793528.3231.3.camel@localhost.localdomain> References: <1196755854.3037.48.camel@vespa.kabelta.loc> <1196789549.17681.27.camel@localhost.localdomain> <1196793528.3231.3.camel@localhost.localdomain> Message-ID: <1196794549.17681.35.camel@localhost.localdomain> On Wed, 2007-12-05 at 00:08 +0530, Tom "spot" Callaway wrote: > On Tue, 2007-12-04 at 12:32 -0500, Simo Sorce wrote: > > On Tue, 2007-12-04 at 09:10 +0100, Tomas Mraz wrote: > > > There are new versions of OpenLDAP (2.4.6) and OpenSSL (0.9.8g) with > > > different soname in rawhide. Please rebuild your packages, which depend > > > on openldap and openssl. > > > > I really would like to rebuild samba packages, unfortunately KDE and its > > problems with GPLv3) is still blocking the new samba packages... > > > > Is there any news from Trolltech about KDE libraries licensing? > > Not yet, but it has not been 3-4 weeks yet. Be patient. :) I am but other packages wait a samba build so ... thanks to Rex for temporarily disabling libsmbclient in KDE until we wait the re-licensing. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From dennis at ausil.us Tue Dec 4 16:30:12 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 4 Dec 2007 10:30:12 -0600 Subject: fedora-packager Message-ID: <200712041030.17904.dennis@ausil.us> Hi All, I created a new hosted project at https://hosted.fedoraproject.org/projects/fedora-packager/ with one simple goal. make it easy for people to setup a fedora package maintainer environment. Right now all that is currently in place is fedora-packager-setup.sh used to setup your certs and configs for koji and plague and a new script fedora-cvs that will checkout from cvs modules for you using your FAS account. Why am i telling you this? well for one fedora-packager-setup.sh is no longer in the koji package its in fedora-packager and two I want your help. Do you have a script that you find really useful to help you maintain your packages? want to share them? then please help make fedora-packager better. We also now have a new comps group fedora-packager. so there is two easy ways to get your development environment setup on a new box "yum groupinstall fedora-packager" and "yum install fedora-packager" both will do the same thing. then run fedora-packager-setup.sh and your on your way. 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 mschwendt.tmp0701.nospam at arcor.de Tue Dec 4 19:15:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Dec 2007 20:15:09 +0100 Subject: TeXLive is in rawhide In-Reply-To: <200712041827.07319.opensource@till.name> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <1196788346.2898.8.camel@localhost.localdomain> <1196788645.3037.95.camel@vespa.kabelta.loc> <200712041827.07319.opensource@till.name> Message-ID: <20071204201509.ca76a47c.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Dec 2007 18:26:58 +0100, Till Maas wrote: > On Di Dezember 4 2007, Tomas Mraz wrote: > > > There is 'Obsoletes: tetex <= 3.0' and others. > > How unspecified release counts? Is it completely ignored in the > > comparsion or does it count as empty? > > tetex <= 3.0 is wrong, because tetex-3.0-50.fc9 is newer that tetex-3.0. In > case there won't be any tetex release bumps, > Obsoletes: tetex < 3.0-51 should work. Wrong. "Obsoletes: tetex <= 3.0" covers all releases including 3.0-50.fc9 From pertusus at free.fr Tue Dec 4 19:36:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 4 Dec 2007 20:36:37 +0100 Subject: fedora-packager In-Reply-To: <200712041030.17904.dennis@ausil.us> References: <200712041030.17904.dennis@ausil.us> Message-ID: <20071204193637.GC2789@free.fr> On Tue, Dec 04, 2007 at 10:30:12AM -0600, Dennis Gilmore wrote: > Hi All, > > I created a new hosted project at > https://hosted.fedoraproject.org/projects/fedora-packager/ with one simple > goal. make it easy for people to setup a fedora package maintainer > environment. Right now all that is currently in place is > fedora-packager-setup.sh used to setup your certs and configs for koji and > plague and a new script fedora-cvs that will checkout from cvs modules for > you using your FAS account. > > Why am i telling you this? well for one fedora-packager-setup.sh is no longer > in the koji package its in fedora-packager and two I want your help. > > Do you have a script that you find really useful to help you maintain your > packages? want to share them? then please help make fedora-packager better. I have get_scratch_packages.sh that can be used to verify multilib conflicts for people with monoarch platforms. It requires multilib-cmp.py that somebody else wrote, I attach it, maybe not the latest version, though. -- Pat -------------- next part -------------- A non-text attachment was scrubbed... Name: get_scratch_packages.sh Type: application/x-sh Size: 738 bytes Desc: not available URL: -------------- next part -------------- #!/usr/bin/python -tt # # Simple script to help ferret out multilib conflicts. # # Can be used in two different modes. The first is comparing two # packages given on the command line and showing any conflicts. # multilib-cmp.py # Can also be used to find multilib conflicts in a tree # multilib-cmp.py # # Copyright, 2006 Red Hat, Inc. # Jeremy Katz # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 only # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. import os,sys import glob import rpm import rpmUtils.arch import rpmUtils.miscutils _ts = None def comparePackages(one, two): fi1 = one.fiFromHeader() fi2 = two.fiFromHeader() num = 0 for file1 in fi1: name = fi1.FN() for file2 in fi2: if fi2.FN() == name: break if fi2.FN() != name: continue # if they're different colors, rpm is fine with it if fi1.FColor() != fi2.FColor(): continue # else, they're the same color and same path. ensure they don't # conflict if fi1.MD5() != fi2.MD5(): print "File conflict for %s in %s-%s-%s" %(fi1.FN(), one['name'], one['version'], one['release']) num += 1 return num def packageCompare(one, two): global _ts if _ts is None: _ts = rpm.TransactionSet() _ts.setVSFlags(-1) if not os.access(one, os.R_OK) or not os.access(two, os.R_OK): print one, two print "need packages!" sys.exit(1) fd = os.open(one, os.O_RDONLY) h1 = _ts.hdrFromFdno(fd) os.close(fd) fd = os.open(two, os.O_RDONLY) h2 = _ts.hdrFromFdno(fd) os.close(fd) return comparePackages(h1, h2) def multilibTreeCompare(tree): if not os.path.isdir(tree): print "Not a tree!" sys.exit(1) checked = [] for f in os.listdir(tree): (n, v, r, e, a) = rpmUtils.miscutils.splitFilename(f) if not rpmUtils.arch.isMultiLibArch(a): continue files = glob.glob("%s/%s-%s-%s.*.rpm" %(tree, n, v, r)) if len(files) == 1: continue for f2 in files: f2 = os.path.basename(f2) (n2, v2, r2, e2, a2) = rpmUtils.miscutils.splitFilename(f2) if (n, a) == (n2, a2): continue if a2 not in rpmUtils.arch.getArchList(a): continue packageCompare("%s/%s" %(tree, f), "%s/%s" %(tree, f2)) pass def main(): if len(sys.argv) == 2: multilibTreeCompare(sys.argv[1]) elif len(sys.argv) == 3: num = packageCompare(sys.argv[1], sys.argv[2]) if num == 0: print "No conflicts" else: print "Invalid usage!" sys.exit(1) if __name__ == "__main__": main() From michel.sylvan at gmail.com Tue Dec 4 19:46:19 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 4 Dec 2007 14:46:19 -0500 Subject: Package Review Process wiki page and Fedora Update System Message-ID: Hi all, I've been noticing that on several occasions, new packagers would get their packages approved, and then not submit the package to Fedora Update System. There's thus a delay before the package is available on stable releases. It just occured to me to check the Package Review Process page on the wiki today, and it turns out that it does not mention Bodhi at all. Should this be added? If so, should new packages be submitted as stable or testing? My personal opinion is stable for any distributions tested by the packager and reviewer, and testing for other distributions (with the caveat that a package for any distribution can't go stable before a newer distribution) Regards, -- Michel Salim http://hircus.jaiku.com/ From nicolas.mailhot at laposte.net Tue Dec 4 20:10:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Dec 2007 21:10:28 +0100 Subject: Package/System-specific repoquery In-Reply-To: <1196790553.7213.13.camel@localhost6.localdomain6> References: <1196789415.7213.7.camel@localhost6.localdomain6> <20071204123456.7d2f9633@redhat.com> <1196790553.7213.13.camel@localhost6.localdomain6> Message-ID: <1196799028.13817.49.camel@rousalka.dyndns.org> Le mardi 04 d?cembre 2007 ? 10:49 -0700, Richi Plana a ?crit : > It's actually pretty important meta-info ... perhaps not for desktop or > server users, but developers could use that info. I understand that RPM > or rpmbuild examines the contents of JAR files. Jars are pretty much a lost cause, we never managed to support them properly, they've not been designed for rpm-like dep checking and they're likely to be discontinued before we get decent support even if we started a new effort today. OSGi and the Modules bit SUN is adding to Java 7 http://jcp.org/en/jsr/detail?id=277 however present good rpm integration potential. But someone knowledgeable with java and rpm needs to create the metadata bridge (it would be especially interesting for the Java 7 modules bit, as it's still not finalised, so it's still possible to get the SUN spec tweaked to help rpm integration) I'm not volunteering :p Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Tue Dec 4 20:33:01 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 4 Dec 2007 22:33:01 +0200 Subject: fedora-packager In-Reply-To: <200712041030.17904.dennis@ausil.us> References: <200712041030.17904.dennis@ausil.us> Message-ID: <200712042233.01409.ville.skytta@iki.fi> On Tuesday 04 December 2007, Dennis Gilmore wrote: > > Why am i telling you this? well for one fedora-packager-setup.sh is no > longer in the koji package its in fedora-packager and two I want your > help. > > Do you have a script that you find really useful to help you maintain your > packages? want to share them? then please help make fedora-packager > better. I would also like to point out that if you have scripts that are rpm packaging related, generally useful and not bound too tightly to Fedora or its infrastructure, to benefit a potentially larger audience than "just" Fedora and derivatives, another package you might be interested in contributing those to is rpmdevtools. There's an infrastructure ticket open for getting it a hosted.fp.org project [0], which hopefully will be taken care of soon. In the meantime, feel free to submit stuff via Bugzilla or mail. [0] https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/189 From opensource at till.name Tue Dec 4 20:33:35 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 21:33:35 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071204201509.ca76a47c.mschwendt.tmp0701.nospam@arcor.de> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712041827.07319.opensource@till.name> <20071204201509.ca76a47c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200712042133.41220.opensource@till.name> On Di Dezember 4 2007, Michael Schwendt wrote: > Wrong. "Obsoletes: tetex <= 3.0" covers all releases including 3.0-50.fc9 Are you sure? Is there any documentation about this freely available? Because: $ rpmdev-vercmp 3.0 3.0-50.fc9 0:3.0-50.fc9 is newer And in case that rpm uses a different version comparison algorithm here, this should be well documented. Maximum rpm and the Fedora rpm guide did not mention that rpm behaves here different. 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 Tue Dec 4 20:38:55 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 21:38:55 +0100 Subject: fedora-packager In-Reply-To: <200712041030.17904.dennis@ausil.us> References: <200712041030.17904.dennis@ausil.us> Message-ID: <200712042138.55976.opensource@till.name> On Di Dezember 4 2007, Dennis Gilmore wrote: > Do you have a script that you find really useful to help you maintain your > packages? want to share them? then please help make fedora-packager > better. There are several scripts available at: http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts 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 mmcgrath at redhat.com Tue Dec 4 20:38:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 04 Dec 2007 14:38:06 -0600 Subject: fedora-packager In-Reply-To: <200712042233.01409.ville.skytta@iki.fi> References: <200712041030.17904.dennis@ausil.us> <200712042233.01409.ville.skytta@iki.fi> Message-ID: <4755BAAE.8030608@redhat.com> Ville Skytt? wrote: > On Tuesday 04 December 2007, Dennis Gilmore wrote: > >> Why am i telling you this? well for one fedora-packager-setup.sh is no >> longer in the koji package its in fedora-packager and two I want your >> help. >> >> Do you have a script that you find really useful to help you maintain your >> packages? want to share them? then please help make fedora-packager >> better. >> > > I would also like to point out that if you have scripts that are rpm packaging > related, generally useful and not bound too tightly to Fedora or its > infrastructure, to benefit a potentially larger audience than "just" Fedora > and derivatives, another package you might be interested in contributing > those to is rpmdevtools. > > There's an infrastructure ticket open for getting it a hosted.fp.org project > [0], which hopefully will be taken care of soon. In the meantime, feel free > to submit stuff via Bugzilla or mail. > Just an FYI to others waiting on hosted tickets, we're in the process of getting some dedicated servers for hosting and we're migrating / testing right now. Should be completed soon. -Mike From mschwendt.tmp0701.nospam at arcor.de Tue Dec 4 21:23:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Dec 2007 22:23:35 +0100 Subject: TeXLive is in rawhide In-Reply-To: <200712042133.41220.opensource@till.name> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712041827.07319.opensource@till.name> <20071204201509.ca76a47c.mschwendt.tmp0701.nospam@arcor.de> <200712042133.41220.opensource@till.name> Message-ID: <20071204222335.6b872972.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Dec 2007 21:33:35 +0100, Till Maas wrote: > On Di Dezember 4 2007, Michael Schwendt wrote: > > > Wrong. "Obsoletes: tetex <= 3.0" covers all releases including 3.0-50.fc9 > > Are you sure? Yes, I am. > Is there any documentation about this freely available? I don't know that. Maybe one of the available books explains it. It's common packaging knowledge, I believe. If no specific release is asked for, it is not necessary anymore to compare a package's %release value. Just as in Requires: foo = 3.0 where your counter-example from below cannot be applied either, since the "equal than" comparison works differently. Any release will match, but you cannot "rpmdev-vercmp 3.0-1 3.0" to prove it. > Because: > $ rpmdev-vercmp 3.0 3.0-50.fc9 > 0:3.0-50.fc9 is newer Strange example, because 1) you ask for a specific Release, and 2) it compares the three EVR args differently. Your first EVR has Release "None", which is mapped to something less than "not None" by RPM implicitly to make comparison against Release 50.fc9 possible. Even Release 0 is greater than "None". So, what value would you expect RPM to substitute "None" with? From jkeating at redhat.com Tue Dec 4 21:36:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 16:36:25 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? Message-ID: <20071204163625.6cda6f82@redhat.com> Currently our cvsadmin request template looks like: New Package CVS Request ======================= Package Name: Short Description: Owners: Branches: InitialCC: Cvsextras Commits: To me this looks like you have to opt /in/ to Cvsextras Commits, and I'm not sure what will happen if you don't fill in a value. Could we word it in such a way that as a requester you'd have to explicitly opt out of of having open acls. I don't have suggested phrasing in mind just yet, but I wondered if folks were open to the 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 opensource at till.name Tue Dec 4 21:47:12 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 22:47:12 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071204222335.6b872972.mschwendt.tmp0701.nospam@arcor.de> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712042133.41220.opensource@till.name> <20071204222335.6b872972.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200712042247.30039.opensource@till.name> On Di Dezember 4 2007, Michael Schwendt wrote: > If no specific release is asked for, it is not necessary anymore to > compare a package's %release value. Just as in > > Requires: foo = 3.0 > > where your counter-example from below cannot be applied either, since > the "equal than" comparison works differently. Any release will match, > but you cannot "rpmdev-vercmp 3.0-1 3.0" to prove it. Is Requires: foo > 3.0 satisfied with foo-3.0-1 or only with every version of foo that is higher than 3.0, e.g. foo-3.1-1? 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 Tue Dec 4 21:58:38 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 22:58:38 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071204163625.6cda6f82@redhat.com> References: <20071204163625.6cda6f82@redhat.com> Message-ID: <200712042258.44283.opensource@till.name> On Di Dezember 4 2007, Jesse Keating wrote: > Currently our cvsadmin request template looks like: > Cvsextras Commits: > > To me this looks like you have to opt /in/ to Cvsextras Commits, and > I'm not sure what will happen if you don't fill in a value. > > Could we word it in such a way that as a requester you'd have to > explicitly opt out of of having open acls. > > I don't have suggested phrasing in mind just yet, but I wondered if > folks were open to the change. One could prefil the template with "yes", then one has to remove it or change it to "no" to opt 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 tmz at pobox.com Tue Dec 4 21:59:07 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 4 Dec 2007 16:59:07 -0500 Subject: mock 0.8.9 In-Reply-To: <20071204170633.GB24532@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> <200712041827.34181.ville.skytta@iki.fi> <20071204170633.GB24532@humbolt.us.dell.com> Message-ID: <20071204215906.GB30509@psilocybe.teonanacatl.org> Michael E Brown wrote: > On Tue, Dec 04, 2007 at 06:27:33PM +0200, Ville Skytt? wrote: >> That's nice, but even better IMHO would be something that could be >> used to pass arbitrary options (or at least -D, --define, --with, >> --without and --target) as-is to rpmbuild, for example everything >> after a "--", like More! More!. Damn user demands. (Just kidding, of course Ville. ;) > So, we could probably easily implement --with{,out} using this code > as a base. Okay, here's another set of patches to implement --with{,out} options. I used git-format-patch this time, and probably did it awkwardly. But hopefully not too badly. Just in case (and for non-git users), I'll also attach a single diff that should apply cleanly to mock-0.8.14. Comments and improvements welcome. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Play "wheels on the bus" and get the hell out of my sight. -- Stewie Griffin -------------- next part -------------- From 153cdbd620cffaebddfceb747c66d727270b1313 Mon Sep 17 00:00:00 2001 From: Todd Zullinger Date: Mon, 3 Dec 2007 20:58:03 -0500 Subject: [PATCH] add --define option to pass rpm macros on the command line --- docs/mock.1 | 5 +++++ py/mock.py | 14 ++++++++++++++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/docs/mock.1 b/docs/mock.1 index 3adc047..ca212b5 100644 --- a/docs/mock.1 +++ b/docs/mock.1 @@ -56,6 +56,11 @@ Dont clean chroot after building. If automatic cleanup is enabled, use this to d \fB\-\-arch=\fR\fIARCH\fP Specify target build arch. .TP +\fB\-\-define=\fR"\fINAME VALUE\fP" +Specify macro definitions used for the build. This option may be used multiple times, just as the rpmbuild \-\-define option can be. For example: + +\fB\-\-define="vendor Not Fedora" \-\-define="packager Some guy"\fR +.TP \fB\-\-resultdir=\fR\fIRESULTDIR\fP Change directory where resulting files (RPMs and build logs) are written. Resultdir can contain python-string substitutions for any variable in the chroot config. For example: diff --git a/py/mock.py b/py/mock.py index bb5df8c..490c77e 100755 --- a/py/mock.py +++ b/py/mock.py @@ -104,6 +104,9 @@ def command_parse(config_opts): " cleanup is enabled, use this to disable.", ) parser.add_option("--arch", action ="store", dest="arch", default=None, help="target build arch") + parser.add_option("--define", action="append", dest="rpmmacros", + default=[], type="string", metavar="'NAME VALUE'", + help="define an rpm macro (may be used more than once)") parser.add_option("--resultdir", action="store", type="string", default=None, help="path for resulting files to be put") parser.add_option("--uniqueext", action="store", type="string", @@ -222,6 +225,17 @@ def set_config_opts_per_cmdline(config_opts, options): if not options.clean: config_opts['clean'] = options.clean + for macro in options.rpmmacros: + try: + k, v = macro.split(" ", 1) + if not k.startswith('%'): + k = '%%%s' % k + config_opts['macros'].update({k: v}) + except: + raise mock.exception.BadCmdline( + "Bad option for '--define' (%s). Use --define 'name value'" + % macro) + if options.resultdir: config_opts['resultdir'] = os.path.expanduser(options.resultdir) if options.uniqueext: -- 1.5.3.6 -------------- next part -------------- From 875080a4ea11b7e46c9aa8a378d490d7156ca8c9 Mon Sep 17 00:00:00 2001 From: Todd Zullinger Date: Tue, 4 Dec 2007 05:28:13 -0500 Subject: [PATCH] use 'MACRO EXPR' in --define docs to match the rpmbuild docs --- docs/mock.1 | 4 ++-- py/mock.py | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/mock.1 b/docs/mock.1 index ca212b5..17b5081 100644 --- a/docs/mock.1 +++ b/docs/mock.1 @@ -56,10 +56,10 @@ Dont clean chroot after building. If automatic cleanup is enabled, use this to d \fB\-\-arch=\fR\fIARCH\fP Specify target build arch. .TP -\fB\-\-define=\fR"\fINAME VALUE\fP" +\fB\-\-define=\fR"\fIMACRO EXPR\fP" Specify macro definitions used for the build. This option may be used multiple times, just as the rpmbuild \-\-define option can be. For example: -\fB\-\-define="vendor Not Fedora" \-\-define="packager Some guy"\fR +\fB\-\-define="with_extra_cheese 1" \-\-define="packager Monkey"\fR .TP \fB\-\-resultdir=\fR\fIRESULTDIR\fP Change directory where resulting files (RPMs and build logs) are written. Resultdir can contain python-string substitutions for any variable in the chroot config. For example: diff --git a/py/mock.py b/py/mock.py index 490c77e..b78d37a 100755 --- a/py/mock.py +++ b/py/mock.py @@ -105,7 +105,7 @@ def command_parse(config_opts): parser.add_option("--arch", action ="store", dest="arch", default=None, help="target build arch") parser.add_option("--define", action="append", dest="rpmmacros", - default=[], type="string", metavar="'NAME VALUE'", + default=[], type="string", metavar="'MACRO EXPR'", help="define an rpm macro (may be used more than once)") parser.add_option("--resultdir", action="store", type="string", default=None, help="path for resulting files to be put") @@ -233,7 +233,7 @@ def set_config_opts_per_cmdline(config_opts, options): config_opts['macros'].update({k: v}) except: raise mock.exception.BadCmdline( - "Bad option for '--define' (%s). Use --define 'name value'" + "Bad option for '--define' (%s). Use --define 'macro expr'" % macro) if options.resultdir: -- 1.5.3.6 -------------- next part -------------- From 6157b70e994c9325c96d47f55b52607003466c3b Mon Sep 17 00:00:00 2001 From: Todd Zullinger Date: Tue, 4 Dec 2007 15:38:24 -0500 Subject: [PATCH] add --with and --without options to enable/disable options in a srpm --- docs/mock.1 | 12 +++++++++++- py/mock.py | 12 ++++++++++++ 2 files changed, 23 insertions(+), 1 deletions(-) diff --git a/docs/mock.1 b/docs/mock.1 index 17b5081..28c2629 100644 --- a/docs/mock.1 +++ b/docs/mock.1 @@ -59,7 +59,17 @@ Specify target build arch. \fB\-\-define=\fR"\fIMACRO EXPR\fP" Specify macro definitions used for the build. This option may be used multiple times, just as the rpmbuild \-\-define option can be. For example: -\fB\-\-define="with_extra_cheese 1" \-\-define="packager Monkey"\fR +\fB\-\-define "with_extra_cheese 1" \-\-define="packager Monkey"\fR +.TP +\fB\-\-with=\fR\fIOPTION\fP +Enable configure OPTION for build. This option may be used multiple times. For example: + +\fB\-\-with extra_cheese\fR +.TP +\fB\-\-without=\fR\fIOPTION\fP +Disable configure OPTION for build. This option may be used multiple times. For example: + +\fB\-\-without anchovies\fR .TP \fB\-\-resultdir=\fR\fIRESULTDIR\fP Change directory where resulting files (RPMs and build logs) are written. Resultdir can contain python-string substitutions for any variable in the chroot config. For example: diff --git a/py/mock.py b/py/mock.py index b78d37a..a4cefa7 100755 --- a/py/mock.py +++ b/py/mock.py @@ -107,6 +107,12 @@ def command_parse(config_opts): parser.add_option("--define", action="append", dest="rpmmacros", default=[], type="string", metavar="'MACRO EXPR'", help="define an rpm macro (may be used more than once)") + parser.add_option("--with", action="append", dest="rpmwith", + default=[], type="string", metavar="option", + help="enable configure option for build (may be used more than once)") + parser.add_option("--without", action="append", dest="rpmwithout", + default=[], type="string", metavar="option", + help="disable configure option for build (may be used more than once)") parser.add_option("--resultdir", action="store", type="string", default=None, help="path for resulting files to be put") parser.add_option("--uniqueext", action="store", type="string", @@ -225,6 +231,12 @@ def set_config_opts_per_cmdline(config_opts, options): if not options.clean: config_opts['clean'] = options.clean + for option in options.rpmwith: + options.rpmmacros.append("_with_%s 1" % option) + + for option in options.rpmwithout: + options.rpmmacros.append("_with_%s 0" % option) + for macro in options.rpmmacros: try: k, v = macro.split(" ", 1) -- 1.5.3.6 -------------- next part -------------- diff --git a/docs/mock.1 b/docs/mock.1 index 3adc047..28c2629 100644 --- a/docs/mock.1 +++ b/docs/mock.1 @@ -56,6 +56,21 @@ Dont clean chroot after building. If automatic cleanup is enabled, use this to d \fB\-\-arch=\fR\fIARCH\fP Specify target build arch. .TP +\fB\-\-define=\fR"\fIMACRO EXPR\fP" +Specify macro definitions used for the build. This option may be used multiple times, just as the rpmbuild \-\-define option can be. For example: + +\fB\-\-define "with_extra_cheese 1" \-\-define="packager Monkey"\fR +.TP +\fB\-\-with=\fR\fIOPTION\fP +Enable configure OPTION for build. This option may be used multiple times. For example: + +\fB\-\-with extra_cheese\fR +.TP +\fB\-\-without=\fR\fIOPTION\fP +Disable configure OPTION for build. This option may be used multiple times. For example: + +\fB\-\-without anchovies\fR +.TP \fB\-\-resultdir=\fR\fIRESULTDIR\fP Change directory where resulting files (RPMs and build logs) are written. Resultdir can contain python-string substitutions for any variable in the chroot config. For example: diff --git a/py/mock.py b/py/mock.py index cb558e0..0fbb1fc 100755 --- a/py/mock.py +++ b/py/mock.py @@ -103,6 +103,15 @@ def command_parse(config_opts): " cleanup is enabled, use this to disable.", ) parser.add_option("--arch", action ="store", dest="arch", default=None, help="target build arch") + parser.add_option("--define", action="append", dest="rpmmacros", + default=[], type="string", metavar="'MACRO EXPR'", + help="define an rpm macro (may be used more than once)") + parser.add_option("--with", action="append", dest="rpmwith", + default=[], type="string", metavar="option", + help="enable configure option for build (may be used more than once)") + parser.add_option("--without", action="append", dest="rpmwithout", + default=[], type="string", metavar="option", + help="disable configure option for build (may be used more than once)") parser.add_option("--resultdir", action="store", type="string", default=None, help="path for resulting files to be put") parser.add_option("--uniqueext", action="store", type="string", @@ -221,6 +230,23 @@ def set_config_opts_per_cmdline(config_opts, options): if not options.clean: config_opts['clean'] = options.clean + for option in options.rpmwith: + options.rpmmacros.append("_with_%s 1" % option) + + for option in options.rpmwithout: + options.rpmmacros.append("_with_%s 0" % option) + + for macro in options.rpmmacros: + try: + k, v = macro.split(" ", 1) + if not k.startswith('%'): + k = '%%%s' % k + config_opts['macros'].update({k: v}) + except: + raise mock.exception.BadCmdline( + "Bad option for '--define' (%s). Use --define 'macro expr'" + % macro) + if options.resultdir: config_opts['resultdir'] = os.path.expanduser(options.resultdir) if options.uniqueext: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From s.adam at diffingo.com Tue Dec 4 22:00:12 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Tue, 04 Dec 2007 17:00:12 -0500 Subject: fedora-packager In-Reply-To: <200712041030.17904.dennis@ausil.us> References: <200712041030.17904.dennis@ausil.us> Message-ID: <1196805612.22517.6.camel@Diffingo.localdomain> On Tue, 2007-12-04 at 10:30 -0600, Dennis Gilmore wrote: > Do you have a script that you find really useful to help you maintain your > packages? want to share them? then please help make fedora-packager better. Does this apply to scripts that help maintainers review new packages, too? I have a small script that checks the sha1sum of a tarball packaged in a SRPM, then downloads the upstream tarball and compares it's sum to that of the one packaged in the SRPM. Stewart From kevin at scrye.com Tue Dec 4 22:06:06 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 4 Dec 2007 15:06:06 -0700 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071204163625.6cda6f82@redhat.com> References: <20071204163625.6cda6f82@redhat.com> Message-ID: <20071204150606.0c534ccb@ghistelwchlohm.scrye.com> On Tue, 4 Dec 2007 16:36:25 -0500 jkeating at redhat.com (Jesse Keating) wrote: > Currently our cvsadmin request template looks like: > > New Package CVS Request > ======================= > Package Name: > Short Description: > Owners: > Branches: > InitialCC: > Cvsextras Commits: > > To me this looks like you have to opt /in/ to Cvsextras Commits, and > I'm not sure what will happen if you don't fill in a value. > > Could we word it in such a way that as a requester you'd have to > explicitly opt out of of having open acls. > > I don't have suggested phrasing in mind just yet, but I wondered if > folks were open to the change. I think thats a fine idea, perhaps it could be something like: New Package CVS Request ================= Required Fields: Package Name: Short Description: Owners: Optional Fields: Branches: (defaults to devel only) InitialCC: (defaults to none, NOTE that owners are automatically cc'ed or assigned bugs, there is never a need to add owners to this field) Cvsextras Commits: (defaults to yes). Further note that all usernames must be in Fedora Account System names, not email address. kevin -------------- 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 Tue Dec 4 22:10:31 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 4 Dec 2007 17:10:31 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071204163625.6cda6f82@redhat.com> References: <20071204163625.6cda6f82@redhat.com> Message-ID: <20071204221031.GC30509@psilocybe.teonanacatl.org> Jesse Keating wrote: > To me this looks like you have to opt /in/ to Cvsextras Commits, and > I'm not sure what will happen if you don't fill in a value. > > Could we word it in such a way that as a requester you'd have to > explicitly opt out of of having open acls. > > I don't have suggested phrasing in mind just yet, but I wondered if > folks were open to the change. I think open by default is reasonable. For those packages that want tighter control perhaps "Private Commits" would be good wording. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rowe's Rule: The odds are five to six that the light at the end of the tunnel is the headlight of an oncoming train. -- Paul Dickson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From markg85 at gmail.com Tue Dec 4 23:40:26 2007 From: markg85 at gmail.com (Mark) Date: Wed, 5 Dec 2007 00:40:26 +0100 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <1196775327.24449.20.camel@averatec> References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> <1196551547.9577.21.camel@localhost> <20071202135814.GA9706@asus.config> <1196775327.24449.20.camel@averatec> Message-ID: <6e24a8e80712041540s3d7cbfd4h21b3477a2ee5d452@mail.gmail.com> > 63.3 MiB + 14.7 MiB = 78.0 MiB epiphany > 83.0 MiB + 16.6 MiB = 99.5 MiB evolution > > > If that doesn't help e-mail me offline because I would love to work with > you to find the difference between my setup and yours. I can imagine the epiphany memory usage IF you have a lot of tabs open.. but evolution..?? what where you doing there? From Michael_E_Brown at dell.com Tue Dec 4 23:41:56 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 4 Dec 2007 17:41:56 -0600 Subject: mock 0.8.9 In-Reply-To: <20071204215906.GB30509@psilocybe.teonanacatl.org> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> <200712041827.34181.ville.skytta@iki.fi> <20071204170633.GB24532@humbolt.us.dell.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> Message-ID: <20071204234155.GC31195@humbolt.us.dell.com> On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > Okay, here's another set of patches to implement --with{,out} options. > I used git-format-patch this time, and probably did it awkwardly. But > hopefully not too badly. Just in case (and for non-git users), I'll > also attach a single diff that should apply cleanly to mock-0.8.14. > > Comments and improvements welcome. :) This looks great to me. I've committed this to the repo. -- Michael From jon.nettleton at gmail.com Tue Dec 4 23:59:57 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Tue, 04 Dec 2007 18:59:57 -0500 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <6e24a8e80712041540s3d7cbfd4h21b3477a2ee5d452@mail.gmail.com> References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> <1196551547.9577.21.camel@localhost> <20071202135814.GA9706@asus.config> <1196775327.24449.20.camel@averatec> <6e24a8e80712041540s3d7cbfd4h21b3477a2ee5d452@mail.gmail.com> Message-ID: <1196812797.13721.27.camel@birkoff.charles.net> On Wed, 2007-12-05 at 00:40 +0100, Mark wrote: > > 63.3 MiB + 14.7 MiB = 78.0 MiB epiphany > > 83.0 MiB + 16.6 MiB = 99.5 MiB evolution > > > > > > If that doesn't help e-mail me offline because I would love to work with > > you to find the difference between my setup and yours. > > I can imagine the epiphany memory usage IF you have a lot of tabs > open.. but evolution..?? what where you doing there? > Evolution has some issues. But it manages my life, so I cut it some slack. On my desktop right now it is using about half of that. I should run valgrind against it but just haven't had the time. Jon From wolfy at nobugconsulting.ro Wed Dec 5 00:17:50 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 05 Dec 2007 02:17:50 +0200 Subject: fedora-packager In-Reply-To: <1196805612.22517.6.camel@Diffingo.localdomain> References: <200712041030.17904.dennis@ausil.us> <1196805612.22517.6.camel@Diffingo.localdomain> Message-ID: <4755EE2E.9090705@nobugconsulting.ro> On 12/05/2007 12:00 AM, Stewart Adam wrote: > On Tue, 2007-12-04 at 10:30 -0600, Dennis Gilmore wrote: > >> Do you have a script that you find really useful to help you maintain your >> packages? want to share them? then please help make fedora-packager better. >> > Does this apply to scripts that help maintainers review new packages, too? > I have a small script that checks the sha1sum of a tarball packaged in a > SRPM, then downloads the upstream tarball and compares it's sum to that of > the one packaged in the SRPM. this check is included in Aurelien Bompard's fedora-qa script (it's in the wiki on his page), a script which I find extremely useful . I am using a slightly patched version (3-4 lines ...) which computes sha1sum instead of md5sum and prints the value if the 2 tarballs are identical. From lordmorgul at gmail.com Wed Dec 5 00:32:37 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 04 Dec 2007 16:32:37 -0800 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <1196812797.13721.27.camel@birkoff.charles.net> References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com> <1196551547.9577.21.camel@localhost> <20071202135814.GA9706@asus.config> <1196775327.24449.20.camel@averatec> <6e24a8e80712041540s3d7cbfd4h21b3477a2ee5d452@mail.gmail.com> <1196812797.13721.27.camel@birkoff.charles.net> Message-ID: <4755F1A5.7040900@gmail.com> Jon Nettleton wrote: > Evolution has some issues. But it manages my life, so I cut it some > slack. On my desktop right now it is using about half of that. I > should run valgrind against it but just haven't had the time. It has had memory leak issues forever, especially with libgtkhtml and when editing new emails... I understand you may need it, but wouldn't talk seriously about any memory issues while using it; this is a foregone conclusion. See http://bugzilla.gnome.org/show_bug.cgi?id=257930 for example. -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From promac at gmail.com Wed Dec 5 01:32:35 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 4 Dec 2007 23:32:35 -0200 Subject: mock 0.8.9 In-Reply-To: <20071204234155.GC31195@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071203220840.GB14186@humbolt.us.dell.com> <20071204103753.GA3755@psilocybe.teonanacatl.org> <200712041827.34181.ville.skytta@iki.fi> <20071204170633.GB24532@humbolt.us.dell.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> Message-ID: <68720af30712041732w4d8dcd7bgfc288ee08b290aae@mail.gmail.com> On Dec 4, 2007 9:41 PM, Michael E Brown wrote: > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > Okay, here's another set of patches to implement --with{,out} options. > > I used git-format-patch this time, and probably did it awkwardly. But > > hopefully not too badly. Just in case (and for non-git users), I'll > > also attach a single diff that should apply cleanly to mock-0.8.14. > > > > Comments and improvements welcome. :) > > This looks great to me. I've committed this to the repo. > It is working for me. I tried --with and --without. This will make my buildings a lot easier. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmus at tmus.dk Wed Dec 5 01:45:24 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 04 Dec 2007 22:45:24 -0300 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071204132031.GA3250@traged.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> Message-ID: <475602B4.9020109@tmus.dk> Adam Tkac wrote: > > I'm not sure what you mean. NM has to write something into > /etc/resolv.conf, right? This decision has to be done on NM side and > number of active devices (or connections) has nothing related to that. > And this information is exactly what named needs (nameserver statement > from resolv.conf). Nothing more (except some notifies when resolv.conf > is changed). > Don't we still have the problem with glibc not supporting updates to resolv.conf and isn't that exactly the reason we need a slim forwarding/caching nameserver locally? Especially for mobile devices, it can get tedious to have to restart the browser after you move to a different network and things like that. /Thomas > Adam > From lordmorgul at gmail.com Wed Dec 5 01:57:41 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 04 Dec 2007 17:57:41 -0800 Subject: firefox vs epiphany In-Reply-To: <47558758.7010704@redhat.com> References: <1196625336.2547.4.camel@tiger> <47541DBB.1070402@redhat.com> <47558758.7010704@redhat.com> Message-ID: <47560595.4020707@gmail.com> Zack Cerza wrote: > rant adjustment: "about brokenness of IE which forces standards-noncompliance of sites to function as desired so that correctly standards-compliant sites have to check for standards compliant browsers" -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From tmz at pobox.com Wed Dec 5 03:08:16 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 4 Dec 2007 22:08:16 -0500 Subject: rpms/gonvert/devel gonvert.spec,1.13,1.14 In-Reply-To: <200712050219.lB52J6GL032378@cvs-int.fedora.redhat.com> References: <200712050219.lB52J6GL032378@cvs-int.fedora.redhat.com> Message-ID: <20071205030816.GD30509@psilocybe.teonanacatl.org> Hi Jon, Jon Ciesla wrote: > Name: gonvert > Version: 0.2.19 > -Release: 1%{?dist} > +Release: 2%{?dist} > Summary: Units conversion utility > Group: Applications/Engineering > -License: GPL+ > +License: GPLv2 Jon, did you get some clarification from upstream on the license? Lacking that, I believe GPL+ is correct. The source (the single python script) doesn't define any particular version, which means that any version of the GPL is allowed, in accordance with Section 9 of the included COPYING file: "... If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is insufficient to protect ourselves with laws; we need to protect ourselves with mathematics. -- Bruce Schneier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From limb at jcomserv.net Wed Dec 5 03:18:30 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 4 Dec 2007 21:18:30 -0600 (CST) Subject: rpms/gonvert/devel gonvert.spec,1.13,1.14 Message-ID: <33918.192.168.0.1.1196824710.squirrel@mail.jcomserv.net> > Hi Jon, > > Jon Ciesla wrote: >> Name: gonvert >> Version: 0.2.19 >> -Release: 1%{?dist} >> +Release: 2%{?dist} >> Summary: Units conversion utility >> Group: Applications/Engineering >> -License: GPL+ >> +License: GPLv2 > > Jon, did you get some clarification from upstream on the license? > Lacking that, I believe GPL+ is correct. > > The source (the single python script) doesn't define any particular > version, which means that any version of the GPL is allowed, in > accordance with Section 9 of the included COPYING file: > > "... If the Program does not specify a version number of this License, > you may choose any version ever published by the Free Software > Foundation." That'll teach me not to RTFL. Thanks. I'll change it back. > -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > It is insufficient to protect ourselves with laws; we need to protect > ourselves with mathematics. > -- Bruce Schneier > > -- novus ordo absurdum From jcm at redhat.com Wed Dec 5 04:50:50 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 04 Dec 2007 23:50:50 -0500 Subject: Smolt database is broken In-Reply-To: <20071120210417.GA29466@devserv.devel.redhat.com> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> Message-ID: <1196830250.20291.14.camel@perihelion> On Tue, 2007-11-20 at 16:04 -0500, Alan Cox wrote: > On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath wrote: > > Here's the top 5: > > > > 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132 > > 336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a > > 402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f > > 884 06e84493-e024-44b1-9b32-32d78af04039 > > 931 e2b67e1d-e325-4740-b938-795addb45280 > > > > > > The left number is times this month someone has submitted a profile with > > that UUID. If we take the last one as an example has come from over 800 > > IP's in the last 20 days. It seems very unlikely that one person would > > find his way to 800 different IP's this month. Let me know if you'd > > like more. > > We shouldn't have any duplicates if its properly random. I don't know how > relevant the actual values are myself because random numbers is "hard maths" > and I'm not a mathematician. I've raised it however but since its turkey > genoiciding season in the USA it might be a bit slow (I'm a pescetarian FWIW, and didn't butcher any Turkeys) Was there any outcome on this in the end? My initial guesses include that there's some hardware device common to some of these reports that is inappropriately registering as a source of random entropy, and then generating very predictable data. That would be a somewhat serious kernel bug that I want to check for. Any news? Alan - whatcha wanna do? Jon. From andreas.bierfert at lowlatency.de Wed Dec 5 05:49:02 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 5 Dec 2007 06:49:02 +0100 Subject: Broken BuildRequires in rawhide In-Reply-To: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> References: <20071203165755.47fb769f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071205064902.03f759cb@alkaid.a.lan> On Mon, 3 Dec 2007 16:57:55 +0100 Michael Schwendt wrote: > These are broken BuildRequires in the rawhide src.rpms: > > package: orange - 0.3-5.cvs20051118.fc8.src from fedora-development-source > unresolved deps: > synce-devel > > package: synce-software-manager - 0.9.0-7.fc6.src from > fedora-development-source unresolved deps: > synce-devel > > package: synce-trayicon - 0.9.0-8.fc6.src from fedora-development-source > unresolved deps: > synce-devel > Fixed. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- 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 Wed Dec 5 06:19:43 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 5 Dec 2007 01:19:43 -0500 Subject: BuildRootOverrides request: devhelp (for vala-0.1.5) In-Reply-To: <4755750C.7050404@redhat.com> References: <20071204065813.2b0fc1cb@redhat.com> <4755750C.7050404@redhat.com> Message-ID: On 04/12/2007, Christopher Aillon wrote: > > On 12/04/2007 04:34 PM, Michel Salim wrote: > > On 04/12/2007, Jesse Keating wrote: > >> On Tue, 4 Dec 2007 01:16:12 -0500 > >> "Michel Salim" wrote: > >> > >>> Could a CVS admin make devhelp available as a BuildRootOverrides? > >>> > >>> https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3962 > >>> > >>> Vala has a soft BR on devhelp -- the documentation files don't get > >>> installed if devhelp is not detected at configure time, and everytime > >>> there is a Firefox update, devhelp lags behind by days, so it will be > >>> nice to have it permanently whitelisted. > >> > >> There isn't a method to make a "permanent" whitelist. Why does your > >> app have to be built against a very specific version of devhelp? > >> > > It does not have to. The problem is that the (rather frequent) Firefox > > security fixes, and that devhelp is not whitelisted, means that at any > > moment in time, it is quite probable that the newer version of Firefox > > is already available in Koji, but the matching version of devhelp is > > not. > > > Actually, the problem existed because of the override from last time. > If the override did not exist, you would be able to build against the > correct version. (Try again now.) Yes, that works, thanks. So the override is not cleared automatically when the package enters the repository? -- Michel Salim http://hircus.jaiku.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From debarshi.ray at gmail.com Wed Dec 5 06:25:39 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 5 Dec 2007 11:55:39 +0530 Subject: Orphaning packages In-Reply-To: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> Message-ID: <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> > Is there someone In rel-eng or cvsadmin or thereabouts that should assist > with this, if Paul hasn't the time? I feel bad making more demands on his > time in order to help him lessen the demands on his time. :) How about doing the same for anjuta [1] and anjuta-gdl [2]? They don't look like Mono packages, which Paul wants to keep, and I would like to take them. Cheers, Debarshi [1] https://admin.fedoraproject.org/pkgdb/packages/name/anjuta [2] https://admin.fedoraproject.org/pkgdb/packages/name/anjuta-gdl -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tjanouse at redhat.com Wed Dec 5 08:42:24 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Wed, 5 Dec 2007 09:42:24 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <475602B4.9020109@tmus.dk> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> Message-ID: <20071205084224.GA8316@redhat.com> On Tue, Dec 04, 2007 at 10:45:24PM -0300, Thomas M Steenholdt wrote: > Don't we still have the problem with glibc not supporting updates to > resolv.conf and isn't that exactly the reason we need a slim > forwarding/caching nameserver locally? Especially for mobile devices, it can > get tedious to have to restart the browser after you move to a different > network and things like that. Yes. -- TJ. (Brno, CZ), BaseOS, Red Hat From fedora at camperquake.de Wed Dec 5 08:58:17 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 5 Dec 2007 09:58:17 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <475602B4.9020109@tmus.dk> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> Message-ID: <20071205095817.46be4d87@dhcp03.addix.net> Hi. On Tue, 04 Dec 2007 22:45:24 -0300, Thomas M Steenholdt wrote: > Don't we still have the problem with glibc not supporting updates to > resolv.conf and isn't that exactly the reason we need a slim > forwarding/caching nameserver locally? Especially for mobile devices, > it can get tedious to have to restart the browser after you move to a > different network and things like that. Err... at least on my system I can add new nameservers to resolv.conf, and (runnning) firefox instances pick up that change (may take some seconds, but they do it). From paul at all-the-johnsons.co.uk Wed Dec 5 10:45:35 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 5 Dec 2007 10:45:35 +0000 Subject: Orphaning packages In-Reply-To: <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> Message-ID: <20071205104535.M45869@all-the-johnsons.co.uk> Hi, > > Is there someone In rel-eng or cvsadmin or thereabouts that should assist > > with this, if Paul hasn't the time? I feel bad making more demands on his > > time in order to help him lessen the demands on his time. :) > > How about doing the same for anjuta [1] and anjuta-gdl [2]? They > don't look like Mono packages, which Paul wants to keep, and I would > like to take them. Feel free to take them. Currently, my main box is down (it has a silly fault on it which won't clear - it hangs after 45 minutes and I can't see anything in dmesg saying it's a software problem, so I'm assuming hardware), but as soon as it's up, I'll rebuild my mono stuff and get it into rawhide. TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From ml at deadbabylon.de Wed Dec 5 10:47:15 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 5 Dec 2007 11:47:15 +0100 Subject: KDE-SIG weekly report (49/2007) Message-ID: <200712051147.22273.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 49/2007 Time: 2007-12-04 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-04 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-04?action=AttachFile&do=get&target=fedora-kde-sig-2007-12-04.txt ---------------------------------------------------------------------------------- = Participants = KevinKofler LaithJuwaidah MaryEllenFoster RexDieter SebastianVahl ---------------------------------------------------------------------------------- = Agenda = * Progress of the inclusion of KDE4 into rawhide * recent bugs = Summary = o kde4 in rawhide, progress: * packages: * the main package of kde4, kdebase-workspace, is already in rawhide * extragear-plasma was submitted for review (#409401) [1] * kdemultimedia(4) contains only some few ported apps. We'll maybe have to ship a compat-kdemultimedia(3) package and/or include some packages from extragear (kmid, kaudciocreator) * also taxipilot requires kdemultimedia3 (which maybe could be fixed) * kdewebdev has to be shipped in kde3 version (quanta isn't ported to kde4) * kopete also has to be shipped in kde3 version (until it works in kde4) * next packages to import: * kdeaccessibility, kdeartwork (RexDieter) * kdegraphics, kdesdk (KevinKofler) * RexDieter has made some changes to comps-f9.xml * ThanNgo has been working to fixup kdm issues * kde-settings should be hostet at hosted.fedoraproject.org * SebastianVahl has started work on the livecd o recent bugs: * #410651 New flash plugin not working for konqueror: known as upstream bug [2] ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-11 ---------------------------------------------------------------------------------- = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=409401 [2] https://bugzilla.redhat.com/show_bug.cgi?id=410651 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From dwmw2 at infradead.org Wed Dec 5 12:02:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Dec 2007 12:02:46 +0000 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071204221031.GC30509@psilocybe.teonanacatl.org> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> Message-ID: <1196856166.13978.468.camel@pmac.infradead.org> On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote: > I think open by default is reasonable. I agree. > For those packages that want tighter control perhaps "Private > Commits" would be good wording. It would be nice if you also needed to give a _good_ reason for making it private. Perhaps even a reason which is approved by FESCo in advance. -- dwmw2 From alan at redhat.com Wed Dec 5 12:05:54 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Dec 2007 07:05:54 -0500 Subject: Smolt database is broken In-Reply-To: <1196830250.20291.14.camel@perihelion> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> <1196830250.20291.14.camel@perihelion> Message-ID: <20071205120554.GA18458@devserv.devel.redhat.com> On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote: > > and I'm not a mathematician. I've raised it however but since its turkey > > genoiciding season in the USA it might be a bit slow > > (I'm a pescetarian FWIW, and didn't butcher any Turkeys) Sounds fishy to me. > Was there any outcome on this in the end? Just been resurrected on l/k From nicolas.mailhot at laposte.net Wed Dec 5 12:20:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Dec 2007 13:20:34 +0100 (CET) Subject: Extreme memory usage for gnome-panel related apps Message-ID: <25398.192.54.193.53.1196857234.squirrel@rousalka.dyndns.org> Le Mer 5 d?cembre 2007 00:40, Mark a ?crit : >> 63.3 MiB + 14.7 MiB = 78.0 MiB epiphany >> 83.0 MiB + 16.6 MiB = 99.5 MiB evolution >> >> >> If that doesn't help e-mail me offline because I would love to work >> with >> you to find the difference between my setup and yours. > > I can imagine the epiphany memory usage IF you have a lot of tabs > open.. but evolution..?? what where you doing there? Do you mean you're one of the lucky bastards that never saw evo happily gurgle Gigs of memory? -- Nicolas Mailhot From fedora at leemhuis.info Wed Dec 5 12:25:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Dec 2007 13:25:00 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <1196856166.13978.468.camel@pmac.infradead.org> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> Message-ID: <4756989C.5040605@leemhuis.info> On 05.12.2007 13:02, David Woodhouse wrote: > On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote: >> I think open by default is reasonable. > I agree. I disagree for packages that have at least one co-maintainer. >> For those packages that want tighter control perhaps "Private >> Commits" would be good wording. > It would be nice if you also needed to give a _good_ reason for making > it private. Perhaps even a reason which is approved by FESCo in advance. "I fear that a just sponsored contributer puts something bad in one of my packages" and "the CTRL+C trick in CVS still works, thus I as maintainer might not even get a mail if someone changes my package(?)" are the reasons why I excluded cvsextras for those of my packages that have co-maintainers. OTOH I think we IMHO should have a group in FAS called something like "experienced maintainers" with sponsors and long term contributers that gets access everywhere; I trust those way more then a just-sponsored contributer that came out of the blue. CU knurd (?) -- not to mention that we are all AFK now and then for a few days From mschwendt.tmp0701.nospam at arcor.de Wed Dec 5 12:51:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Dec 2007 13:51:44 +0100 Subject: TeXLive is in rawhide In-Reply-To: <200712042247.30039.opensource@till.name> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712042133.41220.opensource@till.name> <20071204222335.6b872972.mschwendt.tmp0701.nospam@arcor.de> <200712042247.30039.opensource@till.name> Message-ID: <20071205135144.88357db5.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Dec 2007 22:47:12 +0100, Till Maas wrote: > On Di Dezember 4 2007, Michael Schwendt wrote: > > > If no specific release is asked for, it is not necessary anymore to > > compare a package's %release value. Just as in > > > > Requires: foo = 3.0 > > > > where your counter-example from below cannot be applied either, since > > the "equal than" comparison works differently. Any release will match, > > but you cannot "rpmdev-vercmp 3.0-1 3.0" to prove it. > > Is > > Requires: foo > 3.0 > > satisfied with foo-3.0-1 or only with every version of foo that is higher than > 3.0, e.g. foo-3.1-1? It means that %version must be higher than "3.0". %release does not matter, because it is not specified in the Requires. 3.1-1 is not a version, it is a version-release tuple, and 3.1 > 3.0 already. From markg85 at gmail.com Wed Dec 5 12:53:56 2007 From: markg85 at gmail.com (Mark) Date: Wed, 5 Dec 2007 13:53:56 +0100 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <25398.192.54.193.53.1196857234.squirrel@rousalka.dyndns.org> References: <25398.192.54.193.53.1196857234.squirrel@rousalka.dyndns.org> Message-ID: <6e24a8e80712050453v144bee97n33e660d1049eb9ea@mail.gmail.com> > Do you mean you're one of the lucky bastards that never saw evo > happily gurgle Gigs of memory? more like i've never used it ^_^ i did use Thunderbird but don't know what it's memory usage was. From lkundrak at redhat.com Wed Dec 5 12:59:16 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 05 Dec 2007 13:59:16 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756989C.5040605@leemhuis.info> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> Message-ID: <1196859556.15639.133.camel@localhost.localdomain> Hi, On Wed, 2007-12-05 at 13:25 +0100, Thorsten Leemhuis wrote: > On 05.12.2007 13:02, David Woodhouse wrote: > > On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote: > >> I think open by default is reasonable. > > I agree. > > I disagree for packages that have at least one co-maintainer. Definitely makes some sense. Packages that have a more maintainer are more likely to deserve all the love they deserve compared to ones who get to Fedora from Core and have a single maintainer with cvsextras off by default (I've seen a maintainer of ex-Core package that was not even aware that noone else but him can commit). > >> For those packages that want tighter control perhaps "Private > >> Commits" would be good wording. > > It would be nice if you also needed to give a _good_ reason for making > > it private. Perhaps even a reason which is approved by FESCo in advance. > > "I fear that a just sponsored contributer puts something bad in one of > my packages" and "the CTRL+C trick in CVS still works, thus I as > maintainer might not even get a mail if someone changes my package(?)" > are the reasons why I excluded cvsextras for those of my packages that > have co-maintainers. Why would he put something bad? Being malicious? He can do that in different places also when he has a FAS account, is in cvsextras and can build packages. Being not experienced enough? That's the purpose he has a sponsor for. (btw that CTRL+C thing should get fixed, is there an infra ticket for it?) > OTOH I think we IMHO should have a group in FAS called something like > "experienced maintainers" with sponsors and long term contributers that > gets access everywhere; I trust those way more then a just-sponsored > contributer that came out of the blue. I'd say all sponsored people are "experienced maintainers". Those who are not experienced do post their work in bugzilla. At least I think of sponsorship should serve exactly this purpose, if you believe it is not, then it is unuseful and have to be dealt with somehow. If we solved that by separating the group further, we may end up with something like "extra most super experienced maintainers" groups. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From jkeating at redhat.com Wed Dec 5 12:59:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 07:59:28 -0500 Subject: Undoing ACLs (was Re: Dealing with PPC in Fedora 9(+)) In-Reply-To: <1196856049.13978.466.camel@pmac.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> <1196809101.13978.402.camel@pmac.infradead.org> <1196825378.7206.8.camel@localhost.localdomain> <1196856049.13978.466.camel@pmac.infradead.org> Message-ID: <20071205075928.53421570@redhat.com> On Wed, 05 Dec 2007 12:00:49 +0000 David Woodhouse wrote: > (Although I don't feel wonderfully happy about accepting such rights > for myself alone when I feel strongly that _all_ Fedora contributors > should be able to commit to all packages. It's not as if we can't > revert stuff, and can't promote an attitude of violence towards > people who abuse the privilege, like we already have.) This is actually a topic that has come up a few times. A good number of previously core packages still have default locked down ACLs. This was somewhat mandated by the general populace of core maintainers. However I think that the trial period is over and I hope that the Fedora maintainers at large have proved to be responsible about what they do, so that all maintainers should feel confident in opened packages. I still want there to be an ACL system for when a maintainer strongly feels that his/her package should be kept to a small commit list. However the vast majority would be just fine open, and would promote more of a help you neighbor attitude if ACLs weren't in the way. So I'd like to discuss the idea of having an automated "opening" of all ACLs that a maintainer can opt /out/ of should they choose. Some methodology of tagging each package that should be opened and allowing some time for a maintainer to "untag" the package as it were to opt out of opening it. I'm bouncing this back over to fedora-devel-list as that's where something like this should be brought up. Thoughts? -- 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 Dec 5 13:04:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 08:04:02 -0500 Subject: Orphaning packages In-Reply-To: <20071205104535.M45869@all-the-johnsons.co.uk> References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> <20071205104535.M45869@all-the-johnsons.co.uk> Message-ID: <20071205080402.7b00de21@redhat.com> On Wed, 5 Dec 2007 10:45:35 +0000 "Paul F. Johnson" wrote: > > How about doing the same for anjuta [1] and anjuta-gdl [2]? They > > don't look like Mono packages, which Paul wants to keep, and I > > would like to take them. > > Feel free to take them. > > Currently, my main box is down (it has a silly fault on it which > won't clear - it hangs after 45 minutes and I can't see anything in > dmesg saying it's a software problem, so I'm assuming hardware), but > as soon as it's up, I'll rebuild my mono stuff and get it into > rawhide. I orphaned these in pkgdb. -- 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 bbbush.yuan at gmail.com Wed Dec 5 13:12:30 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Wed, 5 Dec 2007 21:12:30 +0800 Subject: rawhide X applications not responsible, kernel problem? Message-ID: <76e72f800712050512p29109a54i26d4cd50aa1fc94c@mail.gmail.com> Hi, I don't know if others have the same problem, but my mouse and keyboard can lost responsive if they are free for a few minutes. After several seconds, it goes back to normal. It feels like applications are being swapped out and in, but I don't see HDD LED flash at all. The problem is not in kernel-2.6.23.1-49.fc8 but is in kernel-2.6.23.8-63.fc8. Also it is in kernel-2.6.24-0.x but worse than 2.6.23. I guess this is because something changed in the scheduler. My hardware profile is e26cfcbf-a150-4466-a65f-d9c99f5d048e -- bbbush ^_^ From j.w.r.degoede at hhs.nl Wed Dec 5 13:12:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 05 Dec 2007 14:12:41 +0100 Subject: Undoing ACLs (was Re: Dealing with PPC in Fedora 9(+)) In-Reply-To: <20071205075928.53421570@redhat.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> <1196809101.13978.402.camel@pmac.infradead.org> <1196825378.7206.8.camel@localhost.localdomain> <1196856049.13978.466.camel@pmac.infradead.org> <20071205075928.53421570@redhat.com> Message-ID: <4756A3C9.50408@hhs.nl> Jesse Keating wrote: > On Wed, 05 Dec 2007 12:00:49 +0000 > David Woodhouse wrote: > >> (Although I don't feel wonderfully happy about accepting such rights >> for myself alone when I feel strongly that _all_ Fedora contributors >> should be able to commit to all packages. It's not as if we can't >> revert stuff, and can't promote an attitude of violence towards >> people who abuse the privilege, like we already have.) > > This is actually a topic that has come up a few times. A good number > of previously core packages still have default locked down ACLs. This > was somewhat mandated by the general populace of core maintainers. > However I think that the trial period is over and I hope that the > Fedora maintainers at large have proved to be responsible about what > they do, so that all maintainers should feel confident in opened > packages. > > I still want there to be an ACL system for when a maintainer strongly > feels that his/her package should be kept to a small commit list. > However the vast majority would be just fine open, and would promote > more of a help you neighbor attitude if ACLs weren't in the way. > > So I'd like to discuss the idea of having an automated "opening" of all > ACLs that a maintainer can opt /out/ of should they choose. Some > methodology of tagging each package that should be opened and allowing > some time for a maintainer to "untag" the package as it were to opt out > of opening it. > > I'm bouncing this back over to fedora-devel-list as that's where > something like this should be brought up. > > Thoughts? > > + a lott Regards, Hans From fedora at leemhuis.info Wed Dec 5 13:28:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Dec 2007 14:28:02 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <1196859556.15639.133.camel@localhost.localdomain> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> Message-ID: <4756A762.7070107@leemhuis.info> On 05.12.2007 13:59, Lubomir Kundrak wrote: > On Wed, 2007-12-05 at 13:25 +0100, Thorsten Leemhuis wrote: >> On 05.12.2007 13:02, David Woodhouse wrote: >>> On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote: >>>> For those packages that want tighter control perhaps "Private >>>> Commits" would be good wording. >>> It would be nice if you also needed to give a _good_ reason for making >>> it private. Perhaps even a reason which is approved by FESCo in advance. >> "I fear that a just sponsored contributer puts something bad in one of >> my packages" and "the CTRL+C trick in CVS still works, thus I as >> maintainer might not even get a mail if someone changes my package(?)" >> are the reasons why I excluded cvsextras for those of my packages that >> have co-maintainers. > Why would he put something bad? Being malicious? Yes. Sure, for most people the hurdle is likely to high to go that route, but OTOH it a great way to get bad code out to lots of systems quickly (and a way to ruin our fame) > He can do that in > different places also when he has a FAS account, is in cvsextras and can > build packages. Not exactly sure what you mean. His own packages? Sure, that's easy. But as a malicious person I'd would likely take a popular package that more users have installed *if* I have access to it. > Being not experienced enough? [...] We all make errors now and then. IOW: no, I didn't mean that. > (btw that CTRL+C thing should get fixed, is there an > infra ticket for it?) There was one in bugzilla iirc; then there was one in OTRS and someone looked into it, but it didn't get fixed; then infrastructure switched to something else, and there is no current ticket I'm aware off. >> OTOH I think we IMHO should have a group in FAS called something like >> "experienced maintainers" with sponsors and long term contributers that >> gets access everywhere; I trust those way more then a just-sponsored >> contributer that came out of the blue. > I'd say all sponsored people are "experienced maintainers". So someone that just baked his first spec file in his life, got it reviewed, himsel sponsored and the spec file imported is directly "experienced"? /me wonders if we are confusing the terms "sponsored people" and "sponsors" > Those who > are not experienced do post their work in bugzilla. At least I think of > sponsorship should serve exactly this purpose, if you believe it is not, > then it is unuseful and have to be dealt with somehow. If we solved that > by separating the group further, we may end up with something like > "extra most super experienced maintainers" groups. Sure, but OTHO it's black (no access) and white (access everywhere) might be a over simplification. Three or maybe four contributer-levels (access to his own packages, access everywhere, sponsors, admins) IMHO would be better and not that complicated. Cu knurd From atkac at redhat.com Wed Dec 5 13:32:56 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 5 Dec 2007 14:32:56 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> Message-ID: <20071205133256.GA6410@evileye.atkac.englab.brq.redhat.com> On Mon, Dec 03, 2007 at 10:39:03AM +0100, Adam Tkac wrote: > Hi all, > > dhcdbd package has been removed and replaced by > NetworkManager but NM doesn't implement dhcdbd functionality. We > have some patches in Fedora whose makes named capable to get forwarders > from dhcdbd but now they are completely unusable. I'm going to drop > all related patches because they are unusable. I'm interested > how many people used this feature and if I should try develop this again. > If no users exist (or very limited number) I'm going to completely > drop this feature because it doesn't make sence spend time with > something what noone uses. > >From responses whose I got it looks people are interested in this feature but it needs more sophisticated approach than current. Discussion will continue on bind-workers list for a while and I'm going to find best solution with upstream (http://marc.info/?l=bind-workers&m=119686074511951&w=2) Adam -- Adam Tkac, Red Hat, Inc. From mclasen at redhat.com Wed Dec 5 13:45:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 05 Dec 2007 08:45:32 -0500 Subject: Rebuilds for openssl/openldap Message-ID: <1196862332.4396.2.camel@localhost.localdomain> Here is a list of packages which still need to be rebuilt against the new openssl or openldap. (The list is just what is blocking the update on my machine, there may be more in the repository). I would be happy to help out with this, but most of these have ACLs that prevent me from doing so... Matthias apr-util autofs bind-libs bind-utils cups cyrus-sasl cyrus-sasl-md5 fetchmail hpijs hplip htdig httpd httpd-tools inkscape libflashsupport libsane-hpaio mysql-libs nss_ldap ntp opal pam_ccreds postgresql-libs pwlib pyOpenSSL python-ldap qca-tls sendmail subversion sudo tcpdump transmission xchat xorg-x11-server-Xephyr xorg-x11-server-Xnest xorg-x11-server-Xorg From zprikryl at redhat.com Wed Dec 5 13:48:17 2007 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 05 Dec 2007 14:48:17 +0100 Subject: Package alien Message-ID: <4756AC21.30104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I would like to ask you, why was a package "alien" removed from RH distros? Alien is a program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats. (http://kitenet.net/~joey/code/alien/) Thanks - -- Zdenek Prikryl Software Engineer - Base Operating Systems Brno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVqwhGQbtTQ12wjARAidqAJ9iptvPvatGQLqBk2s77CM4JSpvIACfVQJx I/mfpCV8sNkGKtRj3SRENYk= =yK45 -----END PGP SIGNATURE----- From atkac at redhat.com Wed Dec 5 13:57:53 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 5 Dec 2007 14:57:53 +0100 Subject: Rebuilds for openssl/openldap In-Reply-To: <1196862332.4396.2.camel@localhost.localdomain> References: <1196862332.4396.2.camel@localhost.localdomain> Message-ID: <20071205135753.GA7484@evileye.atkac.englab.brq.redhat.com> On Wed, Dec 05, 2007 at 08:45:32AM -0500, Matthias Clasen wrote: > Here is a list of packages which still need to be rebuilt against the > new openssl or openldap. (The list is just what is blocking the update > on my machine, there may be more in the repository). > > I would be happy to help out with this, but most of these have ACLs that > prevent me from doing so... Me too. I think pkgdb will have option "group members can commit?" set to yes by default. Fedora is open so why restrict cvsextras members from commits? Setting that option to yes is annoying if you have many packages. Adam -- Adam Tkac, Red Hat, Inc. From alexl at users.sourceforge.net Wed Dec 5 14:02:30 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 05 Dec 2007 07:02:30 -0700 Subject: Rebuilds for openssl/openldap In-Reply-To: <1196862332.4396.2.camel@localhost.localdomain> (Matthias Clasen's message of "Wed\, 05 Dec 2007 08\:45\:32 -0500") References: <1196862332.4396.2.camel@localhost.localdomain> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> Here is a list of packages which still need to be rebuilt against MC> the new openssl or openldap. (The list is just what is blocking MC> the update on my machine, there may be more in the repository). MC> I would be happy to help out with this, but most of these have MC> ACLs that prevent me from doing so... MC> apr-util autofs bind-libs bind-utils cups cyrus-sasl MC> cyrus-sasl-md5 fetchmail hpijs hplip htdig httpd httpd-tools MC> inkscape libflashsupport libsane-hpaio mysql-libs nss_ldap ntp MC> opal pam_ccreds postgresql-libs pwlib pyOpenSSL python-ldap MC> qca-tls sendmail subversion sudo tcpdump transmission xchat MC> xorg-x11-server-Xephyr xorg-x11-server-Xnest xorg-x11-server-Xorg That's just the tip of iceberg, did you see this e-mail: http://www.redhat.com/archives/fedora-test-list/2007-December/msg00102.html I count *656* packages (which does include subpackages) but either way, is a big number. This rebuild is going to be a huge deal and probably needs to be co-ordinated like a "mass-rebuild" because of BuildRequires ordering problems. Just to give one example: I was trying to rebuild ruby-gnome2, but it didn't work because it depended on cups being rebuilt. Warren Togami on #fedora-devel volunteered to rebuild cups, but cups itself depended on php being rebuilt first, then (I think) php needed to wait on an httpd rebuild, and so on... So we stopped at that point because the deps started getting too deep to be done in an ad-hoc way. To avoid wasting time on rebuilds that will immediately fail, it seems to me that the build should be done in a semi-systematic way (e.g. perhaps concentrating on packages in "Base" comps group, then working up through "Development Libraries" or some such, I don't know). Alex From jcm at redhat.com Wed Dec 5 14:09:31 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 05 Dec 2007 09:09:31 -0500 Subject: Smolt database is broken In-Reply-To: <20071205120554.GA18458@devserv.devel.redhat.com> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> <1196830250.20291.14.camel@perihelion> <20071205120554.GA18458@devserv.devel.redhat.com> Message-ID: <1196863772.25930.42.camel@perihelion> On Wed, 2007-12-05 at 07:05 -0500, Alan Cox wrote: > On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote: > > > and I'm not a mathematician. I've raised it however but since its turkey > > > genoiciding season in the USA it might be a bit slow > > > > (I'm a pescetarian FWIW, and didn't butcher any Turkeys) > > Sounds fishy to me. I fed you a line, knew you'd bite. > > Was there any outcome on this in the end? > > Just been resurrected on l/k Right. That was why I asked - I saw the thread, but it doesn't seem to have gone anywhere yet. I guess the kernel should not be returning UUIDs at all until there's sufficient entropy to do so. I'll ponder it. Jon. From alexl at users.sourceforge.net Wed Dec 5 14:10:13 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 05 Dec 2007 07:10:13 -0700 Subject: Package alien In-Reply-To: <4756AC21.30104@redhat.com> (Zdenek Prikryl's message of "Wed\, 05 Dec 2007 14\:48\:17 +0100") References: <4756AC21.30104@redhat.com> Message-ID: >>>>> "ZP" == Zdenek Prikryl writes: ZP> Hello, I would like to ask you, why was a package "alien" removed ZP> from RH distros? Alien is a program that converts between the ZP> rpm, dpkg, stampede slp, and slackware tgz file ZP> formats. (http://kitenet.net/~joey/code/alien/) I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?), it's not even listed as orphaned in the PackageDB: https://admin.fedoraproject.org/pkgdb/packages/name/alien gives a 404. There's no reason it couldn't be readded, AFAICT, if you wanted to become a contributor to the Fedora package collection: http://fedoraproject.org/wiki/PackageMaintainers/Join Alex From walters at redhat.com Wed Dec 5 14:12:28 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 05 Dec 2007 09:12:28 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205095817.46be4d87@dhcp03.addix.net> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> Message-ID: <1196863948.4124.8.camel@space-ghost.verbum.private> On Wed, 2007-12-05 at 09:58 +0100, Ralf Ertzinger wrote: > Hi. > > On Tue, 04 Dec 2007 22:45:24 -0300, Thomas M Steenholdt wrote: > > > Don't we still have the problem with glibc not supporting updates to > > resolv.conf and isn't that exactly the reason we need a slim > > forwarding/caching nameserver locally? Especially for mobile devices, > > it can get tedious to have to restart the browser after you move to a > > different network and things like that. > > Err... at least on my system I can add new nameservers to resolv.conf, > and (runnning) firefox instances pick up that change (may take some > seconds, but they do it). That's because it calls a magic function (res_init() or something) that means "really stat /etc/resolv.conf". Bottom line is that currently on Linux, if your application wants to work on roaming wireless networks, you need to 1) Listen to NetworkManager for networking changes 2) Know that you have to call res_init() in response to that signal Ideally we wouldn't have 2), but that's the state of things now. From oliver at linux-kernel.at Wed Dec 5 14:18:30 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 05 Dec 2007 15:18:30 +0100 Subject: Package alien In-Reply-To: References: <4756AC21.30104@redhat.com> Message-ID: <4756B336.80908@linux-kernel.at> On 12/05/2007 03:10 PM, Alex Lancaster wrote: >>>>>> "ZP" == Zdenek Prikryl writes: > > ZP> Hello, I would like to ask you, why was a package "alien" removed > ZP> from RH distros? Alien is a program that converts between the > ZP> rpm, dpkg, stampede slp, and slackware tgz file > ZP> formats. (http://kitenet.net/~joey/code/alien/) > > I think it was removed a long time ago before Fedora (I think maybe > back in the Red Hat 8 or 9 days, perhaps?), it's not even listed as > orphaned in the PackageDB: > > https://admin.fedoraproject.org/pkgdb/packages/name/alien > > gives a 404. > > There's no reason it couldn't be readded, AFAICT, if you wanted to > become a contributor to the Fedora package collection: > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > Alex > Last time included in RH, was EL 2.1 http://fr2.rpmfind.net/linux/rpm2html/search.php?query=alien&submit=Search+... PLD and OpenSuSE have RPMs, TurboLinux also. If someone wants to include alien, PLD specfile might be a good starting point... -of From zprikryl at redhat.com Wed Dec 5 14:27:54 2007 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 05 Dec 2007 15:27:54 +0100 Subject: Package alien In-Reply-To: References: <4756AC21.30104@redhat.com> Message-ID: <4756B56A.1090808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think it was removed a long time ago before Fedora (I think maybe > back in the Red Hat 8 or 9 days, perhaps?) Yes, I found alien in RH-[78], but then was removed. And nobody knows why :-) > There's no reason it couldn't be readded, AFAICT, if you wanted to > become a contributor to the Fedora package collection: > > http://fedoraproject.org/wiki/PackageMaintainers/Join If I don't find some important reason, why I shouldn't add this to fedora, then I'll try to be a maintainer. Thanks - -- Zdenek Prikryl Software Engineer - Base Operating Systems Brno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVrVqGQbtTQ12wjARAvTAAJ9kDuYPkxLLnb39o/bLfr26ZjWK+wCeIW9u +YOnOYOsnDkO2zSiuH+3IZU= =bxeD -----END PGP SIGNATURE----- From jdennis at redhat.com Wed Dec 5 14:29:41 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 05 Dec 2007 09:29:41 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756A762.7070107@leemhuis.info> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> Message-ID: <4756B5D5.6030204@redhat.com> >> Why would he put something bad? Being malicious? > Yes. Sure, for most people the hurdle is likely to high to go that > route, but OTOH it a great way to get bad code out to lots of systems > quickly (and a way to ruin our fame) Linux has been mostly immune to malware. For anyone writing malware one of the challenges is propagating the infected code. So lets not give bad folks the perfect vehicle for distributing their malware through an official update channel which automatically gets pushed to tens of thousands of machines with the implication of being clean software. Such an event would be devastating to the entire open source community. If one doesn't think this is going to happen or you think the ultimate consequences for open source adoption would be benign then I have a bridge I'd like to sell you. Also, if you think the bar to getting a Fedora account is so high as to make this unlikely then you've forgotten that anyone with enough software savvy to write malware would view that hurdle as a house of straw. If you think there aren't plenty of folks the world over just waiting for their 15 minutes of hacker fame or who have a desire to teach RedHat/Fedora a lesson then I can offer you a discount on that bridge. Do we need a better mechanism for accepting contributions from the community, probably. Are open commit lists the answer, no. If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it? -- John Dennis From mmcgrath at redhat.com Wed Dec 5 14:25:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 05 Dec 2007 08:25:01 -0600 Subject: Smolt database is broken In-Reply-To: <1196863772.25930.42.camel@perihelion> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> <1196830250.20291.14.camel@perihelion> <20071205120554.GA18458@devserv.devel.redhat.com> <1196863772.25930.42.camel@perihelion> Message-ID: <4756B4BD.608@redhat.com> Jon Masters wrote: > On Wed, 2007-12-05 at 07:05 -0500, Alan Cox wrote: > >> On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote: >> >>>> and I'm not a mathematician. I've raised it however but since its turkey >>>> genoiciding season in the USA it might be a bit slow >>>> >>> (I'm a pescetarian FWIW, and didn't butcher any Turkeys) >>> >> Sounds fishy to me. >> > > I fed you a line, knew you'd bite. > > >>> Was there any outcome on this in the end? >>> >> Just been resurrected on l/k >> > > Right. That was why I asked - I saw the thread, but it doesn't seem to > have gone anywhere yet. I guess the kernel should not be returning UUIDs > at all until there's sufficient entropy to do so. I'll ponder it. > Long story short. There doesn't seem to be any problem with the way the kernel generates UUID's. It has to do with how smolt RPM installs and how the LiveCD is made (all live cd people end up with the same UUID / arch, etc) -Mike From mclasen at redhat.com Wed Dec 5 14:32:04 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 05 Dec 2007 09:32:04 -0500 Subject: Rebuilds for openssl/openldap In-Reply-To: References: <1196862332.4396.2.camel@localhost.localdomain> Message-ID: <1196865124.2725.1.camel@localhost.localdomain> On Wed, 2007-12-05 at 07:02 -0700, Alex Lancaster wrote: > >>>>> "MC" == Matthias Clasen writes: > > I count *656* packages (which does include subpackages) but either > way, is a big number. > > This rebuild is going to be a huge deal and probably needs to be > co-ordinated like a "mass-rebuild" because of BuildRequires ordering > problems. Just to give one example: > > I was trying to rebuild ruby-gnome2, but it didn't work because it > depended on cups being rebuilt. Warren Togami on #fedora-devel > volunteered to rebuild cups, but cups itself depended on php being > rebuilt first, then (I think) php needed to wait on an httpd rebuild, > and so on... So we stopped at that point because the deps started > getting too deep to be done in an ad-hoc way. > > To avoid wasting time on rebuilds that will immediately fail, it seems > to me that the build should be done in a semi-systematic way > (e.g. perhaps concentrating on packages in "Base" comps group, then > working up through "Development Libraries" or some such, I don't > know). Yeah, maybe. We tackled a number of the more nasty rebuilds involving cyclic dependencies and bootstrapping yesterday, and it just takes a long time, since you always have to wait for the next buildroot compose... From jkeating at redhat.com Wed Dec 5 14:27:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 09:27:31 -0500 Subject: Rebuilds for openssl/openldap In-Reply-To: <1196862332.4396.2.camel@localhost.localdomain> References: <1196862332.4396.2.camel@localhost.localdomain> Message-ID: <20071205092731.79e6e62f@redhat.com> On Wed, 05 Dec 2007 08:45:32 -0500 Matthias Clasen wrote: > Here is a list of packages which still need to be rebuilt against the > new openssl or openldap. (The list is just what is blocking the update > on my machine, there may be more in the repository). > > I would be happy to help out with this, but most of these have ACLs > that prevent me from doing so... You seem to be missing a few. Also I realized that there are going to be some ordering issues. I'm currently working on generating a list so that I can run thetango over it (http://hosted.fedoraproject.org/projects/thetango) and produce an ordered build list. I'll be pushing those through the build system today. -- 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 oliver at linux-kernel.at Wed Dec 5 14:31:52 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 05 Dec 2007 15:31:52 +0100 Subject: Package alien In-Reply-To: <4756B56A.1090808@redhat.com> References: <4756AC21.30104@redhat.com> <4756B56A.1090808@redhat.com> Message-ID: <4756B658.1080609@linux-kernel.at> On 12/05/2007 03:27 PM, Zdenek Prikryl wrote: >> I think it was removed a long time ago before Fedora (I think maybe >> back in the Red Hat 8 or 9 days, perhaps?) > > Yes, I found alien in RH-[78], but then was removed. And nobody knows why :-) > >> There's no reason it couldn't be readded, AFAICT, if you wanted to >> become a contributor to the Fedora package collection: > >> http://fedoraproject.org/wiki/PackageMaintainers/Join > > If I don't find some important reason, why I shouldn't add this to fedora, then > I'll try to be a maintainer. The question is: It has been absent for a long time now, so it seems nobody really needs it, does someone? :-) Well. I guess there are a lot of pkgs that only a few guys do use in reality, so go for it. Package it. Share it. Use it. Best, Oliver From zprikryl at redhat.com Wed Dec 5 14:39:27 2007 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 05 Dec 2007 15:39:27 +0100 Subject: Package alien In-Reply-To: <4756B658.1080609@linux-kernel.at> References: <4756AC21.30104@redhat.com> <4756B56A.1090808@redhat.com> <4756B658.1080609@linux-kernel.at> Message-ID: <4756B81F.7050202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The question is: It has been absent for a long time now, so it seems > nobody really needs it, does someone? :-) at least, I use it sometimes (not very often, but...sometimes yes) :-)... - -- Zdenek Prikryl Software Engineer - Base Operating Systems Brno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVrgfGQbtTQ12wjARAvu8AJ9ZaEaiZ9Nk84eTSypndlMrsIO2MACeMpFD IWDNZRgldfkhGVAJzJrf3ws= =o6u5 -----END PGP SIGNATURE----- From oliver at linux-kernel.at Wed Dec 5 14:43:58 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 05 Dec 2007 15:43:58 +0100 Subject: Package alien In-Reply-To: <4756B81F.7050202@redhat.com> References: <4756AC21.30104@redhat.com> <4756B56A.1090808@redhat.com> <4756B658.1080609@linux-kernel.at> <4756B81F.7050202@redhat.com> Message-ID: <4756B92E.5070007@linux-kernel.at> On 12/05/2007 03:39 PM, Zdenek Prikryl wrote: >> The question is: It has been absent for a long time now, so it seems >> nobody really needs it, does someone? :-) > > at least, I use it sometimes (not very often, but...sometimes yes) :-)... Well. This wasn't in question. :-) -of From alan at redhat.com Wed Dec 5 14:44:50 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Dec 2007 09:44:50 -0500 Subject: Smolt database is broken In-Reply-To: <1196863772.25930.42.camel@perihelion> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> <1196830250.20291.14.camel@perihelion> <20071205120554.GA18458@devserv.devel.redhat.com> <1196863772.25930.42.camel@perihelion> Message-ID: <20071205144450.GA23849@devserv.devel.redhat.com> On Wed, Dec 05, 2007 at 09:09:31AM -0500, Jon Masters wrote: > > > (I'm a pescetarian FWIW, and didn't butcher any Turkeys) > > Sounds fishy to me. > I fed you a line, knew you'd bite. It had a barb on it and I fancied a snipe. I shad have known better. I hake to carry this on but I thougt I cod catch you floundering on your perch. We betta move on. Eel be time to skate back to my plaice. Sole long.. You mean piscivore anyway, 'pescetarian' is just a new 'gotta be different' word made up by people who didn't know the dictionary had a word for it already and had for hundreds of years > > > Was there any outcome on this in the end? > > > > Just been resurrected on l/k > > Right. That was why I asked - I saw the thread, but it doesn't seem to > have gone anywhere yet. I guess the kernel should not be returning UUIDs > at all until there's sufficient entropy to do so. I'll ponder it. Possibly. That still doesn't help us in our quest for unique system identifiers however. If we simply don't have enough entropy then we may need to mix in system specific bits but properly one way hashed (eg disc serial numbers) Alan From j.w.r.degoede at hhs.nl Wed Dec 5 14:53:31 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 05 Dec 2007 15:53:31 +0100 Subject: Rebuilds for openssl/openldap In-Reply-To: <20071205092731.79e6e62f@redhat.com> References: <1196862332.4396.2.camel@localhost.localdomain> <20071205092731.79e6e62f@redhat.com> Message-ID: <4756BB6B.9000804@hhs.nl> Jesse Keating wrote: > On Wed, 05 Dec 2007 08:45:32 -0500 > Matthias Clasen wrote: > >> Here is a list of packages which still need to be rebuilt against the >> new openssl or openldap. (The list is just what is blocking the update >> on my machine, there may be more in the repository). >> >> I would be happy to help out with this, but most of these have ACLs >> that prevent me from doing so... > > You seem to be missing a few. Also I realized that there are going to > be some ordering issues. I'm currently working on generating a list so > that I can run thetango over it > (http://hosted.fedoraproject.org/projects/thetango) and produce an > ordered build list. I'll be pushing those through the build system > today. > Thanks for that, your awesome! Yes really you are despite us having differences of opinion sometimes :) Regards, Hans From jkeating at redhat.com Wed Dec 5 15:10:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 10:10:41 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756B5D5.6030204@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> Message-ID: <20071205101041.2c5840cb@redhat.com> On Wed, 05 Dec 2007 09:29:41 -0500 John Dennis wrote: > Linux has been mostly immune to malware. For anyone writing malware > one of the challenges is propagating the infected code. > > So lets not give bad folks the perfect vehicle for distributing their > malware through an official update channel which automatically gets > pushed to tens of thousands of machines with the implication of being > clean software. Such an event would be devastating to the entire open > source community. > > If one doesn't think this is going to happen or you think the > ultimate consequences for open source adoption would be benign then I > have a bridge I'd like to sell you. > > Also, if you think the bar to getting a Fedora account is so high as > to make this unlikely then you've forgotten that anyone with enough > software savvy to write malware would view that hurdle as a house of > straw. > > If you think there aren't plenty of folks the world over just waiting > for their 15 minutes of hacker fame or who have a desire to teach > RedHat/Fedora a lesson then I can offer you a discount on that bridge. > > Do we need a better mechanism for accepting contributions from the > community, probably. Are open commit lists the answer, no. > > If you think the problem would be mitigated by package maintainers > rigorously reviewing all changes *after* they've been committed > you're forgetting human nature and the fact most maintainers are over > worked to begin with. By extension if you demand maintainers review > every commit then how is that effectively different than the current > process of posting a patch in a bugzilla and asking the maintainer to > review it before committing it? And if you think we're the first Linux distro of any size to have wider access to our software source control you're also mistaken. We're not paving new ground here. Debian has NMUs which allow for a Debian maintainer other than the package owner to upload new builds of a package for various reasons: http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Ubuntu has a "Development Team" that have commit access across all the Universe packages, and a "Core Development Team" that has access to the packages in main. This is a lot more like what we used to have, with Core/Extras, but it still gives pretty wide commit access to a number of people. Just as dangerous as what you're worried about. "Open"Suse is a different story. Only Novell employees can maintain opensuse packages. However they have a buildservice which allows just about anybody to build software and publish in a public repo. YaST has clickable links to a number of popular repos. So we're hardly the first, and certainly not the largest, linux distro to have "open" commits for project members. -- 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 cmadams at hiwaay.net Wed Dec 5 15:26:51 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Dec 2007 09:26:51 -0600 Subject: Smolt database is broken In-Reply-To: <20071205144450.GA23849@devserv.devel.redhat.com> References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com> <200711191813.45675.kewley@gps.caltech.edu> <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com> <20071120115203.GA3361@devserv.devel.redhat.com> <474334BB.1080002@redhat.com> <20071120210417.GA29466@devserv.devel.redhat.com> <1196830250.20291.14.camel@perihelion> <20071205120554.GA18458@devserv.devel.redhat.com> <1196863772.25930.42.camel@perihelion> <20071205144450.GA23849@devserv.devel.redhat.com> Message-ID: <20071205152651.GC1188771@hiwaay.net> Once upon a time, Alan Cox said: > Possibly. That still doesn't help us in our quest for unique system identifiers > however. If we simply don't have enough entropy then we may need to mix in > system specific bits but properly one way hashed (eg disc serial numbers) I would think a good list of things to include would be: - lspci -v will not only list the PCI cards but includes which slot they are in - lsusb -v (although I don't think usbutils is installed by default) includes things like firmware version for some devices and again using a different port will give different results - dmidecode sometimes includes serial numbers, also can vary based on which slot things are in - ifconfig -a includes MAC addresses - smartctl -a [each hard drive] depending on drive, includes serial number, temperature, power-on time and count, random variables only the drive make understands There is enough system-specific stuff in those to get pretty random (once hashed). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pertusus at free.fr Wed Dec 5 15:27:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Dec 2007 16:27:02 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756B5D5.6030204@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> Message-ID: <20071205152701.GC4153@free.fr> On Wed, Dec 05, 2007 at 09:29:41AM -0500, John Dennis wrote: > > If you think the problem would be mitigated by package maintainers > rigorously reviewing all changes *after* they've been committed you're > forgetting human nature and the fact most maintainers are over worked to > begin with. By extension if you demand maintainers review every commit then I completly disagree with that. If a packager is not capable of reviewing everything that goes through for his package then something is definitely wrong. Either the packager should orphan the package or ask for co-maintainership but should never let something happen without noticing. > how is that effectively different than the current process of posting a > patch in a bugzilla and asking the maintainer to review it before > committing it? It is different, not the same workflow. It seems to me that, for example, it is very time saving to have someone change the spec, ask a mail for rebuild, without going through bugzilla. Still the package maintainer has to understand enough every patch (or trust the other contributor enough after review). (As a side note I personally think that rebuilds/publishing should not be open while cvs should be.) It is more or less the case given that there is bodhi for stable, but for rawhide it is not the case. -- Pat From pertusus at free.fr Wed Dec 5 15:29:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Dec 2007 16:29:05 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <1196859556.15639.133.camel@localhost.localdomain> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> Message-ID: <20071205152905.GD4153@free.fr> On Wed, Dec 05, 2007 at 01:59:16PM +0100, Lubomir Kundrak wrote: > > I'd say all sponsored people are "experienced maintainers". Those who > are not experienced do post their work in bugzilla. At least I think of > sponsorship should serve exactly this purpose, if you believe it is not, > then it is unuseful and have to be dealt with somehow. If we solved that > by separating the group further, we may end up with something like > "extra most super experienced maintainers" groups. That already exists, see (especially at the end) http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages -- Pat From fedora at leemhuis.info Wed Dec 5 15:30:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Dec 2007 16:30:10 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205101041.2c5840cb@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> Message-ID: <4756C402.8090503@leemhuis.info> On 05.12.2007 16:10, Jesse Keating wrote: > On Wed, 05 Dec 2007 09:29:41 -0500 > John Dennis wrote: > >> Linux has been mostly immune to malware. For anyone writing malware >> one of the challenges is propagating the infected code. >> >> So lets not give bad folks the perfect vehicle for distributing their >> malware through an official update channel which automatically gets >> pushed to tens of thousands of machines with the implication of being >> clean software. Such an event would be devastating to the entire open >> source community. [...] >> If you think the problem would be mitigated by package maintainers >> rigorously reviewing all changes *after* they've been committed >> you're forgetting human nature and the fact most maintainers are over >> worked to begin with. By extension if you demand maintainers review >> every commit then how is that effectively different than the current >> process of posting a patch in a bugzilla and asking the maintainer to >> review it before committing it? > > And if you think we're the first Linux distro of any size to have wider > access to our software source control you're also mistaken. We're not > paving new ground here. [... some examples ....] > So we're hardly the first, and certainly not the largest, linux distro > to have "open" commits for project members. So your option as FESCo member is what? Just continue with the current procedure and hope and pray that nothing happens? For me something like the ubuntu solution ("Development Team" that have commit access across all the Universe packages) sounds good -- we could create such a team by putting sponsors, rel-eng-people and some hand selected red hat employees as well as some long term contributers into a "group" and call them "Development Team" as well. CU knurd From pertusus at free.fr Wed Dec 5 15:34:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Dec 2007 16:34:00 +0100 Subject: Undoing ACLs (was Re: Dealing with PPC in Fedora 9(+)) In-Reply-To: <20071205075928.53421570@redhat.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> <1196809101.13978.402.camel@pmac.infradead.org> <1196825378.7206.8.camel@localhost.localdomain> <1196856049.13978.466.camel@pmac.infradead.org> <20071205075928.53421570@redhat.com> Message-ID: <20071205153400.GE4153@free.fr> On Wed, Dec 05, 2007 at 07:59:28AM -0500, Jesse Keating wrote: > On Wed, 05 Dec 2007 12:00:49 +0000 > > I still want there to be an ACL system for when a maintainer strongly > feels that his/her package should be kept to a small commit list. > However the vast majority would be just fine open, and would promote > more of a help you neighbor attitude if ACLs weren't in the way. At the same time, maybe it would be good if packagers, especially for former core packages asked for co-maintainers when they don't have time to really care of their packages. Otherwise opening ACLs may lead to possible security issues for packages maintained by people that have very little time. That said, I am all for removing ACLs. -- Pat From databasearia at yahoo.com Wed Dec 5 15:32:52 2007 From: databasearia at yahoo.com (Nevruz Mesut Sahin) Date: Wed, 5 Dec 2007 07:32:52 -0800 (PST) Subject: About postfix dovecot and vmail Message-ID: <698711.39639.qm@web32610.mail.mud.yahoo.com> Dear friend yesterday I rent a server AMD 64 which is installed fedora core 6 on the machine and apache 2.2.6, bind 9.3.4 MySQL 5.0.27, Postfix 2.4.5 dovecot 1.0.3, were installed on the machine. I configured apache bind and mysql successfully. But couldn't configured postfix and dovecot. I have more than 20 domains which I want to run on this server. to list services which are working on the server service --status-all I have written in the terminal and I got list below. would you please help me how can I configere mail server with virtual hosts. what is the best way for me. [root at mesut~]#service --status-all acpid (pid 2223) is running... anacron is stopped atd (pid 2515) is running... Avahi daemon is not running Avahi DNS daemon is not running hcid is stopped sdpd is stopped cpuspeed is stopped crond (pid 2490) is running... cupsd is stopped dc_client is stopped dc_server is stopped dovecot (pid 2382) is running... dund is stopped Usage: /etc/init.d/firstboot {start|stop} gpm is stopped hald is stopped hidd (pid 2210) is running... httpd (pid 2569 2568 2567 2566 2565 2564 2563 2562 2561 2560 2559 2558 2557 2556 2555 2554 2553 2552 2551 2550 2477) is running... Firewall is stopped. Firewall is stopped. irattach is stopped irqbalance (pid 2113) is running... Kdump is not operational mdadm is stopped mdmpd is stopped dbus-daemon (pid 2184) is running... multipathd is stopped mysqld (pid 2355) is running... rndc: connect failed: 127.0.0.1#953: connection refused netplugd is stopped Configured devices: lo eth0 Currently active devices: lo eth0 NetworkManager is stopped NetworkManagerDispatcher is stopped rpc.mountd is stopped nfsd is stopped rpc.rquotad is stopped rpc.statd is stopped nscd is stopped ntpd is stopped pand is stopped pcscd is stopped portmap is stopped master (pid 2442) is running... proftpd (pid 2463) is running... Process accounting is disabled. rdisc is stopped rpc.idmapd (pid 2160) is running... saslauthd (pid 2532 2531 2530 2529 2528) is running... smartd (pid 2600) is running... squid is stopped sshd (pid 2702 2687 2240) is running... syslogd (pid 2096) is running... klogd (pid 2099) is running... tux is stopped Usermin (pid 2605) is running webmin (pid 2610) is running wpa_supplicant is stopped xinetd (pid 2254) is running... ypbind is stopped yum-updatesd (pid 2570) is running... --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Dec 5 15:41:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 10:41:20 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756C402.8090503@leemhuis.info> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756C402.8090503@leemhuis.info> Message-ID: <20071205104120.3c9a9c9d@redhat.com> On Wed, 05 Dec 2007 16:30:10 +0100 Thorsten Leemhuis wrote: > For me something like the ubuntu solution ("Development Team" that > have commit access across all the Universe packages) sounds good -- > we could create such a team by putting sponsors, rel-eng-people and > some hand selected red hat employees as well as some long term > contributers into a "group" and call them "Development Team" as well. The only difference between the ubuntu "developer" team and cvsextras membership is we seem a lot more eager to hand out sponsorships. If we were less eager to hand it out, then we'd have that "team". An alternative that has been talked about before, which I see some value in, is that a new group is created, cvsnewbies if you will, and members of those groups only have access to the packages they own. They over time can be promoted to cvspkgs or cvsextras or whatever we're going to call it. Insert some criteria for promotion here. At the end of the day, I just want our package set to be accessible to as many people as possible instead of locked away from as many people as possible. Having just looked a bit closer and talked with Jeremy, here is what I think we can do. "cvsextras" as a FAS group becomes something like just 'cvspkgs'. Warren is already planning on doing this. Membership in this group gives you a couple things. 1) file level ACLs on the cvs server to write to the file system. Everybody has to have this in order for cvs to write out files on your behalf. 2) A grouping of all Fedora package maintainers. All maintainers would have to be in cvspkgs. We would then create a new group, cvsexperienced or some other name such as this. This group is the group that gets CVS ACLs to all modules that haven't opted out of this openness. This takes the place of what we have in pkgdb currently as cvsextras commit. Entry to this group should be relatively low barrier, but there is still a barrier between the fresh contributors and everybody elses packages. Finally we have the cvsadmin group who just has blanket access no matter what, and this doesn't have to change. With some relatively small changes this could be accomplished. The interesting discussion points are A) what is the criteria to get added to cvsexperienced? Obviously sponsors are automatically added, but there should be other ways to get in. B) who from the current members of cvsextras would we grandfather into cvsexperienced? C) what is a better name for "cvsexperienced". D) when to make this 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 fedora at leemhuis.info Wed Dec 5 15:45:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Dec 2007 16:45:26 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205152701.GC4153@free.fr> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205152701.GC4153@free.fr> Message-ID: <4756C796.5020901@leemhuis.info> On 05.12.2007 16:27, Patrice Dumas wrote: > On Wed, Dec 05, 2007 at 09:29:41AM -0500, John Dennis wrote: >> If you think the problem would be mitigated by package maintainers >> rigorously reviewing all changes *after* they've been committed you're >> forgetting human nature and the fact most maintainers are over worked to >> begin with. By extension if you demand maintainers review every commit then > I completly disagree with that. If a packager is not capable of > reviewing everything that goes through for his package then something > is definitely wrong. Either the packager should orphan the package or > ask for co-maintainership but should never let something happen without > noticing. Well, with the CTRL+C bug you might not get a mail if someone changed something. And if we like it or not, I bet we have packagers that just delete CVS commit mails to their packages when they come home after a three weeks holiday and find > 20.000 mails in their inbox. I think that's bad, but that's how some humans are sometimes afaics. > It is different, not the same workflow. It seems to me that, for example, > it is very time saving to have someone change the spec, ask a mail for > rebuild, without going through bugzilla. Still the package maintainer has to > understand enough every patch (or trust the other contributor enough > after review). +1 > (As a side note I personally think that rebuilds/publishing should not be > open while cvs should be.) It is more or less the case given that there > is bodhi for stable, but for rawhide it is not the case. Yes and no. With the current CTRL+C bug someone else might commit something bad to a package owned by someone else. Sooner or later the real owner might do a fresh checkout (something some people do regularly instead of having a local checkout), do another change, build and push. Cu knurd From jkeating at redhat.com Wed Dec 5 15:51:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 10:51:30 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205104120.3c9a9c9d@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756C402.8090503@leemhuis.info> <20071205104120.3c9a9c9d@redhat.com> Message-ID: <20071205105130.47436c4a@redhat.com> On Wed, 5 Dec 2007 10:41:20 -0500 Jesse Keating wrote: > Having just looked a bit closer and talked with Jeremy, here is what I > think we can do. > > "cvsextras" as a FAS group becomes something like just 'cvspkgs'. > Warren is already planning on doing this. Membership in this group > gives you a couple things. > > 1) file level ACLs on the cvs server to > write to the file system. Everybody has to have this in order for cvs > to write out files on your behalf. > > 2) A grouping of all Fedora package maintainers. All maintainers > would have to be in cvspkgs. > > We would then create a new group, cvsexperienced or some other name > such as this. This group is the group that gets CVS ACLs to all > modules that haven't opted out of this openness. This takes the place > of what we have in pkgdb currently as cvsextras commit. Entry to this > group should be relatively low barrier, but there is still a barrier > between the fresh contributors and everybody elses packages. > > Finally we have the cvsadmin group who just has blanket access no > matter what, and this doesn't have to change. > > With some relatively small changes this could be accomplished. The > interesting discussion points are A) what is the criteria to get added > to cvsexperienced? Obviously sponsors are automatically added, but > there should be other ways to get in. B) who from the current members > of cvsextras would we grandfather into cvsexperienced? C) what is a > better name for "cvsexperienced". D) when to make this happen. I forgot to mention. Membership in cvspkgs does not give you wide access. In fact, the members of cvspkgs are not "considered" when creating CVS ACLs. The owners/co-maintainers of packages are, and members of cvsexperienced are (provided the package in question allows for cvsexperienced commit access). This effectively keeps new packagers to only A) the packages they own, and B) the packages the co-maintain with other people. -- 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 zprikryl at redhat.com Wed Dec 5 16:19:45 2007 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 05 Dec 2007 17:19:45 +0100 Subject: Package alien In-Reply-To: References: <4756AC21.30104@redhat.com> Message-ID: <4756CFA1.8050605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think it was removed a long time ago before Fedora (I think maybe > back in the Red Hat 8 or 9 days, perhaps?), Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't problem. But reverse conversion is big problem. For example, if I want to convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are debian packages for creating deb files. All of those packages aren't in fedora repos. So, question is, if one-way conversion is a sufficient reason to create alien package. Other solution is create another package (like deb in OpenSUSE) which contains those debian packages and make alien dependant on this new package. Or let alien be forgotten henceforth. - -- Zdenek Prikryl Software Engineer - Base Operating Systems Brno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVs+hGQbtTQ12wjARApEmAJ4rVLYnJ2L5qo+eoP87zDt5iCZQWgCePfxV 2w8LBNq8lrMkqOTahhE47AI= =VxDS -----END PGP SIGNATURE----- From oliver at linux-kernel.at Wed Dec 5 16:24:30 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 05 Dec 2007 17:24:30 +0100 Subject: Package alien In-Reply-To: <4756CFA1.8050605@redhat.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> Message-ID: <4756D0BE.2030605@linux-kernel.at> On 12/05/2007 05:19 PM, Zdenek Prikryl wrote: >> I think it was removed a long time ago before Fedora (I think maybe >> back in the Red Hat 8 or 9 days, perhaps?), > > Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't > problem. But reverse conversion is big problem. For example, if I want to > convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are > debian packages for creating deb files. All of those packages aren't in fedora > repos. > > So, question is, if one-way conversion is a sufficient reason to create alien > package. Other solution is create another package (like deb in OpenSUSE) which > contains those debian packages and make alien dependant on this new package. Or > let alien be forgotten henceforth. I think you start with one-way version (if you like) and try to get the missing links into Fedora as well and then switch your alien pkg to rebuild and/or use the missing bits... Else, get the deb bits into Fedora and afterwards alien itself... Which sounds for me like the best idea.... -of From fedora at leemhuis.info Wed Dec 5 16:28:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Dec 2007 17:28:49 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205105130.47436c4a@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756C402.8090503@leemhuis.info> <20071205104120.3c9a9c9d@redhat.com> <20071205105130.47436c4a@redhat.com> Message-ID: <4756D1C1.6010503@leemhuis.info> On 05.12.2007 16:51, Jesse Keating wrote: > On Wed, 5 Dec 2007 10:41:20 -0500 > Jesse Keating wrote: > >> Having just looked a bit closer and talked with Jeremy, here is what I >> think we can do. In general: looks good. But it's actually quite similar that was purposed in a older discussion not that many months ago but not further realized because then I was told that having a second group in FAS is not that easy to realize for this task. >> "cvsextras" as a FAS group becomes something like just 'cvspkgs'. >> Warren is already planning on doing this. Membership in this group >> gives you a couple things. >> >> 1) file level ACLs on the cvs server to >> write to the file system. Everybody has to have this in order for cvs >> to write out files on your behalf. >> >> 2) A grouping of all Fedora package maintainers. All maintainers >> would have to be in cvspkgs. >> >> We would then create a new group, cvsexperienced or some other name >> such as this. This group is the group that gets CVS ACLs to all >> modules that haven't opted out of this openness. This takes the place >> of what we have in pkgdb currently as cvsextras commit. Entry to this >> group should be relatively low barrier, but there is still a barrier >> between the fresh contributors and everybody elses packages. With this words it sounds to me like a bit to low barrier, but that depends on the exact definition. >> Finally we have the cvsadmin group who just has blanket access no >> matter what, and this doesn't have to change. >> >> With some relatively small changes this could be accomplished. The >> interesting discussion points are A) what is the criteria to get added >> to cvsexperienced? Obviously sponsors are automatically added, but >> there should be other ways to get in. IMHO is the barrier should be something like "invested quite some work into Fedora (something like: maintained 8 packages or did a lot of other work in Fedora-land and is around for more then 3 or 6 months)" and "showed that be knows the packaging guidelines"; IOW: can be trusted. But something like that is not easily written down. I think FESCo (or some other group; the sponsors maybe?) should just approve people if they trust them. And people should have a reasons to get that access; we should not simply hand it out accoring to some static rules.) >> B) who from the current members >> of cvsextras would we grandfather into cvsexperienced? I'd say only sponsors, people around for a long time (two years maybe?) or with a lot of packages (more then 12 maybe?) and are active. >> C) what is a >> better name for "cvsexperienced". cvstrusted ? >> D) when to make this happen. E) how to maintain that group, as people become inactive or leave over time again. > I forgot to mention. Membership in cvspkgs does not give you wide > access. In fact, the members of cvspkgs are not "considered" when > creating CVS ACLs. The owners/co-maintainers of packages are, and > members of cvsexperienced are (provided the package in question allows > for cvsexperienced commit access). > > This effectively keeps new packagers to only A) the packages they own, > and B) the packages the co-maintain with other people. CU knurd From zprikryl at redhat.com Wed Dec 5 16:42:09 2007 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 05 Dec 2007 17:42:09 +0100 Subject: Package alien In-Reply-To: <4756D0BE.2030605@linux-kernel.at> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <4756D0BE.2030605@linux-kernel.at> Message-ID: <4756D4E1.3070507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think you start with one-way version (if you like) and try to get the > missing links into Fedora as well and then switch your alien pkg to > rebuild and/or use the missing bits... > > Else, get the deb bits into Fedora and afterwards alien itself... Which > sounds for me like the best idea.... I think that second option is better. - -- Zdenek Prikryl Software Engineer - Base Operating Systems Brno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVtThGQbtTQ12wjARAlvHAJ447DO9ZH6aZK6QNXNBgqZZ49XtoQCePcwI oLr4QY4qBXoCKdhMcJ3QXas= =y763 -----END PGP SIGNATURE----- From pertusus at free.fr Wed Dec 5 16:41:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Dec 2007 17:41:31 +0100 Subject: Package alien In-Reply-To: <4756D0BE.2030605@linux-kernel.at> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <4756D0BE.2030605@linux-kernel.at> Message-ID: <20071205164131.GL4153@free.fr> On Wed, Dec 05, 2007 at 05:24:30PM +0100, Oliver Falk wrote: > > I think you start with one-way version (if you like) and try to get the > missing links into Fedora as well and then switch your alien pkg to > rebuild and/or use the missing bits... > > Else, get the deb bits into Fedora and afterwards alien itself... Which > sounds for me like the best idea.... Indeed, it seems to me that alien should depend on dpkg. I have packages available for dpkg, and other debian stuff (and debootstrap is already in fedora): http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/ -- Pat From oliver at linux-kernel.at Wed Dec 5 16:44:09 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 05 Dec 2007 17:44:09 +0100 Subject: Package alien In-Reply-To: <20071205164131.GL4153@free.fr> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <4756D0BE.2030605@linux-kernel.at> <20071205164131.GL4153@free.fr> Message-ID: <4756D559.3010901@linux-kernel.at> On 12/05/2007 05:41 PM, Patrice Dumas wrote: > On Wed, Dec 05, 2007 at 05:24:30PM +0100, Oliver Falk wrote: >> I think you start with one-way version (if you like) and try to get the >> missing links into Fedora as well and then switch your alien pkg to >> rebuild and/or use the missing bits... >> >> Else, get the deb bits into Fedora and afterwards alien itself... Which >> sounds for me like the best idea.... > > Indeed, it seems to me that alien should depend on dpkg. > I have packages available for dpkg, and other debian stuff (and > debootstrap is already in fedora): > > http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/ Well then Zdenek, get the specs. Do a cleanup, run rpmlint, upload somewhere and file a review request :-) -of From orion at cora.nwra.com Wed Dec 5 16:46:17 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 05 Dec 2007 09:46:17 -0700 Subject: Device ownership/permissions Message-ID: <4756D5D9.6040904@cora.nwra.com> What system is responsible for changing device ownership/permissions in fedora when a user logs in on Fedora 8? We're trying to figure out a problem that is causing pulseaudio not to run with latest testing updates (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think it may be a problem with hal-acl-tool, but I really have no clue. -- 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 ndbecker2 at gmail.com Wed Dec 5 15:12:03 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 05 Dec 2007 10:12:03 -0500 Subject: pykde4 planned? Message-ID: Is it planned to have a pykde4 to go with kde4? From wtogami at redhat.com Wed Dec 5 16:51:41 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 05 Dec 2007 11:51:41 -0500 Subject: About postfix dovecot and vmail In-Reply-To: <698711.39639.qm@web32610.mail.mud.yahoo.com> References: <698711.39639.qm@web32610.mail.mud.yahoo.com> Message-ID: <4756D71D.7080204@redhat.com> Nevruz Mesut Sahin wrote: > Dear friend yesterday I rent a server AMD 64 which is installed fedora > core 6 on the machine and apache 2.2.6, bind 9.3.4 MySQL 5.0.27, > Postfix 2.4.5 dovecot 1.0.3, were installed on the machine. I > configured apache bind and mysql successfully. But couldn't configured > postfix and dovecot. I have more than 20 domains which I want to > run on this server. to list services which are working on the > server service --status-all I have written in the terminal and I got > list below. would you please help me how can I configere mail server > with virtual hosts. what is the best way for me. > http://fedoraproject.org/wiki/PostIsOffTopic This is not a user support list. Please take your question to a more appropriate place like http://fedoraforum.org. Aside from this, I think in order to support virtual domains postfix and dovecot need to be built against vpopmail. vpopmail does not ship in Fedora for one reason or another. I tried it a few years ago, but gave up and haven't heard anyone asking for it since. I do recall that we avoided some nasty security holes in some component (don't remember which) in RHEL because we didn't build against vpopmail. Warren Togami wtogami at redhat.com From jkeating at redhat.com Wed Dec 5 16:49:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 11:49:25 -0500 Subject: Device ownership/permissions In-Reply-To: <4756D5D9.6040904@cora.nwra.com> References: <4756D5D9.6040904@cora.nwra.com> Message-ID: <20071205114925.005ea634@redhat.com> On Wed, 05 Dec 2007 09:46:17 -0700 Orion Poplawski wrote: > What system is responsible for changing device ownership/permissions > in fedora when a user logs in on Fedora 8? We're trying to figure > out a problem that is causing pulseaudio not to run with latest > testing updates > (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think it > may be a problem with hal-acl-tool, but I really have no clue. ConsoleKit. -- 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 opensource at till.name Wed Dec 5 17:08:35 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Dec 2007 18:08:35 +0100 Subject: TeXLive is in rawhide In-Reply-To: <20071205135144.88357db5.mschwendt.tmp0701.nospam@arcor.de> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712042247.30039.opensource@till.name> <20071205135144.88357db5.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200712051808.40107.opensource@till.name> On Mi Dezember 5 2007, Michael Schwendt wrote: > On Tue, 04 Dec 2007 22:47:12 +0100, Till Maas wrote: > > Is > > > > Requires: foo > 3.0 > > > > satisfied with foo-3.0-1 or only with every version of foo that is higher > > than 3.0, e.g. foo-3.1-1? > > It means that %version must be higher than "3.0". %release does not > matter, because it is not specified in the Requires. > > 3.1-1 is not a version, it is a version-release tuple, and > 3.1 > 3.0 already. I hope this is the last question to understand how it works: In case of Requires: foo > 3.0-1 does foo-3.1-1 match 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 jon.nettleton at gmail.com Wed Dec 5 17:17:06 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 05 Dec 2007 12:17:06 -0500 Subject: Device ownership/permissions In-Reply-To: <4756D5D9.6040904@cora.nwra.com> References: <4756D5D9.6040904@cora.nwra.com> Message-ID: <1196875026.13721.46.camel@birkoff.charles.net> On Wed, 2007-12-05 at 09:46 -0700, Orion Poplawski wrote: > What system is responsible for changing device ownership/permissions in > fedora when a user logs in on Fedora 8? We're trying to figure out a > problem that is causing pulseaudio not to run with latest testing > updates (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think > it may be a problem with hal-acl-tool, but I really have no clue. > Check dmesg. For me hal-acl-tool is segfaulting. Jon From mschwendt.tmp0701.nospam at arcor.de Wed Dec 5 17:22:07 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Dec 2007 18:22:07 +0100 Subject: TeXLive is in rawhide In-Reply-To: <200712051808.40107.opensource@till.name> References: <20071203122132.GA2791@dhcp-lab-186.brq.redhat.com> <200712042247.30039.opensource@till.name> <20071205135144.88357db5.mschwendt.tmp0701.nospam@arcor.de> <200712051808.40107.opensource@till.name> Message-ID: <20071205182207.3ac383e2.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Dec 2007 18:08:35 +0100, Till Maas wrote: > On Mi Dezember 5 2007, Michael Schwendt wrote: > > On Tue, 04 Dec 2007 22:47:12 +0100, Till Maas wrote: > > > > Is > > > > > > Requires: foo > 3.0 > > > > > > satisfied with foo-3.0-1 or only with every version of foo that is higher > > > than 3.0, e.g. foo-3.1-1? > > > > It means that %version must be higher than "3.0". %release does not > > matter, because it is not specified in the Requires. > > > > 3.1-1 is not a version, it is a version-release tuple, and > > 3.1 > 3.0 already. > > I hope this is the last question to understand how it works: > > In case of > > Requires: foo > 3.0-1 > > does foo-3.1-1 match here? Of course. 3.1 > 3.0 => done From notting at redhat.com Wed Dec 5 17:26:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Dec 2007 12:26:30 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196863948.4124.8.camel@space-ghost.verbum.private> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> Message-ID: <20071205172630.GB10961@nostromo.devel.redhat.com> > That's because it calls a magic function (res_init() or something) that > means "really stat /etc/resolv.conf". Bottom line is that currently on > Linux, if your application wants to work on roaming wireless networks, > you need to *stat*? Don't we have inotify these days? Bill From opensource at till.name Wed Dec 5 17:27:59 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Dec 2007 18:27:59 +0100 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756C796.5020901@leemhuis.info> References: <20071204163625.6cda6f82@redhat.com> <20071205152701.GC4153@free.fr> <4756C796.5020901@leemhuis.info> Message-ID: <200712051828.03908.opensource@till.name> On Mi Dezember 5 2007, Thorsten Leemhuis wrote: > Yes and no. With the current CTRL+C bug someone else might commit > something bad to a package owned by someone else. Sooner or later the > real owner might do a fresh checkout (something some people do regularly > instead of having a local checkout), do another change, build and push. An scm that supports signing commits / repository contens would help here, because one could easily check whether the checked out contents are trusted. Or this there an easy way with cvs to show the last author of every source file? Looking through "cvs log" is not an easy solution 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 jspaleta at gmail.com Wed Dec 5 17:31:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Dec 2007 08:31:19 -0900 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756B5D5.6030204@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> Message-ID: <604aa7910712050931t26403312m3e4483d081f1d3b@mail.gmail.com> On Dec 5, 2007 5:29 AM, John Dennis wrote: > Do we need a better mechanism for accepting contributions from the > community, probably. Are open commit lists the answer, no. I floated a mentor status idea for new contributors. Something equivalent to me bringing in a contributor such that they get commit access to an explicit set of packages that I watch over so that I am on the hook for their commiting behavior. They don't get to push to builds to repositories (they can do scratch builds) and I vouch for them until such time they have a track record of right action to obtain full sponsorship. My understanding was that our acl's are setup to allow this sort of thing yet. And it help if I could make sure forced re-tagging was disabled for them as well. -jef From selinux at gmail.com Wed Dec 5 17:43:22 2007 From: selinux at gmail.com (Tom London) Date: Wed, 5 Dec 2007 09:43:22 -0800 Subject: Device ownership/permissions In-Reply-To: <4756D5D9.6040904@cora.nwra.com> References: <4756D5D9.6040904@cora.nwra.com> Message-ID: <4c4ba1530712050943n18c8f9bat3cb59747918d7cdd@mail.gmail.com> On Dec 5, 2007 8:46 AM, Orion Poplawski wrote: > What system is responsible for changing device ownership/permissions in > fedora when a user logs in on Fedora 8? We're trying to figure out a > problem that is causing pulseaudio not to run with latest testing > updates (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think > it may be a problem with hal-acl-tool, but I really have no clue. > > -- > Orion Poplawski Could it be: https://bugzilla.redhat.com/show_bug.cgi?id=407591 ? tom -- Tom London From bpepple at fedoraproject.org Wed Dec 5 17:59:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Dec 2007 12:59:18 -0500 Subject: Plan for tomorrows (20071206) FESCO meeting Message-ID: <1196877558.25295.5.camel@nixon> 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 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic MISC - automate the mailings of multiarch conflicts, it is hard to test for people without biarch computers - from Patrice Dumas /topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all /topic MISC - Are "spins" a feature? - poelcat, all /topic FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat * http://fedoraproject.org/wiki/Releases/FeatureBluetooth * http://fedoraproject.org/wiki/Releases/FeatureClockApplet * http://fedoraproject.org/wiki/Features/PartitionResizing * http://fedoraproject.org/wiki/Features/VirtStorage * http://fedoraproject.org/wiki/Releases/FeatureFingerprint * http://fedoraproject.org/wiki/Features/PackageKit * http://fedoraproject.org/wiki/Features/Ext4 * http://fedoraproject.org/wiki/Releases/FeatureTexLive * http://fedoraproject.org/wiki/Features/VirtAuthentication * http://fedoraproject.org/wiki/Features/VirtPolicyKit /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, since we have a pretty full schedule). 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... 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 kevin.kofler at chello.at Wed Dec 5 16:53:14 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 5 Dec 2007 16:53:14 +0000 (UTC) Subject: Orphaning packages References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> <20071205104535.M45869@all-the-johnsons.co.uk> <20071205080402.7b00de21@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > On Wed, 5 Dec 2007 10:45:35 +0000 > "Paul F. Johnson" all-the-johnsons.co.uk> wrote: > > > > How about doing the same for anjuta [1] and anjuta-gdl [2]? They > > > don't look like Mono packages, which Paul wants to keep, and I > > > would like to take them. > > > > Feel free to take them. > > [...] > > I orphaned these in pkgdb. What about z88dk? That's also listed as owned by pfj, and I offered to pick it up. Kevin Kofler From kevin.kofler at chello.at Wed Dec 5 16:54:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 5 Dec 2007 16:54:18 +0000 (UTC) Subject: pykde4 planned? References: Message-ID: Neal Becker gmail.com> writes: > Is it planned to have a pykde4 to go with kde4? AFAIK, that's now included in kdebindings, so it should show up when kdebindings 4 hits Rawhide. Kevin Kofler From razvan.vilt at linux360.ro Wed Dec 5 18:05:00 2007 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. VILT) Date: Wed, 05 Dec 2007 20:05:00 +0200 Subject: Sun releases APOC In-Reply-To: <1196777808.17681.19.camel@localhost.localdomain> References: <1196727888.2814.17.camel@fedora.buh.htpassport.net> <1196777808.17681.19.camel@localhost.localdomain> Message-ID: <1196877900.10301.0.camel@fedora.buh.htpassport.net> Simo Sorce wrote: > On Tue, 2007-12-04 at 02:24 +0200, Razvan Corneliu C.R. VILT wrote: > > > While stuff released by Sun Microsystems is not really what fedora-devel > > is usually about, this little piece of technology, with a design simple > > enough for every admin to understand, does change a lot in enterprise > > deployment, and seems to be a natural complement to the FreeIPA project. > > > > It seem indeed a natural match ... now if it only didn't require one to > sign the SCA[1] before being able to contribute upstream :-( > > Simo. > > [1]: http://www.sun.com/software/opensource/contributor_agreement.jsp > Well. Just like with any other dual-licensed software, you can fork it, or sign the contributor agreement. I think that Zimbra, OO.o, OpenJDK, Netbeans and many others require (for acceptable reasons) a similar agreement. Considering the Red Hat/Sun relationship, I know it can go both ways. But in a worst case scenario (which I would be disappointed to see), a fork is acceptable. Cheers, Razvan From jkeating at redhat.com Wed Dec 5 18:04:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 13:04:19 -0500 Subject: Orphaning packages In-Reply-To: References: <41624.63.85.68.164.1196778852.squirrel@mail.jcomserv.net> <3170f42f0712042225i7a9dc166jed5e0c01acc5aa62@mail.gmail.com> <20071205104535.M45869@all-the-johnsons.co.uk> <20071205080402.7b00de21@redhat.com> Message-ID: <20071205130419.769c0185@redhat.com> On Wed, 5 Dec 2007 16:53:14 +0000 (UTC) Kevin Kofler wrote: > What about z88dk? That's also listed as owned by pfj, and I offered > to pick it up. 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 zcerza at redhat.com Wed Dec 5 18:17:02 2007 From: zcerza at redhat.com (Zack Cerza) Date: Wed, 05 Dec 2007 13:17:02 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205101041.2c5840cb@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> Message-ID: <4756EB1E.3050801@redhat.com> Jesse Keating wrote: > On Wed, 05 Dec 2007 09:29:41 -0500 > John Dennis wrote: > >> Linux has been mostly immune to malware. For anyone writing malware >> one of the challenges is propagating the infected code. >> >> So lets not give bad folks the perfect vehicle for distributing their >> malware through an official update channel which automatically gets >> pushed to tens of thousands of machines with the implication of being >> clean software. Such an event would be devastating to the entire open >> source community. >> >> If one doesn't think this is going to happen or you think the >> ultimate consequences for open source adoption would be benign then I >> have a bridge I'd like to sell you. >> >> Also, if you think the bar to getting a Fedora account is so high as >> to make this unlikely then you've forgotten that anyone with enough >> software savvy to write malware would view that hurdle as a house of >> straw. >> >> If you think there aren't plenty of folks the world over just waiting >> for their 15 minutes of hacker fame or who have a desire to teach >> RedHat/Fedora a lesson then I can offer you a discount on that bridge. >> >> Do we need a better mechanism for accepting contributions from the >> community, probably. Are open commit lists the answer, no. >> >> If you think the problem would be mitigated by package maintainers >> rigorously reviewing all changes *after* they've been committed >> you're forgetting human nature and the fact most maintainers are over >> worked to begin with. By extension if you demand maintainers review >> every commit then how is that effectively different than the current >> process of posting a patch in a bugzilla and asking the maintainer to >> review it before committing it? > > And if you think we're the first Linux distro of any size to have wider > access to our software source control you're also mistaken. We're not > paving new ground here. > > Debian has NMUs which allow for a Debian maintainer other than the > package owner to upload new builds of a package for various reasons: > http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Only Debian Developers can do NMUs. Last I checked the process of becoming a Debian Developer was roughly an order of magnitude more rigorous than ours (and possibly to the extent of being beyond reason). Can't comment on the rest of the distros. Zack From jkeating at redhat.com Wed Dec 5 18:39:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 13:39:09 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <4756EB1E.3050801@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756EB1E.3050801@redhat.com> Message-ID: <20071205133909.09a9c2ce@redhat.com> On Wed, 05 Dec 2007 13:17:02 -0500 Zack Cerza wrote: > Only Debian Developers can do NMUs. Right, we're not talking about just having anonymous cvs commit access. You'd have to be a Fedora developer. -- 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 Dec 5 18:53:22 2007 From: zcerza at redhat.com (Zack Cerza) Date: Wed, 05 Dec 2007 13:53:22 -0500 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205133909.09a9c2ce@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756EB1E.3050801@redhat.com> <20071205133909.09a9c2ce@redhat.com> Message-ID: <4756F3A2.7020103@redhat.com> Jesse Keating wrote: > On Wed, 05 Dec 2007 13:17:02 -0500 > Zack Cerza wrote: > >> Only Debian Developers can do NMUs. > > Right, we're not talking about just having anonymous cvs commit > access. You'd have to be a Fedora developer. Sure, I'm just pointing out that it's easier to get access to Fedora than to Debian. From loupgaroublond at gmail.com Wed Dec 5 18:58:47 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 5 Dec 2007 13:58:47 -0500 Subject: Package alien In-Reply-To: <4756CFA1.8050605@redhat.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> Message-ID: <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> On Dec 5, 2007 11:19 AM, Zdenek Prikryl wrote: > Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't > problem. But reverse conversion is big problem. For example, if I want to > convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are > debian packages for creating deb files. All of those packages aren't in fedora > repos. Debian has the inverse, namely, it has all the packages to create RPMs. +1 if the ability to turn RPMs into DEBs show up. It could make getting multi-distro support for Smolt easier. -Yaakov From kwade at redhat.com Wed Dec 5 18:59:31 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 05 Dec 2007 10:59:31 -0800 Subject: summer coding for 2008 Message-ID: <1196881171.25124.24.camel@erato.phig.org> The page for ideas for Fedora projects that interns and summer coding students can tackle is now open: http://fedoraproject.org/wiki/SummerOfCode/2008/Ideas "Good ye gods, Karsten, it's December, why are you worried about that now?" Glad you asked. Fedora got a much smaller number of student slots last year compared to projects of a similar or much smaller size. The GSoC team responds when you have lots of good proposals from students by giving you more slots. We didn't have good ideas out early, we didn't do much publicity early, and students didn't get many proposals in. So, the more ideas on that page, the better. Work can actually happen on an upstream project, through Fedora, if it brings benefits to Fedora. (We did this with Moin Moin the last two years, as well as GNOME's Damned Lies this last year.) Is there anyone interested in helping to coordinate idea creation for the various intern programs we can be part of? Remember that although some programs require students to work on solo coding projects, they can be modular parts of a greater whole. Students can also come from within the existing communities. Depending on interest, we'll probably hold a BarCamp and/or a hackfest session on this topic at FUDCon. The goal is to be prepared and loud about it, so when Google opens the proposal doors in the Spring(?), Fedora is more than ready. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 Dec 5 20:36:51 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 5 Dec 2007 15:36:51 -0500 Subject: Device ownership/permissions In-Reply-To: <4756D5D9.6040904@cora.nwra.com> References: <4756D5D9.6040904@cora.nwra.com> Message-ID: <20071205203651.GH30509@psilocybe.teonanacatl.org> Orion Poplawski wrote: > What system is responsible for changing device ownership/permissions > in fedora when a user logs in on Fedora 8? We're trying to figure > out a problem that is causing pulseaudio not to run with latest > testing updates > (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think it > may be a problem with hal-acl-tool, but I really have no clue. One report[1] blames pilot-link-0.12.2-9 for this. Someone in #fedora confirmed that backing that update out and restarting fixed things. The pilot-link changelog does have this: * Tue Nov 27 2007 Ivana Varekova - 2:0.12.2-9 - Install hal and PoliceKit rules (#280251) put visor to blacklist patch by Harald Hoyer - thanks, thanks Alex Lancaster I'm not sure if that's the problem, but it wouldn't be the first time the pilot-link package completely borked things totally unrelated to it[2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=411321#c7 [2] https://bugzilla.redhat.com/show_bug.cgi?id=238239 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hats off and applause to rogues and revolution! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jon.nettleton at gmail.com Wed Dec 5 20:46:35 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 05 Dec 2007 15:46:35 -0500 Subject: Device ownership/permissions In-Reply-To: <20071205203651.GH30509@psilocybe.teonanacatl.org> References: <4756D5D9.6040904@cora.nwra.com> <20071205203651.GH30509@psilocybe.teonanacatl.org> Message-ID: <1196887595.13721.51.camel@birkoff.charles.net> On Wed, 2007-12-05 at 15:36 -0500, Todd Zullinger wrote: > Orion Poplawski wrote: > > What system is responsible for changing device ownership/permissions > > in fedora when a user logs in on Fedora 8? We're trying to figure > > out a problem that is causing pulseaudio not to run with latest > > testing updates > > (https://bugzilla.redhat.com/show_bug.cgi?id=411071). I'm think it > > may be a problem with hal-acl-tool, but I really have no clue. > > One report[1] blames pilot-link-0.12.2-9 for this. Someone in #fedora > confirmed that backing that update out and restarting fixed things. > > The pilot-link changelog does have this: > > * Tue Nov 27 2007 Ivana Varekova - 2:0.12.2-9 > - Install hal and PoliceKit rules (#280251) > put visor to blacklist > patch by Harald Hoyer - thanks, thanks Alex Lancaster > > I'm not sure if that's the problem, but it wouldn't be the first time > the pilot-link package completely borked things totally unrelated to > it[2]. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=411321#c7 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=238239 > Thats the problem. Thanks Jon From buildsys at fedoraproject.org Wed Dec 5 20:48:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 5 Dec 2007 15:48:38 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-05 Message-ID: <20071205204838.CF66415212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 4 BackupPC-3.1.0-1.fc6 glpi-0.70-0.4.rc3.fc6 mcabber-0.9.5-1.fc6 vala-0.1.5-4.fc6 Changes in Fedora Extras 6: BackupPC-3.1.0-1.fc6 -------------------- * Thu Nov 29 2007 Johan Cwiklinski 3.1.0-1 - New upstream version - Added samba-client as a dependency - Added readme.fedora - Changed CGI admin path in default config file * Fri Sep 21 2007 Johan Cwiklinski 3.0.0-3 - Fixed SELinux policy module glpi-0.70-0.4.rc3.fc6 --------------------- * Fri Nov 16 2007 Remi Collet - 0.70-0.4.rc3 - Release Candidate 3 mcabber-0.9.5-1.fc6 ------------------- * Tue Nov 27 2007 Paul Wouters - 0.9.5-1 - Upgraded to the latest release. - Enable Off-The-Record support vala-0.1.5-4.fc6 ---------------- * Tue Dec 04 2007 Michel Salim - 0.1.5-4 - Backport patch to autodetect location of automake shared files * Tue Dec 04 2007 Michel Salim - 0.1.5-3 - Add build dependency on gtk2-devel * Tue Dec 04 2007 Michel Salim - 0.1.5-2 - Enable project generator tool * Tue Nov 27 2007 Michel Salim - 0.1.5-1 - Update to 0.1.5 * Sun Nov 11 2007 Michel Salim - 0.1.4-2 - Add build dependency on devhelp * Fri Oct 19 2007 Michel Salim - 0.1.4-1 - Update to 0.1.4 - Put newly-added documentation in its own subpackage (depends on devhelp) * Mon Sep 17 2007 Michel Salim - 0.1.3-5 - vapigen subpackage: add missing Require: on perl-XML-Twig * 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 * 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 * Sun Mar 25 2007 Michel Salim - 0.0.8-1 - Update to 0.0.8 * Wed Mar 07 2007 Michel Salim - 0.0.7-1 - Update to 0.0.7 * Wed Feb 28 2007 Michel Salim - 0.0.6-1 - Update to 0.0.6 From wolfy at nobugconsulting.ro Wed Dec 5 21:00:13 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 05 Dec 2007 23:00:13 +0200 Subject: About postfix dovecot and vmail In-Reply-To: <4756D71D.7080204@redhat.com> References: <698711.39639.qm@web32610.mail.mud.yahoo.com> <4756D71D.7080204@redhat.com> Message-ID: <4757115D.7090504@nobugconsulting.ro> On 12/05/2007 06:51 PM, Warren Togami wrote: > Nevruz Mesut Sahin wrote: >> Dear friend yesterday I rent a server AMD 64 which is installed >> fedora core 6 on the machine and apache 2.2.6, bind 9.3.4 MySQL >> 5.0.27, Postfix 2.4.5 dovecot 1.0.3, were installed on the >> machine. I configured apache bind and mysql successfully. But >> couldn't configured postfix and dovecot. I have more than 20 >> domains which I want to run on this server. to list services >> which are working on the server service --status-all I have >> written in the terminal and I got list below. would you please >> help me how can I configere mail server with virtual hosts. what is >> the best way for me. >> > > http://fedoraproject.org/wiki/PostIsOffTopic > This is not a user support list. Please take your question to a more > appropriate place like http://fedoraforum.org. > > Aside from this, I think in order to support virtual domains postfix > and dovecot need to be built against vpopmail. No, they do not need vpopmail. Both know how to talk directly with mysql. Further instructions are available via google, #fedora, or the proper mailing list. From walters at redhat.com Wed Dec 5 21:04:55 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 05 Dec 2007 16:04:55 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205172630.GB10961@nostromo.devel.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> Message-ID: <1196888695.2963.12.camel@space-ghost.verbum.private> On Wed, 2007-12-05 at 12:26 -0500, Bill Nottingham wrote: > > That's because it calls a magic function (res_init() or something) that > > means "really stat /etc/resolv.conf". Bottom line is that currently on > > Linux, if your application wants to work on roaming wireless networks, > > you need to > > *stat*? Don't we have inotify these days? I don't know whether an inotify-based approach would be accepted by the glibc maintainers. Might be worth trying. I have heard that glibc goes out of its way not to have any internal file descriptors, but inotify would require one. I'm not sure how glibc would even use it without creating an internal thread or something. I think the solution is going to be to require the OS to have a caching nameserver on localhost (i.e. /etc/resolv.conf is always 127.0.0.1), and for NetworkManager to control that nameserver in some way. If BIND is dropping support for configuring itself (i.e. it doesn't want to be a usable caching nameserver for roaming laptops), then dnsmasq may be what we need to use. From roland at redhat.com Wed Dec 5 21:13:31 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 5 Dec 2007 13:13:31 -0800 (PST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: Colin Walters's message of Wednesday, 5 December 2007 16:04:55 -0500 <1196888695.2963.12.camel@space-ghost.verbum.private> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> Message-ID: <20071205211331.23DD826F8EA@magilla.localdomain> Or just enable nscd and do nscd -i as needed. From ssorce at redhat.com Wed Dec 5 21:38:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Dec 2007 16:38:58 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196888695.2963.12.camel@space-ghost.verbum.private> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> Message-ID: <1196890738.17277.22.camel@localhost.localdomain> On Wed, 2007-12-05 at 16:04 -0500, Colin Walters wrote: > On Wed, 2007-12-05 at 12:26 -0500, Bill Nottingham wrote: > > > That's because it calls a magic function (res_init() or something) that > > > means "really stat /etc/resolv.conf". Bottom line is that currently on > > > Linux, if your application wants to work on roaming wireless networks, > > > you need to > > > > *stat*? Don't we have inotify these days? > > I don't know whether an inotify-based approach would be accepted by the > glibc maintainers. Might be worth trying. I have heard that glibc goes > out of its way not to have any internal file descriptors, but inotify > would require one. I'm not sure how glibc would even use it without > creating an internal thread or something. > > I think the solution is going to be to require the OS to have a caching > nameserver on localhost (i.e. /etc/resolv.conf is always 127.0.0.1), and > for NetworkManager to control that nameserver in some way. If BIND is > dropping support for configuring itself (i.e. it doesn't want to be a > usable caching nameserver for roaming laptops), then dnsmasq may be what > we need to use. The chaching nameserver is definitely the way to go imo. It also would make it possible to do many other things like querying a different name server based on the request. For example I'd like to query my corporate domain server (over the vpn) buy only for domain names that end in my.corp.com and use my ISP for anything else. This could *easily* be accomplished by a NM savvy caching name server that get notified about dhcp/vpn parameters from network manager. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From ville.skytta at iki.fi Wed Dec 5 21:45:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 5 Dec 2007 23:45:08 +0200 Subject: mock 0.8.9 In-Reply-To: <20071204234155.GC31195@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> Message-ID: <200712052345.08477.ville.skytta@iki.fi> On Wednesday 05 December 2007, Michael E Brown wrote: > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > Okay, here's another set of patches to implement --with{,out} options. > > I used git-format-patch this time, and probably did it awkwardly. But > > hopefully not too badly. Just in case (and for non-git users), I'll > > also attach a single diff that should apply cleanly to mock-0.8.14. > > > > Comments and improvements welcome. :) > > This looks great to me. I've committed this to the repo. Thanks, guys! When there's a mock release out with these changes (assuming they work :)), I think mock has finally caught up with essential features in mach and I'm ready to start using mock. From tmz at pobox.com Wed Dec 5 21:55:15 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 5 Dec 2007 16:55:15 -0500 Subject: mock 0.8.9 In-Reply-To: <200712052345.08477.ville.skytta@iki.fi> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> Message-ID: <20071205215515.GI30509@psilocybe.teonanacatl.org> Ville Skytt? wrote: > Thanks, guys! When there's a mock release out with these changes > (assuming they work :)), I think mock has finally caught up with > essential features in mach and I'm ready to start using mock. They'll be in 0.8.15, which I believe Michael plans to release sometime next week. Yell at me if the define/with options don't work. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Why does a slight tax increase cost you two hundred dollars and a substantial tax cut save you thirty cents? -- Peg Bracken -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From promac at gmail.com Wed Dec 5 21:56:11 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 5 Dec 2007 19:56:11 -0200 Subject: mock 0.8.9 In-Reply-To: <200712052345.08477.ville.skytta@iki.fi> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> Message-ID: <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> On Dec 5, 2007 7:45 PM, Ville Skytt? wrote: > On Wednesday 05 December 2007, Michael E Brown wrote: > > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > > Okay, here's another set of patches to implement --with{,out} options. > > > I used git-format-patch this time, and probably did it awkwardly. But > > > hopefully not too badly. Just in case (and for non-git users), I'll > > > also attach a single diff that should apply cleanly to mock-0.8.14. > > > > > > Comments and improvements welcome. :) > > > > This looks great to me. I've committed this to the repo. > > Thanks, guys! When there's a mock release out with these changes > (assuming > they work :)), I think mock has finally caught up with essential features > in > mach and I'm ready to start using mock. > > > The only issue I have so far is during init: mock -r fedora-7-i386 init INFO: mock.py version 0.8.14 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled root cache State Changed: running yum ERROR: Command failed. See logs for output. # mount -n --bind /home/mock/cache/fedora-7-i386/yum_cache/ /home/mock/fedora-7-i386/root/var/cache/yum But if the chroot is already initialized by a previous mock version, them everything goes fine. I have an updated mock rpm if anyone else is willing to try it. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Wed Dec 5 22:02:54 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Dec 2007 23:02:54 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196890738.17277.22.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> Message-ID: <200712052302.59534.opensource@till.name> On Mi Dezember 5 2007, Simo Sorce wrote: > For example I'd like to query my corporate domain server (over the vpn) > buy only for domain names that end in my.corp.com and use my ISP for > anything else. Btw. dnsmasq allows you to restrict nameservers on domains, i.e. specify a domain for which a nameserver should be asked. But a different question: How do you handle reverse dns lookups for the internal ip (vpn) addresses, are they forwarded to the ISP dns, too? Or do you prevent this somehow? 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 roland at redhat.com Wed Dec 5 22:05:46 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 5 Dec 2007 14:05:46 -0800 (PST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: Till Maas's message of Wednesday, 5 December 2007 23:02:54 +0100 <200712052302.59534.opensource@till.name> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> Message-ID: <20071205220546.EF84326F8EA@magilla.localdomain> > Btw. dnsmasq allows you to restrict nameservers on domains, i.e. specify a > domain for which a nameserver should be asked. But a different question: How > do you handle reverse dns lookups for the internal ip (vpn) addresses, are > they forwarded to the ISP dns, too? Or do you prevent this somehow? Those are just more zones you want to be forwards in the "inside" view. They are even easier to configure automagically, because you just do all the zones for the subnets that are being routed through the VPN connection. From ssorce at redhat.com Wed Dec 5 22:36:21 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Dec 2007 17:36:21 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <200712052302.59534.opensource@till.name> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> Message-ID: <1196894181.17277.31.camel@localhost.localdomain> On Wed, 2007-12-05 at 23:02 +0100, Till Maas wrote: > On Mi Dezember 5 2007, Simo Sorce wrote: > > > For example I'd like to query my corporate domain server (over the vpn) > > buy only for domain names that end in my.corp.com and use my ISP for > > anything else. > > Btw. dnsmasq allows you to restrict nameservers on domains, i.e. specify a > domain for which a nameserver should be asked. But a different question: How > do you handle reverse dns lookups for the internal ip (vpn) addresses, are > they forwarded to the ISP dns, too? Or do you prevent this somehow? This is where integration with nm would make it good, it could get the list of IPs being routed through the vpn and use the vpn provided nameserver from those. (you can also do it by interpreting the routing tables wrt the virtual interface used). Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From cmadams at hiwaay.net Wed Dec 5 22:43:27 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Dec 2007 16:43:27 -0600 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205211331.23DD826F8EA@magilla.localdomain> References: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <20071205211331.23DD826F8EA@magilla.localdomain> Message-ID: <20071205224327.GB1415619@hiwaay.net> Once upon a time, Roland McGrath said: > Or just enable nscd and do nscd -i as needed. nscd ignores TTLs (which can be a problem when accessing sites with low TTLs). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From roland at redhat.com Wed Dec 5 22:47:43 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 5 Dec 2007 14:47:43 -0800 (PST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: Chris Adams's message of Wednesday, 5 December 2007 16:43:27 -0600 <20071205224327.GB1415619@hiwaay.net> References: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <20071205211331.23DD826F8EA@magilla.localdomain> <20071205224327.GB1415619@hiwaay.net> Message-ID: <20071205224743.8903626F8EA@magilla.localdomain> > nscd ignores TTLs (which can be a problem when accessing sites with low > TTLs). That will probably be resolved before F9. From dcbw at redhat.com Wed Dec 5 22:53:03 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Dec 2007 17:53:03 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205220546.EF84326F8EA@magilla.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <20071205220546.EF84326F8EA@magilla.localdomain> Message-ID: <1196895183.14901.13.camel@localhost.localdomain> On Wed, 2007-12-05 at 14:05 -0800, Roland McGrath wrote: > > Btw. dnsmasq allows you to restrict nameservers on domains, i.e. specify a > > domain for which a nameserver should be asked. But a different question: How > > do you handle reverse dns lookups for the internal ip (vpn) addresses, are > > they forwarded to the ISP dns, too? Or do you prevent this somehow? > > Those are just more zones you want to be forwards in the "inside" view. > They are even easier to configure automagically, because you just do all > the zones for the subnets that are being routed through the VPN connection. I think this was one argument against using nscd exclusively and moving to a caching nameserver, because /etc/resolv.conf can't support split DNS. How does one do split DNS with nscd? Dan From tjanouse at redhat.com Wed Dec 5 23:07:01 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Thu, 6 Dec 2007 00:07:01 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196863948.4124.8.camel@space-ghost.verbum.private> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> Message-ID: <20071205230701.GA16753@redhat.com> Hi, On Wed, Dec 05, 2007 at 09:12:28AM -0500, Colin Walters wrote: > 2) Know that you have to call res_init() in response to that signal > > Ideally we wouldn't have 2), but that's the state of things now. I do in no way want to start any distro flame or something, but just in case any of you didn't notice, I'd like to add that Debian has been in this "ideally" state for some time. They have a glibc patch that stats resolv.conf every time a resolving function is called. The resolv.conf file is managed by the resolvconf program and it's kept somewhere in /dev/shm. And, well, it simply works, all the time. -- TJ. (Brno, CZ), BaseOS, Red Hat From roland at redhat.com Wed Dec 5 23:16:49 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 5 Dec 2007 15:16:49 -0800 (PST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: Dan Williams's message of Wednesday, 5 December 2007 17:53:03 -0500 <1196895183.14901.13.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <20071205220546.EF84326F8EA@magilla.localdomain> <1196895183.14901.13.camel@localhost.localdomain> Message-ID: <20071205231649.8BFBD26F8EA@magilla.localdomain> > I think this was one argument against using nscd exclusively and moving > to a caching nameserver, because /etc/resolv.conf can't support split > DNS. How does one do split DNS with nscd? It doesn't do that. nscd -i is just a simple idea for making resolv.conf reloading easy. A fancy solution with a local DNS server of some variety is better if it has nice configuration features. From david at fubar.dk Wed Dec 5 23:18:23 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 05 Dec 2007 18:18:23 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205231649.8BFBD26F8EA@magilla.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <20071205220546.EF84326F8EA@magilla.localdomain> <1196895183.14901.13.camel@localhost.localdomain> <20071205231649.8BFBD26F8EA@magilla.localdomain> Message-ID: <1196896703.15715.35.camel@oneill.fubar.dk> On Wed, 2007-12-05 at 15:16 -0800, Roland McGrath wrote: > > I think this was one argument against using nscd exclusively and moving > > to a caching nameserver, because /etc/resolv.conf can't support split > > DNS. How does one do split DNS with nscd? > > It doesn't do that. nscd -i is just a simple idea for making resolv.conf > reloading easy. A fancy solution with a local DNS server of some variety > is better if it has nice configuration features. As VPN is fairly common these days on desktops; any chance that nscd can grow such an interface? It really doesn't have to be more complicated than, for example, NetworkManager poking it to say "for *.redhat.com use these nameservers". Running a full DNS server on a simple desktop seems like, well, a lot of overhead not to mention security concerns... David From bpepple at fedoraproject.org Wed Dec 5 23:28:35 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Dec 2007 18:28:35 -0500 Subject: FESCo Meeting Summary for 2007-11-29 Message-ID: <1196897315.14655.5.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Jeremy Katz (jeremy) * David Woodhouse (dwmw2) * Christian Iseli (c4chris) * Kevin Fenzi (nirik) * Tom Callaway (spot) * Josh Boyer (jwb) = Members Absent = * Christopher Aillon (caillon) == Summary == === FPC Fonts Policy === * FESCo approved the Fedora Packaging Committee's proposed fonts policy. http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy === Using Matt Domsch's "doesn't rebuild" bugs as AWOL detection === * FESCo though this was a good idea to pursue, and f13 is going to work on a proposal. === When to drop orphan packages === * Packages that are orphaned during a release, will be dropped one month after that release. Ex. packages orphaned during F7 will be dropped from Rawhide one month after F8 is released. === More frequent conflicts testing, with bugs filed === * FESCo thought this was a good idea, and f13 will work on this along with his rebuild proposal. === F9 Feature Process === * FESCo approved the following features for F9: * http://fedoraproject.org/wiki/Releases/FeaturePresto * http://fedoraproject.org/wiki/Releases/FeatureKDE4 * http://fedoraproject.org/wiki/Features/OneSecondX * http://fedoraproject.org/wiki/Features/ServerProvides * http://fedoraproject.org/wiki/Features/XserverOnePointFive === Misc === * FESCo denied a request for xfce4-modemlights-plugin to have a F6 branch created, since F6 goes EOL in a little over a week, IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2007-11-29.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 roland at redhat.com Wed Dec 5 23:32:58 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 5 Dec 2007 15:32:58 -0800 (PST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: David Zeuthen's message of Wednesday, 5 December 2007 18:18:23 -0500 <1196896703.15715.35.camel@oneill.fubar.dk> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <20071205220546.EF84326F8EA@magilla.localdomain> <1196895183.14901.13.camel@localhost.localdomain> <20071205231649.8BFBD26F8EA@magilla.localdomain> <1196896703.15715.35.camel@oneill.fubar.dk> Message-ID: <20071205233258.B79AA26F8EA@magilla.localdomain> > As VPN is fairly common these days on desktops; any chance that nscd can > grow such an interface? It really doesn't have to be more complicated > than, for example, NetworkManager poking it to say "for *.redhat.com use > these nameservers". That is not really what nscd is for. It's really just for caching (and not only for network things). > Running a full DNS server on a simple desktop seems like, well, a lot of > overhead not to mention security concerns... dnsmasq and the like are not "a full DNS server". Something like that designed specifically for this limited use seems like the right way to go. Another option is to write a configurable proxy server using a simpler protocol, a la lwresd. Implement an nsswitch client module and then you can use it either via nscd or directly. It's up to the implementors to decide if a private protocol is better or worse than just using DNS protocol. From ngompa13 at gmail.com Thu Dec 6 00:51:44 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 5 Dec 2007 18:51:44 -0600 Subject: Package alien In-Reply-To: <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> Message-ID: <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> Though, will dpkg and the like be purposely crippled on Fedora like rpm is on Debian systems? It probably would be a good idea to patch dpkg and stuff to make sure they don't work as standard packagers, but rather just helpers to alien, as RPM does on a Debian system. We want to avoid the possibility of package jumbling..... On Dec 5, 2007 12:58 PM, Yaakov Nemoy wrote: > On Dec 5, 2007 11:19 AM, Zdenek Prikryl wrote: > > Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't > > problem. But reverse conversion is big problem. For example, if I want to > > convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are > > debian packages for creating deb files. All of those packages aren't in fedora > > repos. > > Debian has the inverse, namely, it has all the packages to create RPMs. > > +1 if the ability to turn RPMs into DEBs show up. It could make > getting multi-distro support for Smolt easier. > > -Yaakov > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From florin at andrei.myip.org Thu Dec 6 01:17:32 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 05 Dec 2007 17:17:32 -0800 Subject: inotify-aware tail replacement Message-ID: <47574DAC.3060807@andrei.myip.org> http://distanz.ch/inotail/ It's pretty cool. I use it all the time instead of the classic "tail -f", it gives a much better idea about how the file is actually updated, especially for things like /var/log/maillog on a relatively busy server. I made a spec file and a couple packages, one for RHEL 5 x86_64, the other for Fedora 7 i386, you can find them here: http://florin.myip.org/inotail/ If anyone wants to take over the package and include it in Fedora, that would be great. I can't go through the process of becoming a developer to submit the package myself, it's way too complicated and I have almost no time to spare these days. Thanks, -- Florin Andrei http://florin.myip.org/ From pertusus at free.fr Thu Dec 6 01:23:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 6 Dec 2007 02:23:12 +0100 Subject: Package alien In-Reply-To: <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> Message-ID: <20071206012311.GA6172@free.fr> On Wed, Dec 05, 2007 at 06:51:44PM -0600, King InuYasha wrote: > Though, will dpkg and the like be purposely crippled on Fedora like > rpm is on Debian systems? It probably would be a good idea to patch > dpkg and stuff to make sure they don't work as standard packagers, but > rather just helpers to alien, as RPM does on a Debian system. We want > to avoid the possibility of package jumbling..... I have tried and dpkg fails when launched as a package manager, so I think it is safe. Moreover it could be possible to use it to install in a chroot, so crippling it is a bad idea in my opinion. -- Pat From buytenh at wantstofly.org Thu Dec 6 02:20:53 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 6 Dec 2007 03:20:53 +0100 Subject: fedora cvs->git package metadata conversion available Message-ID: <20071206022053.GB18571@xi.wantstofly.org> Hi all, For some time now, I've been working on a git conversion of the Fedora package metadata (which lives in CVS.) I've made the results of that effort available via git:// at: git://fedora.gitbits.net/$pkgname And also via gitweb at: http://fedora.gitbits.net/ Since there are so many packages, only the ones starting with [0-9a] are displayed on the gitweb front page. All other packages' gitwebs can be accessed at URLs with the following format: http://fedora.gitbits.net/?p=$pkgname;a=summary There are two basic reasons why I've been working on this. 0. [ It provides a nice (changeset-based rather than per-file) way of viewing package history, and a couple of other nice features (see below.) ] 1. I have a need to maintain a set of patches to Fedora packages (for adding support for things such as cross-compilation) that will likely not soon or not ever be merged back into Fedora. To me, the most natural and easiest way of maintaining patches of that nature is to maintain them in a VCS that understands distributed operation and remote branches. 2. Over time, I would like to see the possibility for Fedora package metadata to be maintained in something other than CVS. I see this cvs->git conversion as a proof of concept, a way of allowing packagers to experiment with and gradually become familiar with a distributed VCS, and a way of demonstrating the advantages of this approach. Even if you are not interested in switching to a distributed VCS, and would like to keep maintaining your package with CVS, there are a couple of nice things you can do with this: - View package history as a series of commits: http://fedora.gitbits.net/?p=rpm;a=shortlog;h=devel - Viewing package history graphically: $ git clone git://fedora.gitbits.net/rpm $ cd rpm/ $ gitk origin/F-7 origin/F-8 origin/devel This gives you something a la (slightly outdated): http://www.wantstofly.org/~buytenh/fedora-git-rpm.png - Easily extract any random version of any package's metadata as a tar archive: $ git-archive --remote=git://fedora.gitbits.net/rpm rpm-4_4_2-14 > rpm-4_4_2-14.tar An example package maintainer workflow looks something like this: - Clone fedora rpm package: $ git clone git://fedora.gitbits.net/rpm Initialized empty Git repository in /home/buytenh/test/rpm/.git/ remote: Generating pack... remote: Done counting 1399 objects. remote: Deltifying 1399 objects... remote: 100% (1399/1399) done Indexing 1399 objects... remote: Total 1399 (delta 477), reused 1399 (delta 477) 100% (1399/1399) done Resolving 477 deltas... 100% (477/477) done $ (Note that at this point, you have a full copy of the package history on your local disk.) - Create your own branch based on the rawhide branch: $ cd rpm $ git-checkout -b mybranch origin/devel warning: You appear to be on a branch yet to be born. warning: Forcing checkout of origin/devel. Switched to a new branch "mybranch" $ - Make some local modification (e.g. require a newer version of patch): $ vi rpm.spec $ git diff diff --git a/rpm.spec b/rpm.spec index 3495e8a..ab289b2 100644 --- a/rpm.spec +++ b/rpm.spec @@ -6,7 +6,7 @@ Summary: The RPM package management system Name: rpm Version: 4.4.2.2 -Release: 11%{?dist} +Release: 12%{?dist} Group: System Environment/Base Url: http://www.rpm.org/ Source: http://rpm.org/releases/rpm-4.4.x/%{name}-%{version}.tar.gz @@ -107,7 +107,7 @@ Summary: Scripts and executable programs used to build packa Group: Development/Tools Requires: rpm = %{version}-%{release} Requires: elfutils >= 0.128 binutils -Requires: findutils sed grep gawk diffutils file patch >= 2.5 +Requires: findutils sed grep gawk diffutils file patch >= 4.5 Requires: zip gzip bzip2 cpio %description build $ - Commit changes to local branch: $ git add rpm.spec $ git commit Created commit bcd347c: Yo ho ho. 1 files changed, 2 insertions(+), 2 deletions(-) $ - Build SRPM from local branch (e.g. to build in mock): $ build-srpm 01:26:54 URL:http://cvs.fedora.redhat.com/repo/pkgs/rpm/rpm-4.4.2.2.tar.gz/15faa7ebd9791ade1a2f8181821ac259/rpm-4.4.2.2.tar.gz [11031970/11031970] -> "rpm-4.4.2.2.tar.gz" [1] Wrote: /home/buytenh/test/rpm/rpm-4.4.2.2-12.src.rpm $ - Decide that your modifications were crap, and throw everything you've done so far away and start from a fresh rawhide checkout: $ git-checkout -b mybranch2 origin/devel Switched to a new branch "mybranch2" $ git-branch -D mybranch Deleted branch mybranch. $ - Once you're happy with the result, generate a set of patches to commit back into the CVS tree: $ git-format-patch origin/devel 0001-Yo-ho-ho.patch $ (If the Fedora CVS server is ever switched over to git, all of the above steps would still look the same, except the last one (committing your changes back to the server), which would become a call to 'git-push'.) Since the git conversion is currently hosted on my ADSL line, please don't hammer it too hard -- although the git protocol _is_ pretty efficient, and the size of the entire set of git repositories is only about 550 megabytes and fits nicely in the RAM of the server it runs on, there's only about one megabit/s of upstream bandwidth available. Feedback appreciated! thanks, Lennert From seg at haxxed.com Thu Dec 6 02:27:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 05 Dec 2007 20:27:53 -0600 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196888695.2963.12.camel@space-ghost.verbum.private> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> Message-ID: <1196908073.26369.5.camel@localhost> On Wed, 2007-12-05 at 16:04 -0500, Colin Walters wrote: > I think the solution is going to be to require the OS to have a caching > nameserver on localhost (i.e. /etc/resolv.conf is always 127.0.0.1), and > for NetworkManager to control that nameserver in some way. If BIND is > dropping support for configuring itself (i.e. it doesn't want to be a > usable caching nameserver for roaming laptops), then dnsmasq may be what > we need to use. This is *exactly* what dnsmasq is designed for. From what I can tell, the author added dbus support to dnsmasq *specifically* so NetworkManager could use it. I'm not sure what's up with the disconnect 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 limb at jcomserv.net Thu Dec 6 03:28:51 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 5 Dec 2007 21:28:51 -0600 (CST) Subject: Mock/genchemlab/qt problem? Message-ID: <43339.192.168.0.1.1196911731.squirrel@mail.jcomserv.net> I recently updated genchemlab, and I only made a bit of a spec cleanup, and tried to rebuild for rawhide. It died due to the new desktop file image path name specification (no .png, for example). I fixed that, and tried a local mock build to test it to avoid wasting more koji time if it wasn't ready. Mock was pulling in the qt-devel BR correctly, but the build failed, saying it couldn't find the various qt header files required. When I built it from scratch locally (rpmbuild -ba genchemlab.spec), it was fine. When I then submitted the build to koji, it built normally as well. I looked in my mock root, and the qt headers were there. Am I missing something? Jon -- novus ordo absurdum From seg at haxxed.com Thu Dec 6 04:00:14 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 05 Dec 2007 22:00:14 -0600 Subject: Extreme memory usage for gnome-panel related apps In-Reply-To: <25398.192.54.193.53.1196857234.squirrel@rousalka.dyndns.org> References: <25398.192.54.193.53.1196857234.squirrel@rousalka.dyndns.org> Message-ID: <1196913614.26369.10.camel@localhost> On Wed, 2007-12-05 at 13:20 +0100, Nicolas Mailhot wrote: > Do you mean you're one of the lucky bastards that never saw evo > happily gurgle Gigs of memory? I just recently hit the bug where evolution's spellcheck goes nuts and starts rapidly eating all RAM until the machine dies. Hadn't seen it in a while but it would appear its still there. Fortunately I recognized it and managed to kill it off before the machine became completely unusable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Thu Dec 6 04:36:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Dec 2007 22:36:01 -0600 Subject: Mock/genchemlab/qt problem? References: <43339.192.168.0.1.1196911731.squirrel@mail.jcomserv.net> Message-ID: Jon Ciesla wrote: > Mock was pulling in the qt-devel BR correctly, but the build failed, > saying it couldn't find the various qt header files required. When I > built it from scratch locally (rpmbuild -ba genchemlab.spec), it was fine. > When I then submitted the build to koji, it built normally as well. I > looked in my mock root, and the qt headers were there. > > Am I missing something? recent versions of mock changed behavior wrt environment variables, see https://www.redhat.com/archives/fedora-buildsys-list/2007-December/msg00002.html to workaround that, you'll need to add something like this to your spec's %build section: unset QTDIR || : ; . /etc/profile.d/qt.sh -- Rex From mmaslano at redhat.com Thu Dec 6 07:37:45 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 06 Dec 2007 08:37:45 +0100 Subject: inotify-aware tail replacement In-Reply-To: <47574DAC.3060807@andrei.myip.org> References: <47574DAC.3060807@andrei.myip.org> Message-ID: <4757A6C9.8000601@redhat.com> > If anyone wants to take over the package and include it in Fedora, > that would be great. I can't go through the process of becoming a > developer to submit the package myself, it's way too complicated and I > have almost no time to spare these days. I'd like to take over them and push into Fedora. Marcela Maslanova From wolfy at nobugconsulting.ro Thu Dec 6 09:36:50 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 06 Dec 2007 11:36:50 +0200 Subject: inotify-aware tail replacement In-Reply-To: <4757A6C9.8000601@redhat.com> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> Message-ID: <4757C2B2.8070407@nobugconsulting.ro> Marcela Maslanova wrote: > >> If anyone wants to take over the package and include it in Fedora, >> that would be great. I can't go through the process of becoming a >> developer to submit the package myself, it's way too complicated and >> I have almost no time to spare these days. > I'd like to take over them and push into Fedora. > > Marcela Maslanova > That's a program I've packaged myself and I was going to suggest adding it inotify-tools. Marcela, if you submit the package I'll do the review. Note that it would be a good idea to patch the Makefile, it enforces certain compiling flags and installs in /usr/local (thus the usage of %makeinstall in Florin's spec) From mmaslano at redhat.com Thu Dec 6 09:42:33 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 06 Dec 2007 10:42:33 +0100 Subject: inotify-aware tail replacement In-Reply-To: <4757C2B2.8070407@nobugconsulting.ro> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> Message-ID: <4757C409.30508@redhat.com> Manuel Wolfshant wrote: > Marcela Maslanova wrote: >> >>> If anyone wants to take over the package and include it in Fedora, >>> that would be great. I can't go through the process of becoming a >>> developer to submit the package myself, it's way too complicated and >>> I have almost no time to spare these days. >> I'd like to take over them and push into Fedora. >> >> Marcela Maslanova >> > That's a program I've packaged myself and I was going to suggest > adding it inotify-tools. Marcela, if you submit the package I'll do > the review. > Note that it would be a good idea to patch the Makefile, it enforces > certain compiling flags and installs in /usr/local (thus the usage of > %makeinstall in Florin's spec) > I was thinking about pushing inotail into tail from coreutils like a patch, but if we have package inotify-tools that's even better. From tmraz at redhat.com Thu Dec 6 09:42:39 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 06 Dec 2007 10:42:39 +0100 Subject: inotify-aware tail replacement In-Reply-To: <4757C2B2.8070407@nobugconsulting.ro> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> Message-ID: <1196934159.24834.14.camel@vespa.kabelta.loc> On Thu, 2007-12-06 at 11:36 +0200, Manuel Wolfshant wrote: > Marcela Maslanova wrote: > > > >> If anyone wants to take over the package and include it in Fedora, > >> that would be great. I can't go through the process of becoming a > >> developer to submit the package myself, it's way too complicated and > >> I have almost no time to spare these days. > > I'd like to take over them and push into Fedora. > > > > Marcela Maslanova > > > That's a program I've packaged myself and I was going to suggest adding > it inotify-tools. Marcela, if you submit the package I'll do the review. > Note that it would be a good idea to patch the Makefile, it enforces > certain compiling flags and installs in /usr/local (thus the usage of > %makeinstall in Florin's spec) Even better idea would be to integrate inotify support into the regular tail from coreutils. Possibly with different option than -f if there is potential for breaking existing scripts or not if we can decide that moving from periodical polling to inotify shouldn't break anything. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dcbw at redhat.com Thu Dec 6 10:46:11 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 06 Dec 2007 05:46:11 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071205230701.GA16753@redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205230701.GA16753@redhat.com> Message-ID: <1196937971.3980.10.camel@localhost.localdomain> On Thu, 2007-12-06 at 00:07 +0100, Tomas Janousek wrote: > Hi, > > On Wed, Dec 05, 2007 at 09:12:28AM -0500, Colin Walters wrote: > > 2) Know that you have to call res_init() in response to that signal > > > > Ideally we wouldn't have 2), but that's the state of things now. > > I do in no way want to start any distro flame or something, but just in case > any of you didn't notice, I'd like to add that Debian has been in this > "ideally" state for some time. > > They have a glibc patch that stats resolv.conf every time a resolving function > is called. The resolv.conf file is managed by the resolvconf program and it's > kept somewhere in /dev/shm. And, well, it simply works, all the time. I tried to suggest that a few years ago but upstream glibc didn't want to do that, which I guess is fine. Maybe Fedora could just pick up that patch, or start using nscd again by default. Dan From buildsys at fedoraproject.org Thu Dec 6 11:03:34 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 6 Dec 2007 06:03:34 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-06 Message-ID: <20071206110334.73E3015212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 1 drupal-5.4-1.fc6 Changes in Fedora Extras 6: drupal-5.4-1.fc6 ---------------- * Wed Dec 05 2007 Jon Ciesla - 5.4-1 - Upgrade to 5.4, advisory ID DRUPAL-SA-2007-031. - Augmented README regarding symlinks, BZ 254228. From panemade at gmail.com Thu Dec 6 11:12:42 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Thu, 6 Dec 2007 16:42:42 +0530 Subject: inotify-aware tail replacement In-Reply-To: <4757C409.30508@redhat.com> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> <4757C409.30508@redhat.com> Message-ID: Hi, On Dec 6, 2007 3:12 PM, Marcela Maslanova wrote: > > > Manuel Wolfshant wrote: > > Marcela Maslanova wrote: > >> > >>> If anyone wants to take over the package and include it in Fedora, > >>> that would be great. I can't go through the process of becoming a > >>> developer to submit the package myself, it's way too complicated and > >>> I have almost no time to spare these days. > >> I'd like to take over them and push into Fedora. > >> > >> Marcela Maslanova > >> > > That's a program I've packaged myself and I was going to suggest > > adding it inotify-tools. Marcela, if you submit the package I'll do > > the review. > > Note that it would be a good idea to patch the Makefile, it enforces > > certain compiling flags and installs in /usr/local (thus the usage of > > %makeinstall in Florin's spec) > > > I was thinking about pushing inotail into tail from coreutils like a > patch, but if we have package inotify-tools that's even better. > Are you guys looking for this? https://bugzilla.redhat.com/show_bug.cgi?id=413321 Regards, Parag. From ndbecker2 at gmail.com Thu Dec 6 11:41:38 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 06 Dec 2007 06:41:38 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205230701.GA16753@redhat.com> <1196937971.3980.10.camel@localhost.localdomain> Message-ID: Dan Williams wrote: > On Thu, 2007-12-06 at 00:07 +0100, Tomas Janousek wrote: >> Hi, >> >> On Wed, Dec 05, 2007 at 09:12:28AM -0500, Colin Walters wrote: >> > 2) Know that you have to call res_init() in response to that signal >> > >> > Ideally we wouldn't have 2), but that's the state of things now. >> >> I do in no way want to start any distro flame or something, but just in >> case any of you didn't notice, I'd like to add that Debian has been in >> this "ideally" state for some time. >> >> They have a glibc patch that stats resolv.conf every time a resolving >> function is called. The resolv.conf file is managed by the resolvconf >> program and it's kept somewhere in /dev/shm. And, well, it simply works, >> all the time. > > I tried to suggest that a few years ago but upstream glibc didn't want > to do that, which I guess is fine. Maybe Fedora could just pick up that > patch, or start using nscd again by default. > I played with nscd but found it unsatisfactory. Problem was it happily kept stale cache results for machines on dhcp. I don't know if this is controllable, but if not, it seems pretty useless. From gemi at bluewin.ch Thu Dec 6 11:47:19 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 06 Dec 2007 12:47:19 +0100 Subject: Problems building pl (swi-prolog) on ppc64 Message-ID: <1196941639.6140.6.camel@localhost.localdomain> I have difficulties building pl on ppc64. The previous build (a few releases back) has been fine, and i386, x86_64, ppc are ok, too. The koji build page is: http://koji.fedoraproject.org/koji/taskinfo?taskID=278425 The 64-bit ppc arch seems to cause a lot of trouble compared to the 32-bit arch and x86_64. Is there any specific reason for this? In any case I hope someone can help fixing the issue. BTW. I would welcome a co-maintainer for the pl package, preferably someone with experience on archs other that i386. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From kevin.kofler at chello.at Thu Dec 6 11:57:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 6 Dec 2007 11:57:55 +0000 (UTC) Subject: Problems building pl (swi-prolog) on ppc64 References: <1196941639.6140.6.camel@localhost.localdomain> Message-ID: G?rard Milmeister bluewin.ch> writes: > I have difficulties building pl on ppc64. The previous build (a few > releases back) has been fine, and i386, x86_64, ppc are ok, too. The > koji build page is: > http://koji.fedoraproject.org/koji/taskinfo?taskID=278425 Judging by the warnings about aliasing violations, the first thing I'd try is adding -fno-strict-aliasing to the CFLAGS. Kevin Kofler From dcbw at redhat.com Thu Dec 6 11:54:19 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 06 Dec 2007 06:54:19 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205230701.GA16753@redhat.com> <1196937971.3980.10.camel@localhost.localdomain> Message-ID: <1196942059.5042.4.camel@localhost.localdomain> On Thu, 2007-12-06 at 06:41 -0500, Neal Becker wrote: > Dan Williams wrote: > > > On Thu, 2007-12-06 at 00:07 +0100, Tomas Janousek wrote: > >> Hi, > >> > >> On Wed, Dec 05, 2007 at 09:12:28AM -0500, Colin Walters wrote: > >> > 2) Know that you have to call res_init() in response to that signal > >> > > >> > Ideally we wouldn't have 2), but that's the state of things now. > >> > >> I do in no way want to start any distro flame or something, but just in > >> case any of you didn't notice, I'd like to add that Debian has been in > >> this "ideally" state for some time. > >> > >> They have a glibc patch that stats resolv.conf every time a resolving > >> function is called. The resolv.conf file is managed by the resolvconf > >> program and it's kept somewhere in /dev/shm. And, well, it simply works, > >> all the time. > > > > I tried to suggest that a few years ago but upstream glibc didn't want > > to do that, which I guess is fine. Maybe Fedora could just pick up that > > patch, or start using nscd again by default. > > > > I played with nscd but found it unsatisfactory. Problem was it happily kept > stale cache results for machines on dhcp. I don't know if this is > controllable, but if not, it seems pretty useless. I don't think it respects the DNS TTL or something like that. Dan From gemi at bluewin.ch Thu Dec 6 12:24:00 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 06 Dec 2007 13:24:00 +0100 Subject: Problems building pl (swi-prolog) on ppc64 In-Reply-To: References: <1196941639.6140.6.camel@localhost.localdomain> Message-ID: <1196943840.6140.8.camel@localhost.localdomain> On Thu, 2007-12-06 at 11:57 +0000, Kevin Kofler wrote: > Judging by the warnings about aliasing violations, the first thing I'd > try is > adding -fno-strict-aliasing to the CFLAGS. These warnings appear on all platforms, but only ppc64 segfaults. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From kevin.kofler at chello.at Thu Dec 6 12:39:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 6 Dec 2007 12:39:16 +0000 (UTC) Subject: firefox vs epiphany References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> Message-ID: David Nielsen lovesunix.net> writes: > I use Epiphany, it does what I need without looking out of place, it > integrates nicely and it launches much faster. It lacks a few things but > it also leverages a lot of nice features (seemless integration with > GNOME, adopts theme, icons. Has more consistent translations which don't > break with version upgrades) and it has a powerful plugin system so we > can expand it in interesting ways. I use Konqueror, for much of the same reasons, except s/GNOME/KDE/. :-) About plugins, Konqueror is more extensible than most people think (there's mechanisms available like KParts for file formats (as well as support for most Mozilla plugins), servicemenus to easily extend the UI (no C++ needed, they can launch commands in any scripting language which can talk back to Konqueror through DCOP, or D-Bus in KDE 4), KParts can also provide UI extensions (Konqueror's search bar is implemented that way), and the sidebar is also extensible with plugins), but unfortunately, those features aren't used much (except for the file format KParts). :-( But Konqueror has most features you may need built-in already, unlike Firefox which relies a lot on plugins. Kevin Kofler From kevin.kofler at chello.at Thu Dec 6 12:40:33 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 6 Dec 2007 12:40:33 +0000 (UTC) Subject: Problems building pl (swi-prolog) on ppc64 References: <1196941639.6140.6.camel@localhost.localdomain> <1196943840.6140.8.camel@localhost.localdomain> Message-ID: G?rard Milmeister bluewin.ch> writes: > These warnings appear on all platforms, but only ppc64 segfaults. This doesn't exclude an aliasing problem, aliasing bugs often only lead to actually invalid code on some architectures, it all depends on how the GCC optimizers process the code. Kevin Kofler From ndbecker2 at gmail.com Thu Dec 6 13:03:31 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 06 Dec 2007 08:03:31 -0500 Subject: Does libnetfilter_conntrack work with f8 kernels? Message-ID: Doesn't seem to work, any hint? sudo /sbin/modprobe -v ip_conntrack_netlink insmod /lib/modules/2.6.23.8-63.fc8/kernel/net/ipv4/netfilter/nf_nat.ko insmod /lib/modules/2.6.23.8-63.fc8/kernel/net/netfilter/nf_conntrack_netlink.ko [nbecker at nbecker1 l7-filter-userspace-v0.4]$ /usr/bin/l7-filter --help ***WARNING*** The ip_conntrack_netlink module does not appear to be loaded. Unless you have it compiled into your kernel, please load it and run l7-filter again. From rjones at redhat.com Thu Dec 6 13:12:10 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 06 Dec 2007 13:12:10 +0000 Subject: rawhide report: 20071203 changes In-Reply-To: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> Message-ID: <4757F52A.9070205@redhat.com> Don't seem to have had one of these reports for a few days now. Anything gone wrong? 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 caillon at redhat.com Thu Dec 6 13:16:00 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 06 Dec 2007 14:16:00 +0100 Subject: rawhide report: 20071203 changes In-Reply-To: <4757F52A.9070205@redhat.com> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> <4757F52A.9070205@redhat.com> Message-ID: <4757F610.2030207@redhat.com> On 12/06/2007 02:12 PM, Richard W.M. Jones wrote: > Don't seem to have had one of these reports for a few days now. Anything > gone wrong? openssl landed. :-) From pbrobinson at gmail.com Thu Dec 6 13:23:45 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 6 Dec 2007 13:23:45 +0000 Subject: rawhide report: 20071203 changes In-Reply-To: <4757F610.2030207@redhat.com> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> <4757F52A.9070205@redhat.com> <4757F610.2030207@redhat.com> Message-ID: <5256d0b0712060523y2ff30e49x547e776a83e4bf98@mail.gmail.com> > > Don't seem to have had one of these reports for a few days now. Anything > > gone wrong? > > openssl landed. :-) The reports are stilling coming out albeit rather large! Pete From jima at beer.tclug.org Thu Dec 6 13:25:43 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 6 Dec 2007 07:25:43 -0600 (CST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <200712052302.59534.opensource@till.name> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> Message-ID: Replying to a couple points in one email... On Wed, 5 Dec 2007, Colin Walters wrote: > If BIND is dropping support for configuring itself (i.e. it doesn't want > to be a usable caching nameserver for roaming laptops), then dnsmasq may > be what we need to use. Well, crap. I just became a lot more important, huh? On Wed, 5 Dec 2007, Till Maas wrote: > On Mi Dezember 5 2007, Simo Sorce wrote: > >> For example I'd like to query my corporate domain server (over the vpn) >> buy only for domain names that end in my.corp.com and use my ISP for >> anything else. > > Btw. dnsmasq allows you to restrict nameservers on domains, i.e. specify a > domain for which a nameserver should be asked. But a different question: How > do you handle reverse dns lookups for the internal ip (vpn) addresses, are > they forwarded to the ISP dns, too? Or do you prevent this somehow? Same way: server=/my.corp.com/0.0.10.in-addr.arpa/10.0.0.1 That makes dnsmasq look to 10.0.0.1 for both zones' records. On Wed, 5 Dec 2007, David Zeuthen wrote: > Running a full DNS server on a simple desktop seems like, well, a lot of > overhead not to mention security concerns... Have you *used* dnsmasq? As Roland said, it's not a full DNS server; it doesn't even do recursion (it depends on its upstream servers for that). As for security, I'm not hugely concerned if it's bound to 127.0.0.1. On Wed, 5 Dec 2007, Callum Lerwick wrote: > This is *exactly* what dnsmasq is designed for. From what I can tell, > the author added dbus support to dnsmasq *specifically* so > NetworkManager could use it. I'm not sure what's up with the disconnect > here. :) Maybe not NM specifically, but certainly conceptually: "Added method support for DBus (http://www.freedesktop.org/Software/dbus) This is a superior way to re-configure dnsmasq on-the-fly with different upstream nameservers, as the host moves between networks. DBus support must be enabled in src/config.h and should be considered experimental at this point. See DBus-interface for the specification of the DBus method calls supported." (And yes, I enabled dbus support the day I submitted dnsmasq for review. :-) Jima From aph at redhat.com Thu Dec 6 13:28:43 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Dec 2007 13:28:43 +0000 Subject: Problems building pl (swi-prolog) on ppc64 In-Reply-To: <1196943840.6140.8.camel@localhost.localdomain> References: <1196941639.6140.6.camel@localhost.localdomain> <1196943840.6140.8.camel@localhost.localdomain> Message-ID: <18263.63755.557790.397273@zebedee.pink> G?rard Milmeister writes: > On Thu, 2007-12-06 at 11:57 +0000, Kevin Kofler wrote: > > Judging by the warnings about aliasing violations, the first thing I'd > > try is > > adding -fno-strict-aliasing to the CFLAGS. > These warnings appear on all platforms, but only ppc64 segfaults. If you get any such warnings, your program is almost certainly broken. -fno-strict-aliasing is a way to get your program working until it's fixed. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From rjones at redhat.com Thu Dec 6 13:41:25 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 06 Dec 2007 13:41:25 +0000 Subject: rawhide report: 20071203 changes In-Reply-To: <5256d0b0712060523y2ff30e49x547e776a83e4bf98@mail.gmail.com> References: <200712031258.lB3Cw926005412@porkchop.devel.redhat.com> <4757F52A.9070205@redhat.com> <4757F610.2030207@redhat.com> <5256d0b0712060523y2ff30e49x547e776a83e4bf98@mail.gmail.com> Message-ID: <4757FC05.2050202@redhat.com> Peter Robinson wrote: >>> Don't seem to have had one of these reports for a few days now. Anything >>> gone wrong? >> openssl landed. :-) > > The reports are stilling coming out albeit rather large! Funny :-) Well at least I fixed my package ... 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 mcepl at redhat.com Thu Dec 6 13:59:55 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 06 Dec 2007 14:59:55 +0100 Subject: Proposal for Fedora - "GKSUDO" References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> Message-ID: On Tue, 04 Dec 2007 11:38:47 +0100, Patrice Dumas scripst: > Unless there is something special for these pieces of code, anybody can > submit those packages to fedora through the usual review process. Not sure, ask davidz, but I am afraid most of them will horribly clash with PolicyKit/ConsoleKit. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From ssorce at redhat.com Thu Dec 6 14:21:14 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Dec 2007 09:21:14 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196937971.3980.10.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205230701.GA16753@redhat.com> <1196937971.3980.10.camel@localhost.localdomain> Message-ID: <1196950874.17277.36.camel@localhost.localdomain> On Thu, 2007-12-06 at 05:46 -0500, Dan Williams wrote: > On Thu, 2007-12-06 at 00:07 +0100, Tomas Janousek wrote: > > Hi, > > > > On Wed, Dec 05, 2007 at 09:12:28AM -0500, Colin Walters wrote: > > > 2) Know that you have to call res_init() in response to that signal > > > > > > Ideally we wouldn't have 2), but that's the state of things now. > > > > I do in no way want to start any distro flame or something, but just in case > > any of you didn't notice, I'd like to add that Debian has been in this > > "ideally" state for some time. > > > > They have a glibc patch that stats resolv.conf every time a resolving function > > is called. The resolv.conf file is managed by the resolvconf program and it's > > kept somewhere in /dev/shm. And, well, it simply works, all the time. > > I tried to suggest that a few years ago but upstream glibc didn't want > to do that, which I guess is fine. Maybe Fedora could just pick up that > patch, or start using nscd again by default. nscd wont help much for the simple reason the libc interface is very poor and forced many application to directly query DNS instead. For these application nscd server no purpose at all, while a caching server (dnsmasq someone suggest is the perfect fit) works with any app as it works at the protocol level. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From gemi at bluewin.ch Thu Dec 6 14:44:43 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 06 Dec 2007 15:44:43 +0100 Subject: Problems building pl (swi-prolog) on ppc64 In-Reply-To: <18263.63755.557790.397273@zebedee.pink> References: <1196941639.6140.6.camel@localhost.localdomain> <1196943840.6140.8.camel@localhost.localdomain> <18263.63755.557790.397273@zebedee.pink> Message-ID: <1196952283.20431.0.camel@localhost.localdomain> On Thu, 2007-12-06 at 13:28 +0000, Andrew Haley wrote: > If you get any such warnings, your program is almost certainly broken. > -fno-strict-aliasing is a way to get your program working until it's > fixed. I just tried to build with -fno-strict-aliasing, there are no warnings now, but the problem on ppc64 remains. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From choeger at cs.tu-berlin.de Thu Dec 6 14:49:49 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 06 Dec 2007 15:49:49 +0100 Subject: networkmanager-openvpn dependencies Message-ID: <1196952589.3194.3.camel@choeger4> Hi, in fedora 8 nm-openvpn seems not to depend on openvpn itself and thus is pretty useless after installation. Can somebody fix this? regards christoph From jnovy at redhat.com Thu Dec 6 14:58:50 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 6 Dec 2007 15:58:50 +0100 Subject: teTeX is now retired and removed from rawhide Message-ID: <20071206145850.GA7826@dhcp-lab-186.brq.redhat.com> Hi all, teTeX was removed today to get rid of conflicts in the time of buildroot installation: http://koji.fedoraproject.org/koji/getfile?taskID=277871&name=root.log There is IMO no smooth way how to avoid the conflicts. And to finally obsolete teTeX is long planned goal, so if you have any problems/RFEs for TeXLive, please file a bug against rawhide component: texlive - if you found bug in binary TeXLive utilities texlive-texmf - if find anything related to fonts/styles, noarch part texlive-texmf-errata - if you need to update font/style set. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From dwalsh at redhat.com Thu Dec 6 15:33:27 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Dec 2007 10:33:27 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? Message-ID: <47581647.80801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't fully understand how you intend to use keying, but I have talked to Nalin about this, since he is about to allow or does allow the storing of the kerberos tgt in a kernel keyring. Currently pam_keyinit is happening in system-auth as well as most of the login pam modules. SELinux comes into play here, since we want to make sure the context on the keyring is set correctly. "pam_selinux open" sets the kernel to label the keyring with the users context, but in several places pam_keyinit is being called before pam_selinux (system-auth) is the culprit. This results in us having kernel keyrings labeled local_login_t or sshd_t. Which is wrong. They should be labeled user_t or unconfined_t. So I would suggest that we remove pam_keyinit from system_auth and only use it in login pam modules which call it after pam_selinux open. Now the next question is whether it should be called in su or sudo? Since wouldn't this remove access to my keying material? su and sudo do not call pam_selinux open, so it will not setup a labeling for pam_keyinit, and the keys will get created as user_sudo_t or user_su_t for example. At this point what access is expected by the user for these keyrings? Would you expect the keyrings to be labeled kernel_t, or should we remove the pam_keyinit from su and sudo, leaving access to the login keyrings. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHWBZHrlYvE4MpobMRApEUAJ9bBY9we50xJQpLAvNdIyKNrfNXrACg4qzm Rc3m/LwuNZ9f9zO5y1OsJM8= =CqG0 -----END PGP SIGNATURE----- From che666 at gmail.com Thu Dec 6 15:42:11 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 6 Dec 2007 16:42:11 +0100 Subject: firefox vs epiphany In-Reply-To: References: <1196625336.2547.4.camel@tiger> <1196631627.15639.10.camel@localhost.localdomain> <1196634513.2849.0.camel@sb-home> <1196635042.15639.14.camel@localhost.localdomain> <1196652884.982.6.camel@tuxhugs> <475384FB.7070809@mharris.ca> <1196656712.4386.9.camel@Watson.lovesunix.net> Message-ID: On Dec 6, 2007 1:39 PM, Kevin Kofler wrote: > David Nielsen lovesunix.net> writes: > > I use Epiphany, it does what I need without looking out of place, it > > integrates nicely and it launches much faster. It lacks a few things but > > it also leverages a lot of nice features (seemless integration with > > GNOME, adopts theme, icons. Has more consistent translations which don't > > break with version upgrades) and it has a powerful plugin system so we > > can expand it in interesting ways. > > I use Konqueror, for much of the same reasons, except s/GNOME/KDE/. :-) > > About plugins, Konqueror is more extensible than most people think (there's > mechanisms available like KParts for file formats (as well as support for most > Mozilla plugins), servicemenus to easily extend the UI (no C++ needed, they can > launch commands in any scripting language which can talk back to Konqueror > through DCOP, or D-Bus in KDE 4), KParts can also provide UI extensions > (Konqueror's search bar is implemented that way), and the sidebar is also > extensible with plugins), but unfortunately, those features aren't used much > (except for the file format KParts). :-( But Konqueror has most features you > may need built-in already, unlike Firefox which relies a lot on plugins. > > Kevin Kofler > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > One of the must fixes with epiphany is to get the name changed upstream. it conflicts with an older open source boulder dash clone. i mentioned the problem years ago already and actually it wasnt fixed yet the last few years. i am also stuck with galeon because it seems epiphany is trying hard but even after years still fails to offer the same functionality as galeon has (multi search boxes independent of each other... etc) and suffers from additional usability problems and a rather feature unresponsive upstream crowd (no offense... just not my philosophy). maybe it has less buttons and features enough for the gnome target audience but for advanced use cases it is definitely not the tool i use. kind regards, Rudolf Kastl p.s. i am curious if upstream cares about the name clash at all. question of attitude in my eyes. From dcbw at redhat.com Thu Dec 6 15:38:36 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 06 Dec 2007 10:38:36 -0500 Subject: networkmanager-openvpn dependencies In-Reply-To: <1196952589.3194.3.camel@choeger4> References: <1196952589.3194.3.camel@choeger4> Message-ID: <1196955516.25591.0.camel@localhost.localdomain> On Thu, 2007-12-06 at 15:49 +0100, Christoph H?ger wrote: > Hi, > > in fedora 8 nm-openvpn seems not to depend on openvpn itself and thus is > pretty useless after installation. > Can somebody fix this? Yeah, can you file a bug against NetworkManager-openvpn? If one doesn't come it I guess I can do it. Thanks, Dan From choeger at cs.tu-berlin.de Thu Dec 6 15:58:34 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 06 Dec 2007 16:58:34 +0100 Subject: networkmanager-openvpn dependencies In-Reply-To: <1196955516.25591.0.camel@localhost.localdomain> References: <1196952589.3194.3.camel@choeger4> <1196955516.25591.0.camel@localhost.localdomain> Message-ID: <1196956714.12249.1.camel@choeger4> Am Donnerstag, den 06.12.2007, 10:38 -0500 schrieb Dan Williams: > On Thu, 2007-12-06 at 15:49 +0100, Christoph H?ger wrote: > > Hi, > > > > in fedora 8 nm-openvpn seems not to depend on openvpn itself and thus is > > pretty useless after installation. > > Can somebody fix this? > > Yeah, can you file a bug against NetworkManager-openvpn? If one doesn't > come it I guess I can do it. > > Thanks, > Dan > > Sorry, forget about that. I had to install fedora 8 twice and forget to install nm-openvpn at all the second time. Silly me thought it would be there, because nm-applet showed VPN Options. christoph From limb at jcomserv.net Thu Dec 6 17:05:32 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 6 Dec 2007 11:05:32 -0600 (CST) Subject: Mock/genchemlab/qt problem? Message-ID: <3233.63.85.68.164.1196960732.squirrel@mail.jcomserv.net> > Jon Ciesla wrote: > >> Mock was pulling in the qt-devel BR correctly, but the build failed, >> saying it couldn't find the various qt header files required. When I >> built it from scratch locally (rpmbuild -ba genchemlab.spec), it was >> fine. >> When I then submitted the build to koji, it built normally as well. I >> looked in my mock root, and the qt headers were there. >> >> Am I missing something? > > recent versions of mock changed behavior wrt environment variables, see > https://www.redhat.com/archives/fedora-buildsys-list/2007-December/msg00002.html > > to workaround that, you'll need to add something like this to your > spec's %build section: > unset QTDIR || : ; . /etc/profile.d/qt.sh Thanks, worked beautifully! > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From ssorce at redhat.com Thu Dec 6 18:39:19 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Dec 2007 13:39:19 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <47581647.80801@redhat.com> References: <47581647.80801@redhat.com> Message-ID: <1196966359.17277.42.camel@localhost.localdomain> On Thu, 2007-12-06 at 10:33 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I don't fully understand how you intend to use keying, but I have talked > to Nalin about this, since he is about to allow or does allow the > storing of the kerberos tgt in a kernel keyring. > > Currently pam_keyinit is happening in system-auth as well as most of the > login pam modules. > > SELinux comes into play here, since we want to make sure the context on > the keyring is set correctly. "pam_selinux open" sets the kernel to > label the keyring with the users context, but in several places > pam_keyinit is being called before pam_selinux (system-auth) is the > culprit. > > This results in us having kernel keyrings labeled local_login_t or > sshd_t. Which is wrong. They should be labeled user_t or unconfined_t. > > So I would suggest that we remove pam_keyinit from system_auth and only > use it in login pam modules which call it after pam_selinux open. Make a lot of sense to me. > Now the next question is whether it should be called in su or sudo? > Since wouldn't this remove access to my keying material? Do you want sudo to really give you power over keying material? Usually sudo is used to run programs just with a higher privilege on the local machine, and never to obtain key material. I have the feeling that it is somehow wrong to give sudo that power. For su I am still uncertain, but given that su does not authenticate the final user but only the super user I again wonder if that should give any access to the kernel keyring. > su and sudo do not call pam_selinux open, so it will not setup a > labeling for pam_keyinit, and the keys will get created as user_sudo_t > or user_su_t for example. At this point what access is expected by the > user for these keyrings? Would you expect the keyrings to be labeled > kernel_t, or should we remove the pam_keyinit from su and sudo, leaving > access to the login keyrings. I think it is safer to not give su and sudo access to keyrings by default, is there a credible scenario that would require that and that cannot be accomplisced in another way? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From ssorce at redhat.com Thu Dec 6 20:19:18 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Dec 2007 15:19:18 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <21081.1196971368@redhat.com> References: <1196966359.17277.42.camel@localhost.localdomain> <47581647.80801@redhat.com> <21081.1196971368@redhat.com> Message-ID: <1196972358.21254.0.camel@localhost.localdomain> On Thu, 2007-12-06 at 20:02 +0000, David Howells wrote: > Simo Sorce wrote: > > > > Now the next question is whether it should be called in su or sudo? > > > Since wouldn't this remove access to my keying material? > > > > Do you want sudo to really give you power over keying material? > > Usually sudo is used to run programs just with a higher privilege on the > > local machine, and never to obtain key material. > > I think the question, really, is whether the sudo'd program should be able to > use your keys or not, for instance to access a file you've given it as an > argument. Are you thinking a setuid program here ? Or actually really a program run through sudo ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From atkac at redhat.com Thu Dec 6 20:41:16 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 6 Dec 2007 21:41:16 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196888695.2963.12.camel@space-ghost.verbum.private> References: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> Message-ID: <20071206204116.GA7130@traged.englab.brq.redhat.com> On Wed, Dec 05, 2007 at 04:04:55PM -0500, Colin Walters wrote: > I think the solution is going to be to require the OS to have a caching > nameserver on localhost (i.e. /etc/resolv.conf is always 127.0.0.1), and > for NetworkManager to control that nameserver in some way. If BIND is > dropping support for configuring itself (i.e. it doesn't want to be a > usable caching nameserver for roaming laptops), then dnsmasq may be what > we need to use. > Main problem with dnsmasq is that it doesn't support DNSSEC (I read that it supports only forwarding DNSSEC queries). Only named as caching nameserver could validate DNSSEC queries (point me if I'm not correct). Many people think that DNSSEC is useless. If I compare plain DNS and DNSSEC it is something like rsh vs. ssh. I'm interested how many people think ssh is useless. Use dnsmasq will be good for now but in the end We have to implement dynamic forwarders into named or DNSSEC into other server. I've already started thread about this topic in BIND upstream so I think We will find good compromise and solve this problem. Adam -- Adam Tkac, Red Hat, Inc. From tcallawa at redhat.com Thu Dec 6 20:46:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 07 Dec 2007 02:16:40 +0530 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <1196966359.17277.42.camel@localhost.localdomain> References: <47581647.80801@redhat.com> <1196966359.17277.42.camel@localhost.localdomain> Message-ID: <1196974000.4239.3.camel@localhost.localdomain> On Thu, 2007-12-06 at 13:39 -0500, Simo Sorce wrote: > I have the feeling that it is somehow wrong to give sudo that power. > For su I am still uncertain, but given that su does not authenticate > the > final user but only the super user I again wonder if that should give > any access to the kernel keyring. Maybe this is is an ignorant question, but wouldn't you want this for loading/unloading kernel modules via su -c / sudo? Thanks to the nature of iwl3945 and similar drivers, I have been known to execute commands like: $ sudo /sbin/modprobe -r iwl3945 $ sudo /sbin/modprobe iwl3945 I'd think that having proper access to the kernel keyring for ops like that would be ideal, if not necessary. I'm also concerned about when we start making sudo/su not act like the root user, with all rights and permissions, because really, that is the purpose of sudo / su, and one of the reasons that those commands require either root's credentials to use (su / sudo) and/or specific permission (sudoers). ~spot From fedora at camperquake.de Thu Dec 6 20:47:59 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 6 Dec 2007 21:47:59 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071206204116.GA7130@traged.englab.brq.redhat.com> References: <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <20071206204116.GA7130@traged.englab.brq.redhat.com> Message-ID: <20071206214759.2ff7283d@lain.camperquake.de> Hi. On Thu, 6 Dec 2007 21:41:16 +0100, Adam Tkac wrote > many people think ssh is useless. Use dnsmasq will be good for now but > in the end We have to implement dynamic forwarders into named or > DNSSEC into other server. I've already started thread about this topic > in BIND upstream so I think We will find good compromise and solve > this problem. Well, having to choose between "not working at all" and "not working for DNSSEC", I'll take the latter. From kzak at redhat.com Thu Dec 6 20:49:56 2007 From: kzak at redhat.com (Karel Zak) Date: Thu, 6 Dec 2007 21:49:56 +0100 Subject: inotify-aware tail replacement In-Reply-To: <1196934159.24834.14.camel@vespa.kabelta.loc> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> <1196934159.24834.14.camel@vespa.kabelta.loc> Message-ID: <20071206204956.GC13166@petra.dvoda.cz> On Thu, Dec 06, 2007 at 10:42:39AM +0100, Tomas Mraz wrote: > > On Thu, 2007-12-06 at 11:36 +0200, Manuel Wolfshant wrote: > > Marcela Maslanova wrote: > > > > > >> If anyone wants to take over the package and include it in Fedora, > > >> that would be great. I can't go through the process of becoming a > > >> developer to submit the package myself, it's way too complicated and > > >> I have almost no time to spare these days. > > > I'd like to take over them and push into Fedora. > > > > > > Marcela Maslanova > > > > > That's a program I've packaged myself and I was going to suggest adding > > it inotify-tools. Marcela, if you submit the package I'll do the review. > > Note that it would be a good idea to patch the Makefile, it enforces > > certain compiling flags and installs in /usr/local (thus the usage of > > %makeinstall in Florin's spec) > > Even better idea would be to integrate inotify support into the regular > tail from coreutils. Possibly with different option than -f if there is coreutils = portability; inotify = linux (>= 2.6.13) > potential for breaking existing scripts or not if we can decide that > moving from periodical polling to inotify shouldn't break anything. BTW, there is also tailf from util-linux[-ng]. The inotify support is on my wish list. Volunteers? ;-) Karel -- Karel Zak From david at fubar.dk Thu Dec 6 20:48:47 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 15:48:47 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <7f692fec0712031842g53967202l16bcebd1dc47b23e@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <7f692fec0712031842g53967202l16bcebd1dc47b23e@mail.gmail.com> Message-ID: <1196974127.17759.122.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 21:42 -0500, Yaakov Nemoy wrote: > On Dec 3, 2007 9:32 PM, masch wrote: > > Hi! > > Is it possible to include any utility link in Ubuntu gksu, gksudo, > > gnomesu or gnomesudo?? > > It's really usefully for some scripts We have consolehelper which is similar to graphical sudo helpers. > AFAIU (as far as i understand) PolicyKit is going to handle those > sorts of details. It's far more ideal, because then for some users, > they can never escalate their privileges, some users can only escalate > with a root password, and some with their own password. It's this > understanding that it will be here "any time soon" that's kept me from > complaining about the obvious lack of gksudo. PolicyKit actually been in the distro since F8. Granted for F8 it's only used for mounting partitions from non-hotpluggable drives with non-removable media (e.g. Windows partitions). For F9 a lot more stuff will use it already written: - intlclock - pulseaudio (for gaining realtime auths) - add/remove software (though the jury is out whether PackageKit will replace pup/pirut on the F9 desktop live cd) written but not in rawhide yet - gnome-system-monitor (kill processes, adjust priority) planned ? - gdm (for shutting down/rebooting the box) - avahi (for publishing network services) - NetworkManager (connect to networks) - gvfs: Nautilus/gedit/etc. (for manipulating files you don't own) I'm also planning to write a small replacement for consolehelper (going to write feature pages / file bugs soon) so you can use polkit-auth(1) http://hal.freedesktop.org/docs/PolicyKit/polkit-auth.1.html or the polkit-gnome-authorization UI http://people.freedesktop.org/~david/polkitg-auth-1.png ?http://people.freedesktop.org/~david/polkitg-auth-2.png ?http://people.freedesktop.org/~david/polkitg-auth-3.png http://people.freedesktop.org/~david/polkit-icon-and-vendor.png to manage who is allowed to run a given X application as root. Finally, I'm working with the FreeIPA team to store authorizations in the directory. David From walters at redhat.com Thu Dec 6 20:54:20 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 06 Dec 2007 15:54:20 -0500 Subject: inotify-aware tail replacement In-Reply-To: <20071206204956.GC13166@petra.dvoda.cz> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> <1196934159.24834.14.camel@vespa.kabelta.loc> <20071206204956.GC13166@petra.dvoda.cz> Message-ID: <1196974460.4704.4.camel@space-ghost.verbum.private> On Thu, 2007-12-06 at 21:49 +0100, Karel Zak wrote: > coreutils = portability; inotify = linux (>= 2.6.13) We have SELinux support in coreutils, I don't really see why an inotify patch would be a problem. Having a separate program just because there's a different implementation detail is silly. From ajackson at redhat.com Thu Dec 6 21:23:43 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 06 Dec 2007 16:23:43 -0500 Subject: Planned change to xorg-x11-font-utils Message-ID: <1196976223.2303.51.camel@localhost.localdomain> The bdftruncate script provided by xorg-x11-font-utils drags in a dependency on perl. As far as I can tell, nothing in the distro uses it. The font-utils package is required by the various bitmap font packages, as it provides mkfontdir and mkfontscale. I plan to drop bdftruncate from font-utils to get rid of the perl bloat, unless someone has a compelling reason not to. - ajax From david at fubar.dk Thu Dec 6 20:52:01 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 15:52:01 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> Message-ID: <1196974321.17759.126.camel@oneill.fubar.dk> On Thu, 2007-12-06 at 14:59 +0100, Matej Cepl wrote: > On Tue, 04 Dec 2007 11:38:47 +0100, Patrice Dumas scripst: > > Unless there is something special for these pieces of code, anybody can > > submit those packages to fedora through the usual review process. > > Not sure, ask davidz, but I am afraid most of them will horribly clash > with PolicyKit/ConsoleKit. Right, it's going to be confusing to developers because they won't know what to use. So please don't do this. Also note that Ubuntu is switching away from gksudo to PolicyKit https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration That, we already have consolehelper which does this. And soon, as I wrote about in the other mail, we'll have the PolicyKit-powered consolehelper replacement that will make it very easy to manage authorizations on a per-app basis. David From nicolas.mailhot at laposte.net Thu Dec 6 21:09:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Dec 2007 22:09:40 +0100 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1196976223.2303.51.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> Message-ID: <1196975380.23188.6.camel@rousalka.dyndns.org> Le jeudi 06 d?cembre 2007 ? 16:23 -0500, Adam Jackson a ?crit : > The bdftruncate script provided by xorg-x11-font-utils drags in a > dependency on perl. As far as I can tell, nothing in the distro uses > it. The font-utils package is required by the various bitmap font > packages, as it provides mkfontdir and mkfontscale. Actually, I wrote last week I'd like font packages not to depend on anything, be it "just" xorg-x11-font-utils of full perl. Pre-generating fonts-* at build time is easy. Having dynamic fontconfig-like generation less so but is not overly difficult either. Both would reduce considerably the problems ?bdftruncate creates. Since you seem to care about it do you want to take over core fonts packaging guidelines maintenance? (I want a pony!) > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > unless someone has a compelling reason not to. Nothing compelling, though it's a shame to drop functionalities for packages which need a good dependency makeover anyway. -- 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 nalin at redhat.com Thu Dec 6 21:22:34 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 6 Dec 2007 16:22:34 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <1196974000.4239.3.camel@localhost.localdomain> References: <47581647.80801@redhat.com> <1196966359.17277.42.camel@localhost.localdomain> <1196974000.4239.3.camel@localhost.localdomain> Message-ID: <20071206212233.GA27056@redhat.com> On Fri, Dec 07, 2007 at 02:16:40AM +0530, Tom spot Callaway wrote: > On Thu, 2007-12-06 at 13:39 -0500, Simo Sorce wrote: > > I have the feeling that it is somehow wrong to give sudo that power. > > For su I am still uncertain, but given that su does not authenticate > > the > > final user but only the super user I again wonder if that should give > > any access to the kernel keyring. > > Maybe this is is an ignorant question, but wouldn't you want this for > loading/unloading kernel modules via su -c / sudo? Thanks to the nature > of iwl3945 and similar drivers, I have been known to execute commands > like: > > $ sudo /sbin/modprobe -r iwl3945 > $ sudo /sbin/modprobe iwl3945 > > I'd think that having proper access to the kernel keyring for ops like > that would be ideal, if not necessary. I'm also concerned about when we > start making sudo/su not act like the root user, with all rights and > permissions, because really, that is the purpose of sudo / su, and one > of the reasons that those commands require either root's credentials to > use (su / sudo) and/or specific permission (sudoers). Here's another maybe-ignorant question. The iwl3945 module reads credentials from the kernel keyring of the user/process that loads it? If so, what sort of credentials is it expecting to find there? I don't have a system with one of these, and a quick web search isn't laying it out for me, so a pointer to the right docs would be enough of an answer. Cheers, Nalin From dr.diesel at gmail.com Thu Dec 6 21:32:33 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 6 Dec 2007 16:32:33 -0500 Subject: Why do kmod packages no longer update? Message-ID: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> Same problem with all kmod packages on all machines, while attempting to update to the .63 kernel. They .63 kmod is listed in the update list? --> Running transaction check --> Processing Dependency: kernel-x86_64 = 2.6.23.1-49.fc8 for package: kmod-nvidia-2.6.23.1-49.fc8 ---> Package kmod-nvidia-2.6.23.8-63.fc8.x86_64 0:100.14.19-19.lvn8 set to be updated --> Finished Dependency Resolution Error: Missing Dependency: kernel-x86_64 = 2.6.23.1-49.fc8 is needed by package kmod-nvidia-2.6.23.1-49.fc8 Is this a packaging error on Livna's part or some new policy I missed? Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From katzj at redhat.com Thu Dec 6 21:33:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Dec 2007 16:33:32 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <20071206212233.GA27056@redhat.com> References: <47581647.80801@redhat.com> <1196966359.17277.42.camel@localhost.localdomain> <1196974000.4239.3.camel@localhost.localdomain> <20071206212233.GA27056@redhat.com> Message-ID: <1196976812.3631.98.camel@localhost.localdomain> On Thu, 2007-12-06 at 16:22 -0500, Nalin Dahyabhai wrote: > On Fri, Dec 07, 2007 at 02:16:40AM +0530, Tom spot Callaway wrote: > > On Thu, 2007-12-06 at 13:39 -0500, Simo Sorce wrote: > > > I have the feeling that it is somehow wrong to give sudo that power. > > > For su I am still uncertain, but given that su does not authenticate > > > the > > > final user but only the super user I again wonder if that should give > > > any access to the kernel keyring. > > > > Maybe this is is an ignorant question, but wouldn't you want this for > > loading/unloading kernel modules via su -c / sudo? Thanks to the nature > > of iwl3945 and similar drivers, I have been known to execute commands > > like: > > > > $ sudo /sbin/modprobe -r iwl3945 > > $ sudo /sbin/modprobe iwl3945 > > > > I'd think that having proper access to the kernel keyring for ops like > > that would be ideal, if not necessary. I'm also concerned about when we > > start making sudo/su not act like the root user, with all rights and > > permissions, because really, that is the purpose of sudo / su, and one > > of the reasons that those commands require either root's credentials to > > use (su / sudo) and/or specific permission (sudoers). > > Here's another maybe-ignorant question. The iwl3945 module reads > credentials from the kernel keyring of the user/process that loads it? > If so, what sort of credentials is it expecting to find there? The module doesn't read any credentials from the keyring. I think spot is delirious from jet lag ;-) Jeremy From notting at redhat.com Thu Dec 6 21:38:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Dec 2007 16:38:11 -0500 Subject: inotify-aware tail replacement In-Reply-To: <1196974460.4704.4.camel@space-ghost.verbum.private> References: <47574DAC.3060807@andrei.myip.org> <4757A6C9.8000601@redhat.com> <4757C2B2.8070407@nobugconsulting.ro> <1196934159.24834.14.camel@vespa.kabelta.loc> <20071206204956.GC13166@petra.dvoda.cz> <1196974460.4704.4.camel@space-ghost.verbum.private> Message-ID: <20071206213811.GF4775@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > On Thu, 2007-12-06 at 21:49 +0100, Karel Zak wrote: > > > coreutils = portability; inotify = linux (>= 2.6.13) > > We have SELinux support in coreutils, I don't really see why an inotify > patch would be a problem. > > Having a separate program just because there's a different > implementation detail is silly. Is there any reason the user should *care* about the implementation of tail -f? Bill From skvidal at fedoraproject.org Thu Dec 6 21:37:58 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 06 Dec 2007 16:37:58 -0500 Subject: Why do kmod packages no longer update? In-Reply-To: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> Message-ID: <1196977078.20942.5.camel@cutter> On Thu, 2007-12-06 at 16:32 -0500, Dr. Diesel wrote: > Same problem with all kmod packages on all machines, while attempting > to update to the .63 kernel. They .63 kmod is listed in the update > list? > > --> Running transaction check > --> Processing Dependency: kernel-x86_64 = 2.6.23.1-49.fc8 for > package: kmod-nvidia-2.6.23.1-49.fc8 > ---> Package kmod-nvidia-2.6.23.8-63.fc8.x86_64 0:100.14.19-19.lvn8 > set to be updated > --> Finished Dependency Resolution > Error: Missing Dependency: kernel-x86_64 = 2.6.23.1-49.fc8 is needed > by package kmod-nvidia-2.6.23.1-49.fc8 > > > Is this a packaging error on Livna's part or some new policy I missed? > it was a yum bug and it is fixed in yum 3.2.8 which is out in updates. :) -sv From jbarnes at virtuousgeek.org Thu Dec 6 21:41:24 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 6 Dec 2007 13:41:24 -0800 Subject: inotify-aware tail replacement In-Reply-To: <20071206213811.GF4775@nostromo.devel.redhat.com> References: <47574DAC.3060807@andrei.myip.org> <1196974460.4704.4.camel@space-ghost.verbum.private> <20071206213811.GF4775@nostromo.devel.redhat.com> Message-ID: <200712061341.24177.jbarnes@virtuousgeek.org> On Thursday, December 06, 2007 1:38 pm Bill Nottingham wrote: > Colin Walters (walters at redhat.com) said: > > On Thu, 2007-12-06 at 21:49 +0100, Karel Zak wrote: > > > coreutils = portability; inotify = linux (>= 2.6.13) > > > > We have SELinux support in coreutils, I don't really see why an inotify > > patch would be a problem. > > > > Having a separate program just because there's a different > > implementation detail is silly. > > Is there any reason the user should *care* about the implementation > of tail -f? Well, the manpage says -f is affected by the sleep argument, so it's conceivable that there are scripts depending on that behavior... -w (for watch) may be a good name for a new flag. Jesse From walters at redhat.com Thu Dec 6 21:44:31 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 06 Dec 2007 16:44:31 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <1196974321.17759.126.camel@oneill.fubar.dk> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> Message-ID: <1196977471.4704.28.camel@space-ghost.verbum.private> On Thu, 2007-12-06 at 15:52 -0500, David Zeuthen wrote: > On Thu, 2007-12-06 at 14:59 +0100, Matej Cepl wrote: > > On Tue, 04 Dec 2007 11:38:47 +0100, Patrice Dumas scripst: > > > Unless there is something special for these pieces of code, anybody can > > > submit those packages to fedora through the usual review process. > > > > Not sure, ask davidz, but I am afraid most of them will horribly clash > > with PolicyKit/ConsoleKit. > > Right, it's going to be confusing to developers because they won't know > what to use. So please don't do this. Also note that Ubuntu is switching > away from gksudo to PolicyKit > > https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration Well, right - for their apps like the software updater. But we still need a generic mechanism for asking a "wheel user" for a password in a nice way to run an arbitrary command. Use cases being "rmmod iw3945" as spot mentioned, or developers restarting tomcat on their local machine, editing /etc/yum.repos.d, really the list is endless. I guess though a sane way to start would be to restrict "arbitrary command" to "tty app", without also supporting X apps. > That, we already have consolehelper which does this. I guess you could make a consolehelper app called "runcommand" or something which had UGROUPS=wheel? Hm, I can't get it to work in a quick attempt. > And soon, as I > wrote about in the other mail, we'll have the PolicyKit-powered > consolehelper replacement that will make it very easy to manage > authorizations on a per-app basis. I'm just hoping we can land the bits so that removing the root password from Fedora is as simple and manageable as flipping one switch - and then we can flip that switch by default for the desktop config. And that we have a nice UI for prompting for the user password to run arbitrary commands. From jspaleta at gmail.com Thu Dec 6 21:50:25 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Dec 2007 12:50:25 -0900 Subject: Package alien In-Reply-To: <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> Message-ID: <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> On Dec 5, 2007 3:51 PM, King InuYasha wrote: > Though, will dpkg and the like be purposely crippled on Fedora like > rpm is on Debian systems? It probably would be a good idea to patch > dpkg and stuff to make sure they don't work as standard packagers, but > rather just helpers to alien, as RPM does on a Debian system. We want > to avoid the possibility of package jumbling..... I would certainly concur with this. Without making a judgment as to the value of having alien or other alternative packaging tools in the repository.. I would agree that if we are going to be putting dpkg and friends into the repository that they come configured by default to only act as helpers for using Fedora as a (re)packaging host. Enabling functionality beyond that should be relatively difficult to enable if not disabled entirely at buildtime. There maybe some rather clever unorthodox ways to make use of a fully capable dpkg in other ways, but I don't want users accidental stumbling into those situations just because they installed dpkg and followed a google'd recipe article to have dpkg replace rpm on their Fedora system. -jef From nalin at redhat.com Thu Dec 6 21:54:00 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 6 Dec 2007 16:54:00 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <47581647.80801@redhat.com> References: <47581647.80801@redhat.com> Message-ID: <20071206215400.GB27056@redhat.com> It should probably be pointed out that the keyring we're talking about here is the kernel's keyring, which you can manipulate using 'keyctl' from the 'keyutils' package, and not the GNOME keyring. That said, On Thu, Dec 06, 2007 at 10:33:27AM -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > I don't fully understand how you intend to use keying, but I have talked > to Nalin about this, since he is about to allow or does allow the > storing of the kerberos tgt in a kernel keyring. The krb5 package grew this ability either in F7 or an update; set KRB5CCNAME=KEYRING:blahblahblah in your environment and 'kinit' and 'kdestroy' to your heart's content. Raw Hide's pam_krb5 adds a 'ccname_template' option which can be used to tell it to create a keyring-based ccache for your session instead of the usual file-based one. It still defaults to files, though. For now, at least. [snip] > So I would suggest that we remove pam_keyinit from system_auth and only > use it in login pam modules which call it after pam_selinux open. Agreed completely. It's surprising when the new credentials your screensaver got by using a PAM module get stored in a brand-new keyring which is not tied to the rest of your desktop session. > Now the next question is whether it should be called in su or sudo? > Since wouldn't this remove access to my keying material? That's an interesting problem. In the process of authenticating for sudo or su, we _might_ get new credentials which would be stored in the keyring. It's easier for me to think about if I think of those creds as being a Kerberos TGT, but since the keyring can store any kind of data, I don't think we can assume it's only going to crop up when you're using Kerberos. Anyway, we probably don't want to store them in the same keyring as the parent process, because that be a pretty bad leak, so for the sake of that case we should always be creating a new keyring in su and sudo. But if we don't get new creds, it's going to be more useful to just re-use any creds we already have, in case they're being used to store credentials which let us access networked filesystems. Assuming that behavior wouldn't be super-broken (if it is, someone jump in, please!), how could we make that happen? That is, how can we create a new session only when we have things to store in it? > su and sudo do not call pam_selinux open, so it will not setup a > labeling for pam_keyinit, and the keys will get created as user_sudo_t > or user_su_t for example. At this point what access is expected by the > user for these keyrings? Would you expect the keyrings to be labeled > kernel_t, or should we remove the pam_keyinit from su and sudo, leaving > access to the login keyrings. I'd kind of expect those keyrings to be labeled as usual. Is there value to having different labels on them, aside from being able to restrict what other types of processes can access them in an SELinux sense? While we're sorting all of that out, we should probably make sure the right thing's going on wrt pam_namespace and pam_loginuid. Sorry, more questions than answers. Nalin From ssorce at redhat.com Thu Dec 6 21:57:57 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Dec 2007 16:57:57 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <21289.1196977809@redhat.com> References: <1196972358.21254.0.camel@localhost.localdomain> <1196966359.17277.42.camel@localhost.localdomain> <47581647.80801@redhat.com> <21081.1196971368@redhat.com> <21289.1196977809@redhat.com> Message-ID: <1196978277.22456.1.camel@localhost.localdomain> On Thu, 2007-12-06 at 21:50 +0000, David Howells wrote: > Simo Sorce wrote: > > > Are you thinking a setuid program here ? > > Or actually really a program run through sudo ? > > Well, I was talking about sudo, but the same can apply to setuid programs. The problem I have with giving sudo/setuid programs access to my credentials is trust, they are ultimately running with different credentials after all. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From cmadams at hiwaay.net Thu Dec 6 22:02:23 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 6 Dec 2007 16:02:23 -0600 Subject: inotify-aware tail replacement In-Reply-To: <200712061341.24177.jbarnes@virtuousgeek.org> References: <47574DAC.3060807@andrei.myip.org> <1196974460.4704.4.camel@space-ghost.verbum.private> <20071206213811.GF4775@nostromo.devel.redhat.com> <200712061341.24177.jbarnes@virtuousgeek.org> Message-ID: <20071206220223.GD1403341@hiwaay.net> Once upon a time, Jesse Barnes said: > On Thursday, December 06, 2007 1:38 pm Bill Nottingham wrote: > > Is there any reason the user should *care* about the implementation > > of tail -f? > > Well, the manpage says -f is affected by the sleep argument, so it's > conceivable that there are scripts depending on that behavior... That's already a coreutils extension (e.g. not in SUS, not on other OSes I spot-checked), so I don't think anythink would hurt by just changing -f behavior (maybe if -s is specified automatically fall-back to the old behavior). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From lists at ebourne.me.uk Thu Dec 6 22:02:43 2007 From: lists at ebourne.me.uk (Martin Ebourne) Date: Thu, 6 Dec 2007 22:02:43 +0000 (UTC) Subject: inotify-aware tail replacement References: <47574DAC.3060807@andrei.myip.org> <1196974460.4704.4.camel@space-ghost.verbum.private> <20071206213811.GF4775@nostromo.devel.redhat.com> <200712061341.24177.jbarnes@virtuousgeek.org> Message-ID: On Thu, 06 Dec 2007 13:41:24 -0800, Jesse Barnes wrote: > On Thursday, December 06, 2007 1:38 pm Bill Nottingham wrote: >> Is there any reason the user should *care* about the implementation of >> tail -f? > > Well, the manpage says -f is affected by the sleep argument, so it's > conceivable that there are scripts depending on that behavior... So an inotify patch could be automatically disabled if -s is given. In that case use the old behaviour. > -w (for watch) may be a good name for a new flag. I don't think there's much point adding it as a new flag since it wouldn't get used, thus nullifying the benefit. I agree with the others, much better to integrate it into coreutils tail than provide another version. Cheers, Martin, From nalin at redhat.com Thu Dec 6 22:29:16 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 6 Dec 2007 17:29:16 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <21605.1196979514@redhat.com> References: <20071206215400.GB27056@redhat.com> <47581647.80801@redhat.com> <21605.1196979514@redhat.com> Message-ID: <20071206222916.GB28220@redhat.com> On Thu, Dec 06, 2007 at 10:18:34PM +0000, David Howells wrote: > Nalin Dahyabhai wrote: > > > It should probably be pointed out that the keyring we're talking about > > here is the kernel's keyring, which you can manipulate using 'keyctl' > > from the 'keyutils' package, and not the GNOME keyring. That said, > > When you say "the kernel's keyring" I presume you mean the session keyring > retained by the kernel on behalf of a group of tasks. Yes. Apologies if that was vague or imprecise. I was trying to head off confusion, and apparently failing miserably. Nalin From david at fubar.dk Thu Dec 6 22:38:20 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 17:38:20 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <1196977471.4704.28.camel@space-ghost.verbum.private> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> Message-ID: <1196980700.17759.192.camel@oneill.fubar.dk> On Thu, 2007-12-06 at 16:44 -0500, Colin Walters wrote: > On Thu, 2007-12-06 at 15:52 -0500, David Zeuthen wrote: > > On Thu, 2007-12-06 at 14:59 +0100, Matej Cepl wrote: > > > On Tue, 04 Dec 2007 11:38:47 +0100, Patrice Dumas scripst: > > > > Unless there is something special for these pieces of code, anybody can > > > > submit those packages to fedora through the usual review process. > > > > > > Not sure, ask davidz, but I am afraid most of them will horribly clash > > > with PolicyKit/ConsoleKit. > > > > Right, it's going to be confusing to developers because they won't know > > what to use. So please don't do this. Also note that Ubuntu is switching > > away from gksudo to PolicyKit > > > > https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration > > Well, right - for their apps like the software updater. > > But we still need a generic mechanism for asking a "wheel user" for a > password in a nice way to run an arbitrary command. Use cases being > "rmmod iw3945" as spot mentioned, or developers restarting tomcat on > their local machine, editing /etc/yum.repos.d, really the list is > endless. I guess though a sane way to start would be to restrict > "arbitrary command" to "tty app", without also supporting X apps. Sure, we should just ship with an /etc/sudoers that allows you to run any command if you are in the 'wheel' group. Personally I just use 'sudo su -', enter my password, and off I go with the root shell. > > That, we already have consolehelper which does this. > > I guess you could make a consolehelper app called "runcommand" or > something which had UGROUPS=wheel? Hm, I can't get it to work in a > quick attempt. The point is that you want fine-grained access for this. So the way I imagine this is going to work is that you can do $ polkit-auth --user the_wife --grant org.fd.policykit.run-as.system-config-display to grant the_wife the authorization to always run system-config-display. Or you can go crazy and require what authentication is needed via polkit-action(1) or the GTK+ tool http://people.freedesktop.org/~david/polkitg-auth-1.png http://people.freedesktop.org/~david/polkitg-auth-2.png http://people.freedesktop.org/~david/polkitg-auth-3.png to e.g. configure that system-config-display needs the users own password or an administrator password. > > And soon, as I > > wrote about in the other mail, we'll have the PolicyKit-powered > > consolehelper replacement that will make it very easy to manage > > authorizations on a per-app basis. > > I'm just hoping we can land the bits so that removing the root password > from Fedora is as simple and manageable as flipping one switch - and > then we can flip that switch by default for the desktop config. And > that we have a nice UI for prompting for the user password to run > arbitrary commands. That's the plan. PolicyKit 0.8 (out in a 4-6 weeks or so) will get two extra UNIX user groups so we'll end up with three groups defining what users can do wheel : gives you full root access through sudo polkit_admin : defines administrative users; any PolicyKit auth dialog that asks for an administrator to authenticate will allow you to select one of these users in this group to authenticate. It looks like this http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-wheel-group-1.png http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html polkit_lockdown : any user in this UNIX group cannot even authenticate to gain PolicyKit authorizations (think guest/KIOSK) As you can imagine this gives you a lot of flexibility in defining what a user can and can't do. With this, specifically for the desktop live CD we'll just - rewrite /etc/sudoers to allow any command - disable root logins and unset the root password (See Ubuntu) which can all be achieved from the Kickstart file (as such, these changes will end up on installed copies of the OS). There's also some firstboot work in adding toggles for these three groups (specifically someone _needs_ to be in the 'wheel' group) but that shouldn't be too hard. There's also Anaconda work in making sure the root password isn't asked for. Should be trivial as well. That's the plan anyway. Someone should probably write a feature page; Colin, are you up for that? :-) David From ssorce at redhat.com Thu Dec 6 22:43:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Dec 2007 17:43:52 -0500 Subject: I think the placement of the pam_keyinit.so in the pam files is incorrect? In-Reply-To: <21578.1196979421@redhat.com> References: <1196978277.22456.1.camel@localhost.localdomain> <1196972358.21254.0.camel@localhost.localdomain> <1196966359.17277.42.camel@localhost.localdomain> <47581647.80801@redhat.com> <21081.1196971368@redhat.com> <21289.1196977809@redhat.com> <21578.1196979421@redhat.com> Message-ID: <1196981032.22456.3.camel@localhost.localdomain> On Thu, 2007-12-06 at 22:17 +0000, David Howells wrote: > Simo Sorce wrote: > > > The problem I have with giving sudo/setuid programs access to my > > credentials is trust, they are ultimately running with different > > credentials after all. > > There is no right answer, unfortunately. Sometimes you want to give access > and sometimes you don't. > > I've been told by some OpenAFS developers that the OpenAFS key must be > accessible by a program run under su. > > Something you have to remember: the current working directory may not be > available if you don't have the right key, the binary you want to execute may > not be available even. Open files, however, should be immune to this effect. Yes I am well aware of that, we are going to implement the same stuff in cifs.ko, ie you have to authenticate to get access. Still it make me question if I want to give a sudoed app access to my material, if I su/sudo to root then probably it's ok, root is powerful enough to be trust-able by a mortal user. If you su to another user, things change a lot IMO. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jspaleta at gmail.com Thu Dec 6 22:57:25 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Dec 2007 13:57:25 -0900 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <1196980700.17759.192.camel@oneill.fubar.dk> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> <1196980700.17759.192.camel@oneill.fubar.dk> Message-ID: <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> On Dec 6, 2007 1:38 PM, David Zeuthen wrote: > to grant the_wife the authorization to always run system-config-display. Not to imply that my wife doesn't deserve to have all of her action authorization grants to be manipulated by hand...but if I had to do this manually for ALL my wives that's a pretty time-consuming and unnecessarily repetitive. We'll we have access to a set of pre-defined roles that can be re-applied to multiple users to grant a number of common actions based on expected usage patterns? -jef From david at fubar.dk Thu Dec 6 23:01:35 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 18:01:35 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> <1196980700.17759.192.camel@oneill.fubar.dk> <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> Message-ID: <1196982095.17759.199.camel@oneill.fubar.dk> On Thu, 2007-12-06 at 13:57 -0900, Jeff Spaleta wrote: > On Dec 6, 2007 1:38 PM, David Zeuthen wrote: > > to grant the_wife the authorization to always run system-config-display. > > Not to imply that my wife doesn't deserve to have all of her action > authorization grants to be manipulated by hand...but if I had to do > this manually for ALL my wives that's a pretty time-consuming and > unnecessarily repetitive. > > We'll we have access to a set of pre-defined roles that can be > re-applied to multiple users to grant a number of common actions based > on expected usage patterns? Sure, that's supported already. An authorization comes with a .policy file that defines the defaults http://hal.freedesktop.org/docs/PolicyKit/polkit-conf.html#conf-declaring-actions The key here to pay attention to is . If it's 'yes' then a user in an active session on the local console is implicitly authorized. No stupid authentication dialogs. You can tweak that with http://people.freedesktop.org/~david/polkitg-auth-2.png and polkit-action(1) http://hal.freedesktop.org/docs/PolicyKit/polkit-action.1.html e.g., you can specify whether for the given action - Require an administrator to authenticate - Require the user to authenticate and you can specify whether the gained authorization can be kept forever, for the session, for the life time of the process using it or whether it can only be used a single time. The user can even opt out; see the various auth dialogs here http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html All this landed in Rawhide today so go get PolicyKit 0.7 and PolicyKit-gnome 0.7 and play around with it (the GTK+ program is in System->Preferences->System->Authorizations) David From david at fubar.dk Thu Dec 6 23:05:00 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 18:05:00 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> <1196980700.17759.192.camel@oneill.fubar.dk> <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> Message-ID: <1196982300.17759.202.camel@oneill.fubar.dk> On Thu, 2007-12-06 at 13:57 -0900, Jeff Spaleta wrote: > On Dec 6, 2007 1:38 PM, David Zeuthen wrote: > > to grant the_wife the authorization to always run system-config-display. > > Not to imply that my wife doesn't deserve to have all of her action > authorization grants to be manipulated by hand...but if I had to do > this manually for ALL my wives that's a pretty time-consuming and > unnecessarily repetitive. > > We'll we have access to a set of pre-defined roles that can be > re-applied to multiple users to grant a number of common actions based > on expected usage patterns? Uhm, and to actually answer the question: Will I be able to grant an authorization to members of group wifes? (that was your question, right?) The answer to this is that with PK 0.8 you will. Right now we only support users. David From ajackson at redhat.com Thu Dec 6 23:45:41 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 06 Dec 2007 18:45:41 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1196975380.23188.6.camel@rousalka.dyndns.org> References: <1196976223.2303.51.camel@localhost.localdomain> <1196975380.23188.6.camel@rousalka.dyndns.org> Message-ID: <1196984741.2303.61.camel@localhost.localdomain> On Thu, 2007-12-06 at 22:09 +0100, Nicolas Mailhot wrote: > Le jeudi 06 d?cembre 2007 ? 16:23 -0500, Adam Jackson a ?crit : > > The bdftruncate script provided by xorg-x11-font-utils drags in a > > dependency on perl. As far as I can tell, nothing in the distro uses > > it. The font-utils package is required by the various bitmap font > > packages, as it provides mkfontdir and mkfontscale. > > Actually, I wrote last week I'd like font packages not to depend on > anything, be it "just" xorg-x11-font-utils of full perl. Pre-generating > fonts-* at build time is easy. Having dynamic fontconfig-like generation > less so but is not overly difficult either. Both would reduce > considerably the problems ?bdftruncate creates. I agree that we should be able to package core fonts "up front" in the sense of not needing processing in scriptlets, but I am utterly unmotivated to make that happen. > Since you seem to care about it do you want to take over core fonts > packaging guidelines maintenance? (I want a pony!) Not even a little bit. I don't care about core fonts working in the slightest. My interest here is just on removing a rather bizarre arc in the dep graph. - ajax From jspaleta at gmail.com Thu Dec 6 23:18:45 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Dec 2007 14:18:45 -0900 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <1196982300.17759.202.camel@oneill.fubar.dk> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> <1196980700.17759.192.camel@oneill.fubar.dk> <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> <1196982300.17759.202.camel@oneill.fubar.dk> Message-ID: <604aa7910712061518h7f4197f4i9a0254e1cd88b9c3@mail.gmail.com> On Dec 6, 2007 2:05 PM, David Zeuthen wrote: > Will I be able to grant an authorization to members of group wifes? > (that was your question, right?) Basically... though the groupname harem might make more sense. > The answer to this is that with PK 0.8 you will. Right now we only > support users. I'm trying to re-synthesize Colin's questions into the usage patterns I'm dealing with. A lot of the problems I need to address involve dealing with hardware access from a cmdline through something like an ssh session for a group of specific users... not the wheel group. If I could create the deathray_admin group and add users to it, then grant write access to deathray hardware for that whole group that would be great. -jef From david at fubar.dk Thu Dec 6 23:21:57 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Dec 2007 18:21:57 -0500 Subject: Proposal for Fedora - "GKSUDO" In-Reply-To: <604aa7910712061518h7f4197f4i9a0254e1cd88b9c3@mail.gmail.com> References: <93d66b780712031832wc7c58d7p2e0f89285b742997@mail.gmail.com> <20071204103847.GD28178@free.fr> <1196974321.17759.126.camel@oneill.fubar.dk> <1196977471.4704.28.camel@space-ghost.verbum.private> <1196980700.17759.192.camel@oneill.fubar.dk> <604aa7910712061457l5699db57j6fd591cb249fa2b6@mail.gmail.com> <1196982300.17759.202.camel@oneill.fubar.dk> <604aa7910712061518h7f4197f4i9a0254e1cd88b9c3@mail.gmail.com> Message-ID: <1196983317.17759.208.camel@oneill.fubar.dk> On Thu, 2007-12-06 at 14:18 -0900, Jeff Spaleta wrote: > I'm trying to re-synthesize Colin's questions into the usage patterns > I'm dealing with. A lot of the problems I need to address involve > dealing with hardware access from a cmdline through something like an > ssh session for a group of specific users... not the wheel group. If > I could create the deathray_admin group and add users to it, then > grant write access to deathray hardware for that whole group that > would be great. Right. That kind of thing will be possible. David From seg at haxxed.com Fri Dec 7 00:11:48 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 06 Dec 2007 18:11:48 -0600 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> Message-ID: <1196986308.28417.8.camel@localhost> On Thu, 2007-12-06 at 07:25 -0600, Jima wrote: > On Wed, 5 Dec 2007, Callum Lerwick wrote: > > This is *exactly* what dnsmasq is designed for. From what I can tell, > > the author added dbus support to dnsmasq *specifically* so > > NetworkManager could use it. I'm not sure what's up with the disconnect > > here. :) > > Maybe not NM specifically, but certainly conceptually: > > "Added method support for DBus (http://www.freedesktop.org/Software/dbus) > This is a superior way to re-configure dnsmasq on-the-fly with different > upstream nameservers, as the host moves between networks. DBus support > must be enabled in src/config.h and should be considered experimental at > this point. See DBus-interface for the specification of the DBus method > calls supported." http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00023.html http://osdir.com/ml/network.networkmanager.devel/2005-05/msg00012.html http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00036.html The dnsmasq author was very eager to have dnsmasq used by NM back in 2005. I haven't found any explanation as to why it didn't happen. Here's a nice fresh thread, it even links back to this one: http://www.nabble.com/nm-with-dnsmasq--t4940689.html They seem really dead set on sticking with bind. Seriously, why? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Dec 7 00:30:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Dec 2007 19:30:20 -0500 Subject: inotify-aware tail replacement In-Reply-To: References: <47574DAC.3060807@andrei.myip.org> <1196974460.4704.4.camel@space-ghost.verbum.private> <20071206213811.GF4775@nostromo.devel.redhat.com> <200712061341.24177.jbarnes@virtuousgeek.org> Message-ID: <20071206193020.4f3b5eb5@redhat.com> On Thu, 6 Dec 2007 22:02:43 +0000 (UTC) Martin Ebourne wrote: > I agree with the others, much better to integrate it into coreutils > tail than provide another version. When that happens, I'll happily remove inotail from the distro (: -- 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 seg at haxxed.com Fri Dec 7 01:00:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 06 Dec 2007 19:00:09 -0600 Subject: Package alien In-Reply-To: <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> Message-ID: <1196989209.28417.23.camel@localhost> On Thu, 2007-12-06 at 12:50 -0900, Jeff Spaleta wrote: > I would certainly concur with this. Without making a judgment as to > the value of having alien or other alternative packaging tools in the > repository.. I would agree that if we are going to be putting dpkg and > friends into the repository that they come configured by default to > only act as helpers for using Fedora as a (re)packaging host. > Enabling functionality beyond that should be relatively difficult to > enable if not disabled entirely at buildtime. There maybe some rather > clever unorthodox ways to make use of a fully capable dpkg in other > ways, but I don't want users accidental stumbling into those > situations just because they installed dpkg and followed a google'd > recipe article to have dpkg replace rpm on their Fedora system. I once installed FC2 by hand, using debian's rpm, to hot-convert said debian machine to Fedora. :) And I kept notes: http://www.haxxed.com/random/fedorainstall.txt Its actually the oldest surviving Fedora install I have, and is still in use. Its survived apt-rpm upgrades up to FC5 or so, and its been yum upgrades since then. And survived most of the hardware being replaced and a total re-purposing. It was originally a firewall box, but was replaced by a (Linux based) wireless router and re-purposed as an "HTPC"... -------------- 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 eswierk at arastra.com Fri Dec 7 02:13:15 2007 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 6 Dec 2007 18:13:15 -0800 Subject: InstantMirror-0.2 Release In-Reply-To: <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> References: <20071204070618.86E2273167@hormel.redhat.com> <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> Message-ID: On 12/4/07, chasd wrote: > If it was expected that InstantMirror was to be very popular, or > there was a large number of other packages that would make use of > directives, it might make sense to modify the default > apache configuration to be more "virtual host friendly." As it > stands, I think some prudent suggestions in the provided > InstantMirror.conf file ( and perhaps renaming it ) is the best plan. Actually InstantMirror should work just fine in a simple non-VirtualHost configuration, so perhaps the default Apache configuration file can leave out the VirtualHost directives and we can bundle the fancier VirtualHost configuration as an example in the docs directory. > Anyway, I was able to test my suggestions on two different servers > with two different sets of configuration files in conf.d, and my > recommendations seem to work well in both cases. I guess that means > this package is thoroughly tested ;) Well, Warren has done an excellent job finding stupid bugs in my original implementation. > If I could make one other suggestion about InstantMirror, it would be > to include a sample.repo file in /usr/share/doc/InstantMirror-x/ or > throw it into /etc/yum.repos.d/ with enabled=0. Good idea. > BTW, InstantMirror is much simpler, lighter weight and easier to use > than WSUS. Although WSUS has other abilities, InstantMirror has a > good 50% of the functionality of WSUS. This package may seem > innocuous, if you mentioned WSUS in the same breath as InstantMirror, > it might warrant a mention as a feature, at least targeted at some > new-to-Linux admins. I have no idea what WSUS does but my guess is the 80/20 rule applies. Still, the fact that a useful admin tool can be implemented in less than 100 lines of Python demonstrates the excellent design of Apache, mod_python and Python. --Ed From wtogami at redhat.com Fri Dec 7 03:34:37 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 06 Dec 2007 22:34:37 -0500 Subject: InstantMirror-0.2 Release In-Reply-To: References: <20071204070618.86E2273167@hormel.redhat.com> <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> Message-ID: <4758BF4D.5030804@redhat.com> Ed Swierk wrote: > On 12/4/07, chasd wrote: >> If it was expected that InstantMirror was to be very popular, or >> there was a large number of other packages that would make use of >> directives, it might make sense to modify the default >> apache configuration to be more "virtual host friendly." As it >> stands, I think some prudent suggestions in the provided >> InstantMirror.conf file ( and perhaps renaming it ) is the best plan. > > Actually InstantMirror should work just fine in a simple > non-VirtualHost configuration, so perhaps the default Apache > configuration file can leave out the VirtualHost directives and we can > bundle the fancier VirtualHost configuration as an example in the docs > directory. I personally dislike this idea. It is already fully commented out in the default InstantMirror.conf. Why don't we: 1) Keep the contents as-is. 2) Add a note to other examples the doc directory. 3) Rename the file to zz-InstantMirror.conf so it never goes first. > >> If I could make one other suggestion about InstantMirror, it would be >> to include a sample.repo file in /usr/share/doc/InstantMirror-x/ or >> throw it into /etc/yum.repos.d/ with enabled=0. > > Good idea. I'm not sure about this. I might be okay with keeping a sample.repo in docs, but not /etc/yum.respo.d/. This is because anybody should be able to add their own mirror to MirrorManager itself and not need any per-client configuration. Also /etc/yum.repos.d/ included in InstantMirror would mean that you need to install InstantMirror on each of your clients as well. How much sense does this make? =) > >> BTW, InstantMirror is much simpler, lighter weight and easier to use >> than WSUS. Although WSUS has other abilities, InstantMirror has a >> good 50% of the functionality of WSUS. This package may seem >> innocuous, if you mentioned WSUS in the same breath as InstantMirror, >> it might warrant a mention as a feature, at least targeted at some >> new-to-Linux admins. > > I have no idea what WSUS does but my guess is the 80/20 rule applies. > Still, the fact that a useful admin tool can be implemented in less > than 100 lines of Python demonstrates the excellent design of Apache, > mod_python and Python. Reportedly Debian has 3 implementations of a reverse proxy mirror, some even handle apt metadata in an intelligent way to expire the repository contents. Might be worth looking into to get ideas for future improvement for InstantMirror. Warren Togami wtogami at redhat.com From yabraham2 at gmail.com Fri Dec 7 04:10:31 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Thu, 6 Dec 2007 23:10:31 -0500 Subject: yum update openssh--> infinite loop on dependency check Message-ID: <47324ed80712062010p689d566dy533d75e6c375cdb3@mail.gmail.com> on my Rawhide system, I tried "yum update openssh" and yum went to infinite loop. it was showing the checking libssl, libcrypto, libldap et el over and over again. BTW, I know openssh has broken dependency. But I was expecting yum to display no libssl ... and stop. yum-3.2.7-2.fc9 /Yonas From kevin.kofler at chello.at Fri Dec 7 06:12:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 7 Dec 2007 06:12:56 +0000 (UTC) Subject: Planned change to xorg-x11-font-utils References: <1196976223.2303.51.camel@localhost.localdomain> Message-ID: Adam Jackson redhat.com> writes: > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > unless someone has a compelling reason not to. What's the problem with depending on Perl? It's a useful scripting language, used in a lot of packages, thus so many things require it that you'll be hard-pressed to find a working system without Perl, especially an X11-enabled one. For example, kdelibs requires Perl (it's used for things like kconf_update), so any KDE system will always have Perl anyway. Kevin Kofler From david at fubar.dk Fri Dec 7 06:26:37 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 07 Dec 2007 01:26:37 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: References: <1196976223.2303.51.camel@localhost.localdomain> Message-ID: <1197008797.4460.3.camel@oneill.fubar.dk> On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > Adam Jackson redhat.com> writes: > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > unless someone has a compelling reason not to. > > What's the problem with depending on Perl? It's a useful scripting language, > used in a lot of packages, thus so many things require it that you'll be > hard-pressed to find a working system without Perl, especially an X11-enabled > one. For example, kdelibs requires Perl (it's used for things like > kconf_update), so any KDE system will always have Perl anyway. Perl is 10MB compressed and 30MB uncompressed. On a system like OLPC that matters a lot. I remember when I worked on OLPC I did a lot of work with danpb fixing up Fedora to remove such non-sense dependencies. We need to care about things like these if we want Fedora to matter in embedded and virt environments. David From david at fubar.dk Fri Dec 7 06:26:37 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 07 Dec 2007 01:26:37 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: References: <1196976223.2303.51.camel@localhost.localdomain> Message-ID: <1197008797.4460.3.camel@oneill.fubar.dk> On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > Adam Jackson redhat.com> writes: > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > unless someone has a compelling reason not to. > > What's the problem with depending on Perl? It's a useful scripting language, > used in a lot of packages, thus so many things require it that you'll be > hard-pressed to find a working system without Perl, especially an X11-enabled > one. For example, kdelibs requires Perl (it's used for things like > kconf_update), so any KDE system will always have Perl anyway. Perl is 10MB compressed and 30MB uncompressed. On a system like OLPC that matters a lot. I remember when I worked on OLPC I did a lot of work with danpb fixing up Fedora to remove such non-sense dependencies. We need to care about things like these if we want Fedora to matter in embedded and virt environments. David From Michael_E_Brown at dell.com Fri Dec 7 07:04:48 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 7 Dec 2007 01:04:48 -0600 Subject: mock 0.8.9 In-Reply-To: <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> Message-ID: <20071207070448.GA20952@humbolt.us.dell.com> On Wed, Dec 05, 2007 at 07:56:11PM -0200, Paulo Cavalcanti wrote: > On Dec 5, 2007 7:45 PM, Ville Skytt? wrote: > > > On Wednesday 05 December 2007, Michael E Brown wrote: > > > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > > > Okay, here's another set of patches to implement --with{,out} options. > > > > I used git-format-patch this time, and probably did it awkwardly. But > > > > hopefully not too badly. Just in case (and for non-git users), I'll > > > > also attach a single diff that should apply cleanly to mock-0.8.14. > > > > > > > > Comments and improvements welcome. :) > > > > > > This looks great to me. I've committed this to the repo. > > > > Thanks, guys! When there's a mock release out with these changes > > (assuming > > they work :)), I think mock has finally caught up with essential features > > in > > mach and I'm ready to start using mock. > > > > > > > > The only issue I have so far is during init: > > > mock -r fedora-7-i386 init > > INFO: mock.py version 0.8.14 starting... > State Changed: init plugins > State Changed: start > State Changed: lock buildroot > State Changed: clean > State Changed: init > State Changed: lock buildroot > INFO: enabled yum cache > State Changed: cleaning yum metadata > INFO: enabled root cache > State Changed: running yum > ERROR: Command failed. See logs for output. > # mount -n --bind /home/mock/cache/fedora-7-i386/yum_cache/ > /home/mock/fedora-7-i386/root/var/cache/yum > > But if the chroot is already initialized by a previous mock version, them > everything goes fine. > > I have an updated mock rpm if anyone else is willing to try it. Mock 0.8.15 is in updates-stable now and has a fix for this problem. -- Michael From promac at gmail.com Fri Dec 7 07:58:22 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Fri, 7 Dec 2007 05:58:22 -0200 Subject: mock 0.8.9 In-Reply-To: <20071207070448.GA20952@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> Message-ID: <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> On Dec 7, 2007 5:04 AM, Michael E Brown wrote: > On Wed, Dec 05, 2007 at 07:56:11PM -0200, Paulo Cavalcanti wrote: > > On Dec 5, 2007 7:45 PM, Ville Skytt? wrote: > > > > > On Wednesday 05 December 2007, Michael E Brown wrote: > > > > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > > > > Okay, here's another set of patches to implement --with{,out} > options. > > > > > I used git-format-patch this time, and probably did it awkwardly. > But > > > > > hopefully not too badly. Just in case (and for non-git users), > I'll > > > > > also attach a single diff that should apply cleanly to mock-0.8.14 > . > > > > > > > > > > Comments and improvements welcome. :) > > > > > > > > This looks great to me. I've committed this to the repo. > > > > > > Thanks, guys! When there's a mock release out with these changes > > > (assuming > > > they work :)), I think mock has finally caught up with essential > features > > > in > > > mach and I'm ready to start using mock. > > > > > > > > > > > > > The only issue I have so far is during init: > > > > > > mock -r fedora-7-i386 init > > > > INFO: mock.py version 0.8.14 starting... > > State Changed: init plugins > > State Changed: start > > State Changed: lock buildroot > > State Changed: clean > > State Changed: init > > State Changed: lock buildroot > > INFO: enabled yum cache > > State Changed: cleaning yum metadata > > INFO: enabled root cache > > State Changed: running yum > > ERROR: Command failed. See logs for output. > > # mount -n --bind /home/mock/cache/fedora-7-i386/yum_cache/ > > /home/mock/fedora-7-i386/root/var/cache/yum > > > > But if the chroot is already initialized by a previous mock version, > them > > everything goes fine. > > > > I have an updated mock rpm if anyone else is willing to try it. > > Mock 0.8.15 is in updates-stable now and has a fix for this problem. > Thanks! I installed mock 0.8.15 yesterday and I did not see any problem yet. This version seems to be very good. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.lauridsen at googlemail.com Fri Dec 7 09:38:54 2007 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 07 Dec 2007 10:38:54 +0100 Subject: yum update openssh--> infinite loop on dependency check In-Reply-To: <47324ed80712062010p689d566dy533d75e6c375cdb3@mail.gmail.com> References: <47324ed80712062010p689d566dy533d75e6c375cdb3@mail.gmail.com> Message-ID: <475914AE.2020103@googlemail.com> yonas Abraham wrote: > on my Rawhide system, I tried "yum update openssh" and yum went to > infinite loop. it was showing the checking libssl, libcrypto, libldap > et el over and over again. > > > BTW, I know openssh has broken dependency. But I was expecting yum to > display no libssl ... and stop. > > yum-3.2.7-2.fc9 > > /Yonas > > This should be fixed in yum-3.2.8 Tim From dcbw at redhat.com Fri Dec 7 09:51:23 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 04:51:23 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196986308.28417.8.camel@localhost> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> Message-ID: <1197021083.2603.7.camel@localhost.localdomain> On Thu, 2007-12-06 at 18:11 -0600, Callum Lerwick wrote: > On Thu, 2007-12-06 at 07:25 -0600, Jima wrote: > > On Wed, 5 Dec 2007, Callum Lerwick wrote: > > > This is *exactly* what dnsmasq is designed for. From what I can tell, > > > the author added dbus support to dnsmasq *specifically* so > > > NetworkManager could use it. I'm not sure what's up with the disconnect > > > here. :) > > > > Maybe not NM specifically, but certainly conceptually: > > > > "Added method support for DBus (http://www.freedesktop.org/Software/dbus) > > This is a superior way to re-configure dnsmasq on-the-fly with different > > upstream nameservers, as the host moves between networks. DBus support > > must be enabled in src/config.h and should be considered experimental at > > this point. See DBus-interface for the specification of the DBus method > > calls supported." > > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00023.html > http://osdir.com/ml/network.networkmanager.devel/2005-05/msg00012.html > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00036.html > > The dnsmasq author was very eager to have dnsmasq used by NM back in > 2005. I haven't found any explanation as to why it didn't happen. > > Here's a nice fresh thread, it even links back to this one: > > http://www.nabble.com/nm-with-dnsmasq--t4940689.html > > They seem really dead set on sticking with bind. Seriously, why? Who is this they? I'm probably this "they" :) I'm not dead-set on anything; dnsmasq is fine. It didn't happen because back then, I didn't have time to make it happen, and dnsmasq wasn't in Fedora at that point, and nobody else came up with a patch to make it happen. I'm willing to take a patch to put support for dnsmasq into NM in the same way that the named stuff is there, but ideally I want to rework the DNS handling to be more flexible. People these days want to handle the DNS updates differently, from udpating resolv.conf directly, to use dbus-enabled caching-nameservers, to using resolvconf (on SUSE and Debian). We support 1.5 of those out of 3, and that's not good enough. But to get where we'd like to go, NM needs to have more flexibility in the DNS information handling. Dan From atkac at redhat.com Fri Dec 7 10:42:35 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 7 Dec 2007 11:42:35 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196986308.28417.8.camel@localhost> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> Message-ID: <20071207104235.GA7295@traged.englab.brq.redhat.com> On Thu, Dec 06, 2007 at 06:11:48PM -0600, Callum Lerwick wrote: > > On Thu, 2007-12-06 at 07:25 -0600, Jima wrote: > > On Wed, 5 Dec 2007, Callum Lerwick wrote: > > > This is *exactly* what dnsmasq is designed for. From what I can tell, > > > the author added dbus support to dnsmasq *specifically* so > > > NetworkManager could use it. I'm not sure what's up with the disconnect > > > here. :) > > > > Maybe not NM specifically, but certainly conceptually: > > > > "Added method support for DBus (http://www.freedesktop.org/Software/dbus) > > This is a superior way to re-configure dnsmasq on-the-fly with different > > upstream nameservers, as the host moves between networks. DBus support > > must be enabled in src/config.h and should be considered experimental at > > this point. See DBus-interface for the specification of the DBus method > > calls supported." > > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00023.html > http://osdir.com/ml/network.networkmanager.devel/2005-05/msg00012.html > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00036.html > > The dnsmasq author was very eager to have dnsmasq used by NM back in > 2005. I haven't found any explanation as to why it didn't happen. > > Here's a nice fresh thread, it even links back to this one: > > http://www.nabble.com/nm-with-dnsmasq--t4940689.html > > They seem really dead set on sticking with bind. Seriously, why? Why? Generally dnsmasq (or other lightweight) DNS server beat BIND with executable size and performance on one processor systems. In other cases like functionality, performance on multi cores and portability beat BIND other servers. And as I wrote above future of DNS is in DNSSEC. And I'm not sure if dnsmasq author is eager to implement it. That's why BIND should not be marked as irrelevant on this field. Adam -- Adam Tkac, Red Hat, Inc. From s.a.w.vanderknijff at student.hhs.nl Fri Dec 7 11:02:04 2007 From: s.a.w.vanderknijff at student.hhs.nl (Knijff, S.A.W. van der) Date: Fri, 07 Dec 2007 12:02:04 +0100 Subject: Research: effects of diversity on threads from malware Message-ID: I'm performing an research about the effects of diversity on malware. In this research there will be looked at the effects of diversity within an operating system on malware, in this case different GNU/Linux distro's. Cause of the limited time schedule there will only be tested with three distro's, after this there will be picked one distro which is tested on different architectures. There is chosen to work with Fedora Core 6, OpenSuse 10.2 and Ubuntu 6.10. Before starting the real-life tests there is a need to make some assumptions on what will happen when the malware is run on a system. Here for there will be looked at the compiler flags that are used during compilation of the distribution, I'm namely interested in the compiler flags which enhance the security within the distro. Also are there any kind of security measurements besides the compiler flags, for example SELinux, AppArmor, Address Randomization Execshield, PIE or others? I hope that you can provide me with some answers on my questions so i can move on with the research. Stephan From d.lesca at solinos.it Fri Dec 7 11:24:03 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Fri, 07 Dec 2007 12:24:03 +0100 Subject: f8: install via PXE/NFS problem (mount) Message-ID: <1197026643.13142.79.camel@lesca.home.solinos.it> Hi, I have a PXE/NFS systems for install Fedora from fc1 to f7. All work fine. Today I have add also f8 in this system but I having problems with mount via NFS. kickstart.cfg file is load via nfs (ks=nfs:pxesetup:/u/kickstart/ks-8.cfg) and the source files are in pxesetup:/u/f8 The process start correctly, mount an load ks-8.cfg, mount source dir but when anaconda trying remount kickstart file got an error and the setup process stop. I have switch to CTRL+ALT+F2 and I have trying mount some other dir: mount -t nfs pxesetup:/u/f7 /tmp/f7 but the mount command fail with timeout ... Some problema I have get when I have trying add to my PXE system setup last f7respin ... Probably is a kernel-2.6.23 problem or new-NFS problem ?.... Someone can help me? Many thanks. -- Dario Lesca From dcbw at redhat.com Fri Dec 7 11:28:27 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 06:28:27 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071207104235.GA7295@traged.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> Message-ID: <1197026907.4655.6.camel@localhost.localdomain> On Fri, 2007-12-07 at 11:42 +0100, Adam Tkac wrote: > On Thu, Dec 06, 2007 at 06:11:48PM -0600, Callum Lerwick wrote: > > > > On Thu, 2007-12-06 at 07:25 -0600, Jima wrote: > > > On Wed, 5 Dec 2007, Callum Lerwick wrote: > > > > This is *exactly* what dnsmasq is designed for. From what I can tell, > > > > the author added dbus support to dnsmasq *specifically* so > > > > NetworkManager could use it. I'm not sure what's up with the disconnect > > > > here. :) > > > > > > Maybe not NM specifically, but certainly conceptually: > > > > > > "Added method support for DBus (http://www.freedesktop.org/Software/dbus) > > > This is a superior way to re-configure dnsmasq on-the-fly with different > > > upstream nameservers, as the host moves between networks. DBus support > > > must be enabled in src/config.h and should be considered experimental at > > > this point. See DBus-interface for the specification of the DBus method > > > calls supported." > > > > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00023.html > > http://osdir.com/ml/network.networkmanager.devel/2005-05/msg00012.html > > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00036.html > > > > The dnsmasq author was very eager to have dnsmasq used by NM back in > > 2005. I haven't found any explanation as to why it didn't happen. > > > > Here's a nice fresh thread, it even links back to this one: > > > > http://www.nabble.com/nm-with-dnsmasq--t4940689.html > > > > They seem really dead set on sticking with bind. Seriously, why? > > Why? Generally dnsmasq (or other lightweight) DNS server beat BIND > with executable size and performance on one processor systems. In > other cases like functionality, performance on multi cores and > portability beat BIND other servers. And as I wrote above future of > DNS is in DNSSEC. And I'm not sure if dnsmasq author is eager to > implement it. That's why BIND should not be marked as irrelevant on this > field. NM shouldn't really care what the caching nameserver implementation is, anything is fine. It just happens that the current bits talked to named because patches for dnsmasq didn't materialize out of thin air. Plus I'd like to rethink how NM interacts with nameservers (ideally, NM waits for pulls, not pushes stuff out). But that shouldn't stop somebody from writing a patch for pushing info to dnsmasq that works today, if dnsmasq's dbus name is claimed on the system bus. If both named and dnsmasq are claimed, then NM should just pick one (dnsmasq perhaps). If neither name is claimed, NM should fall back to the current behavior of writing out resolv.conf directly. Dan From sundaram at fedoraproject.org Fri Dec 7 11:39:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Dec 2007 17:09:49 +0530 Subject: Research: effects of diversity on threads from malware In-Reply-To: References: Message-ID: <47593105.9030003@fedoraproject.org> Knijff, S.A.W. van der wrote: > I'm performing an research about the effects of diversity > on malware. In this research there will be looked at the > effects of diversity within an operating system on malware, > in this case different GNU/Linux distro's. > Cause of the limited time schedule there will only be > tested with three distro's, after this there will be picked > one distro which is tested on different architectures. > There is chosen to work with Fedora Core 6, OpenSuse 10.2 > and Ubuntu 6.10. > Before starting the real-life tests there is a need to make > some assumptions on what will happen when the malware is > run on a system. Here for there will be looked at the > compiler flags that are used during compilation of the > distribution, I'm namely interested in the compiler flags > which enhance the security within the distro. > Also are there any kind of security measurements besides > the compiler flags, for example SELinux, AppArmor, Address > Randomization Execshield, PIE or others? > I hope that you can provide me with some answers on my > questions so i can move on with the research. Refer http://fedoraproject.org/wiki/Security/Features Rahul From buildsys at redhat.com Fri Dec 7 11:56:41 2007 From: buildsys at redhat.com (Build System) Date: Fri, 7 Dec 2007 06:56:41 -0500 Subject: rawhide report: 20071207 changes Message-ID: <200712071156.lB7Bufwa022681@porkchop.devel.redhat.com> New package ocaml-ocamlnet Network protocols for OCaml New package perl-Class-C3-Componentised Load mix-ins or components to your C3-based class New package perl-MRO-Compat Mro::* interface compatibility for Perls < 5.9.5 New package snake Smart Network Automated Kickstart Environment Removed package ruby-zoom Updated Packages: PolicyKit-0.7-3.fc9 ------------------- * Thu Dec 06 2007 David Zeuthen - 0.7-3.fc9 - Conflict with older hal release * Thu Dec 06 2007 David Zeuthen - 0.7-2.fc9 - BR intltool and adjust License to MIT * Thu Dec 06 2007 David Zeuthen - 0.7-1.fc9 - Update to latest upstream release PolicyKit-gnome-0.7-1.fc9 ------------------------- * Thu Dec 06 2007 David Zeuthen - 0.7-1.fc9 - Update to latest upstream release alacarte-0.11.3-5.fc9 --------------------- * Sun Dec 02 2007 Todd Zullinger - 0.11.3-5 - put the python scripts in sitelib, not sitearch - remove autoconf, automake, and intltool BRs - don't run autoconf/automake in %build - BR perl(XML::Parser) - remove smeg Obsoletes and Provides - minor rpmlint cleanups anaconda-11.4.0.6-1 ------------------- * Thu Dec 06 2007 Chris Lumens - 11.4.0.6-1 - Remove confirmation screen (katzj) - Use a better cio_ignore line (#253075). (dcantrell) - Remove the release notes code entirely. (clumens) - Remove existing InstallMethod code. (clumens) - Add a specfile rule to bump the version. (katzj) - Make the tag an annotated tag (katzj) - Fixup chunk of dwmw2's patch to be cleaner (katzj) - Update mk-images.ppc for new zImage wrapper (#409691) (dwmw2) - Remove gdb.i386 on upgrade (#407431) (katzj) - device nodes are in /dev (or, at least, should be) (notting) anjuta-gdl-0.7.3-2.fc9 ---------------------- * Thu Dec 06 2007 Release Engineering - 0.7.3-2 - Rebuild for deps at-spi-1.21.3-1.fc9 ------------------- * Thu Dec 06 2007 Matthias Clasen - 1.21.3-1 - Update to 1.21.3 autofs-1:5.0.2-19 ----------------- * Thu Dec 06 2007 Jeremy Katz - 1:5.0.2-19 - rebuild for new ldap bes-3.5.1-4.fc9 --------------- * Thu Dec 06 2007 Release Engineering - 3.5.1-4 - Rebuild for deps bind-32:9.5.0-19.b1.fc9 ----------------------- * Thu Dec 06 2007 Adam Tkac 32:9.5.0-19.b1 - 9.5.0b1 (#405281, #392491) * Thu Dec 06 2007 Release Engineering 32:9.5.0-18.6.a7 - Rebuild for deps * Wed Dec 05 2007 Adam Tkac 32:9.5.0-18.5.a7 - build with -O0 cairo-1.5.4-1.fc9 ----------------- * Thu Dec 06 2007 Matthias Clasen - 1.5.4-1 - Update to 1.5.4 centerim-1:4.22.1.20071124-3.fc9 -------------------------------- * Thu Dec 06 2007 Release Engineering - 4.22.1.20071124-3 - Rebuild for deps compizconfig-python-0.6.0.1-2.fc9 --------------------------------- * Sun Nov 25 2007 Mohd Izhar Firdaus Ismail 0.6.0.1-2 - 0.6.0.1 release * Sun Oct 21 2007 Mohd Izhar Firdaus Ismail 0.6.0-1 - official 0.6.0 tarball release * Sun Aug 19 2007 Mohd Izhar Firdaus Ismail 0.6.0-0.3.20071018git - removed devel package cups-pdf-2.4.6-6.fc9.1 ---------------------- * Thu Dec 06 2007 Remi Collet 2.4.6-6.fc9.1 - change module version from 2.4.6.1 to 2.4.7 * Tue Dec 04 2007 Remi Collet 2.4.6-6 - handle unconfined_home_dir_t and unconfined_home_t dbmail-2.2.7-2.fc9 ------------------ * Thu Dec 06 2007 Release Engineering - 2.2.7-2 - Rebuild for deps dejavu-fonts-2.22-0.1.20071206svn2135.fc9 ----------------------------------------- * Thu Dec 06 2007 ??? 2.22-0.1.20071206svn2135 ??? 2.22 rc phase started ??? sync with guidelines desktop-file-utils-0.14-2.fc9 ----------------------------- * Thu Dec 06 2007 Ray Strode 0.14-2 - make icon extension a warning not an error drupal-5.4-2.fc9 ---------------- * Thu Dec 06 2007 Jon Ciesla - 5.4-2 - Fix /files -> /var/lib/drupal dir perms, BZ 414761. ecryptfs-utils-30-2.fc9 ----------------------- * Thu Dec 06 2007 Karsten Hopp 30-2 - rebuild with new openssl libs ekg-1.7-3.fc9 ------------- * Thu Dec 06 2007 Release Engineering - 1.7-3 - Rebuild for deps * Tue Aug 28 2007 Dominik Mierzejewski 1.7-2 - rebuilt for ppc32 - update license tag * Fri Jun 29 2007 Dominik Mierzejewski 1.7-1 - 1.7 final - enable voip support (gsm is in Fedora now) - remove redundant BR: autoconf - support giflib - fixes CVE-2007-166{3,4,5} (bug #246034) ekg2-0.1.1-2.fc9 ---------------- * Thu Dec 06 2007 Release Engineering - 0.1.1-2 - Rebuild for deps emacs-22.1.50-2.fc9 ------------------- * Thu Dec 06 2007 Chip Coldwell 22.1.50-2 - drop -DSYSTEM_PURESIZE_EXTRA=16777216 (bz409581) * Mon Nov 19 2007 Chip Coldwell 22.1.50-1 - pulled sources from GNU CVS * Mon Nov 19 2007 Chip Coldwell 22.1-9 - fixup alternatives mess (bz239745, bz246540) engine_pkcs11-0.1.4-1.fc9 ------------------------- * Thu Dec 06 2007 Matt Anderson - 0.1.4-1 - Update to latest upstream sources esmtp-0.6.0-2.fc9 ----------------- * Thu Dec 06 2007 Release Engineering - 0.6.0-2 - Rebuild for deps f-spot-0.4.1-1.fc9 ------------------ * Thu Dec 06 2007 Matthias Clasen - 0.4.1-1 - Update to 0.4.1 * Sat Nov 17 2007 Matthias Clasen - 0.4.0-4 - Remove comments from ExclusiveArch line (#388581) freeradius-1.1.7-3.4.ipa.fc9 ---------------------------- * Thu Dec 06 2007 Release Engineering - 1.1.7-3.4.ipa - Rebuild for deps fusion-icon-0-0.2.20071206git.fc9 --------------------------------- genchemlab-1.0-7.fc9 -------------------- * Thu Dec 06 2007 Jon Ciesla - 1.0-7 - Fixed env for qt for mock. gkrellm-2.3.1-2.fc9 ------------------- * Tue Dec 04 2007 Ville Skytt?? - 2.3.1-2 - Clean up desktop-file-utils 0.14 warnings. * Mon Dec 03 2007 Hans de Goede 2.3.1-1 - New upstream release 2.3.1 - Drop upstreamed gnutls and lm_sensors-3.0.0 patches * Wed Oct 24 2007 Hans de Goede 2.3.0-5 - Add support for lm_sensors-3.0.0 glest-2.0.1-5.fc9 ----------------- * Thu Dec 06 2007 Aurelien Bompard 2.0.1-5 - fix keyboard (bug 411911) * Sat Dec 01 2007 Aurelien Bompard 2.0.1-4 - add a symlink to the "scenarios" directory (bug 403401) * Sat Oct 06 2007 Aurelien Bompard 2.0.1-3 - incorporate opengl-games-utils' functionality into the wrapper script gmyth-0.4-6.fc9 --------------- * Wed Dec 05 2007 - Bastien Nocera - 0.4-6 - Rebuild gnokii-0.6.22-2.fc9 ------------------- * Thu Dec 06 2007 - Linus Walleij - 0.6.22-2 - Pick up new libssl .solib version dependency. gnome-chemistry-utils-0.8.4-2.fc9 --------------------------------- * Thu Dec 06 2007 Julian Sikorski - 0.8.4-2 - Rebuilt against xulrunner - Cleaned up the spec gnome-terminal-2.21.3-1.fc9 --------------------------- * Thu Dec 06 2007 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 gucharmap-2.21.3-1.fc9 ---------------------- * Thu Dec 06 2007 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 hal-0.5.10-3.fc9 ---------------- * Thu Dec 06 2007 David Zeuthen - 0.5.10-3.fc9 - Grant user 'haldaemon' an authorization to read authorizations of other users htdig-3:3.2.0b6-14.fc9 ---------------------- * Wed Dec 05 2007 Adam Tkac 3:3.2.0b6-14 - rebuild against new openssl jabberd-2.0-0.s11.15.fc9 ------------------------ * Wed Dec 05 2007 Adrian Reber - 2.0-0.s11.15 - rebuilt for new openssl and openldap java-1.7.0-icedtea-1.7.0.0-0.21.b23.snapshot.fc9 ------------------------------------------------ * Wed Dec 05 2007 Thomas Fitzsimmons - 1.7.0.0-0.21.b23.snapshot - Update icedteasnapshot. * Fri Nov 30 2007 Thomas Fitzsimmons - 1.7.0.0-0.21.b23.snapshot - Update icedteasnapshot. - Remove ExclusiveArch. - Assume i386. - Add support for ppc and ppc64. - Bootstrap on ppc and ppc64. jd-1.9.8-0.1.svn1599.fc9.1 -------------------------- * Fri Dec 07 2007 Mamoru Tasaka - 1.9.8-0.1.svn1599 - svn 1599 * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 * Thu Nov 15 2007 Mamoru Tasaka - 1.9.7-0.4.rc071105 - 1.9.7 rc 071115 jfbterm-0.4.7-13.fc9 -------------------- * Mon Dec 03 2007 Mamoru Tasaka - 0.4.7-13 - Add BR: jisksp16-1990-fonts due to fonts-japanese split - Workarround for bug 408731 jwhois-4.0-6.fc9 ---------------- * Thu Dec 06 2007 Vitezslav Crhonek - 4.0-6 - Fix buildroot - Fix matching of cidr-ipv6 network addressed (patch by Lubomir Kundrak ) Resolves: #280941 kasablanca-0.4.0.2-11.fc9 ------------------------- * Thu Dec 06 2007 Rex Dieter 0.4.0.2-11 - respin (for openssl) kdebase3-3.5.8-16.fc9 --------------------- * Tue Dec 04 2007 Rex Dieter - 3.5.8-16 - disable kioslave/smb (f9+, samba-3.2.x/gplv3 ickiness) - omit kde_settings optionals kdelibs-6:3.97.0-4.fc9 ---------------------- * Thu Dec 06 2007 Rex Dieter 3.97.0-4 - drop Req: kdebase-runtime oxygen-icon-theme (at least for now) * Thu Dec 06 2007 Rex Dieter 3.97.0-2 - drop BR: subversion temporarily (due to rawhide breakage) * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 kdelibs3-3.5.8-17.fc9 --------------------- * Tue Dec 04 2007 Rex Dieter - 3.5.8-17 - update openssl patch kernel-2.6.24-0.77.rc4.git4.fc9 ------------------------------- * Thu Dec 06 2007 Dave Jones - 2.6.24-rc4-git4 * Wed Dec 05 2007 Dave Jones - 2.6.24-rc4-git3 * Wed Dec 05 2007 Dave Jones - Don't do sparse builds by default. The output is rarely looked at, and it adds time to the build. libapreq2-2.09-0.rc2.12.fc9 --------------------------- * Mon Dec 03 2007 Bojan Smojver - 2.09-0.rc2.12 - tag for rebuild libetpan-0.52-3.fc9 ------------------- * Thu Dec 06 2007 Andreas Bierfert - 0.52-3 - bump libgnomedb-1:3.0.0-5.fc9 ------------------------ * Thu Dec 06 2007 Jeremy Katz - 1:3.0.0-5 - rebuild for new openssl libnasl-2.2.10-3.fc9 -------------------- * Thu Dec 06 2007 Release Engineering - 2.2.10-3 - Rebuild for deps * Thu Dec 06 2007 Release Engineering - 2.2.10-2 - Rebuild for deps libp11-0.2.3-1.fc9 ------------------ * Thu Dec 06 2007 Matt Anderson - 0.2.3-1 - Update to latest upstream sources libsemanage-2.0.15-1.fc9 ------------------------ * Thu Dec 06 2007 Dan Walsh - 2.0.15-1 - Update to upstream * Fix genhomedircon handling of shells and missing user context template from Dan Walsh. * Copy the store path in semanage_select_store from Dan Walsh. - Add expand-check=0 to semanage.conf libtranslate-0.99-11.fc9 ------------------------ * Thu Dec 06 2007 Dmitry Butskoy - 0.99-11 - add post-marker patch (#411861, from ) - more updates for services.xml (#401621) lvm2-2.02.29-3.fc9 ------------------ * Thu Dec 06 2007 Jeremy Katz - 2.02.29-3 - fix requirements * Thu Dec 06 2007 Alasdair Kergon - 2.02.29-2 - Fold device-mapper build into this lvm2 spec file. man-pages-es-1.55-4.fc9 ----------------------- * Thu Dec 06 2007 Ding-Yi Chen - 1.55-4 - [Bug 226124] Merge Review: man-pages-es (comment 10) - Fix improper SPEC file man-pages-it-2.65-6.fc9 ----------------------- * Thu Dec 06 2007 Ding-Yi Chen - 2.65-6 - [Bug 226125] Merge Review: man-page-it (Comment 8) mod_authz_ldap-0.26-9 --------------------- * Thu Dec 06 2007 Joe Orton 0.26-9 - rebuild for new OpenLDAP * Thu Mar 22 2007 Joe Orton 0.26-8 - add fix for filter paranthesis parsing - update example configurations * Wed Jul 12 2006 Jesse Keating 0.26-7.1 - rebuild mod_perl-2.0.3-15 ----------------- * Thu Dec 06 2007 Joe Orton 2.0.3-15 - rebuild for new OpenLDAP mod_revocator-1.0.2-2.fc9 ------------------------- nspluginwrapper-0.9.91.5-14.fc9 ------------------------------- * Thu Dec 06 2007 Martin Stransky 0.9.91.5-14 - enabled xpcom support - added fix for #393541 - scripts will never fail opal-2.2.11-2.fc9 ----------------- * Thu Dec 06 2007 Jeremy Katz - 2.2.11-2 - rebuild for new openssl and openldap paraview-3.2.1-1.fc9 -------------------- * Mon Dec 03 2007 - Orion Poplawski - 3.2.1-1 - Update to 3.2.1 - Use macros for version numbers - Add patches to fix documentation install location and use assistant-qt4, not install copies of Qt libraries, and not use rpath. - Install ld.so.conf.d file - Fixup desktop files perl-Crypt-OpenSSL-X509-0.5-3.fc9 --------------------------------- * Thu Dec 06 2007 Wes Hardaker - 0.5-3 - Bump to force rebuild with new openssl lib version * Fri Nov 09 2007 Wes Hardaker - 0.5-2 - Update license tag to the proper new wording perl-HTML-Encoding-0.56-1.fc9 ----------------------------- * Thu Dec 06 2007 Ville Skytt?? - 0.56-1 - 0.56. perl-SGML-Parser-OpenSP-0.991-1.fc9 ----------------------------------- * Thu Dec 06 2007 Ville Skytt?? - 0.991-1 - 0.991. perltidy-20071205-1.fc9 ----------------------- * Thu Dec 06 2007 Ville Skytt?? - 20071205-1 - 20071205. - Convert docs to UTF-8. php-pear-Net-FTP-1.3.3-1.fc9.1 ------------------------------ pl-5.6.47-7.fc9 --------------- * Wed Dec 05 2007 Gerard Milmeister - 5.6.47-5 - disable jpl for now * Wed Dec 05 2007 Gerard Milmeister - 5.6.47-4 - enable shared library building * Wed Dec 05 2007 Gerard Milmeister - 5.6.47-1 - new release 5.6.47 plplot-5.8.0-3.fc9 ------------------ * Tue Dec 04 2007 - Orion Poplawski - 5.8.0-3 - Updated multiarch patch for all language example makefiles (bug #342901) rpmlint-0.82-2.fc9 ------------------ * Thu Dec 06 2007 Ville Skytt?? - 0.82-2 - Remove leftover "Affero GPL" from last license list sync (Todd Zullinger). * Thu Dec 06 2007 Ville Skytt?? - 0.82-1 - 0.82, fixes #362441, #388881, #399871, #409941. - Sync Fedora license list with Revision 0.61 (Wiki rev 98). * Fri Sep 28 2007 Todd Zullinger - Sync Fedora license list with Revision 0.55 (Wiki rev 92). rrdtool-1.3-0.2.beta2.fc9 ------------------------- * Thu Dec 06 2007 Jarod Wilson 1.3.0-2.beta2 - Update to rrdtool 1.3 beta2 scim-bridge-0.4.13-6.fc9 ------------------------ * Thu Dec 06 2007 Huang Peng - 0.4.13-6 - Recreate scim-bridge-0.4.13-fix-undefined-symbol.patch. seahorse-2.21.3-1.fc9 --------------------- * Sat Dec 01 2007 Matt Domsch 2.21.3-1 - upgrade to 2.21.3 - enable avahi integration - rpmlint cleanups: remove rpath, unneeded .so, tag config files sip-4.7.3-1.fc9 --------------- * Thu Dec 06 2007 Rex Dieter - 4.7.3-1 - sip-4.7.3 * Wed Dec 05 2007 Rex Dieter - 4.7.2-1 - sip-4.7.2 - omit needless scriptlets syck-0.61-3.fc9 --------------- * Thu Dec 06 2007 Oliver Falk - 0.61-3 - Rebuilt against new PHP synce-trayicon-0.9.0-12.fc9 --------------------------- * Thu Dec 06 2007 Andreas Bierfert - 0.9.0-12 - fix desktop file * Tue Dec 04 2007 Andreas Bierfert - 0.9.0-11 - fix BR * Fri Aug 10 2007 Andreas Bierfert - 0.9.0-10 - fix patch (Dave Jones) tcpdump-14:3.9.8-3.fc9 ---------------------- * Thu Dec 06 2007 Miroslav Lichvar - 14:3.9.8-3 - update IKEv2 support * Thu Dec 06 2007 Jeremy Katz - 14:3.9.8-2 - rebuild for new openssl texlive-texmf-2007-2.fc9 ------------------------ * Thu Dec 06 2007 Jindrich Novy - 2007-2 - don't conflict with tetex-doc (#413141) - remove tex4ht from texlive, it's packaged separately (#411501) totem-2.21.3-3.fc9 ------------------ * Thu Dec 06 2007 - Bastien Nocera - 2.21.3-3 - The mozilla plugin only need gecko-libs, not devel Thanks to Jeremy Katz for noticing * Thu Dec 06 2007 Release Engineering - 2.21.3-2 - Rebuild for deps wmweather+-2.9-6.fc9 -------------------- * Wed Dec 05 2007 Andreas Bierfert - 2.9-6 - bump xscreensaver-1:5.04-3.fc9 ------------------------- * Fri Dec 07 2007 Mamoru Tasaka - 1:5.04-3 - Fix desktop icon name for desktop-file-utils 0.14+ on F-9+ xulrunner-1.9-0.beta1.4.fc9 --------------------------- * Thu Dec 06 2007 Martin Stransky 1.9-0.beta1.4 - fixed mozilla-plugin.pc (#412971) z88dk-1.7-1.fc9 --------------- * Thu Dec 06 2007 Kevin Kofler - 1.7-1 - update to 1.7 - use preferred SF URL - mention TI calculators in description - mkdir buildroot in install - don't try to build target libs with host CFLAGS - fix buggy makefiles leading to silently missing libraries zsh-4.3.4-5.fc9 --------------- * Sat Nov 03 2007 James Antill - 4.3.4-5 - Fix 8bit chars in prompts. - Resolves: 375211 Broken deps for i386 ---------------------------------------------------------- amarok - 1.4.7-12.fc9.i386 requires libssl.so.6 amarok - 1.4.7-12.fc9.i386 requires libcrypto.so.6 anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5 authd - 1.4.3-10.i386 requires libcrypto.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 balsa - 2.3.20-1.fc8.i386 requires libcrypto.so.6 balsa - 2.3.20-1.fc8.i386 requires libssl.so.6 beagle - 0.2.18-2.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 ccsm - 0.6.0-3.fc9.noarch requires compizconfig-python = 0:0.6.0 claws-mail - 3.1.0-1.fc9.i386 requires libldap-2.3.so.0 claws-mail - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail - 3.1.0-1.fc9.i386 requires liblber-2.3.so.0 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.i386 requires libcrypto.so.6 compat-erlang - R10B-10.7.fc7.i386 requires libssl.so.6 compat-erlang - R10B-10.7.fc7.i386 requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 dnssec-tools - 1.3-5.fc9.i386 requires libcrypto.so.6 dnssec-tools-perlmods - 1.3-5.fc9.i386 requires libcrypto.so.6 drivel - 2.1.1-0.2.20071130svn.fc9.i386 requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libssl.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libcrypto.so.6 erlang - R11B-5.3.fc8.i386 requires libssl.so.6 erlang - R11B-5.3.fc8.i386 requires libcrypto.so.6 fedora-ds-base - 1.1.0-2.0.fc9.i386 requires libcrypto.so.6 flow-tools - 0.68.3-1.fc9.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gg2-gadu-gadu - 2.3.0-3.fc8.i386 requires libssl.so.6 gg2-gadu-gadu - 2.3.0-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 heartbeat - 2.1.2-2.fc8.i386 requires libcrypto.so.6 hpijs - 1:2.7.10-1.fc9.i386 requires libcrypto.so.6 hplip - 2.7.10-1.fc9.i386 requires libcrypto.so.6 httrack - 3.42-4.fc9.i386 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ike-scan - 1.9-2.fc8.i386 requires libcrypto.so.6 ipsec-tools - 0.7-3.fc8.i386 requires libcrypto.so.6 kadu - 0.5.0-4.fc8.i386 requires libssl.so.6 kadu - 0.5.0-4.fc8.i386 requires libcrypto.so.6 kadu-mail - 0.5.0-4.fc8.i386 requires libssl.so.6 kadu-mail - 0.5.0-4.fc8.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kdenetwork - 7:3.5.8-4.fc8.i386 requires libssl.so.6 kdenetwork - 7:3.5.8-4.fc8.i386 requires libcrypto.so.6 kdepimlibs - 3.96.2-1.fc9.i386 requires liblber-2.3.so.0 kdepimlibs - 3.96.2-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdeutils - 6:3.96.2-2.fc9.i386 requires libldap-2.3.so.0 kdeutils - 6:3.96.2-2.fc9.i386 requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 libgda-ldap - 1:3.0.1-5.fc9.i386 requires libldap-2.3.so.0 libgda-ldap - 1:3.0.1-5.fc9.i386 requires liblber-2.3.so.0 libgda-mysql - 1:3.0.1-5.fc9.i386 requires libssl.so.6 libgda-mysql - 1:3.0.1-5.fc9.i386 requires libcrypto.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libcrypto.so.6 libsane-hpaio - 2.7.10-1.fc9.i386 requires libcrypto.so.6 libtorrent - 0.11.8-1.fc8.i386 requires libcrypto.so.6 licq - 1.3.4-8.fc9.i386 requires libssl.so.6 licq - 1.3.4-8.fc9.i386 requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libssl.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libcrypto.so.6 linuxdcpp - 1.0.0-2.fc8.i386 requires libssl.so.6 linuxdcpp - 1.0.0-2.fc8.i386 requires libcrypto.so.6 maniadrive - 1.2-5.fc9.i386 requires libphp5-5.2.4.so maniadrive-track-editor - 1.2-5.fc9.i386 requires libphp5-5.2.4.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mysql-administrator - 5.0r12-4.fc9.i386 requires libssl.so.6 mysql-administrator - 5.0r12-4.fc9.i386 requires libcrypto.so.6 mysql-query-browser - 5.0r12-4.fc9.i386 requires libssl.so.6 mysql-query-browser - 5.0r12-4.fc9.i386 requires libcrypto.so.6 nagios-plugins-dhcp - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-dhcp - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nagios-plugins-http - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-http - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nagios-plugins-icmp - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-icmp - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nagios-plugins-ldap - 1.4.8-8.fc9.i386 requires libldap-2.3.so.0 nagios-plugins-ldap - 1.4.8-8.fc9.i386 requires liblber-2.3.so.0 nagios-plugins-mysql - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-mysql - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nagios-plugins-smtp - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-smtp - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nagios-plugins-tcp - 1.4.8-8.fc9.i386 requires libssl.so.6 nagios-plugins-tcp - 1.4.8-8.fc9.i386 requires libcrypto.so.6 nessus-client - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-client - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nessus-gui - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-gui - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nessus-server - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-server - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 pam_mysql - 1:0.7-0.1.rc1.fc9.i386 requires libssl.so.6 pam_mysql - 1:0.7-0.1.rc1.fc9.i386 requires libcrypto.so.6 pam_ssh - 1.92-3.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-Bignum - 0.04-1.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 postfix - 2:2.4.6-1.fc9.i386 requires libldap-2.3.so.0 postfix - 2:2.4.6-1.fc9.i386 requires libssl.so.6 postfix - 2:2.4.6-1.fc9.i386 requires libcrypto.so.6 postfix - 2:2.4.6-1.fc9.i386 requires liblber-2.3.so.0 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 pure-ftpd - 1.0.21-13.fc8.i386 requires libldap-2.3.so.0 pure-ftpd - 1.0.21-13.fc8.i386 requires libssl.so.6 pure-ftpd - 1.0.21-13.fc8.i386 requires libcrypto.so.6 pure-ftpd - 1.0.21-13.fc8.i386 requires liblber-2.3.so.0 qca-ossl - 2.0.0-0.1.beta1.fc9.i386 requires libssl.so.6 qca-ossl - 2.0.0-0.1.beta1.fc9.i386 requires libcrypto.so.6 rapidsvn - 0.9.4-6.fc8.i386 requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires liblber-2.3.so.0 raydium - 1.2-5.fc9.i386 requires libphp5-5.2.4.so rsyslog-mysql - 1.19.11-1.fc9.i386 requires libssl.so.6 rsyslog-mysql - 1.19.11-1.fc9.i386 requires libcrypto.so.6 scsi-target-utils - 0.0-1.20070803snap.fc8.i386 requires libcrypto.so.6 sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 sipsak - 0.9.6-1.fc6.i386 requires libcrypto.so.6 sofia-sip - 1.12.6-11.fc8.i386 requires libssl.so.6 sofia-sip - 1.12.6-11.fc8.i386 requires libcrypto.so.6 sofia-sip-glib - 1.12.6-11.fc8.i386 requires libssl.so.6 sofia-sip-glib - 1.12.6-11.fc8.i386 requires libcrypto.so.6 sofia-sip-utils - 1.12.6-11.fc8.i386 requires libssl.so.6 sofia-sip-utils - 1.12.6-11.fc8.i386 requires libcrypto.so.6 stonith - 2.1.2-2.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 sysprof - 1.0.8-2.fc8.i386 requires kmod-sysprof >= 0:1.0.8 tellico - 1.2.14-2.fc8.i386 requires libssl.so.6 tellico - 1.2.14-2.fc8.i386 requires libcrypto.so.6 tor-core - 0.1.2.18-1.fc9.i386 requires libssl.so.6 tor-core - 0.1.2.18-1.fc9.i386 requires libcrypto.so.6 tripwire - 2.4.1.2-3.fc8.i386 requires libcrypto.so.6 ulogd-mysql - 1.24-5.fc8.i386 requires libssl.so.6 ulogd-mysql - 1.24-5.fc8.i386 requires libcrypto.so.6 valknut - 0.3.11-1.fc8.i386 requires libssl.so.6 valknut - 0.3.11-1.fc8.i386 requires libcrypto.so.6 wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 wireshark - 0.99.7-0.pre2.fc9.i386 requires libcrypto.so.6 wireshark-gnome - 0.99.7-0.pre2.fc9.i386 requires libcrypto.so.6 xar - 1.5.1-4.fc8.i386 requires libcrypto.so.6 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xen - 3.1.2-1.fc9.i386 requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libcrypto.so.6 zabbix - 1.4.2-4.fc9.i386 requires libldap-2.3.so.0 zabbix - 1.4.2-4.fc9.i386 requires liblber-2.3.so.0 zabbix-agent - 1.4.2-4.fc9.i386 requires libldap-2.3.so.0 zabbix-agent - 1.4.2-4.fc9.i386 requires liblber-2.3.so.0 zoneminder - 1.22.3-9.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- amarok - 1.4.7-12.fc9.x86_64 requires libcrypto.so.6()(64bit) amarok - 1.4.7-12.fc9.x86_64 requires libssl.so.6()(64bit) amarok - 1.4.7-12.fc9.i386 requires libssl.so.6 amarok - 1.4.7-12.fc9.i386 requires libcrypto.so.6 anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 anjuta - 1:2.2.0-3.fc8.x86_64 requires liblber-2.3.so.0()(64bit) anjuta - 1:2.2.0-3.fc8.x86_64 requires libldap-2.3.so.0()(64bit) audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit) authd - 1.4.3-10.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) balsa - 2.3.20-1.fc8.x86_64 requires libcrypto.so.6()(64bit) balsa - 2.3.20-1.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.2.18-2.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) ccsm - 0.6.0-3.fc9.noarch requires compizconfig-python = 0:0.6.0 claws-mail - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) compat-erlang - R10B-10.7.fc7.x86_64 requires libcrypto.so.6()(64bit) compat-erlang - R10B-10.7.fc7.x86_64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) dnssec-tools - 1.3-5.fc9.x86_64 requires libcrypto.so.6()(64bit) dnssec-tools-perlmods - 1.3-5.fc9.x86_64 requires libcrypto.so.6()(64bit) drivel - 2.1.1-0.2.20071130svn.fc9.x86_64 requires libcrypto.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.x86_64 requires libssl.so.6()(64bit) fedora-ds-base - 1.1.0-2.0.fc9.i386 requires libcrypto.so.6 fedora-ds-base - 1.1.0-2.0.fc9.x86_64 requires libcrypto.so.6()(64bit) flow-tools - 0.68.3-1.fc9.x86_64 requires libcrypto.so.6()(64bit) flow-tools - 0.68.3-1.fc9.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gg2-gadu-gadu - 2.3.0-3.fc8.x86_64 requires libssl.so.6()(64bit) gg2-gadu-gadu - 2.3.0-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) heartbeat - 2.1.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) heartbeat - 2.1.2-2.fc8.i386 requires libcrypto.so.6 hpijs - 1:2.7.10-1.fc9.i386 requires libcrypto.so.6 hpijs - 1:2.7.10-1.fc9.x86_64 requires libcrypto.so.6()(64bit) hplip - 2.7.10-1.fc9.x86_64 requires libcrypto.so.6()(64bit) httrack - 3.42-4.fc9.i386 requires openssl = 0:0.9.8b httrack - 3.42-4.fc9.x86_64 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) ike-scan - 1.9-2.fc8.x86_64 requires libcrypto.so.6()(64bit) ipsec-tools - 0.7-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.x86_64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.x86_64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.x86_64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.x86_64 requires libcrypto.so.6()(64bit) kdenetwork - 7:3.5.8-4.fc8.x86_64 requires libssl.so.6()(64bit) kdenetwork - 7:3.5.8-4.fc8.x86_64 requires libcrypto.so.6()(64bit) kdepimlibs - 3.96.2-1.fc9.i386 requires liblber-2.3.so.0 kdepimlibs - 3.96.2-1.fc9.i386 requires libldap-2.3.so.0 kdepimlibs - 3.96.2-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdepimlibs - 3.96.2-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.i386 requires libldap-2.3.so.0 kdeutils - 6:3.96.2-2.fc9.i386 requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) libgda-ldap - 1:3.0.1-5.fc9.x86_64 requires liblber-2.3.so.0()(64bit) libgda-ldap - 1:3.0.1-5.fc9.x86_64 requires libldap-2.3.so.0()(64bit) libgda-mysql - 1:3.0.1-5.fc9.x86_64 requires libcrypto.so.6()(64bit) libgda-mysql - 1:3.0.1-5.fc9.x86_64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libssl.so.6()(64bit) libsane-hpaio - 2.7.10-1.fc9.x86_64 requires libcrypto.so.6()(64bit) libtorrent - 0.11.8-1.fc8.i386 requires libcrypto.so.6 libtorrent - 0.11.8-1.fc8.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.x86_64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.x86_64 requires libssl.so.6()(64bit) maniadrive - 1.2-5.fc9.x86_64 requires libphp5-5.2.4.so()(64bit) maniadrive-track-editor - 1.2-5.fc9.x86_64 requires libphp5-5.2.4.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mysql-administrator - 5.0r12-4.fc9.x86_64 requires libcrypto.so.6()(64bit) mysql-administrator - 5.0r12-4.fc9.x86_64 requires libssl.so.6()(64bit) mysql-query-browser - 5.0r12-4.fc9.x86_64 requires libcrypto.so.6()(64bit) mysql-query-browser - 5.0r12-4.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-dhcp - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-dhcp - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-http - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-http - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-icmp - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-icmp - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-ldap - 1.4.8-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) nagios-plugins-ldap - 1.4.8-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) nagios-plugins-mysql - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-mysql - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-smtp - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-smtp - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nagios-plugins-tcp - 1.4.8-8.fc9.x86_64 requires libssl.so.6()(64bit) nagios-plugins-tcp - 1.4.8-8.fc9.x86_64 requires libcrypto.so.6()(64bit) nessus-client - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nessus-client - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nessus-server - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-server - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 pam_mysql - 1:0.7-0.1.rc1.fc9.x86_64 requires libssl.so.6()(64bit) pam_mysql - 1:0.7-0.1.rc1.fc9.x86_64 requires libcrypto.so.6()(64bit) pam_mysql - 1:0.7-0.1.rc1.fc9.i386 requires libssl.so.6 pam_mysql - 1:0.7-0.1.rc1.fc9.i386 requires libcrypto.so.6 pam_ssh - 1.92-3.fc9.x86_64 requires libcrypto.so.6()(64bit) pam_ssh - 1.92-3.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-Bignum - 0.04-1.fc9.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) postfix - 2:2.4.6-1.fc9.i386 requires libldap-2.3.so.0 postfix - 2:2.4.6-1.fc9.i386 requires libssl.so.6 postfix - 2:2.4.6-1.fc9.i386 requires libcrypto.so.6 postfix - 2:2.4.6-1.fc9.i386 requires liblber-2.3.so.0 postfix - 2:2.4.6-1.fc9.x86_64 requires libcrypto.so.6()(64bit) postfix - 2:2.4.6-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) postfix - 2:2.4.6-1.fc9.x86_64 requires libssl.so.6()(64bit) postfix - 2:2.4.6-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) pure-ftpd - 1.0.21-13.fc8.x86_64 requires libcrypto.so.6()(64bit) pure-ftpd - 1.0.21-13.fc8.x86_64 requires libldap-2.3.so.0()(64bit) pure-ftpd - 1.0.21-13.fc8.x86_64 requires libssl.so.6()(64bit) pure-ftpd - 1.0.21-13.fc8.x86_64 requires liblber-2.3.so.0()(64bit) qca-ossl - 2.0.0-0.1.beta1.fc9.x86_64 requires libssl.so.6()(64bit) qca-ossl - 2.0.0-0.1.beta1.fc9.x86_64 requires libcrypto.so.6()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires liblber-2.3.so.0()(64bit) raydium - 1.2-5.fc9.i386 requires libphp5-5.2.4.so raydium - 1.2-5.fc9.x86_64 requires libphp5-5.2.4.so()(64bit) rsyslog-mysql - 1.19.11-1.fc9.x86_64 requires libssl.so.6()(64bit) rsyslog-mysql - 1.19.11-1.fc9.x86_64 requires libcrypto.so.6()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.x86_64 requires libcrypto.so.6()(64bit) sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) sipsak - 0.9.6-1.fc6.x86_64 requires libcrypto.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.x86_64 requires libssl.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.x86_64 requires libcrypto.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.i386 requires libssl.so.6 sofia-sip - 1.12.6-11.fc8.i386 requires libcrypto.so.6 sofia-sip-glib - 1.12.6-11.fc8.i386 requires libssl.so.6 sofia-sip-glib - 1.12.6-11.fc8.i386 requires libcrypto.so.6 sofia-sip-glib - 1.12.6-11.fc8.x86_64 requires libssl.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.x86_64 requires libcrypto.so.6()(64bit) sofia-sip-utils - 1.12.6-11.fc8.x86_64 requires libssl.so.6()(64bit) sofia-sip-utils - 1.12.6-11.fc8.x86_64 requires libcrypto.so.6()(64bit) stonith - 2.1.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) stonith - 2.1.2-2.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.x86_64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.x86_64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires liblber-2.3.so.0()(64bit) sysprof - 1.0.8-2.fc8.x86_64 requires kmod-sysprof >= 0:1.0.8 tellico - 1.2.14-2.fc8.x86_64 requires libcrypto.so.6()(64bit) tellico - 1.2.14-2.fc8.x86_64 requires libssl.so.6()(64bit) tor-core - 0.1.2.18-1.fc9.x86_64 requires libssl.so.6()(64bit) tor-core - 0.1.2.18-1.fc9.x86_64 requires libcrypto.so.6()(64bit) tripwire - 2.4.1.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) ulogd-mysql - 1.24-5.fc8.x86_64 requires libssl.so.6()(64bit) ulogd-mysql - 1.24-5.fc8.x86_64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.x86_64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.x86_64 requires libssl.so.6()(64bit) wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 wireshark - 0.99.7-0.pre2.fc9.i386 requires libcrypto.so.6 wireshark - 0.99.7-0.pre2.fc9.x86_64 requires libcrypto.so.6()(64bit) wireshark-gnome - 0.99.7-0.pre2.fc9.x86_64 requires libcrypto.so.6()(64bit) xar - 1.5.1-4.fc8.i386 requires libcrypto.so.6 xar - 1.5.1-4.fc8.x86_64 requires libcrypto.so.6()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xen - 3.1.2-1.fc9.x86_64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libcrypto.so.6()(64bit) zabbix - 1.4.2-4.fc9.x86_64 requires libldap-2.3.so.0()(64bit) zabbix - 1.4.2-4.fc9.x86_64 requires liblber-2.3.so.0()(64bit) zabbix-agent - 1.4.2-4.fc9.x86_64 requires libldap-2.3.so.0()(64bit) zabbix-agent - 1.4.2-4.fc9.x86_64 requires liblber-2.3.so.0()(64bit) zoneminder - 1.22.3-9.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- amarok - 1.4.7-12.fc9.ppc64 requires libcrypto.so.6()(64bit) amarok - 1.4.7-12.fc9.ppc64 requires libssl.so.6()(64bit) amarok - 1.4.7-12.fc9.ppc requires libssl.so.6 amarok - 1.4.7-12.fc9.ppc requires libcrypto.so.6 anjuta - 1:2.2.0-3.fc8.ppc requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.ppc requires libldap-2.3.so.0 audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5 authd - 1.4.3-10.ppc requires libcrypto.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 balsa - 2.3.20-1.fc8.ppc requires libcrypto.so.6 balsa - 2.3.20-1.fc8.ppc requires libssl.so.6 beagle - 0.2.18-2.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 ccsm - 0.6.0-3.fc9.noarch requires compizconfig-python = 0:0.6.0 claws-mail - 3.1.0-1.fc9.ppc requires libldap-2.3.so.0 claws-mail - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail - 3.1.0-1.fc9.ppc requires liblber-2.3.so.0 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc requires libcrypto.so.6 compat-erlang - R10B-10.7.fc7.ppc requires libssl.so.6 compat-erlang - R10B-10.7.fc7.ppc requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 dnssec-tools - 1.3-5.fc9.ppc requires libcrypto.so.6 dnssec-tools-perlmods - 1.3-5.fc9.ppc requires libcrypto.so.6 drivel - 2.1.1-0.2.20071130svn.fc9.ppc requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libssl.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libcrypto.so.6 erlang - R11B-5.3.fc8.ppc requires libssl.so.6 erlang - R11B-5.3.fc8.ppc requires libcrypto.so.6 fedora-ds-base - 1.1.0-2.0.fc9.ppc requires libcrypto.so.6 fedora-ds-base - 1.1.0-2.0.fc9.ppc64 requires libcrypto.so.6()(64bit) flow-tools - 0.68.3-1.fc9.ppc64 requires libcrypto.so.6()(64bit) flow-tools - 0.68.3-1.fc9.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gg2-gadu-gadu - 2.3.0-3.fc8.ppc requires libssl.so.6 gg2-gadu-gadu - 2.3.0-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 heartbeat - 2.1.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) heartbeat - 2.1.2-2.fc8.ppc requires libcrypto.so.6 hpijs - 1:2.7.10-1.fc9.ppc64 requires libcrypto.so.6()(64bit) hpijs - 1:2.7.10-1.fc9.ppc requires libcrypto.so.6 hplip - 2.7.10-1.fc9.ppc requires libcrypto.so.6 httrack - 3.42-4.fc9.ppc requires openssl = 0:0.9.8b httrack - 3.42-4.fc9.ppc64 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 ike-scan - 1.9-2.fc8.ppc requires libcrypto.so.6 ipsec-tools - 0.7-3.fc8.ppc requires libcrypto.so.6 kadu - 0.5.0-4.fc8.ppc requires libssl.so.6 kadu - 0.5.0-4.fc8.ppc requires libcrypto.so.6 kadu-mail - 0.5.0-4.fc8.ppc requires libssl.so.6 kadu-mail - 0.5.0-4.fc8.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kdenetwork - 7:3.5.8-4.fc8.ppc requires libssl.so.6 kdenetwork - 7:3.5.8-4.fc8.ppc requires libcrypto.so.6 kdepimlibs - 3.96.2-1.fc9.ppc requires liblber-2.3.so.0 kdepimlibs - 3.96.2-1.fc9.ppc requires libldap-2.3.so.0 kdepimlibs - 3.96.2-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdepimlibs - 3.96.2-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.ppc requires libldap-2.3.so.0 kdeutils - 6:3.96.2-2.fc9.ppc requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libgda-ldap - 1:3.0.1-5.fc9.ppc requires libldap-2.3.so.0 libgda-ldap - 1:3.0.1-5.fc9.ppc requires liblber-2.3.so.0 libgda-mysql - 1:3.0.1-5.fc9.ppc requires libssl.so.6 libgda-mysql - 1:3.0.1-5.fc9.ppc requires libcrypto.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libcrypto.so.6 libsane-hpaio - 2.7.10-1.fc9.ppc requires libcrypto.so.6 libtorrent - 0.11.8-1.fc8.ppc64 requires libcrypto.so.6()(64bit) libtorrent - 0.11.8-1.fc8.ppc requires libcrypto.so.6 licq - 1.3.4-8.fc9.ppc requires libssl.so.6 licq - 1.3.4-8.fc9.ppc requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libssl.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libcrypto.so.6 linuxdcpp - 1.0.0-2.fc8.ppc requires libssl.so.6 linuxdcpp - 1.0.0-2.fc8.ppc requires libcrypto.so.6 maniadrive - 1.2-5.fc9.ppc requires libphp5-5.2.4.so maniadrive-track-editor - 1.2-5.fc9.ppc requires libphp5-5.2.4.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo mysql-administrator - 5.0r12-4.fc9.ppc requires libssl.so.6 mysql-administrator - 5.0r12-4.fc9.ppc requires libcrypto.so.6 mysql-query-browser - 5.0r12-4.fc9.ppc requires libssl.so.6 mysql-query-browser - 5.0r12-4.fc9.ppc requires libcrypto.so.6 nagios-plugins-dhcp - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-dhcp - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nagios-plugins-http - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-http - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nagios-plugins-icmp - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-icmp - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nagios-plugins-ldap - 1.4.8-8.fc9.ppc requires libldap-2.3.so.0 nagios-plugins-ldap - 1.4.8-8.fc9.ppc requires liblber-2.3.so.0 nagios-plugins-mysql - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-mysql - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nagios-plugins-smtp - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-smtp - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 nagios-plugins-tcp - 1.4.8-8.fc9.ppc requires libssl.so.6 nagios-plugins-tcp - 1.4.8-8.fc9.ppc requires libcrypto.so.6 nessus-client - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-client - 2.2.9-2.fc7.ppc requires libcrypto.so.6 nessus-gui - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-gui - 2.2.9-2.fc7.ppc requires libcrypto.so.6 nessus-server - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-server - 2.2.9-2.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 pam_mysql - 1:0.7-0.1.rc1.fc9.ppc64 requires libssl.so.6()(64bit) pam_mysql - 1:0.7-0.1.rc1.fc9.ppc64 requires libcrypto.so.6()(64bit) pam_mysql - 1:0.7-0.1.rc1.fc9.ppc requires libssl.so.6 pam_mysql - 1:0.7-0.1.rc1.fc9.ppc requires libcrypto.so.6 pam_ssh - 1.92-3.fc9.ppc requires libcrypto.so.6 pam_ssh - 1.92-3.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-Bignum - 0.04-1.fc9.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 postfix - 2:2.4.6-1.fc9.ppc requires libldap-2.3.so.0 postfix - 2:2.4.6-1.fc9.ppc requires libssl.so.6 postfix - 2:2.4.6-1.fc9.ppc requires libcrypto.so.6 postfix - 2:2.4.6-1.fc9.ppc requires liblber-2.3.so.0 postfix - 2:2.4.6-1.fc9.ppc64 requires libcrypto.so.6()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires libssl.so.6()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 pure-ftpd - 1.0.21-13.fc8.ppc requires libldap-2.3.so.0 pure-ftpd - 1.0.21-13.fc8.ppc requires libssl.so.6 pure-ftpd - 1.0.21-13.fc8.ppc requires libcrypto.so.6 pure-ftpd - 1.0.21-13.fc8.ppc requires liblber-2.3.so.0 qca-ossl - 2.0.0-0.1.beta1.fc9.ppc requires libssl.so.6 qca-ossl - 2.0.0-0.1.beta1.fc9.ppc requires libcrypto.so.6 rapidsvn - 0.9.4-6.fc8.ppc requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires liblber-2.3.so.0 raydium - 1.2-5.fc9.ppc requires libphp5-5.2.4.so raydium - 1.2-5.fc9.ppc64 requires libphp5-5.2.4.so()(64bit) rsyslog-mysql - 1.19.11-1.fc9.ppc requires libssl.so.6 rsyslog-mysql - 1.19.11-1.fc9.ppc requires libcrypto.so.6 scsi-target-utils - 0.0-1.20070803snap.fc8.ppc requires libcrypto.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 sipsak - 0.9.6-1.fc6.ppc requires libcrypto.so.6 sofia-sip - 1.12.6-11.fc8.ppc requires libssl.so.6 sofia-sip - 1.12.6-11.fc8.ppc requires libcrypto.so.6 sofia-sip - 1.12.6-11.fc8.ppc64 requires libssl.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.ppc64 requires libcrypto.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.ppc64 requires libssl.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.ppc64 requires libcrypto.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.ppc requires libssl.so.6 sofia-sip-glib - 1.12.6-11.fc8.ppc requires libcrypto.so.6 sofia-sip-utils - 1.12.6-11.fc8.ppc requires libssl.so.6 sofia-sip-utils - 1.12.6-11.fc8.ppc requires libcrypto.so.6 stonith - 2.1.2-2.fc8.ppc requires libcrypto.so.6 stonith - 2.1.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc requires libldap-2.3.so.0 subversion - 1.4.4-7.ppc requires libssl.so.6 subversion - 1.4.4-7.ppc requires libcrypto.so.6 subversion - 1.4.4-7.ppc requires liblber-2.3.so.0 tellico - 1.2.14-2.fc8.ppc requires libssl.so.6 tellico - 1.2.14-2.fc8.ppc requires libcrypto.so.6 tor-core - 0.1.2.18-1.fc9.ppc requires libssl.so.6 tor-core - 0.1.2.18-1.fc9.ppc requires libcrypto.so.6 tripwire - 2.4.1.2-3.fc8.ppc requires libcrypto.so.6 ulogd-mysql - 1.24-5.fc8.ppc requires libssl.so.6 ulogd-mysql - 1.24-5.fc8.ppc requires libcrypto.so.6 valknut - 0.3.11-1.fc8.ppc requires libssl.so.6 valknut - 0.3.11-1.fc8.ppc requires libcrypto.so.6 wireshark - 0.99.7-0.pre2.fc9.ppc requires libcrypto.so.6 wireshark - 0.99.7-0.pre2.fc9.ppc64 requires libcrypto.so.6()(64bit) wireshark-gnome - 0.99.7-0.pre2.fc9.ppc requires libcrypto.so.6 xar - 1.5.1-4.fc8.ppc requires libcrypto.so.6 xar - 1.5.1-4.fc8.ppc64 requires libcrypto.so.6()(64bit) xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libcrypto.so.6 zabbix - 1.4.2-4.fc9.ppc requires libldap-2.3.so.0 zabbix - 1.4.2-4.fc9.ppc requires liblber-2.3.so.0 zabbix-agent - 1.4.2-4.fc9.ppc requires libldap-2.3.so.0 zabbix-agent - 1.4.2-4.fc9.ppc requires liblber-2.3.so.0 zoneminder - 1.22.3-9.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- amarok - 1.4.7-12.fc9.ppc64 requires libcrypto.so.6()(64bit) amarok - 1.4.7-12.fc9.ppc64 requires libssl.so.6()(64bit) audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit) authd - 1.4.3-10.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) balsa - 2.3.20-1.fc8.ppc64 requires libcrypto.so.6()(64bit) balsa - 2.3.20-1.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) compat-erlang - R10B-10.7.fc7.ppc64 requires libcrypto.so.6()(64bit) compat-erlang - R10B-10.7.fc7.ppc64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) dnssec-tools - 1.3-5.fc9.ppc64 requires libcrypto.so.6()(64bit) dnssec-tools-perlmods - 1.3-5.fc9.ppc64 requires libcrypto.so.6()(64bit) drivel - 2.1.1-0.2.20071130svn.fc9.ppc64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.ppc64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.ppc64 requires libssl.so.6()(64bit) fedora-ds-base - 1.1.0-2.0.fc9.ppc64 requires libcrypto.so.6()(64bit) flow-tools - 0.68.3-1.fc9.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gg2-gadu-gadu - 2.3.0-3.fc8.ppc64 requires libssl.so.6()(64bit) gg2-gadu-gadu - 2.3.0-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) heartbeat - 2.1.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) hpijs - 1:2.7.10-1.fc9.ppc64 requires libcrypto.so.6()(64bit) hplip - 2.7.10-1.fc9.ppc64 requires libcrypto.so.6()(64bit) httrack - 3.42-4.fc9.ppc64 requires openssl = 0:0.9.8b ike-scan - 1.9-2.fc8.ppc64 requires libcrypto.so.6()(64bit) ipsec-tools - 0.7-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.ppc64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.ppc64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.ppc64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.ppc64 requires libcrypto.so.6()(64bit) kdenetwork - 7:3.5.8-4.fc8.ppc64 requires libssl.so.6()(64bit) kdenetwork - 7:3.5.8-4.fc8.ppc64 requires libcrypto.so.6()(64bit) kdepimlibs - 3.96.2-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdepimlibs - 3.96.2-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kdeutils - 6:3.96.2-2.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libgda-ldap - 1:3.0.1-5.fc9.ppc64 requires liblber-2.3.so.0()(64bit) libgda-ldap - 1:3.0.1-5.fc9.ppc64 requires libldap-2.3.so.0()(64bit) libgda-mysql - 1:3.0.1-5.fc9.ppc64 requires libcrypto.so.6()(64bit) libgda-mysql - 1:3.0.1-5.fc9.ppc64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libssl.so.6()(64bit) libsane-hpaio - 2.7.10-1.fc9.ppc64 requires libcrypto.so.6()(64bit) libtorrent - 0.11.8-1.fc8.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.ppc64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.ppc64 requires libssl.so.6()(64bit) maniadrive - 1.2-5.fc9.ppc64 requires libphp5-5.2.4.so()(64bit) maniadrive-track-editor - 1.2-5.fc9.ppc64 requires libphp5-5.2.4.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mysql-administrator - 5.0r12-4.fc9.ppc64 requires libcrypto.so.6()(64bit) mysql-administrator - 5.0r12-4.fc9.ppc64 requires libssl.so.6()(64bit) mysql-query-browser - 5.0r12-4.fc9.ppc64 requires libcrypto.so.6()(64bit) mysql-query-browser - 5.0r12-4.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-dhcp - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-dhcp - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-http - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-http - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-icmp - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-icmp - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-ldap - 1.4.8-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) nagios-plugins-ldap - 1.4.8-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) nagios-plugins-mysql - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-mysql - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-smtp - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-smtp - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) nagios-plugins-tcp - 1.4.8-8.fc9.ppc64 requires libssl.so.6()(64bit) nagios-plugins-tcp - 1.4.8-8.fc9.ppc64 requires libcrypto.so.6()(64bit) nessus-client - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) nessus-client - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) nessus-server - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-server - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 pam_mysql - 1:0.7-0.1.rc1.fc9.ppc64 requires libssl.so.6()(64bit) pam_mysql - 1:0.7-0.1.rc1.fc9.ppc64 requires libcrypto.so.6()(64bit) pam_ssh - 1.92-3.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-Bignum - 0.04-1.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires libcrypto.so.6()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires libssl.so.6()(64bit) postfix - 2:2.4.6-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) pure-ftpd - 1.0.21-13.fc8.ppc64 requires libcrypto.so.6()(64bit) pure-ftpd - 1.0.21-13.fc8.ppc64 requires libldap-2.3.so.0()(64bit) pure-ftpd - 1.0.21-13.fc8.ppc64 requires libssl.so.6()(64bit) pure-ftpd - 1.0.21-13.fc8.ppc64 requires liblber-2.3.so.0()(64bit) qca-ossl - 2.0.0-0.1.beta1.fc9.ppc64 requires libssl.so.6()(64bit) qca-ossl - 2.0.0-0.1.beta1.fc9.ppc64 requires libcrypto.so.6()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires liblber-2.3.so.0()(64bit) raydium - 1.2-5.fc9.ppc64 requires libphp5-5.2.4.so()(64bit) rsyslog-mysql - 1.19.11-1.fc9.ppc64 requires libssl.so.6()(64bit) rsyslog-mysql - 1.19.11-1.fc9.ppc64 requires libcrypto.so.6()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) sipsak - 0.9.6-1.fc6.ppc64 requires libcrypto.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.ppc64 requires libssl.so.6()(64bit) sofia-sip - 1.12.6-11.fc8.ppc64 requires libcrypto.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.ppc64 requires libssl.so.6()(64bit) sofia-sip-glib - 1.12.6-11.fc8.ppc64 requires libcrypto.so.6()(64bit) sofia-sip-utils - 1.12.6-11.fc8.ppc64 requires libssl.so.6()(64bit) sofia-sip-utils - 1.12.6-11.fc8.ppc64 requires libcrypto.so.6()(64bit) stonith - 2.1.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) tellico - 1.2.14-2.fc8.ppc64 requires libcrypto.so.6()(64bit) tellico - 1.2.14-2.fc8.ppc64 requires libssl.so.6()(64bit) tor-core - 0.1.2.18-1.fc9.ppc64 requires libssl.so.6()(64bit) tor-core - 0.1.2.18-1.fc9.ppc64 requires libcrypto.so.6()(64bit) tripwire - 2.4.1.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) ulogd-mysql - 1.24-5.fc8.ppc64 requires libssl.so.6()(64bit) ulogd-mysql - 1.24-5.fc8.ppc64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.ppc64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.ppc64 requires libssl.so.6()(64bit) wireshark - 0.99.7-0.pre2.fc9.ppc64 requires libcrypto.so.6()(64bit) wireshark-gnome - 0.99.7-0.pre2.fc9.ppc64 requires libcrypto.so.6()(64bit) xar - 1.5.1-4.fc8.ppc64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libcrypto.so.6()(64bit) zabbix - 1.4.2-4.fc9.ppc64 requires libldap-2.3.so.0()(64bit) zabbix - 1.4.2-4.fc9.ppc64 requires liblber-2.3.so.0()(64bit) zabbix-agent - 1.4.2-4.fc9.ppc64 requires libldap-2.3.so.0()(64bit) zabbix-agent - 1.4.2-4.fc9.ppc64 requires liblber-2.3.so.0()(64bit) zoneminder - 1.22.3-9.fc8.ppc64 requires libcrypto.so.6()(64bit) From mk at crc.dk Fri Dec 7 11:57:59 2007 From: mk at crc.dk (Mogens Kjaer) Date: Fri, 07 Dec 2007 12:57:59 +0100 Subject: f8: install via PXE/NFS problem (mount) In-Reply-To: <1197026643.13142.79.camel@lesca.home.solinos.it> References: <1197026643.13142.79.camel@lesca.home.solinos.it> Message-ID: <47593547.9060904@crc.dk> Dario Lesca wrote: ... > I have switch to CTRL+ALT+F2 and I have trying mount some other dir: > > mount -t nfs pxesetup:/u/f7 /tmp/f7 > > but the mount command fail with timeout ... Does the mount command work if you append "-o nolock"? Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From galibert at pobox.com Fri Dec 7 12:53:46 2007 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 7 Dec 2007 13:53:46 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197026907.4655.6.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> Message-ID: <20071207125346.GA8298@dspnet.fr.eu.org> On Fri, Dec 07, 2007 at 06:28:27AM -0500, Dan Williams wrote: > NM shouldn't really care what the caching nameserver implementation is, > anything is fine. It just happens that the current bits talked to named > because patches for dnsmasq didn't materialize out of thin air. Plus > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > for pulls, not pushes stuff out). No, it should stay a push. DNS configuration changes happen way less often than DNS lookups, so the communication should be done on changes (after an initial pull of course, which should include a "hi, I'm here, talk to me"). OG. From paul at all-the-johnsons.co.uk Fri Dec 7 12:55:48 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Fri, 7 Dec 2007 12:55:48 +0000 Subject: rawhide report: 20071207 changes In-Reply-To: <200712071156.lB7Bufwa022681@porkchop.devel.redhat.com> References: <200712071156.lB7Bufwa022681@porkchop.devel.redhat.com> Message-ID: <20071207125548.M84424@all-the-johnsons.co.uk> Hi, > Broken deps for x86_64 > ---------------------------------------------------------- > amarok - 1.4.7-12.fc9.x86_64 requires libcrypto.so.6()(64bit) > amarok - 1.4.7-12.fc9.x86_64 requires libssl.so.6()(64bit) > amarok - 1.4.7-12.fc9.i386 requires libssl.so.6 > amarok - 1.4.7-12.fc9.i386 requires libcrypto.so.6 With so many packages reliant on openssl, is there any way that if openssl is rebuilt, the build system automatically tries to rebuild the packages reliant on it? Rawhide is pretty unusable with so many packages broken... TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From pertusus at free.fr Fri Dec 7 13:24:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 7 Dec 2007 14:24:27 +0100 Subject: Package alien In-Reply-To: <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> Message-ID: <20071207132427.GA2604@free.fr> On Thu, Dec 06, 2007 at 12:50:25PM -0900, Jeff Spaleta wrote: > On Dec 5, 2007 3:51 PM, King InuYasha wrote: > > Though, will dpkg and the like be purposely crippled on Fedora like > > rpm is on Debian systems? It probably would be a good idea to patch > > dpkg and stuff to make sure they don't work as standard packagers, but > > rather just helpers to alien, as RPM does on a Debian system. We want > > to avoid the possibility of package jumbling..... > > I would certainly concur with this. Without making a judgment as to > the value of having alien or other alternative packaging tools in the > repository.. I would agree that if we are going to be putting dpkg and > friends into the repository that they come configured by default to > only act as helpers for using Fedora as a (re)packaging host. > Enabling functionality beyond that should be relatively difficult to I don't think that we should do anything special with dpgk. Just recompile it as is from upstream. If users are dumb and use dpkg to install packages it is their responsibility. Just like when they do ./configure --prefix=/use --sysconfdir=/etc && make && make install Or use CPAN. Our responsibility is integration, not being smart for dumb users. > enable if not disabled entirely at buildtime. There maybe some rather > clever unorthodox ways to make use of a fully capable dpkg in other > ways, but I don't want users accidental stumbling into those > situations just because they installed dpkg and followed a google'd > recipe article to have dpkg replace rpm on their Fedora system. I can't see what is wrong with having 'dpkg replace rpm on their Fedora system' if it works and it is what the user intends to do. The target for dpkg are not casual users, and casual users won't use it anyway. In %description, I put dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet. It may admitedly be enhanced, to say something like dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet, and in any case you are likely to trash your system if you install packages using dpkg. -- Pat From ajackson at redhat.com Fri Dec 7 15:08:54 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 07 Dec 2007 10:08:54 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: References: <1196976223.2303.51.camel@localhost.localdomain> Message-ID: <1197040134.2303.77.camel@localhost.localdomain> On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > Adam Jackson redhat.com> writes: > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > unless someone has a compelling reason not to. > > What's the problem with depending on Perl? It's a useful scripting language, > used in a lot of packages, thus so many things require it that you'll be > hard-pressed to find a working system without Perl, especially an X11-enabled > one. For example, kdelibs requires Perl (it's used for things like > kconf_update), so any KDE system will always have Perl anyway. I'm not arguing against perl qua perl. I am arguing against needless arcs in the dep graph. This one package has a perl dependency solely because it provides a single perl script that no one is ever likely to use. Sure, it's just one dep, but every dep counts. The complexity of the graph directly affects runtime performance for rpm and yum, and the ability to use trimmed subsets of Fedora for custom purposes. The graph is important. We argue so much for correcness in initial packaging. We should be correct at the system level too. - ajax From dcbw at redhat.com Fri Dec 7 14:37:27 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 09:37:27 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071207125346.GA8298@dspnet.fr.eu.org> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> Message-ID: <1197038247.10672.2.camel@localhost.localdomain> On Fri, 2007-12-07 at 13:53 +0100, Olivier Galibert wrote: > On Fri, Dec 07, 2007 at 06:28:27AM -0500, Dan Williams wrote: > > NM shouldn't really care what the caching nameserver implementation is, > > anything is fine. It just happens that the current bits talked to named > > because patches for dnsmasq didn't materialize out of thin air. Plus > > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > > for pulls, not pushes stuff out). > > No, it should stay a push. DNS configuration changes happen way less > often than DNS lookups, so the communication should be done on changes > (after an initial pull of course, which should include a "hi, I'm > here, talk to me"). With the pull method, it _would_ still be done on changes. The things that care listen for signals from NM about when the things change, and when they do, they pull the info out of NM. Nothing here needs to poll to get the info it wants. The situation I'm trying to avoid, here, is writing 4 different backends in NM for every single way that people want to handle their DNS information. 1 for named, 1 for dnsmasq, 1 for /etc/resolv.conf, and 1 for resolvconf on debian/suse. That's just pointless and I don't want to put the new flavor of the week in NetworkManager itself. Dan From dcbw at redhat.com Fri Dec 7 14:41:45 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 09:41:45 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1197040134.2303.77.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> <1197040134.2303.77.camel@localhost.localdomain> Message-ID: <1197038505.10672.6.camel@localhost.localdomain> On Fri, 2007-12-07 at 10:08 -0500, Adam Jackson wrote: > On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > > Adam Jackson redhat.com> writes: > > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > > unless someone has a compelling reason not to. > > > > What's the problem with depending on Perl? It's a useful scripting language, > > used in a lot of packages, thus so many things require it that you'll be > > hard-pressed to find a working system without Perl, especially an X11-enabled > > one. For example, kdelibs requires Perl (it's used for things like > > kconf_update), so any KDE system will always have Perl anyway. > > I'm not arguing against perl qua perl. I am arguing against needless > arcs in the dep graph. This one package has a perl dependency solely > because it provides a single perl script that no one is ever likely to > use. > > Sure, it's just one dep, but every dep counts. The complexity of the > graph directly affects runtime performance for rpm and yum, and the > ability to use trimmed subsets of Fedora for custom purposes. The graph > is important. We argue so much for correcness in initial packaging. We > should be correct at the system level too. And this is exactly the issue we faced with more constrained platforms like OLPC; we had to hack that perl dep out of the X package because _nothing_ else in the platform depended on perl, we didn't want to ship perl, and perl takes up 20MB of space that we didn't have. Packagers need to be more aggressive about splitting out deps from packages if they want to be useful on targeted devices like the OLPC, the Classmate, the eepc, and Fedora ARM. Dan From jwboyer at gmail.com Fri Dec 7 14:46:58 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 7 Dec 2007 08:46:58 -0600 Subject: rawhide report: 20071207 changes In-Reply-To: <20071207125548.M84424@all-the-johnsons.co.uk> References: <200712071156.lB7Bufwa022681@porkchop.devel.redhat.com> <20071207125548.M84424@all-the-johnsons.co.uk> Message-ID: <20071207084658.5097873b@weaponx> On Fri, 7 Dec 2007 12:55:48 +0000 "Paul F. Johnson" wrote: > Hi, > > > Broken deps for x86_64 > > ---------------------------------------------------------- > > amarok - 1.4.7-12.fc9.x86_64 requires libcrypto.so.6()(64bit) > > amarok - 1.4.7-12.fc9.x86_64 requires libssl.so.6()(64bit) > > amarok - 1.4.7-12.fc9.i386 requires libssl.so.6 > > amarok - 1.4.7-12.fc9.i386 requires libcrypto.so.6 > > > > With so many packages reliant on openssl, is there any way that if openssl is > rebuilt, the build system automatically tries to rebuild the packages reliant > on it? The problem with that is it's not always a simple rebuild that is needed. API/ABI changes, etc need an actual maintainer to look at them. That, and then the buildsys would have to have CVS access to bump the release of all those packages, and that just seems evil. josh From ssorce at redhat.com Fri Dec 7 15:18:32 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 07 Dec 2007 10:18:32 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197026907.4655.6.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> Message-ID: <1197040712.23679.4.camel@localhost.localdomain> On Fri, 2007-12-07 at 06:28 -0500, Dan Williams wrote: > NM shouldn't really care what the caching nameserver implementation is, > anything is fine. It just happens that the current bits talked to named > because patches for dnsmasq didn't materialize out of thin air. Plus > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > for pulls, not pushes stuff out). IMO this is not ideal at all, NM knows when interfaces change, not the other way around, *but* if you mean that NM should broadcast a generic "an interface has changed" event and then wait for DNS daemons to query NM to know what are the specifics, that makes indeed sense. In this case we already have scripts in NM that get called when an interface changes, I guess all we need is to: A) make sure this is done for all interfaces including tun0, virt* vlan*, whatever so that the thing is consistent and we do not need special cases B) each package will make scripts that can tell the appropriate daemon in the appropriate way what happened so that it can fetch data out of NM If tight integration exist in the DNS daemon of course all it can do is just sit and wait for the message to appear on dbus I guess. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From kevin.kofler at chello.at Fri Dec 7 15:49:22 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 7 Dec 2007 15:49:22 +0000 (UTC) Subject: Package alien References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> Message-ID: Patrice Dumas free.fr> writes: > The target for dpkg are not casual users, and casual users won't use it > anyway. In %description, I put > > dpkg and dselect will certainly be non-functional on a rpm-based system > because packages dependencies will likely be unmet. > > It may admitedly be enhanced, to say something like > > dpkg and dselect will certainly be non-functional on a rpm-based system > because packages dependencies will likely be unmet, and in any case > you are likely to trash your system if you install packages using > dpkg. I think you should not only say what does not work, but also what does work, so people know why you're packaging them in the first place, e.g.: dpkg and dselect are provided to allow converting between package formats with alien and installing Debian or Debian-based distributions in a chroot for virtualization. They are NOT intended to be used to manage packages within your Fedora installation, and attempting to use it that way will not work and may even break your system! Kevin Kofler From buildsys at fedoraproject.org Fri Dec 7 16:17:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 7 Dec 2007 11:17:33 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-07 Message-ID: <20071207161733.32F7015212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 1 tiquit-2.5-1.fc6 Changes in Fedora Extras 6: tiquit-2.5-1.fc6 ---------------- * Wed Nov 28 2007 Jon Ciesla - 2.5-1 - New upstream, fixes missing field bug. * Fri Oct 05 2007 Jon Ciesla - 2.4-6 - Fixed BADSOURCE. * Thu Aug 16 2007 Jon Ciesla - 2.4-5 - License tag correction. From jspaleta at gmail.com Fri Dec 7 16:40:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Dec 2007 07:40:34 -0900 Subject: Package alien In-Reply-To: <20071207132427.GA2604@free.fr> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> Message-ID: <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> On Dec 7, 2007 4:24 AM, Patrice Dumas wrote: > The target for dpkg are not casual users, and casual users won't use it > anyway. And when someone wants to put a dpkg-enabled tool in the distro that does target casual users? It's a slippery slope. We avoid being on that slope by not having a fully functional dpkg on the system at all. -jef From pertusus at free.fr Fri Dec 7 16:50:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 7 Dec 2007 17:50:16 +0100 Subject: Package alien In-Reply-To: <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> Message-ID: <20071207165016.GD2604@free.fr> On Fri, Dec 07, 2007 at 07:40:34AM -0900, Jeff Spaleta wrote: > On Dec 7, 2007 4:24 AM, Patrice Dumas wrote: > > The target for dpkg are not casual users, and casual users won't use it > > anyway. > > And when someone wants to put a dpkg-enabled tool in the distro that > does target casual users? What kind of tool are you thinking of? If we have tools that use dpkg then there is a lack of proper integration. The solution is not to have a non functional dpkg, but properly integrated packages. > It's a slippery slope. We avoid > being on that slope by not having a fully functional dpkg on the system at all. It is better if the dpkg we give is upstream dpkg, such that user can use it in any way they want. -- Pat From d.lesca at solinos.it Fri Dec 7 17:11:04 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Fri, 07 Dec 2007 18:11:04 +0100 Subject: f8: install via PXE/NFS problem (mount) In-Reply-To: <47593547.9060904@crc.dk> References: <1197026643.13142.79.camel@lesca.home.solinos.it> <47593547.9060904@crc.dk> Message-ID: <1197047464.13142.170.camel@lesca.home.solinos.it> Il giorno ven, 07/12/2007 alle 12.57 +0100, Mogens Kjaer ha scritto: > > Does the mount command work if you append "-o nolock"? not work -- Dario Lesca From galibert at pobox.com Fri Dec 7 17:14:54 2007 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 7 Dec 2007 18:14:54 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197038247.10672.2.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> Message-ID: <20071207171454.GA30635@dspnet.fr.eu.org> On Fri, Dec 07, 2007 at 09:37:27AM -0500, Dan Williams wrote: > With the pull method, it _would_ still be done on changes. The things > that care listen for signals from NM about when the things change, and > when they do, they pull the info out of NM. Nothing here needs to poll > to get the info it wants. Color me confused, if NM sends a message to say "DNS config has changed", why doesn't it put the new configuration in the message? Why the extra round trip? OG. From mspevack at redhat.com Thu Dec 6 17:06:01 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 6 Dec 2007 12:06:01 -0500 (EST) Subject: FUDCon Raleigh 2008 Message-ID: The next FUDCon (Fedora User and Developer Conference) will be in Raleigh, NC from January 11-13, 2008. The event is 100% free to attend. For more information, and to SIGN UP, please visit: http://barcamp.org/FUDConRaleigh2008 We hope to see you there. _______________________________________________ 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 Fri Dec 7 17:36:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Dec 2007 12:36:36 -0500 Subject: Koji build system outage in effect Message-ID: <20071207123636.6dadf535@redhat.com> We've had an emergency outage of the Koji build system. The load spiked and started taking all available connections to the dbserver which started failing other services. We've initiated an emergency reboot of the host. I will reply when the outage is over. -- 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 dcbw at redhat.com Fri Dec 7 17:53:25 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 12:53:25 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071207171454.GA30635@dspnet.fr.eu.org> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> Message-ID: <1197050005.30465.2.camel@localhost.localdomain> On Fri, 2007-12-07 at 18:14 +0100, Olivier Galibert wrote: > On Fri, Dec 07, 2007 at 09:37:27AM -0500, Dan Williams wrote: > > With the pull method, it _would_ still be done on changes. The things > > that care listen for signals from NM about when the things change, and > > when they do, they pull the info out of NM. Nothing here needs to poll > > to get the info it wants. > > Color me confused, if NM sends a message to say "DNS config has > changed", why doesn't it put the new configuration in the message? > Why the extra round trip? Depends; if it's all the DHCP parameters, that's a lot of information to spam the bus with when possibly nobody will be listening. Maybe it doesn't matter because maybe most people DHCP-returned option list isn't large. When I really meant with push vs. pull was that currently, NetworkManager itself has all the D-Bus code to invoke method calls on named. That's heavy-pushing, you might almost call it poking-with-a-telephone-pole. I don't want to do that anymore, not for named and not for anything else either. I'm perfectly fine with pushing out the information in the D-Bus signal. Dan From florin at andrei.myip.org Fri Dec 7 17:57:39 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 07 Dec 2007 09:57:39 -0800 Subject: inotify-aware tail replacement In-Reply-To: References: <47574DAC.3060807@andrei.myip.org> <1196974460.4704.4.camel@space-ghost.verbum.private> <20071206213811.GF4775@nostromo.devel.redhat.com> <200712061341.24177.jbarnes@virtuousgeek.org> Message-ID: <47598993.1080400@andrei.myip.org> Martin Ebourne wrote: > > I agree with the others, much better to integrate it into coreutils tail > than provide another version. I don't care, either way is fine, as long as there's a way to tail files with inotify, instead of the old poll method. -- Florin Andrei http://florin.myip.org/ From dcbw at redhat.com Fri Dec 7 17:55:44 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 12:55:44 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197040712.23679.4.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <1197040712.23679.4.camel@localhost.localdomain> Message-ID: <1197050144.30465.5.camel@localhost.localdomain> On Fri, 2007-12-07 at 10:18 -0500, Simo Sorce wrote: > On Fri, 2007-12-07 at 06:28 -0500, Dan Williams wrote: > > > NM shouldn't really care what the caching nameserver implementation is, > > anything is fine. It just happens that the current bits talked to named > > because patches for dnsmasq didn't materialize out of thin air. Plus > > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > > for pulls, not pushes stuff out). > > IMO this is not ideal at all, NM knows when interfaces change, not the > other way around, *but* if you mean that NM should broadcast a generic > "an interface has changed" event and then wait for DNS daemons to query > NM to know what are the specifics, that makes indeed sense. The latter, optionally including the changed DHCP parameters in the D-Bus signal. > In this case we already have scripts in NM that get called when an > interface changes, I guess all we need is to: > A) make sure this is done for all interfaces including tun0, virt* > vlan*, whatever so that the thing is consistent and we do not need > special cases Yup. > B) each package will make scripts that can tell the appropriate daemon > in the appropriate way what happened so that it can fetch data out of NM Yup, or that can parse the DHCP options pushed out in the change signal, parse them, and do the right thing with the daemon. For named without D-Bus, that means using some tool to shove that info into named over whatever control socket it now has (omapi?). Dan > If tight integration exist in the DNS daemon of course all it can do is > just sit and wait for the message to appear on dbus I guess. > > Simo. > > -- > | Simo S Sorce | > | Sr.Soft.Eng. | > | Red Hat, Inc | > | New York, NY | > From ssorce at redhat.com Fri Dec 7 18:09:23 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 07 Dec 2007 13:09:23 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197050144.30465.5.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <1197040712.23679.4.camel@localhost.localdomain> <1197050144.30465.5.camel@localhost.localdomain> Message-ID: <1197050963.23679.29.camel@localhost.localdomain> On Fri, 2007-12-07 at 12:55 -0500, Dan Williams wrote: > On Fri, 2007-12-07 at 10:18 -0500, Simo Sorce wrote: > > On Fri, 2007-12-07 at 06:28 -0500, Dan Williams wrote: > > > > > NM shouldn't really care what the caching nameserver implementation is, > > > anything is fine. It just happens that the current bits talked to named > > > because patches for dnsmasq didn't materialize out of thin air. Plus > > > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > > > for pulls, not pushes stuff out). > > > > IMO this is not ideal at all, NM knows when interfaces change, not the > > other way around, *but* if you mean that NM should broadcast a generic > > "an interface has changed" event and then wait for DNS daemons to query > > NM to know what are the specifics, that makes indeed sense. > > The latter, optionally including the changed DHCP parameters in the > D-Bus signal. I am also thinking VPN options here. For example with NM-vpnc I can tell it which ip ranges to route, and get back which DNSs I should use, I'd like both info to be available to the DNS caching daemon. Possibly in a consistent way across all NM managed VPN stuff like vpnc, openvpn, ... > > In this case we already have scripts in NM that get called when an > > interface changes, I guess all we need is to: > > A) make sure this is done for all interfaces including tun0, virt* > > vlan*, whatever so that the thing is consistent and we do not need > > special cases > > Yup. > > > B) each package will make scripts that can tell the appropriate daemon > > in the appropriate way what happened so that it can fetch data out of NM > > Yup, or that can parse the DHCP options pushed out in the change signal, > parse them, and do the right thing with the daemon. For named without > D-Bus, that means using some tool to shove that info into named over > whatever control socket it now has (omapi?). Yes I think it's not the duty of NM to know how to poke on the caching daemon, just please do not limit yourself to eth/wlan network interfaces and dhcp, but make sure we can do the same for other interfaces (vpn, ppp, theNextBigThing, ...) Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From mschwendt.tmp0701.nospam at arcor.de Fri Dec 7 18:08:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Dec 2007 19:08:50 +0100 Subject: FLAC 1.2.x may need rebuilds In-Reply-To: <20071116155244.d64400c8.mschwendt.tmp0701.nospam@arcor.de> References: <20071116155244.d64400c8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071207190850.588bf253.mschwendt.tmp0701.nospam@arcor.de> On Fri, 16 Nov 2007 15:52:44 +0100, Michael Schwendt wrote: > The Fedora 8 upgrade from FLAC 1.1.4 to 1.2.0 has broken FLAC file import > in Audacity. A simple rebuild of Audacity fixes it. > > All packagers with a dependency on libFLAC* are advised to check whether > they also need to rebuild their packages. > > flac 1.2.1-1 : Tue Sep 18 2007 > flac 1.2.0-1 : Tue Sep 11 2007 > > [...] > > Fedora 7 most likely is affected, too, due to a FLAC security update > from 1.1.4 to 1.2.1: > > flac 1.2.1-1 : Wed Oct 17 2007 This was likely the reason for the FLAC crash in k3b, too, ( https://bugzilla.redhat.com/382341 ) because k3b-1.0.3-3.fc8 was last built in August. From jkeating at redhat.com Fri Dec 7 18:16:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Dec 2007 13:16:14 -0500 Subject: Koji build system outage in effect In-Reply-To: <20071207123636.6dadf535@redhat.com> References: <20071207123636.6dadf535@redhat.com> Message-ID: <20071207131614.6535cbf6@redhat.com> On Fri, 7 Dec 2007 12:36:36 -0500 Jesse Keating wrote: > We've had an emergency outage of the Koji build system. The load > spiked and started taking all available connections to the dbserver > which started failing other services. We've initiated an emergency > reboot of the host. > > I will reply when the outage is over. The outage is over. I've attempted to resubmit some of the jobs that were active before the outage. However if I've missed a job, you can resubmit with "koji resubmit ". -- 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 dcbw at redhat.com Fri Dec 7 18:17:46 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 13:17:46 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197050963.23679.29.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <1197040712.23679.4.camel@localhost.localdomain> <1197050144.30465.5.camel@localhost.localdomain> <1197050963.23679.29.camel@localhost.localdomain> Message-ID: <1197051466.30465.24.camel@localhost.localdomain> On Fri, 2007-12-07 at 13:09 -0500, Simo Sorce wrote: > On Fri, 2007-12-07 at 12:55 -0500, Dan Williams wrote: > > On Fri, 2007-12-07 at 10:18 -0500, Simo Sorce wrote: > > > On Fri, 2007-12-07 at 06:28 -0500, Dan Williams wrote: > > > > > > > NM shouldn't really care what the caching nameserver implementation is, > > > > anything is fine. It just happens that the current bits talked to named > > > > because patches for dnsmasq didn't materialize out of thin air. Plus > > > > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > > > > for pulls, not pushes stuff out). > > > > > > IMO this is not ideal at all, NM knows when interfaces change, not the > > > other way around, *but* if you mean that NM should broadcast a generic > > > "an interface has changed" event and then wait for DNS daemons to query > > > NM to know what are the specifics, that makes indeed sense. > > > > The latter, optionally including the changed DHCP parameters in the > > D-Bus signal. > > I am also thinking VPN options here. For example with NM-vpnc I can tell > it which ip ranges to route, and get back which DNSs I should use, I'd > like both info to be available to the DNS caching daemon. > Possibly in a consistent way across all NM managed VPN stuff like vpnc, > openvpn, ... What I'm thinking of, here, is that each Connection will have associated DHCP-type information, provided either by the DHCP server, or the VPN, or whatever (maybe even statically configured DNS and such). Since NM advertises the list of active connections, each client that wants information can listen for signals when the connection comes up or goes down, and get the config info pretty easily. Parts of this are not implemented yet though. But I think it's conceptually the right place for this sort of thing. > > > In this case we already have scripts in NM that get called when an > > > interface changes, I guess all we need is to: > > > A) make sure this is done for all interfaces including tun0, virt* > > > vlan*, whatever so that the thing is consistent and we do not need > > > special cases > > > > Yup. > > > > > B) each package will make scripts that can tell the appropriate daemon > > > in the appropriate way what happened so that it can fetch data out of NM > > > > Yup, or that can parse the DHCP options pushed out in the change signal, > > parse them, and do the right thing with the daemon. For named without > > D-Bus, that means using some tool to shove that info into named over > > whatever control socket it now has (omapi?). > > Yes I think it's not the duty of NM to know how to poke on the caching > daemon, just please do not limit yourself to eth/wlan network interfaces > and dhcp, but make sure we can do the same for other interfaces (vpn, > ppp, theNextBigThing, ...) Right; since VPNs and such are _also_ Connection objects, they would get their own config info in the plan outlined above as well. Dan > Simo. > > -- > | Simo S Sorce | > | Sr.Soft.Eng. | > | Red Hat, Inc | > | New York, NY | > From gouldwp at auburn.edu Fri Dec 7 18:27:11 2007 From: gouldwp at auburn.edu (Walter Gould) Date: Fri, 07 Dec 2007 12:27:11 -0600 Subject: Newbie question Message-ID: <4759907F.3000608@auburn.edu> List, I need some guidance. I would like to build packages for a few perl modules to be submitted. What is the overall view of using something like cpan2rpm for building rpms or spec files? How would a package built using this hold up during the review process? I am not real experienced in building rpms but would really like to give getting these modules included a shot. My long-term goal for doing this is to eventually get netdisco (Netdisco is an Open Source web-based network management tool. See http://netdisco.org) packaged and submitted. However, there are a number of dependencies (the perl modules) that need to be packaged and submitted first. Any guidance and/or suggestions would really be appreciated. Thanks, -- Walter P. Gould Info. Tech. Specialist Office of Information Technology Auburn University, AL www.auburn.edu/~gouldwp From berrange at redhat.com Fri Dec 7 18:32:06 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 7 Dec 2007 18:32:06 +0000 Subject: Newbie question In-Reply-To: <4759907F.3000608@auburn.edu> References: <4759907F.3000608@auburn.edu> Message-ID: <20071207183206.GA13518@redhat.com> On Fri, Dec 07, 2007 at 12:27:11PM -0600, Walter Gould wrote: > List, > > I need some guidance. I would like to build packages for a few perl > modules to be submitted. What is the overall view of using something > like cpan2rpm for building rpms or spec files? How would a package > built using this hold up during the review process? I am not real > experienced in building rpms but would really like to give getting these > modules included a shot. cpanspec generates much better spec files than cpan2rpm. The latter won't pass review at all, the former will be pretty close to correct - only minor tweaks required. Regards, 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 david at fubar.dk Fri Dec 7 18:28:24 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 07 Dec 2007 13:28:24 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197050005.30465.2.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> <1197050005.30465.2.camel@localhost.localdomain> Message-ID: <1197052104.3161.36.camel@oneill.fubar.dk> On Fri, 2007-12-07 at 12:53 -0500, Dan Williams wrote: > I'm perfectly fine with pushing out the information in the D-Bus signal. There may be security risks in doing this; a malicious unprivileged process can easily listen for these things and abuse the information. David From chris.stone at gmail.com Fri Dec 7 18:48:16 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Dec 2007 10:48:16 -0800 Subject: Newbie question In-Reply-To: <4759907F.3000608@auburn.edu> References: <4759907F.3000608@auburn.edu> Message-ID: Just install rpmdevtools and use the command (rpmdev-newspec perl-foo) where foo is the name of your perl module. This will create a template spec file you can use for Fedora submissions. From wwoods at redhat.com Fri Dec 7 19:07:26 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 07 Dec 2007 19:07:26 +0000 Subject: yum updating itself first? In-Reply-To: <1196977078.20942.5.camel@cutter> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> Message-ID: <1197054446.22594.12.camel@metroid.rdu.redhat.com> On Thu, 2007-12-06 at 16:37 -0500, seth vidal wrote: > On Thu, 2007-12-06 at 16:32 -0500, Dr. Diesel wrote: > > > > Is this a packaging error on Livna's part or some new policy I missed? > > > > it was a yum bug and it is fixed in yum 3.2.8 which is out in > updates. :) We've probably talked about this before but.. how hard would it be to change yum to update itself (and its deps) before attempting the rest of the transaction, for simple updates? There've been a lot of bugs lately where "update yum before updating everything else" was the solution. Seems like that would be the Right Thing To Do in general. -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 mattdm at mattdm.org Fri Dec 7 19:10:52 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Dec 2007 14:10:52 -0500 Subject: yum updating itself first? In-Reply-To: <1197054446.22594.12.camel@metroid.rdu.redhat.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> Message-ID: <20071207191052.GA16393@jadzia.bu.edu> On Fri, Dec 07, 2007 at 07:07:26PM +0000, Will Woods wrote: > We've probably talked about this before but.. how hard would it be to > change yum to update itself (and its deps) before attempting the rest of > the transaction, for simple updates? > There've been a lot of bugs lately where "update yum before updating > everything else" was the solution. Seems like that would be the Right > Thing To Do in general. Maybe something for yum-updatesd to consider rather than in yum itself? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Fri Dec 7 19:11:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Dec 2007 10:11:08 -0900 Subject: yum updating itself first? In-Reply-To: <1197054446.22594.12.camel@metroid.rdu.redhat.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> Message-ID: <604aa7910712071111g6eed42efwb6403380335ad381@mail.gmail.com> On Dec 7, 2007 10:07 AM, Will Woods wrote: > We've probably talked about this before but.. how hard would it be to > change yum to update itself (and its deps) before attempting the rest of > the transaction, for simple updates? > > There've been a lot of bugs lately where "update yum before updating > everything else" was the solution. Seems like that would be the Right > Thing To Do in general. If you are going to go down this road... do you want to go further and have yum look for a yum update no matter what the specified install/update transaction is? -jef From skvidal at fedoraproject.org Fri Dec 7 19:11:40 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 07 Dec 2007 14:11:40 -0500 Subject: yum updating itself first? In-Reply-To: <1197054446.22594.12.camel@metroid.rdu.redhat.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> Message-ID: <1197054700.7714.9.camel@cutter> On Fri, 2007-12-07 at 19:07 +0000, Will Woods wrote: > On Thu, 2007-12-06 at 16:37 -0500, seth vidal wrote: > > On Thu, 2007-12-06 at 16:32 -0500, Dr. Diesel wrote: > > > > > > Is this a packaging error on Livna's part or some new policy I missed? > > > > > > > it was a yum bug and it is fixed in yum 3.2.8 which is out in > > updates. :) > > We've probably talked about this before but.. how hard would it be to > change yum to update itself (and its deps) before attempting the rest of > the transaction, for simple updates? > > There've been a lot of bugs lately where "update yum before updating > everything else" was the solution. Seems like that would be the Right > Thing To Do in general. > except when you jump distro versions b/c then updating yum might be more like: yum python glibc theworld. -sv From j.w.r.degoede at hhs.nl Fri Dec 7 19:17:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 07 Dec 2007 20:17:07 +0100 Subject: yum updating itself first? In-Reply-To: <604aa7910712071111g6eed42efwb6403380335ad381@mail.gmail.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> <604aa7910712071111g6eed42efwb6403380335ad381@mail.gmail.com> Message-ID: <47599C33.4090607@hhs.nl> Jeff Spaleta wrote: > On Dec 7, 2007 10:07 AM, Will Woods wrote: >> We've probably talked about this before but.. how hard would it be to >> change yum to update itself (and its deps) before attempting the rest of >> the transaction, for simple updates? >> >> There've been a lot of bugs lately where "update yum before updating >> everything else" was the solution. Seems like that would be the Right >> Thing To Do in general. > > If you are going to go down this road... do you want to go further and > have yum look for a yum update no matter what the specified > install/update transaction is? > No in that case I want it to do as I've told it. But when I tell it to update everything first updating itself and then exec-ing its new self to continue with the rest of the updates isn't a bad idea IMHO, but then the GUI tools need to be thought to do the same. Regards, Hans From drago01 at gmail.com Fri Dec 7 19:18:59 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 7 Dec 2007 20:18:59 +0100 Subject: yum updating itself first? In-Reply-To: <47599C33.4090607@hhs.nl> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> <604aa7910712071111g6eed42efwb6403380335ad381@mail.gmail.com> <47599C33.4090607@hhs.nl> Message-ID: On Dec 7, 2007 8:17 PM, Hans de Goede wrote: > Jeff Spaleta wrote: > > On Dec 7, 2007 10:07 AM, Will Woods wrote: > >> We've probably talked about this before but.. how hard would it be to > >> change yum to update itself (and its deps) before attempting the rest of > >> the transaction, for simple updates? > >> > >> There've been a lot of bugs lately where "update yum before updating > >> everything else" was the solution. Seems like that would be the Right > >> Thing To Do in general. > > > > If you are going to go down this road... do you want to go further and > > have yum look for a yum update no matter what the specified > > install/update transaction is? > > > > No in that case I want it to do as I've told it. But when I tell it to update > everything first updating itself and then exec-ing its new self to continue > with the rest of the updates isn't a bad idea IMHO, but then the GUI tools need > to be thought to do the same. +1 From mschwendt.tmp0701.nospam at arcor.de Fri Dec 7 19:29:12 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Dec 2007 20:29:12 +0100 Subject: yum updating itself first? In-Reply-To: <1197054446.22594.12.camel@metroid.rdu.redhat.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> Message-ID: <20071207202912.4042431f.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Dec 2007 19:07:26 +0000, Will Woods wrote: > On Thu, 2007-12-06 at 16:37 -0500, seth vidal wrote: > > On Thu, 2007-12-06 at 16:32 -0500, Dr. Diesel wrote: > > > > > > Is this a packaging error on Livna's part or some new policy I missed? > > > > > > > it was a yum bug and it is fixed in yum 3.2.8 which is out in > > updates. :) > > We've probably talked about this before but.. how hard would it be to > change yum to update itself (and its deps) before attempting the rest of > the transaction, for simple updates? > > There've been a lot of bugs lately where "update yum before updating > everything else" was the solution. Seems like that would be the Right > Thing To Do in general. "yum -y update" prior to "yum install ..." also fixes many dependency problems. From databasearia at yahoo.com Fri Dec 7 20:49:21 2007 From: databasearia at yahoo.com (Nevruz Mesut Sahin) Date: Fri, 7 Dec 2007 12:49:21 -0800 (PST) Subject: about postfix.spec Message-ID: <466785.59785.qm@web32609.mail.mud.yahoo.com> Dear friends My system is fedora core 6. Postfix version 2.4.5 was installed defoult on the system. Now I am trying to configure postfix dovecot with mysql support the documents tell that there is postfix.spec file in the /usr/src/redhat/SPECS/ but there is not such a file to change %define MYSQL 0 to %define MYSQL 1 but there is no such a file do I need to create this file and write in it. --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Fri Dec 7 21:33:48 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 7 Dec 2007 22:33:48 +0100 Subject: about postfix.spec In-Reply-To: <466785.59785.qm@web32609.mail.mud.yahoo.com> References: <466785.59785.qm@web32609.mail.mud.yahoo.com> Message-ID: <62bc09df0712071333i30b2b642n4e7e2bb47040a72f@mail.gmail.com> 2007/12/7, Nevruz Mesut Sahin : > > Dear friends My system is fedora core 6. Postfix version 2.4.5 was > installed defoult on the system. Now I am trying to configure postfix > dovecot with mysql support the documents tell that there is postfix.specfile in the /usr/src/redhat/SPECS/ but there is not such a file to change %define > MYSQL 0 to %define MYSQL 1 but there is no such a file do I need to > create this file and write in it. hum...You should read closed your mysql docs. Also learn what is a spec file on RPM based system. However, you don't need to edit any .spec file to set up your postfix configuration. ------------------------------ > Never miss a thing. Make Yahoo your homepage. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From myfedora at richip.dhs.org Fri Dec 7 21:33:35 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Dec 2007 14:33:35 -0700 Subject: yum updating itself first? In-Reply-To: <1197054446.22594.12.camel@metroid.rdu.redhat.com> References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> Message-ID: <1197063215.23069.7.camel@localhost6.localdomain6> On Fri, 2007-12-07 at 19:07 +0000, Will Woods wrote: > On Thu, 2007-12-06 at 16:37 -0500, seth vidal wrote: > > On Thu, 2007-12-06 at 16:32 -0500, Dr. Diesel wrote: > > > > > > Is this a packaging error on Livna's part or some new policy I missed? > > > > > > > it was a yum bug and it is fixed in yum 3.2.8 which is out in > > updates. :) > > We've probably talked about this before but.. how hard would it be to > change yum to update itself (and its deps) before attempting the rest of > the transaction, for simple updates? > > There've been a lot of bugs lately where "update yum before updating > everything else" was the solution. Seems like that would be the Right > Thing To Do in general. So far, I've been doing that manually (ie. if I see yum or one of its libs about to be updated, I cancel the yum update and manually update yum first). Sometimes it's a question of there being a correct order in the first place and if it's known what it is, then it should be automated. -- Richi Plana From databasearia at yahoo.com Fri Dec 7 21:44:00 2007 From: databasearia at yahoo.com (Nevruz Mesut Sahin) Date: Fri, 7 Dec 2007 13:44:00 -0800 (PST) Subject: about postfix.spec In-Reply-To: <62bc09df0712071333i30b2b642n4e7e2bb47040a72f@mail.gmail.com> Message-ID: <113192.91792.qm@web32605.mail.mud.yahoo.com> now where can I find this file. I have doc. and it tells that I should change this file. Also if this is not a rpm system I would ask this to debian list becouse people in debian list more helpfull and expert. until now people in fedora list just advised me to reed more doc. Also they did not refer any doc. Xavier Lamien wrote: 2007/12/7, Nevruz Mesut Sahin : Dear friends My system is fedora core 6. Postfix version 2.4.5 was installed defoult on the system. Now I am trying to configure postfix dovecot with mysql support the documents tell that there is postfix.spec file in the /usr/src/redhat/SPECS/ but there is not such a file to change %define MYSQL 0 to %define MYSQL 1 but there is no such a file do I need to create this file and write in it. hum...You should read closed your mysql docs. Also learn what is a spec file on RPM based system. However, you don't need to edit any .spec file to set up your postfix configuration. --------------------------------- Never miss a thing. Make Yahoo your homepage. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Fri Dec 7 23:07:53 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 8 Dec 2007 00:07:53 +0100 Subject: about postfix.spec In-Reply-To: <113192.91792.qm@web32605.mail.mud.yahoo.com> References: <62bc09df0712071333i30b2b642n4e7e2bb47040a72f@mail.gmail.com> <113192.91792.qm@web32605.mail.mud.yahoo.com> Message-ID: <62bc09df0712071507j3e31b461y5bc224cf71afe674@mail.gmail.com> 2007/12/7, Nevruz Mesut Sahin : > > now where can I find this file. I have doc. and it tells that I should > change this file. Also if this is not a rpm system I would ask this to > debian list becouse people in debian list more helpfull and expert. until > now people in fedora list just advised me to reed more doc. Also they did > not refer any doc. Well, as i said you don't read closer. And we're here to be _helpfull_ as you say but you have in your hand to do a minimum and ask right question to have right answears and more help. Why advised you ? because we're not here to do your job. you have to search a bit to instead "wait and eat." It's not with this kind of reply you'll need some help. However, you fedora Core 6 release is an RPM based system (sponsored by redhat). You should now that at least. The question you should ask is : "did the postfix installed package on fedora core 6 has been installed with the configuration linked here %your_link ?". In this case i can tell you that the shipped postfix in Fedora release is not configured with what you wanted to do. the mySQL is defined to 0. Another thing, the Fedora Core 6 is/or will not be supported (it'll set to EOL). Regards, *Xavier Lamien * wrote: > > > > 2007/12/7, Nevruz Mesut Sahin : > > > > Dear friends My system is fedora core 6. Postfix version 2.4.5 was > > installed defoult on the system. Now I am trying to configure postfix > > dovecot with mysql support the documents tell that there is > > postfix.spec file in the /usr/src/redhat/SPECS/ but there is not such a > > file to change %define MYSQL 0 to %define MYSQL 1 but there is no such > > a file do I need to create this file and write in it. > > > hum...You should read closed your mysql docs. > Also learn what is a spec file on RPM based system. > > However, you don't need to edit any .spec file to set up your postfix > configuration. > > > ------------------------------ > > Never miss a thing. Make Yahoo your homepage. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > ------------------------------ > Looking for last minute shopping deals? Find them fast with Yahoo! Search. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jam at zoidtechnologies.com Fri Dec 7 23:20:41 2007 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Fri, 7 Dec 2007 18:20:41 -0500 Subject: about postfix.spec In-Reply-To: <62bc09df0712071507j3e31b461y5bc224cf71afe674@mail.gmail.com> References: <62bc09df0712071333i30b2b642n4e7e2bb47040a72f@mail.gmail.com> <113192.91792.qm@web32605.mail.mud.yahoo.com> <62bc09df0712071507j3e31b461y5bc224cf71afe674@mail.gmail.com> Message-ID: <20071207232041.GB13347@zoidtechnologies.com> On Sat, Dec 08, 2007 at 12:07:53AM +0100, Xavier Lamien wrote: [..snipped..] > In this case i can tell you that the shipped postfix in Fedora release is > not configured with what you wanted to do. > the mySQL is defined to 0. > right.. and the OP was asking where he can get the spec file so he can change that option to a "1" and rebuild the rpms. normally you would do that by installing the "src" package. and as for threatening going to debian because the people there are "more helpful", go for it. regards, J -- http://zoidtechnologies.com/ -- websites that suck less From galibert at pobox.com Sat Dec 8 00:05:32 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 8 Dec 2007 01:05:32 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197052104.3161.36.camel@oneill.fubar.dk> References: <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> <1197050005.30465.2.camel@localhost.localdomain> <1197052104.3161.36.camel@oneill.fubar.dk> Message-ID: <20071208000532.GA77335@dspnet.fr.eu.org> On Fri, Dec 07, 2007 at 01:28:24PM -0500, David Zeuthen wrote: > > On Fri, 2007-12-07 at 12:53 -0500, Dan Williams wrote: > > I'm perfectly fine with pushing out the information in the D-Bus signal. > > There may be security risks in doing this; a malicious unprivileged > process can easily listen for these things and abuse the information. A user process can listen in on root-root dbus communications? OG. From dcbw at redhat.com Sat Dec 8 00:11:06 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Dec 2007 19:11:06 -0500 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071208000532.GA77335@dspnet.fr.eu.org> References: <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> <1197050005.30465.2.camel@localhost.localdomain> <1197052104.3161.36.camel@oneill.fubar.dk> <20071208000532.GA77335@dspnet.fr.eu.org> Message-ID: <1197072666.4563.7.camel@localhost.localdomain> On Sat, 2007-12-08 at 01:05 +0100, Olivier Galibert wrote: > On Fri, Dec 07, 2007 at 01:28:24PM -0500, David Zeuthen wrote: > > > > On Fri, 2007-12-07 at 12:53 -0500, Dan Williams wrote: > > > I'm perfectly fine with pushing out the information in the D-Bus signal. > > > > There may be security risks in doing this; a malicious unprivileged > > process can easily listen for these things and abuse the information. > > A user process can listen in on root-root dbus communications? Anything that can get on the bus gets signals. And most anything can get on the bus, by design, otherwise D-Bus would be pretty useless. What you _can't_ do most of the time is claim a bus name for yourself and provide a service, unless you're specifically authorized to do so by a config file in /etc/dbus-1/system.d or the session bus config dir. And services can specify what can and cannot call their _methods_, but signals are broadcast and readable by everyone by design. The most security paranoid model would have NM pushing the config information to the caching nameserver directly with method calls, because those aren't broadcast on the bus like signals are. But that removes a lot of utility and is a lot more code. It may be that we just have to audit the list of options and whitelist or blacklist certain things from being exposed over the D-Bus interface. Dan From jspaleta at gmail.com Sat Dec 8 00:25:17 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Dec 2007 15:25:17 -0900 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071208000532.GA77335@dspnet.fr.eu.org> References: <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> <1197050005.30465.2.camel@localhost.localdomain> <1197052104.3161.36.camel@oneill.fubar.dk> <20071208000532.GA77335@dspnet.fr.eu.org> Message-ID: <604aa7910712071625p52a3b448o19d346588f035e05@mail.gmail.com> On Dec 7, 2007 3:05 PM, Olivier Galibert wrote: > A user process can listen in on root-root dbus communications? I think issue here is this. If there are unpriviledged clients that could use legitimately use the "change state" broadcast notice, they'd also have access to the actual state information if the specifics of the new dns information comes bundled with the change state notice. Whereas if you did via the roundtrip where one of the dns services saw the signal and then asked NM for the specific information, you could still have under-priviledged clients on the bus receive the change of state signal, but not the specific information because NM would know which services to hand that information to. -jef"my existence is hypothetical at best"spaleta From ndbecker2 at gmail.com Sat Dec 8 01:35:36 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 07 Dec 2007 20:35:36 -0500 Subject: Anyone working on ksquirrel? Message-ID: I will try to package this if nobody else is. From tcallawa at redhat.com Sat Dec 8 02:31:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Dec 2007 08:01:49 +0530 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1197040134.2303.77.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> <1197040134.2303.77.camel@localhost.localdomain> Message-ID: <1197081109.4572.11.camel@localhost.localdomain> On Fri, 2007-12-07 at 10:08 -0500, Adam Jackson wrote: > On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > > Adam Jackson redhat.com> writes: > > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > > unless someone has a compelling reason not to. > > > > What's the problem with depending on Perl? It's a useful scripting language, > > used in a lot of packages, thus so many things require it that you'll be > > hard-pressed to find a working system without Perl, especially an X11-enabled > > one. For example, kdelibs requires Perl (it's used for things like > > kconf_update), so any KDE system will always have Perl anyway. > > I'm not arguing against perl qua perl. I am arguing against needless > arcs in the dep graph. This one package has a perl dependency solely > because it provides a single perl script that no one is ever likely to > use. > > Sure, it's just one dep, but every dep counts. The complexity of the > graph directly affects runtime performance for rpm and yum, and the > ability to use trimmed subsets of Fedora for custom purposes. The graph > is important. We argue so much for correcness in initial packaging. We > should be correct at the system level too. Rather than dropping bdftruncate entirely, perhaps simply put it in its own subpackage? You wouldn't need it to Require anything (the perl deps will be autogenerated), nor would xorg-x11-font-utils need to Require the bdftruncate subpackage, effectively solving the problem without dropping (semi) useful code. %package -n bdftruncate Summary: Generate truncated BDF font from ISO 10646-1 encoded BDF font Group: Applications/System %description -n bdftruncate bdftruncate allows one to generate from an ISO10646-1 encoded BDF font other ISO10646-1 BDF fonts in which all characters above a threshold code value are stored unencoded. This is often desirable because the Xlib API and X11 protocol data structures used for representing font metric information are extremely inefficient when handling sparsely populated fonts. ... %files -n bdftruncate %defattr(-,root,root,-) %{_bindir}/bdftruncate %{_mandir}/bdftruncate.* ~spot From zaitcev at redhat.com Sat Dec 8 05:38:49 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 7 Dec 2007 21:38:49 -0800 Subject: Severe X breakage heads up In-Reply-To: <1195487249.2292.40.camel@localhost.localdomain> References: <1194294608.15341.204.camel@localhost.localdomain> <47419CA5.9050204@mlbassoc.com> <1195487249.2292.40.camel@localhost.localdomain> Message-ID: <20071207213849.2b2a1641.zaitcev@redhat.com> On Mon, 19 Nov 2007 10:47:29 -0500, Adam Jackson wrote: > http://xorg.freedesktop.org/wiki/PciReworkHowto > > It's mostly mechanical, but there are some bits that may require actual > understanding of PCI. If you port a driver and get it working, either > send me the patch or post it to xorg at lists.freedesktop.org and we'll get > it merged. I am having trouble with sis. The PCI stuff is easy, I've done it. However, the driver has about half a dozen places with something like: src/sis_dri.c:#if XORG_VERSION_CURRENT < XORG_VERSION_NUMERIC(6,7,99,1,0) But this is nonsensual, because: /usr/include/xorg/xorg-server.h:#define XORG_VERSION_CURRENT (((1) * 10000000) + ((4) * 100000) + ((0) * 1000) + 1) It looks like the code expected major 7, but we define 1 in xorg-server.h. How did that thing even build before the PCI rework? Even if it built, the build enabled all the wrong options. What should be done? xorg-x11-server-devel-1.4.99.1-0.10.fc9 libdrm-devel-2.4.0-0.1.fc9 -- Pete From debarshi.ray at gmail.com Sat Dec 8 09:23:16 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 8 Dec 2007 14:53:16 +0530 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> <20071203140231.4f1f4fb2@redhat.com> <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> Message-ID: <3170f42f0712080123w12bcfef4s54b26138271fdd68@mail.gmail.com> Although bouml-doc-3.0-2 is there in F-7 updates and devel, I can't find it in F-8 updates yet. I checked the following mirrors: + http://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/8/SRPMS/ + ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/8/SRPMS/ Am I missing something? Cheerio, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at fedoraproject.org Sat Dec 8 10:14:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 8 Dec 2007 05:14:45 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-08 Message-ID: <20071208101445.56D9C15212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 4 kdeartwork-extras-3.5.8-1.fc6 kdegraphics-extras-3.5.8-1.fc6 kdemultimedia-extras-3.5.8-1.fc6 kdetoys-3.5.8-1.fc6 Changes in Fedora Extras 6: kdeartwork-extras-3.5.8-1.fc6 ----------------------------- * Fri Dec 07 2007 Rex Dieter 3.5.8-1 - 3.5.8 kdegraphics-extras-3.5.8-1.fc6 ------------------------------ * Fri Dec 07 2007 Rex Dieter 7:3.5.8-1 - 3.5.8 kdemultimedia-extras-3.5.8-1.fc6 -------------------------------- * Thu Dec 06 2007 Rex Dieter - 6:3.5.8-1 - kde-3.5.8 kdetoys-3.5.8-1.fc6 ------------------- * Sat Oct 13 2007 Rex Dieter 7:3.5.8-1 - kde-3.5.8 * Mon Aug 20 2007 Rex Dieter 7:3.5.7-2 - License: GPLv2+ - drop Requires: kdebase (kde-filesystem helps here) (f7+) * Mon Jun 11 2007 Rex Dieter 7:3.5.7-1 - kde-3.5.7 * Fri Apr 13 2007 Rex Dieter 7:3.5.6-3 - Requires: kdebase (for directory ownership) * Tue Jan 16 2007 Rex Dieter 7:3.5.6-1 - kweather isn't configurable (#208510, kde#122850) - kde-3.5.6 * Thu Oct 05 2006 Rex Dieter 7:3.5.5-1 - kde-3.5.5 From mike at miketc.com Sat Dec 8 12:15:26 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 08 Dec 2007 06:15:26 -0600 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <3170f42f0712080123w12bcfef4s54b26138271fdd68@mail.gmail.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> <20071203140231.4f1f4fb2@redhat.com> <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> <3170f42f0712080123w12bcfef4s54b26138271fdd68@mail.gmail.com> Message-ID: <1197116126.3820.1.camel@scrappy.miketc.com> On Sat, 2007-12-08 at 14:53 +0530, Debarshi 'Rishi' Ray wrote: > Although bouml-doc-3.0-2 is there in F-7 updates and devel, I can't > find it in F-8 updates yet. I checked the following mirrors: > + http://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/8/SRPMS/ > + ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/8/SRPMS/ > > Am I missing something? Yep, your missing it. Try a different mirror, as it is in updates (actually, 3.0-1 is in testing?), not updates-testing. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From kulbirsaini at students.iiit.ac.in Sat Dec 8 12:25:46 2007 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Sat, 8 Dec 2007 17:55:46 +0530 (IST) Subject: OMGWTF !! Remote Desktop in Fedora 8 Message-ID: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Hi all! I am using Fedora 7 upgraded to Fedora 8 packages via Yum. I have Remote Desktop (System -> Preferences -> Internet & Network -> Remote Desktop ) in my packages and using it. Problem: When I login to my system using 'vncviewer :0', i can access everything on the remote pc but the problem is the screen on server system (system with ) unlocks and everything that I do remotely is replicated on the actual system. Somebody will say, wtf? it is designed to be so. But the problem is the screen unlocks and anybody in my lab can capture my system and do whatever he/she wants. Its a big security issue. And somebody may even get a heart attack when he/she sees that the mouse is static and no human being is near the pc and still the windows are opening and closing and some text is being typed in terminal :-O :P ------------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Institute: http://www.iiit.ac.in/ My Linux-Blog: http://linux.saini.co.in/ My Web-Blog: http://life.saini.co.in/ ------------------------------------------------------- From buildsys at redhat.com Sat Dec 8 12:32:30 2007 From: buildsys at redhat.com (Build System) Date: Sat, 8 Dec 2007 07:32:30 -0500 Subject: rawhide report: 20071208 changes Message-ID: <200712081232.lB8CWUBC007175@porkchop.devel.redhat.com> New package d-feet A powerful D-Bus Debugger New package dsniff Tools for network auditing and penetration testing New package inotail An inotify-enabled tail replacement New package libbeagle Beagle C interface New package munipack MuniPack is a CCD photometry package New package oniguruma Regular expressions library New package pcapdiff Compares packet captures, detects forged, dropped or mangled packets New package qemu-launcher A graphical front-end to Qemu virtual machines New package wkf Japanese Kanji code converting filter New package xfce4-modemlights-plugin Modemlights for the Xfce panel Removed package audacious-docklet Updated Packages: PyQt-3.17.4-1.fc9 ----------------- * Thu Dec 06 2007 Rex Dieter - 3.17.4-1 - 3.17.4 PyQt4-4.3.3-1.fc9 ----------------- * Wed Dec 05 2007 Rex Dieter 4.3.3-1 - PyQt-4.3.3 amarok-1.4.7-14.fc9 ------------------- * Fri Dec 07 2007 Alex Lancaster 1.4.7-14 - Rebuild for new openssl * Thu Nov 29 2007 Rex Dieter 1.4.7-13 - fix --with-mp4v2 handling (#346011#c5,6) * Thu Nov 29 2007 Rex Dieter 1.4.7-12 - --with-mp4v2 (#346011#c3) - fix asf/wma support (rh#346011,kde#151733) anaconda-11.4.0.7-1 ------------------- * Fri Dec 07 2007 Chris Lumens - 11.4.0.7-1 - Tweak save-exception-to-disk algorithm. (notting) - Merge the FTP and HTTP methods into a single URL method. (clumens) - Fixes to the live install method (katzj) - Use HAL and DBus for probing and device node creation in stage2. (notting) - Get rid of /tmp/ramfs usage. (katzj) astromenace-1.2-5.fc9 --------------------- * Fri Dec 07 2007 Jon Ciesla - 1.2-5 - Added patch to fix stuck mouse, BZ 327671. authd-1.4.3-11 -------------- * Fri Dec 07 2007 Release Engineering - 1.4.3-11 - Rebuild for deps azureus-3.0.3.4-2.fc9 --------------------- * Fri Dec 07 2007 Lillian Angel - 3.0.3.4-2 - Removed ExcludeArch. - Updated Release. - Added firefox as a requirement for the browser support. - Moved JAVA_HOME to script. - Added MOZILLA_FIVE_HOME to script. - Updated LD_LIBRARY_PATH in script. bc-1.06-30.fc9 -------------- * Fri Dec 07 2007 Zdenek Prikryl 1.06-30.fc9 - Package review (#225611) * 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 bcfg2-0.9.5.2-1.fc9 ------------------- * Mon Nov 12 2007 Jeffrey C. Ollie - 0.9.5.2-1 - Update to 0.9.5.2 booty-0.93-1.fc9 ---------------- * Fri Dec 07 2007 Jeremy Katz - 0.93-1 - Fix up for changes in anaconda (katzj) - use /boot directory for bootloader on Efika (dwmw2) ccsm-0.6.0-6.fc9 ---------------- * Sat Dec 08 2007 Mohd Izhar Firdaus Ismail 0.6.0-5 - added installed but unpackaged file ccsm-0.6.0-py2.5.egg-info * Sun Nov 25 2007 Mohd Izhar Firdaus Ismail 0.6.0-4 - changed requires to allow flexible upgrade of compizconfig-python and libcompizconfig compat-erlang-R10B-11.9.fc9 --------------------------- * Fri Dec 07 2007 Gerard Milmeister - R10B-11.9 - build id problems fixed * Wed Dec 05 2007 Release Engineering - R10B-11 - Rebuild for deps deluge-0.5.7.1-1.fc9 -------------------- * Fri Dec 07 2007 Peter Gordon - 0.5.7.1-1 - Update to new upstream bug-fix release (0.5.7.1). - Sort %files list (aesthetic-only change). dnssec-tools-1.3-6.fc9 ---------------------- * Fri Dec 07 2007 Release Engineering - 1.3-6 - Rebuild for deps drivel-2.1.1-0.3.20071130svn.fc9 -------------------------------- * Thu Dec 06 2007 Paul W. Frields - 2.1.1-0.3.20071130svn - Rebuild against new openssl libs fedora-ds-base-1.1.0-3.fc9 -------------------------- * Fri Dec 07 2007 Release Engineering - 1.1.0-3 - Rebuild for deps flow-tools-0.68.3-2.fc9 ----------------------- * Fri Dec 07 2007 Release Engineering - 0.68.3-2 - Rebuild for deps fop-0.94-2 ---------- * Fri Dec 07 2007 Lillian Angel - 0.94-2 - Updated Release. * Thu Dec 06 2007 Lillian Angel - 0.94-1 - Removed ppc/64 conditions since IcedTea is now available for ppc/64. gg2-2.3.0-5.fc9 --------------- * Fri Dec 07 2007 Dominik Mierzejewski 2.3.0-5 - fixed BRs - simplified configure call - fixed desktop file * Thu Dec 06 2007 Release Engineering - 2.3.0-4 - Rebuild for deps gnome-applets-1:2.21.2-1.fc9 ---------------------------- * Wed Dec 05 2007 Matthias Clasen - 1:2.21.2-1 - Update to 2.21.2 - Drop the battstat applet gnome-games-1:2.21.3-1.fc9 -------------------------- * Thu Dec 06 2007 Matthias Clasen - 1:2.21.3-1 - Update to 2.21.3 - Build against system ggz packages gnome-keyring-2.21.3.2-1.fc9 ---------------------------- * Fri Dec 07 2007 Matthias Clasen - 2.21.3.2-1 - Update to 2.21.3.2 * Fri Nov 30 2007 Matthias Clasen - 2.20.2-2 - Reenable auto-unlock * Mon Nov 26 2007 Matthias Clasen - 2.20.2-1 - Update to 2.20.2 gnome-volume-manager-2.22.0-1.fc9 --------------------------------- * Fri Dec 07 2007 Matthias Clasen - 2.22.0-1 - Update to 2.22.0 heartbeat-2.1.2-3.fc9 --------------------- * Fri Dec 07 2007 Release Engineering - 2.1.2-3 - Rebuild for deps hplip-2.7.10-2.fc9 ------------------ * Fri Dec 07 2007 Release Engineering - 2.7.10-2 - Rebuild for deps httrack-3.42-6.fc9 ------------------ * Fri Dec 07 2007 Release Engineering - 3.42-6 - Rebuild for deps ike-scan-1.9-3.fc9 ------------------ ipsec-tools-0.7-5.fc9 --------------------- * Fri Dec 07 2007 Steve Conklin - 0.7-5 - Bump for retagging * Fri Dec 07 2007 Steve Conklin - 0.7-4 - Rebuild for dependencies java-1.7.0-icedtea-1.7.0.0-0.22.b23.snapshot.fc9 ------------------------------------------------ * Thu Dec 06 2007 Thomas Fitzsimmons - 1.7.0.0-0.22.b23.snapshot - Clear bootstrap mode on ppc and ppc64. jd-1.9.8-0.1.svn1602.fc9.1 -------------------------- * Sat Dec 08 2007 Mamoru Tasaka - 1.9.8-0.1.svn1602 - svn 1602 * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 * Thu Nov 15 2007 Mamoru Tasaka - 1.9.7-0.4.rc071105 - 1.9.7 rc 071115 kde-settings-4.0-4.fc9 ---------------------- * Fri Dec 07 2007 Than Ngo 4.0-4 - kdmrc: ServerTimeout=30 kdeaccessibility-1:3.97.0-2.fc9 ------------------------------- * Fri Dec 07 2007 Rex Dieter 1:3.97.0-2 - fix %files (unpackaged mono/index.theme) * Wed Dec 05 2007 Rex Dieter 1:3.97.0-1 - kde-3.97.0 * Tue Dec 04 2007 Rex Dieter 1:3.96.2-2 - minor touchups - Provides: mono-icon-theme - drop -libs,-devel subpkgs kdebase-6:3.97.0-1.fc9 ---------------------- * Thu Dec 06 2007 Than Ngo 3.97.0-1 - update to 3.97.0 kdebase-runtime-3.97.0-1.fc9 ---------------------------- * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 * Tue Dec 04 2007 Rex Dieter 3.96.2-4 - disable kioslave/smb (f9+, samba-3.2.x/gplv3 ickiness) * Sun Dec 02 2007 Kevin Kofler 3.96.2-3 - build without libxcb in F7 as we STILL don't have it (see #373361) kdebase-workspace-3.97.0-1.fc9 ------------------------------ * Wed Dec 05 2007 Rex Dieter 3.96.2-3 - fix kdm/kcheckpass/kscreensaver to get working kdeedu-3.97.0-1.fc9 ------------------- * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 kdegames-6:3.97.0-1.fc9 ----------------------- * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 * Thu Nov 29 2007 Rex Dieter 3.96.2-1 - kde-3.96.2 * Tue Nov 27 2007 Rex Dieter 3.96.1-1 - kde-3.96.1 kdegraphics-7:3.97.0-3.fc9 -------------------------- * Fri Dec 07 2007 Than Ngo 3.97.0-3 - get rid of useless define for F9 * Thu Dec 06 2007 Kevin Kofler 3.97.0-2 - don't hardcode %fedora - Requires: lpr (provided by cups) for printing in Okular * Thu Dec 06 2007 Than Ngo 3.97.0-1 - 3.97.0 kdenetwork-7:3.97.0-3.fc9 ------------------------- * Fri Dec 07 2007 Kevin Kofler 3.97.0-3 - BR: openldap-devel, it's needed in kopete * Fri Dec 07 2007 Than Ngo 3.97.0-2 - BR: qimageblitz-devel, it's needed in kopete * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 kdepimlibs-3.97.0-1.fc9 ----------------------- * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 kdetoys-7:3.97.0-1.fc9 ---------------------- * Wed Dec 05 2007 Rex Dieter 7:3.97.0-1 - kde-3.97.0 kdeutils-6:3.97.0-1.fc9 ----------------------- * Wed Dec 05 2007 Rex Dieter 6:3.97.0-1 - kde-3.97.0 kita-0.177.3-12.fc9 ------------------- * Sat Dec 08 2007 Mamoru Tasaka - 0.177.3-12 - kdelibs3-devel switch libgda-1:3.0.1-6.fc9 -------------------- * Thu Dec 06 2007 Release Engineering - 3.0.1-6 - Rebuild for deps libgpg-error-1.6-1 ------------------ * Fri Dec 07 2007 Nalin Dahyabhai - 1.6-1 - update to 1.6 - add suggested summary, buildrequires, and modify install call as suggested by package review (#226021) libnasl-2.2.10-2.fc9 -------------------- * Thu Dec 06 2007 Release Engineering - 2.2.10-2 - Rebuild for deps * Wed Aug 22 2007 Andreas Bierfert 2.2.10-1 - version upgrade - new license tag * Wed Apr 25 2007 Andreas Bierfert 2.2.9-2 - fix #228374 libshout-2.2.2-2.fc9 -------------------- * Fri Dec 07 2007 kwizart < kwizart at gmail.com > - 2.2.2-2 - Fix http://bugzilla.redhat.com/415121 - Add disable-static - Don't use makeinstall macro - Update License field libsilc-0:1.1.5-1.fc9 --------------------- * Fri Dec 07 2007 Stu Tomlinson 1.1.5-1 - Update to 1.1.5, now fully event based, so clients don't need to poll every few milliseconds, reducing power consumption libtorrent-0.11.8-2.fc9 ----------------------- * Fri Dec 07 2007 Release Engineering - 0.11.8-2 - Rebuild for deps linuxwacom-0.7.9.3-1.fc9 ------------------------ * Fri Dec 07 2007 Jeremy Katz - 0.7.9.3-1 - Update to upstream version 0.7.9-3 which works somewhat better with the new X server maniadrive-1.2-6.fc9 -------------------- * Thu Dec 06 2007 Hans de Goede 1.2-6 - Rebuild for new php version mikmod-3.2.2-6.beta1.fc9 ------------------------ * Fri Dec 07 2007 Jindrich Novy 3.2.2-6.beta1 - merge review fixes (#226142) mysql-gui-tools-5.0r12-5.fc9 ---------------------------- * Thu Dec 06 2007 Release Engineering - 5.0r12-5 - Rebuild for deps nagios-plugins-1.4.10-2.fc9 --------------------------- * Thu Dec 06 2007 Release Engineering - 1.4.10-2 - Rebuild for deps * Thu Dec 06 2007 Mike McGrath 1.4.10-1 - Upstream released new version - Removed some patches * Fri Oct 26 2007 Mike McGrath 1.4.8-9 - Fix for Bug 348731 and CVE-2007-5623 pam_mysql-1:0.7-0.2.rc1.fc9 --------------------------- * Thu Dec 06 2007 Release Engineering - 0.7-0.2.rc1 - Rebuild for deps pam_ssh-1.92-4.fc9 ------------------ * Fri Dec 07 2007 Release Engineering - 1.92-4 - Rebuild for deps perl-Crypt-OpenSSL-Bignum-0.04-2.fc9 ------------------------------------ * Fri Dec 07 2007 Jesse Keating - 0.04-2 - Fix the bad version bump * Thu Dec 06 2007 Release Engineering - 0.05-2 - Rebuild for deps * Thu Dec 06 2007 Wes Hardaker - 0.05-1 - Bump to force rebuild with new openssl lib version pidgin-2.3.1-1.fc9 ------------------ * Fri Dec 07 2007 Stu Tomlinson 2.3.1-1 - 2.3.1 Many bugfixes * Tue Nov 27 2007 Stu Tomlinson - 2.3.0-1 - Fix MSN local display name bug * Mon Nov 26 2007 Stu Tomlinson - 2.3.0-1 - 2.3.0 postfix-2:2.4.6-2.fc9 --------------------- * Thu Dec 06 2007 Release Engineering - 2.4.6-2 - Rebuild for deps pure-ftpd-1.0.21-14.fc9 ----------------------- * Thu Dec 06 2007 Release Engineering - 1.0.21-14 - Rebuild for deps python-2.5.1-18.fc9 ------------------- * Fri Dec 07 2007 James Antill - 2.5.1-18 - Create a python-test sub-module, over 3MB of stuff noone wants. - Don't remove egginfo files, try this see what happens ... may revert. - Resolves: rhbz#414711 * Mon Dec 03 2007 Jeremy Katz - 2.5.1-17 - rebuild for new libssl * Fri Nov 30 2007 James Antill - 2.5.1-16 - Fix pyconfig.h comment typo. - Add back test_support.py and the __init__.py file. - Resolves: rhbz#387401 qca-ossl-2.0.0-0.2.beta1.fc9 ---------------------------- * Fri Dec 07 2007 Release Engineering - 2.0.0-0.2.beta1 - Rebuild for deps rhythmbox-0.11.3-9.fc9 ---------------------- * Fri Dec 07 2007 - Bastien Nocera - 0.11.3-9 - Add patch to fix possible crasher when playing any song (#410991) rsyslog-1.19.11-2.fc9 --------------------- * Thu Dec 06 2007 Release Engineering - 1.19.11-2 - Rebuild for deps sane-backends-1.0.18-19.fc9 --------------------------- * Fri Dec 07 2007 Release Engineering - 1.0.18-19 - do a bootstrap build without hplip requirements sipsak-0.9.6-2.fc9 ------------------ * Fri Dec 07 2007 Release Engineering - 0.9.6-2 - Rebuild for deps sofia-sip-1.12.6-12.fc9 ----------------------- * Thu Dec 06 2007 Release Engineering - 1.12.6-12 - Rebuild for deps sysprof-1.0.9-2.fc9 ------------------- * Fri Dec 07 2007 Release Engineering - 1.0.9-2 - Rebuild for deps * Sat Dec 01 2007 Gianluca Sforna - 1.0.9-1 - version update to 1.0.9 - drop kernel module - do not add category X-Fedora to desktop file system-config-soundcard-2.0.6-14.fc9 ------------------------------------ * Fri Dec 07 2007 Martin Stransky - 2.0.6-14 - added dbus-python dependency (#402031) telepathy-salut-0.2.0-1.fc9 --------------------------- * Fri Dec 07 2007 Brian Pepple - 0.2.0-1 - Update to 0.2.0. tellico-1.2.14-4.fc9 -------------------- * Fri Dec 07 2007 Alex Lancaster - 1.2.14-4 - Specify kde{libs,multimedia,pim}3-devel for BR (kdelibs-devel now provides KDE 4) * Thu Dec 06 2007 Jos?? Matos - 1.2.14-3 - Rebuild for new libssl (F9+). thunar-volman-0.2.0-1.fc9 ------------------------- * Mon Dec 03 2007 Christoph Wickert - 0.2.0-1 - Update to 0.2.0 and Thunar 0.9.0 tor-0.1.2.18-2.fc9 ------------------ * Thu Dec 06 2007 Release Engineering - 0.1.2.18-2 - Rebuild for deps totem-2.21.3-2.fc9 ------------------ * Thu Dec 06 2007 Release Engineering - 2.21.3-2 - Rebuild for deps * Mon Dec 03 2007 - Bastien Nocera - 2.21.3-1 - Update to 2.21.3 - Add tracker video search sub-package * Wed Nov 21 2007 - Bastien Nocera - 2.21.2-2 - Try to build against xulrunner tripwire-2.4.1.2-4.fc9 ---------------------- * Fri Dec 07 2007 Release Engineering - 2.4.1.2-4 - Rebuild for deps * Wed Aug 29 2007 Brandon Holbrook 2.4.1.2-3 - Pull in a new config.guess to properly detect ppc64 archs ulogd-1.24-7.fc9 ---------------- * Thu Dec 06 2007 Release Engineering - 1.24-7 - Rebuild for deps wireshark-0.99.7-0.pre2.1.fc9 ----------------------------- * Fri Dec 07 2007 Radek Vok??l 0.99.7-0.pre2.1 - rebuilt for openssl xar-1.5.1-5.fc9 --------------- * Fri Dec 07 2007 Release Engineering - 1.5.1-5 - Rebuild for deps * Thu Aug 23 2007 Matthias Saou 1.5.1-4 - Rebuild for new BuildID feature. - Add /usr/bin/awk build requirement, needed for the libxml configure check. * Wed Aug 08 2007 Matthias Saou 1.5.1-2 - Patch memset call with swapped arguments (Dave Jones). xen-3.1.2-2.fc9 --------------- * Fri Dec 07 2007 Release Engineering - 3.1.2-2 - Rebuild for deps xfce4-cpugraph-plugin-0.4.0-2.fc9 --------------------------------- * Fri Dec 07 2007 Christoph Wickert - 0.4.0-2 - Rebuild for Xfce 4.4.2 xfce4-fsguard-plugin-0.4.0-2.fc9 -------------------------------- * Fri Dec 07 2007 Christoph Wickert - 0.4.0-2 - Rebuild for Xfce 4.4.2 xfce4-notes-plugin-1.6.0-2.fc9 ------------------------------ * Fri Dec 07 2007 Christoph Wickert - 1.6.0-2 - Rebuild for Xfce 4.4.2 xfce4-places-plugin-1.0.0-2.fc9 ------------------------------- * Fri Dec 07 2007 Christoph Wickert - 0.0.10-2 - Rebuild for Xfce 4.4.2 and Thunar 0.9.0 xfce4-sensors-plugin-0.10.99.2-3.fc9 ------------------------------------ * Fri Dec 07 2007 Christoph Wickert - 0.10.99.2-3 - Rebuild for Xfce 4.4.2 xfce4-weather-plugin-0.6.2-2.fc9 -------------------------------- * Fri Dec 07 2007 Christoph Wickert - 0.6.2-2 - Rebuild for Xfce 4.4.2 * Mon Nov 19 2007 Christoph Wickert - 0.6.2-1 - Update to 0.6.0 on Xfce 4.4.1 yum-utils-1.1.9-1.fc9 --------------------- * Fri Dec 07 2007 Tim Lauridsen - mark as 1.1.9 * Fri Oct 26 2007 Seth Vidal - add upgrade-helper plugin z88dk-1.7-2.fc9 --------------- * Fri Dec 07 2007 Kevin Kofler - 1.7-2 - patch for 64-bit issues (#185511) - drop ExcludeArch for 64-bit architectures (#185511) zabbix-1.4.2-5.fc9 ------------------ * Thu Dec 06 2007 Release Engineering - 1.4.2-5 - Rebuild for deps Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 balsa - 2.3.20-1.fc8.i386 requires libcrypto.so.6 balsa - 2.3.20-1.fc8.i386 requires libssl.so.6 beagle - 0.2.18-2.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 claws-mail - 3.1.0-1.fc9.i386 requires libldap-2.3.so.0 claws-mail - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail - 3.1.0-1.fc9.i386 requires liblber-2.3.so.0 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.i386 requires libcrypto.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.i386 requires libssl.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.i386 requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libssl.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libcrypto.so.6 erlang - R11B-5.3.fc8.i386 requires libssl.so.6 erlang - R11B-5.3.fc8.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 httrack - 3.42-6.fc9.i386 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kadu - 0.5.0-4.fc8.i386 requires libssl.so.6 kadu - 0.5.0-4.fc8.i386 requires libcrypto.so.6 kadu-mail - 0.5.0-4.fc8.i386 requires libssl.so.6 kadu-mail - 0.5.0-4.fc8.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libcrypto.so.6 licq - 1.3.4-8.fc9.i386 requires libssl.so.6 licq - 1.3.4-8.fc9.i386 requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libssl.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libcrypto.so.6 linuxdcpp - 1.0.0-2.fc8.i386 requires libssl.so.6 linuxdcpp - 1.0.0-2.fc8.i386 requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nessus-client - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-client - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nessus-gui - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-gui - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nessus-server - 2.2.9-2.fc7.i386 requires libssl.so.6 nessus-server - 2.2.9-2.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires liblber-2.3.so.0 scsi-target-utils - 0.0-1.20070803snap.fc8.i386 requires libcrypto.so.6 sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 valknut - 0.3.11-1.fc8.i386 requires libssl.so.6 valknut - 0.3.11-1.fc8.i386 requires libcrypto.so.6 wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libcrypto.so.6 zoneminder - 1.22.3-9.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 anjuta - 1:2.2.0-3.fc8.x86_64 requires liblber-2.3.so.0()(64bit) anjuta - 1:2.2.0-3.fc8.x86_64 requires libldap-2.3.so.0()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) balsa - 2.3.20-1.fc8.x86_64 requires libcrypto.so.6()(64bit) balsa - 2.3.20-1.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.2.18-2.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.x86_64 requires libcrypto.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.x86_64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) httrack - 3.42-6.fc9.x86_64 requires openssl = 0:0.9.8b httrack - 3.42-6.fc9.i386 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kadu - 0.5.0-4.fc8.x86_64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.x86_64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.x86_64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.x86_64 requires libcrypto.so.6()(64bit) kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.x86_64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-client - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nessus-client - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nessus-server - 2.2.9-2.fc7.x86_64 requires libcrypto.so.6()(64bit) nessus-server - 2.2.9-2.fc7.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires liblber-2.3.so.0()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.x86_64 requires libcrypto.so.6()(64bit) sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.x86_64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.x86_64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires liblber-2.3.so.0()(64bit) valknut - 0.3.11-1.fc8.x86_64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.x86_64 requires libssl.so.6()(64bit) wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libcrypto.so.6()(64bit) zoneminder - 1.22.3-9.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.ppc requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.ppc requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 balsa - 2.3.20-1.fc8.ppc requires libcrypto.so.6 balsa - 2.3.20-1.fc8.ppc requires libssl.so.6 beagle - 0.2.18-2.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 claws-mail - 3.1.0-1.fc9.ppc requires libldap-2.3.so.0 claws-mail - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail - 3.1.0-1.fc9.ppc requires liblber-2.3.so.0 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc requires libcrypto.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc requires libssl.so.6 claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libssl.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libcrypto.so.6 erlang - R11B-5.3.fc8.ppc requires libssl.so.6 erlang - R11B-5.3.fc8.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 httrack - 3.42-6.fc9.ppc requires openssl = 0:0.9.8b httrack - 3.42-6.fc9.ppc64 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kadu - 0.5.0-4.fc8.ppc requires libssl.so.6 kadu - 0.5.0-4.fc8.ppc requires libcrypto.so.6 kadu-mail - 0.5.0-4.fc8.ppc requires libssl.so.6 kadu-mail - 0.5.0-4.fc8.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.ppc requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libcrypto.so.6 licq - 1.3.4-8.fc9.ppc requires libssl.so.6 licq - 1.3.4-8.fc9.ppc requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libssl.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libcrypto.so.6 linuxdcpp - 1.0.0-2.fc8.ppc requires libssl.so.6 linuxdcpp - 1.0.0-2.fc8.ppc requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 nessus-client - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-client - 2.2.9-2.fc7.ppc requires libcrypto.so.6 nessus-gui - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-gui - 2.2.9-2.fc7.ppc requires libcrypto.so.6 nessus-server - 2.2.9-2.fc7.ppc requires libssl.so.6 nessus-server - 2.2.9-2.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires liblber-2.3.so.0 scsi-target-utils - 0.0-1.20070803snap.fc8.ppc requires libcrypto.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc requires libldap-2.3.so.0 subversion - 1.4.4-7.ppc requires libssl.so.6 subversion - 1.4.4-7.ppc requires libcrypto.so.6 subversion - 1.4.4-7.ppc requires liblber-2.3.so.0 valknut - 0.3.11-1.fc8.ppc requires libssl.so.6 valknut - 0.3.11-1.fc8.ppc requires libcrypto.so.6 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libcrypto.so.6 zoneminder - 1.22.3-9.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) balsa - 2.3.20-1.fc8.ppc64 requires libcrypto.so.6()(64bit) balsa - 2.3.20-1.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-bogofilter - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-clamav - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-dillo - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-pgp - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc64 requires libcrypto.so.6()(64bit) claws-mail-plugins-spamassassin - 3.1.0-1.fc9.ppc64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) erlang - R11B-5.3.fc8.ppc64 requires libcrypto.so.6()(64bit) erlang - R11B-5.3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) httrack - 3.42-6.fc9.ppc64 requires openssl = 0:0.9.8b kadu - 0.5.0-4.fc8.ppc64 requires libcrypto.so.6()(64bit) kadu - 0.5.0-4.fc8.ppc64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.ppc64 requires libssl.so.6()(64bit) kadu-mail - 0.5.0-4.fc8.ppc64 requires libcrypto.so.6()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.ppc64 requires libcrypto.so.6()(64bit) linuxdcpp - 1.0.0-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-client - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) nessus-client - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-gui - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) nessus-server - 2.2.9-2.fc7.ppc64 requires libcrypto.so.6()(64bit) nessus-server - 2.2.9-2.fc7.ppc64 requires libssl.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) qemu-launcher - 1.7.4-3.fc9.noarch requires qemu rapidsvn - 0.9.4-6.fc8.ppc64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires liblber-2.3.so.0()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) valknut - 0.3.11-1.fc8.ppc64 requires libcrypto.so.6()(64bit) valknut - 0.3.11-1.fc8.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libcrypto.so.6()(64bit) zoneminder - 1.22.3-9.fc8.ppc64 requires libcrypto.so.6()(64bit) From bserkez at gmail.com Sat Dec 8 13:26:30 2007 From: bserkez at gmail.com (Brett Serkez) Date: Sat, 8 Dec 2007 08:26:30 -0500 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Message-ID: On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: > > Problem: When I login to my system using 'vncviewer :0', i can access > everything on the remote pc but the problem is the screen on server system > (system with ) unlocks and everything that I do remotely is replicated > on the actual system. > > Somebody will say, wtf? it is designed to be so. But the problem is the > screen unlocks and anybody in my lab can capture my system and do whatever > he/she wants. > > Its a big security issue. > > And somebody may even get a heart attack when he/she sees that the mouse is > static and no human being is near the pc and still the windows are opening > and closing and some text is being typed in terminal :-O :P This is working as designed. You can use the vncserver daemon to create virtual desktops, as many as the system resources of your system can support, these will not be visible on the desktop. Then you can connect to any of these virtual desktops from the console or remotely as you desire. Brett From kmaraas at broadpark.no Sat Dec 8 13:43:12 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 08 Dec 2007 14:43:12 +0100 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Message-ID: <1197121392.2692.3.camel@localhost.localdomain> l?., 08.12.2007 kl. 08.26 -0500, skrev Brett Serkez: > On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: > > > > Problem: When I login to my system using 'vncviewer :0', i can access > > everything on the remote pc but the problem is the screen on server system > > (system with ) unlocks and everything that I do remotely is replicated > > on the actual system. > > > > Somebody will say, wtf? it is designed to be so. But the problem is the > > screen unlocks and anybody in my lab can capture my system and do whatever > > he/she wants. > > > > Its a big security issue. > > > > And somebody may even get a heart attack when he/she sees that the mouse is > > static and no human being is near the pc and still the windows are opening > > and closing and some text is being typed in terminal :-O :P > > This is working as designed. You can use the vncserver daemon to > create virtual desktops, as many as the system resources of your > system can support, these will not be visible on the desktop. Then > you can connect to any of these virtual desktops from the console or > remotely as you desire. > Then shouldn't this be the default for vino when sharing the dekstop? I guess the case where the screen unlocks and everything is shown on the screen is great in the case where support staff wants to show users what to do on screen, but is that really the most relevant case? Cheers Kjartan From kulbirsaini at students.iiit.ac.in Sat Dec 8 13:45:40 2007 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Sat, 8 Dec 2007 19:15:40 +0530 (IST) Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Message-ID: <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> > On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: >> >> Problem: When I login to my system using 'vncviewer :0', i can access >> everything on the remote pc but the problem is the screen on server system >> (system with ) unlocks and everything that I do remotely is replicated >> on the actual system. >> >> Somebody will say, wtf? it is designed to be so. But the problem is the >> screen unlocks and anybody in my lab can capture my system and do whatever >> he/she wants. >> >> Its a big security issue. >> >> And somebody may even get a heart attack when he/she sees that the mouse >> is >> static and no human being is near the pc and still the windows are opening >> and closing and some text is being typed in terminal :-O :P > > This is working as designed. You can use the vncserver daemon to > create virtual desktops, as many as the system resources of your > system can support, these will not be visible on the desktop. Then > you can connect to any of these virtual desktops from the console or > remotely as you desire. > > Brett > But the with vncviewer doesn't give you the desktop you have on the server. It creates/initializes another desktop env and give access to it. And Remote Desktop gives access to the exact desktop you have opened on the server. So, when I connect to the Remote Desktop, it unlocks the screen on the server and anybody who is nearby can capture the machine. ------------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Institute: http://www.iiit.ac.in/ My Linux-Blog: http://linux.saini.co.in/ My Web-Blog: http://life.saini.co.in/ IRC nick : generalBordeaux Channels : #fedora, #fedora-devel ------------------------------------------------------- From dennis at ausil.us Fri Dec 7 15:45:22 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 7 Dec 2007 09:45:22 -0600 Subject: Extras 6 building Message-ID: <200712070945.27886.dennis@ausil.us> Hi All, The ability to build packages for Fedora Extras 6 has been switched off. The last day of support for Fedora Core 6 is today. Thanks 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 bserkez at gmail.com Sat Dec 8 14:01:38 2007 From: bserkez at gmail.com (Brett Serkez) Date: Sat, 8 Dec 2007 09:01:38 -0500 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> Message-ID: On Dec 8, 2007 8:45 AM, Kulbir Saini wrote: > > But the with vncviewer doesn't give you the desktop you have on the server. > It creates/initializes another desktop env and give access to it. And Remote > Desktop gives access to the exact desktop you have opened on the server. So, > when I connect to the Remote Desktop, it unlocks the screen on the server > and anybody who is nearby can capture the machine. This is what you said the first time and I gave you a work around. Perhaps implementing an option to keep the desktop blank would be useful, in the WinDoze world LogMeIn gives you this option, which is what you may be looking for long-term. In the mean time, if you want privacy, create a virtual, hidden desktop and then connect to it from were ever you want, from the server's desktop or a remote system. This would be more secure in a number of ways including being about to logout, not just lock the server's desktop at the end of the day without losing your work. Good luck, Brett From jkeating at redhat.com Sat Dec 8 14:28:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 8 Dec 2007 09:28:08 -0500 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <1197116126.3820.1.camel@scrappy.miketc.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> <20071203140231.4f1f4fb2@redhat.com> <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> <3170f42f0712080123w12bcfef4s54b26138271fdd68@mail.gmail.com> <1197116126.3820.1.camel@scrappy.miketc.com> Message-ID: <20071208092808.376235ba@redhat.com> On Sat, 08 Dec 2007 06:15:26 -0600 Mike Chambers wrote: > Yep, your missing it. Try a different mirror, as it is in updates > (actually, 3.0-1 is in testing?), not updates-testing. I've deleted the 3.0-1 update. http://mirror.lib.ucdavis.edu/fedora/linux/updates/8/i386/bouml-doc-3.0-2.noarch.rpm -- 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 Sat Dec 8 14:36:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 08 Dec 2007 09:36:22 -0500 Subject: libbeagle bump Message-ID: <1197124582.3035.1.camel@localhost.localdomain> I've built libbeagle-0.3.0 yesterday, which bumps the soname, so dependent packages will have to be rebuilt. From a quick check, this affects: kerry brasero yelp From kulbirsaini at students.iiit.ac.in Sat Dec 8 14:41:34 2007 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Sat, 8 Dec 2007 20:11:34 +0530 (IST) Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> Message-ID: <45495.172.16.34.34.1197124894.squirrel@students.iiit.ac.in> > On Dec 8, 2007 8:45 AM, Kulbir Saini wrote: >> >> But the with vncviewer doesn't give you the desktop you have on the >> server. >> It creates/initializes another desktop env and give access to it. And Remote >> Desktop gives access to the exact desktop you have opened on the server. So, >> when I connect to the Remote Desktop, it unlocks the screen on the server >> and anybody who is nearby can capture the machine. > > This is what you said the first time and I gave you a work around. > Perhaps implementing an option to keep the desktop blank would be > useful, in the WinDoze world LogMeIn gives you this option, which is > what you may be looking for long-term. Exactly! > In the mean time, if you want privacy, create a virtual, hidden > desktop and then connect to it from were ever you want, from the > server's desktop or a remote system. This would be more secure in a > number of ways including being about to logout, not just lock the > server's desktop at the end of the day without losing your work. I am already using vncviewer this way. But this way, I don't get access to my kopete message queue which is logged in on the original desktop and not in the virtual desktop. > Good luck, > > Brett > ------------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Institute: http://www.iiit.ac.in/ My Linux-Blog: http://linux.saini.co.in/ My Web-Blog: http://life.saini.co.in/ IRC nick : generalBordeaux Channels : #fedora, #fedora-devel on freenode ------------------------------------------------------- From wtogami at redhat.com Sat Dec 8 16:25:38 2007 From: wtogami at redhat.com (Warren Togami) Date: Sat, 08 Dec 2007 11:25:38 -0500 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <45495.172.16.34.34.1197124894.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> <45495.172.16.34.34.1197124894.squirrel@students.iiit.ac.in> Message-ID: <475AC582.5030100@redhat.com> Kulbir Saini wrote: > > I am already using vncviewer this way. But this way, I don't get access to > my kopete message queue which is logged in on the original desktop and not > in the virtual desktop. Then login to your virtual desktop using vncviewer from the real desktop when you are using this machine locally. You are off-topic. This is a development discussion list. You should have brought this to a user support forum like fedoraforum.org. They would have told you exactly the same things. Warren Togami wtogami at redhat.com From myfedora at richip.dhs.org Sat Dec 8 16:45:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Dec 2007 09:45:29 -0700 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Message-ID: <1197132329.28824.8.camel@localhost6.localdomain6> On Sat, 2007-12-08 at 08:26 -0500, Brett Serkez wrote: > On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: > > > > Problem: When I login to my system using 'vncviewer :0', i can access > > everything on the remote pc but the problem is the screen on server system > > (system with ) unlocks and everything that I do remotely is replicated > > on the actual system. > > > > Somebody will say, wtf? it is designed to be so. But the problem is the > > screen unlocks and anybody in my lab can capture my system and do whatever > > he/she wants. > > > > Its a big security issue. > > > > And somebody may even get a heart attack when he/she sees that the mouse is > > static and no human being is near the pc and still the windows are opening > > and closing and some text is being typed in terminal :-O :P > > This is working as designed. You can use the vncserver daemon to > create virtual desktops, as many as the system resources of your > system can support, these will not be visible on the desktop. Then > you can connect to any of these virtual desktops from the console or > remotely as you desire. Actually, there are cases when a user or an administrator might need to remotely access the current running desktop session. Kulbir already mentioned one (something I myself have often wished ... access to my IM client from whatever workstation I'm on without interrupting connection). In such cases, I like the idea that the screensaver stops and allows the activity on the desktop to show (if I were the user, I wouldn't want anyone accessing my machine without my knowing it if I was sitting in front of it with the screen locked). However, I wouldn't want the keyboard or mouse to be active, either (still requiring an unlock). If that were to be a feature request (or even a security review), against what component should it be reported to? Does screensaver even support just input-locking? -- Richi Plana From peterleese at lineone.net Sat Dec 8 17:22:41 2007 From: peterleese at lineone.net (Peter Leese) Date: Sat, 8 Dec 2007 17:22:41 +0000 Subject: Mozplugger Message-ID: <20071208172241.016d7a75.peterleese@lineone.net> I notice that mozplugger is still at 1.7.3, whereas latest version is 1.9.0, is the package still being maintained, if not can I take ownership? Peter From lesmikesell at gmail.com Sat Dec 8 17:44:33 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 08 Dec 2007 11:44:33 -0600 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> Message-ID: <475AD801.9040008@gmail.com> Kulbir Saini wrote: > > But the with vncviewer doesn't give you the desktop you have on the server. > It creates/initializes another desktop env and give access to it. And Remote > Desktop gives access to the exact desktop you have opened on the server. So, > when I connect to the Remote Desktop, it unlocks the screen on the server > and anybody who is nearby can capture the machine. The approach I use is to always use the freenx server and the free NX client from www.nomachine.com instead of the console even for access in the same office. It is fast enough that you barely notice the difference if at all - and you can connect from windows or a Mac as well as Linux. Then when you leave you can suspend the session and there is nothing visible until you reconnect although everything keeps running. One thing that makes this practical for me is that I have a dual-monitor windows box on my desk and I park the NX client so it fills one of the monitors, giving the effect of a separate machine except it doesn't have to be nearby and I can cut and paste between programs on both systems, but it works so well that I'd consider it even if I only had a single machine. You could log in as a dummy user that couldn't directly access anything important, then run everything in an NX session connected back to the same machine as your real user and when you connect remotely you'd get the session no one can see. -- Les Mikesell lesmikesell at gmail.com From jonathan.underwood at gmail.com Sat Dec 8 18:05:13 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 8 Dec 2007 18:05:13 +0000 Subject: Mozplugger In-Reply-To: <20071208172241.016d7a75.peterleese@lineone.net> References: <20071208172241.016d7a75.peterleese@lineone.net> Message-ID: <645d17210712081005u22298edbh9d62aaa07d1c5bc1@mail.gmail.com> On 08/12/2007, Peter Leese wrote: > I notice that mozplugger is still at 1.7.3, whereas latest version is 1.9.0, is the package still being maintained, if not can I take ownership? Have you filed a bug requesting an package update? That would be the first step. From kulbirsaini at students.iiit.ac.in Sat Dec 8 18:18:03 2007 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Sat, 8 Dec 2007 23:48:03 +0530 (IST) Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <475AC582.5030100@redhat.com> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> <45495.172.16.34.34.1197124894.squirrel@students.iiit.ac.in> <475AC582.5030100@redhat.com> Message-ID: <55570.172.16.34.34.1197137883.squirrel@students.iiit.ac.in> > Kulbir Saini wrote: >> >> I am already using vncviewer this way. But this way, I don't get access to >> my kopete message queue which is logged in on the original desktop and not >> in the virtual desktop. > > Then login to your virtual desktop using vncviewer from the real desktop > when you are using this machine locally. How impractical ? I mean its possible, but how would it feel to work on a virtual desktop using vncviewer while you have the complete access to the desktop. > You are off-topic. This is a development discussion list. You should > have brought this to a user support forum like fedoraforum.org. They > would have told you exactly the same things. Well, I apologize if I am off-topic. But FYI, I am not seeking any support on the issue. I know that currently there is not practical solution. All solutions available are ad-hoc which can't be used in the long run. As its the development list, I was trying to bring the issue to the developers of vncviewer/vncserver for Fedora. My apologies if I was wrong in my assumptions. Peace !!! > Warren Togami > wtogami at redhat.com ------------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Institute: http://www.iiit.ac.in/ My Linux-Blog: http://linux.saini.co.in/ My Web-Blog: http://life.saini.co.in/ IRC nick : generalBordeaux Channels : #fedora, #fedora-devel on freenode ------------------------------------------------------- From buildsys at fedoraproject.org Sat Dec 8 18:20:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 8 Dec 2007 13:20:18 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-12-08 Message-ID: <20071208182018.09B8A15212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 5 em8300-kmod-0.16.3-1.2.6.22.14_72.fc6 (!) kdeartwork-extras-3.5.8-1.fc6 : INVALID rebuild, not published! (!) kdegraphics-extras-3.5.8-1.fc6 : INVALID rebuild, not published! (!) kdemultimedia-extras-3.5.8-1.fc6 : INVALID rebuild, not published! sysprof-kmod-1.0.8-1.2.6.22.14_72.fc6 Changes in Fedora Extras 6: em8300-kmod-0.16.3-1.2.6.22.14_72.fc6 ------------------------------------- * Sat Dec 08 2007 Ville Skytt? - Rebuild for kernel 2.6.22.14-72.fc6. kdeartwork-extras-3.5.8-1.fc6 ----------------------------- * Fri Dec 07 2007 Rex Dieter 3.5.8-1 - 3.5.8 kdegraphics-extras-3.5.8-1.fc6 ------------------------------ * Fri Dec 07 2007 Rex Dieter 7:3.5.8-1 - 3.5.8 kdemultimedia-extras-3.5.8-1.fc6 -------------------------------- * Thu Dec 06 2007 Rex Dieter - 6:3.5.8-1 - kde-3.5.8 sysprof-kmod-1.0.8-1.2.6.22.14_72.fc6 ------------------------------------- * Tue Aug 21 2007 Gianluca Sforna - Update License field From lesmikesell at gmail.com Sat Dec 8 18:36:57 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 08 Dec 2007 12:36:57 -0600 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <55570.172.16.34.34.1197137883.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <56542.172.16.34.34.1197121540.squirrel@students.iiit.ac.in> <45495.172.16.34.34.1197124894.squirrel@students.iiit.ac.in> <475AC582.5030100@redhat.com> <55570.172.16.34.34.1197137883.squirrel@students.iiit.ac.in> Message-ID: <475AE449.7070708@gmail.com> Kulbir Saini wrote: >> Then login to your virtual desktop using vncviewer from the real desktop >> when you are using this machine locally. > > How impractical ? I mean its possible, but how would it feel to work on a > virtual desktop using vncviewer while you have the complete access to the > desktop. Running freenx/NX it would feel just the same - at the expense of a bit of RAM used for the virtual copy and buffering - and those become extremely valuable when you access the session remotely. -- Les Mikesell lesmikesell at gmail.com From jima at beer.tclug.org Sat Dec 8 19:05:05 2007 From: jima at beer.tclug.org (Jima) Date: Sat, 8 Dec 2007 13:05:05 -0600 (CST) Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071207104235.GA7295@traged.englab.brq.redhat.com> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> Message-ID: On Fri, 7 Dec 2007, Adam Tkac wrote: > Why? Generally dnsmasq (or other lightweight) DNS server beat BIND > with executable size and performance on one processor systems. In > other cases like functionality, performance on multi cores and > portability beat BIND other servers. And as I wrote above future of > DNS is in DNSSEC. And I'm not sure if dnsmasq author is eager to > implement it. That's why BIND should not be marked as irrelevant on this > field. Okay, so I asked him. His reply: > You're right that dnsmasq attempts to preserve security information: to > the extent that signed packets are passed through bit-perfect to avoid > breaking the signature, It doesn't, however actually know about DNSSEC > at all. > > My attitude is that I'm very happy to take a patch which implements > checking (preferably with suitable #ifdefs so it can be ommitted, if > it's big). I'm not in a position to do the work myself at the moment. I > don't have the knowledge, and I don't have the time to aquire it. IOW, our standard mantra: "patches accepted." :-) Jima From xavier at bachelot.org Sat Dec 8 19:17:27 2007 From: xavier at bachelot.org (Xavier Bachelot) Date: Sat, 08 Dec 2007 20:17:27 +0100 Subject: Severe X breakage heads up In-Reply-To: <47419CA5.9050204@mlbassoc.com> References: <1194294608.15341.204.camel@localhost.localdomain> <47419CA5.9050204@mlbassoc.com> Message-ID: <475AEDC7.9040907@bachelot.org> Gary Thomas wrote: > Adam Jackson wrote: >> I plan to rebase the X server to git master a week from today (Monday, >> November 12), which means the changes should hit rawhide on Tuesday. >> > I'm interested in getting a few drivers going that haven't made it to > rawhide yet. In particular, 'via' > and 'mga'. What's the best process for helping out with this? Is is > straight forward to just grab > the latest driver from GIT and build a new/improved RPM? > xorg-x11-drv-via is dead, it's been replaced by xorg-x11-drv-openchrome which has just been ported to libpciaccess. Please grab it from rawhide and report bugs either to openchrome.org bug tracker or in RH bugzilla. Regards, Xavier From txtoth at gmail.com Sat Dec 8 20:40:35 2007 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 8 Dec 2007 14:40:35 -0600 Subject: sabayon looking for gnomesu Message-ID: Is there a gnomesu in Fedora 8? If not then what, rebuild sabayon --enable-consolehelper? From mschwendt.tmp0701.nospam at arcor.de Sat Dec 8 22:47:17 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 8 Dec 2007 23:47:17 +0100 Subject: Fedora Extras Package Build Report 2007-12-08 In-Reply-To: <20071208182018.09B8A15212F@buildsys.fedoraproject.org> References: <20071208182018.09B8A15212F@buildsys.fedoraproject.org> Message-ID: <20071208234717.a2abbdd4.mschwendt.tmp0701.nospam@arcor.de> On Sat, 8 Dec 2007 13:20:18 -0500 (EST), buildsys wrote: > > Packages built and released for Fedora Extras 6: 5 > > em8300-kmod-0.16.3-1.2.6.22.14_72.fc6 > (!) kdeartwork-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > (!) kdegraphics-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > (!) kdemultimedia-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > sysprof-kmod-1.0.8-1.2.6.22.14_72.fc6 The three KDE packages have been built and published before: $ plague-client list email rdieter at math.unl.edu status finished uid_gt 37000 From dennis at ausil.us Sat Dec 8 23:38:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 8 Dec 2007 17:38:00 -0600 Subject: Fedora Extras Package Build Report 2007-12-08 In-Reply-To: <20071208234717.a2abbdd4.mschwendt.tmp0701.nospam@arcor.de> References: <20071208182018.09B8A15212F@buildsys.fedoraproject.org> <20071208234717.a2abbdd4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200712081738.07292.dennis@ausil.us> On Saturday 08 December 2007, Michael Schwendt wrote: > On Sat, 8 Dec 2007 13:20:18 -0500 (EST), buildsys wrote: > > Packages built and released for Fedora Extras 6: 5 > > > > em8300-kmod-0.16.3-1.2.6.22.14_72.fc6 > > (!) kdeartwork-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > > (!) kdegraphics-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > > (!) kdemultimedia-extras-3.5.8-1.fc6 : INVALID rebuild, not published! > > sysprof-kmod-1.0.8-1.2.6.22.14_72.fc6 > > The three KDE packages have been built and published before: > > $ plague-client list email rdieter at math.unl.edu status finished uid_gt > 37000 i had missed the earlier push and when the needsign dir was completely gone i assumed they had not been pushed and rebuilt them. Sorry for the noise 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 promac at gmail.com Sun Dec 9 00:56:20 2007 From: promac at gmail.com (Paulo Cavalcanti) Date: Sat, 8 Dec 2007 22:56:20 -0200 Subject: mock 0.8.9 In-Reply-To: <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> Message-ID: <68720af30712081656w555388ecrc15921e8155485a9@mail.gmail.com> On Dec 7, 2007 5:58 AM, Paulo Cavalcanti wrote: > > > On Dec 7, 2007 5:04 AM, Michael E Brown wrote: > > > On Wed, Dec 05, 2007 at 07:56:11PM -0200, Paulo Cavalcanti wrote: > > > On Dec 5, 2007 7:45 PM, Ville Skytt? wrote: > > > > > > > On Wednesday 05 December 2007, Michael E Brown wrote: > > > > > On Tue, Dec 04, 2007 at 04:59:07PM -0500, Todd Zullinger wrote: > > > > > > Okay, here's another set of patches to implement --with{,out} > > options. > > > > > > I used git-format-patch this time, and probably did it > > awkwardly. But > > > > > > hopefully not too badly. Just in case (and for non-git users), > > I'll > > > > > > also attach a single diff that should apply cleanly to > > mock-0.8.14. > > > > > > > > > > > > Comments and improvements welcome. :) > > > > > > > > > > This looks great to me. I've committed this to the repo. > > > > > > > > Thanks, guys! When there's a mock release out with these changes > > > > (assuming > > > > they work :)), I think mock has finally caught up with essential > > features > > > > in > > > > mach and I'm ready to start using mock. > > > > > > > > > > > > > > > > > > The only issue I have so far is during init: > > > > > > > > > mock -r fedora-7-i386 init > > > > > > INFO: mock.py version 0.8.14 starting... > > > State Changed: init plugins > > > State Changed: start > > > State Changed: lock buildroot > > > State Changed: clean > > > State Changed: init > > > State Changed: lock buildroot > > > INFO: enabled yum cache > > > State Changed: cleaning yum metadata > > > INFO: enabled root cache > > > State Changed: running yum > > > ERROR: Command failed. See logs for output. > > > # mount -n --bind /home/mock/cache/fedora-7-i386/yum_cache/ > > > /home/mock/fedora-7-i386/root/var/cache/yum > > > > > > But if the chroot is already initialized by a previous mock version, > > them > > > everything goes fine. > > > > > > I have an updated mock rpm if anyone else is willing to try it. > > > > Mock 0.8.15 is in updates-stable now and has a fix for this problem. > > > > Thanks! > > I installed mock 0.8.15 yesterday and I did not see any problem yet. > This version seems to be very good. > > Hi, The --without option is not working. I think that options.rpmmacros.append("_with_%s 0" % option) should be replaced for options.rpmmacros.append("_without_%s 1" % option) I am appending a patch to fix it Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: without.txt URL: From halfline at gmail.com Sun Dec 9 01:28:08 2007 From: halfline at gmail.com (Ray Strode) Date: Sat, 8 Dec 2007 20:28:08 -0500 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> Message-ID: <45abe7d80712081728y27eb83e1yf00e9c9cf75ec50d@mail.gmail.com> Hi, On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: > > Hi all! > > I am using Fedora 7 upgraded to Fedora 8 packages via Yum. I have Remote > Desktop (System -> Preferences -> Internet & Network -> Remote Desktop ) in > my packages and using it. > > Problem: When I login to my system using 'vncviewer :0', i can access > everything on the remote pc but the problem is the screen on server system > (system with ) unlocks and everything that I do remotely is replicated > on the actual system. Yea, it's a known issue: http://bugzilla.gnome.org/show_bug.cgi?id=311780 It's a pretty hard problem to solve though, and no one has put the time in to tackle it. In the mean time, if this is an issue for you, I would suggest using Xvnc (from the vnc-server package) instead of vino. It works by running an entirely different session, separate from the logged in and locked session. --Ray From loupgaroublond at gmail.com Sun Dec 9 02:24:50 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 8 Dec 2007 21:24:50 -0500 Subject: Package alien In-Reply-To: <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> Message-ID: <7f692fec0712081824ub407240o54d8b3804aac277f@mail.gmail.com> On Dec 7, 2007 11:40 AM, Jeff Spaleta wrote: > On Dec 7, 2007 4:24 AM, Patrice Dumas wrote: > > The target for dpkg are not casual users, and casual users won't use it > > anyway. > > And when someone wants to put a dpkg-enabled tool in the distro that > does target casual users? It's a slippery slope. We avoid > being on that slope by not having a fully functional dpkg on the system at all. Do you want to hassle most people that have a legitimate use just to protect everyone else? My level of tolerance is a one time warning, and then for all security features to *get out of the way*. Granted, we probably don't need apt-dpkg in Fedora, and synaptic is a very bad idea in my book, (although I'm sure someone else would disagree,) but it seems crazy to have to bend over backwards because there are stupid people around. -Yaakov From the.masch at gmail.com Sun Dec 9 03:18:12 2007 From: the.masch at gmail.com (masch) Date: Sat, 8 Dec 2007 22:18:12 -0500 Subject: Offer to Update Wine Package Message-ID: <93d66b780712081918h4b8e78efg89990fd1977c6871@mail.gmail.com> Hi! I'm want to help with the update of Wine Package. I'm know it's very hard to maintain a lot of packages, so I offer to help you with this updates. What can I do to help you? Thanks... Salu2... From tmz at pobox.com Sun Dec 9 05:13:33 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 9 Dec 2007 00:13:33 -0500 Subject: mock 0.8.9 In-Reply-To: <68720af30712081656w555388ecrc15921e8155485a9@mail.gmail.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> <68720af30712081656w555388ecrc15921e8155485a9@mail.gmail.com> Message-ID: <20071209051333.GZ30509@psilocybe.teonanacatl.org> Paulo Cavalcanti wrote: > The --without option is not working. > > I think that > > options.rpmmacros.append("_with_%s 0" % option) > > should be replaced for > > options.rpmmacros.append("_without_%s 1" % option) What does the specfile look like? I may have done something wrong with the options. I read the macros and rpmpopt-4.4.2.2 files in /usr/lib/rpm to determine what they set when with or without was used and it seemed to me that when --without foo was passed, rpm defined _with_foo 0. Is that not how it works? (Mock's not actually passing the --with/--without options to rpmbuild. It is writing the _with_foo in ~/.rpmmacros of the chroot, in case that matters.) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's not denial. I'm just very selective about what I accept as reality. -- Calvin ("Calvin and Hobbes") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From Michael_E_Brown at dell.com Sun Dec 9 05:34:55 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Sat, 8 Dec 2007 23:34:55 -0600 Subject: mock 0.8.9 In-Reply-To: <20071209051333.GZ30509@psilocybe.teonanacatl.org> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> <68720af30712081656w555388ecrc15921e8155485a9@mail.gmail.com> <20071209051333.GZ30509@psilocybe.teonanacatl.org> Message-ID: <20071209053454.GA15457@humbolt.us.dell.com> On Sun, Dec 09, 2007 at 12:13:33AM -0500, Todd Zullinger wrote: > Paulo Cavalcanti wrote: > > The --without option is not working. > > > > I think that > > > > options.rpmmacros.append("_with_%s 0" % option) > > > > should be replaced for > > > > options.rpmmacros.append("_without_%s 1" % option) > > What does the specfile look like? I may have done something wrong > with the options. I read the macros and rpmpopt-4.4.2.2 files in > /usr/lib/rpm to determine what they set when with or without was used > and it seemed to me that when --without foo was passed, rpm defined > _with_foo 0. Is that not how it works? (Mock's not actually passing > the --with/--without options to rpmbuild. It is writing the _with_foo > in ~/.rpmmacros of the chroot, in case that matters.) Paulo appears to be correct. I will queue up this patch for the next release. /usr/share/doc/rpm-4.4.2.2/conditionalbuilds ================== The new options are implemented using popt to add aliases to the existing rpm options --define to specify macros from the command line. The magic necessary to add the new options is (from the file /usr/lib/rpm/rpmpopt*) \verbatim rpmb alias --with --define "_with_!#:+ --with-!#:+" rpmb alias --without --define "_without_!#:+ --without-!#:+" \endverbatim ================== -- Michael > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From tmz at pobox.com Sun Dec 9 05:53:32 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 9 Dec 2007 00:53:32 -0500 Subject: mock 0.8.9 In-Reply-To: <20071209053454.GA15457@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <20071204215906.GB30509@psilocybe.teonanacatl.org> <20071204234155.GC31195@humbolt.us.dell.com> <200712052345.08477.ville.skytta@iki.fi> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> <68720af30712062358o3e842227vdda107282072d51a@mail.gmail.com> <68720af30712081656w555388ecrc15921e8155485a9@mail.gmail.com> <20071209051333.GZ30509@psilocybe.teonanacatl.org> <20071209053454.GA15457@humbolt.us.dell.com> Message-ID: <20071209055332.GB30509@psilocybe.teonanacatl.org> Michael E Brown wrote: > /usr/share/doc/rpm-4.4.2.2/conditionalbuilds > ================== > The new options are implemented using popt to add aliases to the > existing rpm > options --define to specify macros from the command line. The magic > necessary > to add the new options is (from the file /usr/lib/rpm/rpmpopt*) > \verbatim > rpmb alias --with --define "_with_!#:+ --with-!#:+" > rpmb alias --without --define "_without_!#:+ > --without-!#:+" > \endverbatim > ================== Bah. I was confused by reading the sections in /usr/lib/rpm/rpmpopt* regarding %without() and %bcond_without(). Sorry for not catching that with better testing. Thanks Paulo. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Giving a politician access to your wallet is like giving a dog access to your refrigerator. -- Tim Barber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Dec 9 08:36:11 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 9 Dec 2007 08:36:11 +0000 (UTC) Subject: yum updating itself first? References: <2a28d2ab0712061332g2fc7969bpf70e9ae4a6d3ba6c@mail.gmail.com> <1196977078.20942.5.camel@cutter> <1197054446.22594.12.camel@metroid.rdu.redhat.com> <1197054700.7714.9.camel@cutter> Message-ID: seth vidal fedoraproject.org> writes: > except when you jump distro versions b/c then updating yum might be more > like: > yum > python > glibc > theworld. Python is more likely to be the one to drag in "the world" than glibc in such a scenario. Glibc is backward-compatible, so packages built for the old one are supposed to run on the new one, it should not be necessary to upgrade everything to upgrade glibc. And glibc itself has few to no deps, for obvious reasons. ;-) Python on the other hand has several dependencies which could need upgrading. Kevin Kofler From ville.skytta at iki.fi Sun Dec 9 10:19:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 9 Dec 2007 12:19:49 +0200 Subject: mock 0.8.9 In-Reply-To: <20071207070448.GA20952@humbolt.us.dell.com> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> Message-ID: <200712091219.50417.ville.skytta@iki.fi> On Friday 07 December 2007, Michael E Brown wrote: > Mock 0.8.15 is in updates-stable now and has a fix for this problem. http://download.fedora.redhat.com/pub/fedora/linux/updates/8/x86_64/ still has 0.8.9 but bodhi shows 0.8.15 was pushed to stable updates on 6th. Anyone know what's up? From lordmorgul at gmail.com Sun Dec 9 10:56:10 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 09 Dec 2007 02:56:10 -0800 Subject: Offer to Update Wine Package In-Reply-To: <93d66b780712081918h4b8e78efg89990fd1977c6871@mail.gmail.com> References: <93d66b780712081918h4b8e78efg89990fd1977c6871@mail.gmail.com> Message-ID: <475BC9CA.1000603@gmail.com> masch wrote: > Hi! > I'm want to help with the update of Wine Package. I'm know it's very > hard to maintain a lot of packages, so I offer to help you with this > updates. What can I do to help you? > > Thanks... > Salu2... You probably should start by contacting the wine maintainer, who atm I believe is Andreas Bierfert (andreas.bierfert _a t_ lowlatency.de) and asking what you can do to help, see http://fedoraproject.org/wiki/AndreasBierfert/Wine. -- Andrew Farris gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From buildsys at redhat.com Sun Dec 9 13:11:31 2007 From: buildsys at redhat.com (Build System) Date: Sun, 9 Dec 2007 08:11:31 -0500 Subject: rawhide report: 20071209 changes Message-ID: <200712091311.lB9DBVvi023154@porkchop.devel.redhat.com> New package perl-Class-Accessor-Grouped Lets you build groups of accessors Updated Packages: amtu-1.0.6-1.fc9 ---------------- * Sat Dec 08 2007 Steve Grubb 1.0.6-1 - new upstream version balsa-2.3.21-1.fc9 ------------------ * Sat Dec 08 2007 Pawel Salek - 2.3.21-1 - update to 2.3.21 and rebuild. * Thu Dec 06 2007 Release Engineering - 2.3.20-2 - Rebuild for deps bodhi-0.4.8-1.fc9 ----------------- * Fri Dec 07 2007 Luke Macken - 0.4.8-1 - 0.4.8 * Wed Nov 28 2007 Luke Macken - 0.4.7-1 - 0.4.7 centerim-1:4.22.2-1.fc9 ----------------------- * Sat Dec 08 2007 Lubomir Kundrak - 1:4.22.2-1 - New upstream relese * Wed Nov 28 2007 Lubomir Kundrak - 1:4.22.1.20071124-2 - Synchronized with GIT to fix the ICQ client side contacts problems (#402301) * Thu Oct 25 2007 Lubomir Kundrak - 1:4.22.1.20071022-1 - New upstream tarball, functionally equivalent to previous revision of the pkg claws-mail-3.1.0-3.fc9 ---------------------- * Sat Dec 08 2007 Andreas Bierfert - 3.1.0-3 - fix desktop file * Thu Dec 06 2007 Release Engineering - 3.1.0-2 - Rebuild for deps * Mon Nov 19 2007 Andreas Bierfert - 3.1.0-1 - version upgrade digikam-0.9.3-0.5.rc1.fc9 ------------------------- * Sat Dec 08 2007 Rex Dieter 0.9.3-0.5.rc1 - digikam-0.9.3-rc1 - BR: kdelibs3-devel * Tue Nov 20 2007 Rex Dieter 0.9.3-0.2.beta3 - digikam-0.9.3-beta3 * Tue Nov 13 2007 Rex Dieter 0.9.3-0.1.beta2 - digikam-0.9.3-beta2 ds9-5.0-6.fc9 ------------- * Sat Dec 08 2007 Sergio Pascual 5.0-6 - Fixed problems with TCL package loading e2tools-0.0.16-9.fc9 -------------------- * Sun Dec 09 2007 Hans Ulrich Niedermann - 0.0.16-9 - Use format string macro from inttypes.h and uint64_t (#349851). eggdrop-1.6.18-12.fc9 --------------------- * Sat Dec 08 2007 Robert Scheck 1.6.18-12 - Added a patch to fix some stack based overflows (CVE-2007-2807) erlang-R12B-0.1.fc9 ------------------- * Sat Dec 08 2007 Gerard Milmeister - R12B-0.1 - new release R12B-0 * Wed Dec 05 2007 Release Engineering - R11B-6 - Rebuild for deps * Sun Aug 19 2007 Gerard Milmeister - R11B-5.3 - fix some permissions gnome-applets-1:2.21.2-2.fc9 ---------------------------- * Sun Dec 09 2007 Matthias Clasen - 1:2.21.2-2 - Silence the %post script gnotime-2.2.3-3.fc9 ------------------- * Fri Dec 07 2007 Toshio Kuratomi - 2.2.3-3 - Upstream's fix needed some fuzz cleanups. - Fix the desktop file's Icon definition. * Fri Dec 07 2007 Toshio Kuratomi - 2.2.3-2 - Fix for reordering projects via drag and drop. gstreamer-python-0.10.9-1.fc9 ----------------------------- * Sun Dec 09 2007 Denis Leroy - 0.10.9-1 - Update to upstream 0.10.9 - Removed exit patch, is upstream hunspell-pl-0.20071208-1.fc9 ---------------------------- * Sat Dec 08 2007 Caolan McNamara - 0.20071208-1 - new version jd-1.9.8-0.2.svn1609.fc9 ------------------------ * Sun Dec 09 2007 Mamoru Tasaka - 1.9.8-0.2.svn1609 - svn 1609 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 k3b-0:1.0.4-5.fc9 ----------------- * Sat Dec 08 2007 Rex Dieter - 0:1.0.4-5 - patch for "k3b can't reload media for verification" (kde#151816) - BR: kdelibs3-devel kadu-0.5.0-6.fc9 ---------------- * Sat Dec 08 2007 Micha?? Bentkowski - 0.5.0-6 - Change kdelibs-devel to kdelibs3-devel * Fri Dec 07 2007 Release Engineering - 0.5.0-5 - Rebuild for deps kdebase3-3.5.8-18.fc9 --------------------- * Sat Dec 08 2007 Rex Dieter - 3.5.8-18 - omit pam configs, kdm bits, xsession/gdm support (f9+) kernel-2.6.24-0.79.rc4.git5.fc9 ------------------------------- * Fri Dec 07 2007 Peter Jones - Turn on CONFIG_FB_IMAC . * Fri Dec 07 2007 Dave Jones - 2.6.24-rc4-git5 * Thu Dec 06 2007 Dave Jones - 2.6.24-rc4-git4 libnasl-2.2.10-4.fc9 -------------------- * Sat Dec 08 2007 Andreas Bierfert 2.2.10-4 - fix #342241 * Thu Dec 06 2007 Release Engineering - 2.2.10-3 - Rebuild for deps linuxdcpp-1.0.0-4.fc9 --------------------- * Sat Dec 08 2007 Marcin Garski 1.0.0-4 - Fix desktop file (#413231) mew-5.2.52-1.fc9 ---------------- * Wed Dec 05 2007 Akira TAGOH - 5.2.52-1 - New upstream release. mysql-proxy-0.6.0-1.fc9 ----------------------- * Sat Dec 08 2007 Ruben Kerkhof - 0.6.0-1 - Upstream released new version - Fix license tag - Add BR for check-devel and flex mythes-de-0.20071208-1.fc9 -------------------------- nano-2.0.6-3.fc9 ---------------- * Fri Dec 07 2007 Jason L Tibbitts III - 2.0.6-3 - Pass rnano.1 through iconv to silence the final rpmlint complaint and finish up the merge review. nessus-core-2.2.10-3.fc9 ------------------------ * Sat Dec 08 2007 Andreas Bierfert - 2.2.10-3 - fix build #399211 (patch from Oliver Falk) - fix multilib issues #342661 - fix init scripts #246992 * Thu Dec 06 2007 Release Engineering - 2.2.10-2 - Rebuild for deps * Wed Aug 22 2007 Andreas Bierfert - 2.2.10-1 - version upgrade - new license tag nessus-libraries-2.2.10-2.fc9 ----------------------------- * Sat Dec 08 2007 Andreas Bierfert 2.2.10-2 - fix multilib #342671 openoffice.org-1:2.3.1-9.8.fc9 ------------------------------ * Sat Dec 08 2007 Caolan McNamara - 1:2.3.1-9.8 - Resolves: rhbz#384401 attempt to allow davs:// to work * Mon Dec 03 2007 Caolan McNamara - 1:2.3.1-9.7 - Resolves: rhbz#206400 add long awaited workspace.notes2.patch + drop openoffice.org-2.3.0.ooo53885.raiseannotationpriority.sw.patch integrated - add openoffice.org-2.3.1.oooXXXXX.ucb.davprotocol.patch for dav:// and davs:// perl-GSSAPI-0.24-2.fc9 ---------------------- * Sat Dec 08 2007 Steven Pritchard 0.24-2 - Update License tag. - Use fixperms macro instead of our own chmod incantation. - Source in /etc/profile.d/krb5-devel.sh to get our path right. perl-WWW-Mechanize-1.32-1.fc9 ----------------------------- * Fri Dec 07 2007 Chris Weyl - 1.32-1 - update to 1.32 pitivi-0.11.1-1.fc9 ------------------- * Sat Dec 08 2007 Jeffrey C. Ollie - 0.11.1-1 - Update to 0.11.1 pychess-0.8-0.1.beta2.fc9 ------------------------- * Mon Dec 03 2007 Michel Salim - 0.8-0.1.beta2 - Update to 0.8beta2 python-boto-0.9d-1.fc9 ---------------------- python-dns-1.6.0-1.fc9 ---------------------- * Tue Dec 04 2007 Jeffrey C. Ollie - 1.6.0-1 - Update to 1.6.0 qemu-launcher-1.7.4-4.fc9 ------------------------- * Sun Dec 09 2007 Nicholas Boyle - 1.7.4-4 - Added ExcludeArch: ppc64, as there is no ppc64 build for qemu shorewall-4.0.6-3.fc9 --------------------- * Sat Dec 08 2007 Jonathan G. Underwood - 4.0.6-3 - Added patch-perl-4.0.6-2.diff and patch-perl-4.0.6-3.diff - Fixed URLs for tarballs to match where upstream has moved them to smb4k-0.8.7-3.fc9 ----------------- * Sat Dec 08 2007 Marcin Garski 0.8.7-3 - Fix BR's to compile on rawhide * Sun Dec 02 2007 Marcin Garski 0.8.7-2 - Add qt-devel to BR * Sun Dec 02 2007 Marcin Garski 0.8.7-1 - Update to 0.8.7 tkimg-1.3-0.5.20071018svn.fc9 ----------------------------- * Thu Nov 08 2007 Sergio Pascual 1.3-0.5.20071018svn - Build patch simplified valknut-0.3.11-2.fc9 -------------------- * Wed Dec 05 2007 Luke Macken 0.3.11-2 - Rebuild xorg-x11-drv-openchrome-0.2.900-9.fc9 ------------------------------------- * Sat Dec 08 2007 Xavier Bachelot - 0.2.900-9 - Add patch for preliminary libpciaccess support. * Wed Nov 28 2007 Adam Jackson 0.2.900-8 - Obsolete xorg-x11-drv-via. The king is dead, long live the king. - Munge xorg.conf in %post to change from via to openchrome. - Drive-by spec cleanups. xpa-2.1.8-3.fc9 --------------- * Sat Dec 08 2007 Sergio Pascual 2.1.8-3 - Tcl interface in a different subpackage - pkgIndex.tcl added yelp-2.21.1-2.fc9 ----------------- * Sat Dec 08 2007 Matthias Clasen - 2.21.1-2 - Rebuild against new libbeagle zoneminder-1.22.3-10.fc9 ------------------------ * Thu Dec 06 2007 Martin Ebourne - 1.22.3-10 - Rebuild for new openssl Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.2.18-2.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libssl.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.i386 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 httrack - 3.42-6.fc9.i386 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.i386 requires libcrypto.so.6 licq - 1.3.4-8.fc9.i386 requires libssl.so.6 licq - 1.3.4-8.fc9.i386 requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libssl.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires liblber-2.3.so.0 scsi-target-utils - 0.0-1.20070803snap.fc8.i386 requires libcrypto.so.6 sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 anjuta - 1:2.2.0-3.fc8.x86_64 requires liblber-2.3.so.0()(64bit) anjuta - 1:2.2.0-3.fc8.x86_64 requires libldap-2.3.so.0()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.2.18-2.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.x86_64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) httrack - 3.42-6.fc9.x86_64 requires openssl = 0:0.9.8b httrack - 3.42-6.fc9.i386 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.x86_64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires liblber-2.3.so.0()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.x86_64 requires libcrypto.so.6()(64bit) sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.x86_64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.x86_64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires liblber-2.3.so.0()(64bit) wine-ldap - 0.9.49-1.fc9.i386 requires libldap_r-2.3.so.0 wine-ldap - 0.9.49-1.fc9.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.ppc requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.ppc requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.2.18-2.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libssl.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.ppc requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 httrack - 3.42-6.fc9.ppc requires openssl = 0:0.9.8b httrack - 3.42-6.fc9.ppc64 requires openssl = 0:0.9.8b ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.ppc requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libssl.so.6 libpreludedb-mysql - 0.9.11.1-2.fc7.ppc requires libcrypto.so.6 licq - 1.3.4-8.fc9.ppc requires libssl.so.6 licq - 1.3.4-8.fc9.ppc requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libssl.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libssl.so.6 perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires liblber-2.3.so.0 scsi-target-utils - 0.0-1.20070803snap.fc8.ppc requires libcrypto.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc requires libldap-2.3.so.0 subversion - 1.4.4-7.ppc requires libssl.so.6 subversion - 1.4.4-7.ppc requires libcrypto.so.6 subversion - 1.4.4-7.ppc requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.ppc64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) httrack - 3.42-6.fc9.ppc64 requires openssl = 0:0.9.8b kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libcrypto.so.6()(64bit) libpreludedb-mysql - 0.9.11.1-2.fc7.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libssl.so.6()(64bit) perl-Crypt-OpenSSL-RSA - 0.25-1.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires liblber-2.3.so.0()(64bit) scsi-target-utils - 0.0-1.20070803snap.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libcrypto.so.6()(64bit) From jkeating at redhat.com Sun Dec 9 14:17:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 9 Dec 2007 09:17:32 -0500 Subject: mock 0.8.9 In-Reply-To: <200712091219.50417.ville.skytta@iki.fi> References: <68720af30712021322h1bc0a068q8054f667f68ea3ad@mail.gmail.com> <68720af30712051356i541a3f28wd610fd46b68c88aa@mail.gmail.com> <20071207070448.GA20952@humbolt.us.dell.com> <200712091219.50417.ville.skytta@iki.fi> Message-ID: <20071209091732.40f7dbcc@redhat.com> On Sun, 9 Dec 2007 12:19:49 +0200 Ville Skytt? wrote: > http://download.fedora.redhat.com/pub/fedora/linux/updates/8/x86_64/ > still has 0.8.9 but bodhi shows 0.8.15 was pushed to stable updates > on 6th. Anyone know what's up? Strange, it looks like it never got the right tag in koji. Fixing. -- 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 andreas.bierfert at lowlatency.de Sun Dec 9 17:52:43 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 9 Dec 2007 18:52:43 +0100 Subject: Offer to Update Wine Package In-Reply-To: <475BC9CA.1000603@gmail.com> References: <93d66b780712081918h4b8e78efg89990fd1977c6871@mail.gmail.com> <475BC9CA.1000603@gmail.com> Message-ID: <20071209185243.38ca068f@alkaid.a.lan> On Sun, 09 Dec 2007 02:56:10 -0800 Andrew Farris wrote: > You probably should start by contacting the wine maintainer, who atm I believe > is Andreas Bierfert (andreas.bierfert _a t_ lowlatency.de) and asking what you > can do to help, see http://fedoraproject.org/wiki/AndreasBierfert/Wine. Could not have said it better ;) - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- 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 Sun Dec 9 19:11:37 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 9 Dec 2007 19:11:37 +0000 Subject: AWOL John Mahowald? Message-ID: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> Hi, Has anyone heard from John Mahowald (jpmahowald at gmail.com) ? He's the gnome-compiz-manager maintainer, but hasn't been responding to bug reports for some time. I've opened an AWOL bug #417381. Hopefully he'll come back. Jonathan. From lemenkov at gmail.com Sun Dec 9 20:37:30 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 9 Dec 2007 23:37:30 +0300 Subject: Are there any policy in creating SIGs? Message-ID: Hello All! I think there is demand for Fedora Erlang SIG, because there are some erlangers using Fedora, RHEL and derivatives. So I've got a question - is it enough just to create proper wiki-page (SIGs/Erlang) or I need pass some formal procedure? -- With best regards! From dan at danny.cz Sun Dec 9 20:38:54 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 09 Dec 2007 21:38:54 +0100 Subject: AWOL John Mahowald? In-Reply-To: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> References: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> Message-ID: <1197232734.3292.1.camel@eagle.danny.cz> Jonathan Underwood p??e v Ne 09. 12. 2007 v 19:11 +0000: > Hi, > > Has anyone heard from John Mahowald (jpmahowald at gmail.com) ? He's the > gnome-compiz-manager maintainer, but hasn't been responding to bug > reports for some time. I've opened an AWOL bug #417381. Hopefully > he'll come back. He was active on #fedora-devel today and should be still online. Dan From j.w.r.degoede at hhs.nl Sun Dec 9 21:15:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Dec 2007 22:15:18 +0100 Subject: Are there any policy in creating SIGs? In-Reply-To: References: Message-ID: <475C5AE6.6090809@hhs.nl> Peter Lemenkov wrote: > Hello All! > I think there is demand for Fedora Erlang SIG, because there are some > erlangers using Fedora, RHEL and derivatives. > > So I've got a question - is it enough just to create proper wiki-page > (SIGs/Erlang) or I need pass some formal procedure? > Nope, creating a page and declaring yourselves a SIG is enough to create a SIG, creating officially enforced Erlang packaging guidelines ofcourse does require the usual procedures for creating guidelines, but there are no rules surrounding SIG creation. Regards, Hans From denis at poolshark.org Sun Dec 9 21:35:46 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 09 Dec 2007 22:35:46 +0100 Subject: AWOL John Mahowald? In-Reply-To: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> References: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> Message-ID: <475C5FB2.9000203@poolshark.org> Jonathan Underwood wrote: > Hi, > > Has anyone heard from John Mahowald (jpmahowald at gmail.com) ? He's the > gnome-compiz-manager maintainer, but hasn't been responding to bug > reports for some time. I've opened an AWOL bug #417381. Hopefully > he'll come back. Could somebody approve my packagedb ACL request ? I'll then go ahead and check in the fix. From nicolas.mailhot at laposte.net Sun Dec 9 21:41:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Dec 2007 22:41:37 +0100 Subject: Are there any policy in creating SIGs? In-Reply-To: <475C5AE6.6090809@hhs.nl> References: <475C5AE6.6090809@hhs.nl> Message-ID: <1197236497.3679.0.camel@rousalka.dyndns.org> Le dimanche 09 d?cembre 2007 ? 22:15 +0100, Hans de Goede a ?crit : > but there are no rules surrounding SIG creation. Creating a SIG is easy, making it live less so. -- 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 bpepple at fedoraproject.org Sun Dec 9 21:55:15 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 09 Dec 2007 16:55:15 -0500 Subject: FESCo Meeting Summary for 2007-12-06 Message-ID: <1197237315.21721.3.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Jeremy Katz (jeremy) * Christian Iseli (c4chris) * Kevin Fenzi (nirik) * Josh Boyer (jwb) * Christopher Aillon (caillon) = Absent = * David Woodhouse (dwmw2) * Tom Callaway (spot) == Summary == === Are "spins" a feature? === * FESCo agreed that spins are not features, but that they should be touted on the -announce or -devel-announce lists. === Merge Reviews === * Long discussion on how to deal with merge reviews. tibbs & nirik are going to work on a proposal of packages to work on completing, and FESCo needs to get tangible buy-in from RH engineering mgnt. === F9 Feature Process === * FESCo approved the following features for F9: * http://fedoraproject.org/wiki/Releases/FeatureBluetooth * http://fedoraproject.org/wiki/Releases/FeatureClockApplet * http://fedoraproject.org/wiki/Features/PartitionResizing * http://fedoraproject.org/wiki/Features/VirtStorage * http://fedoraproject.org/wiki/Releases/FeatureFingerprint * http://fedoraproject.org/wiki/Features/PackageKit * http://fedoraproject.org/wiki/Features/Ext4 * http://fedoraproject.org/wiki/Releases/FeatureTexLive === Misc === * bpepple & Bob Jensen (EvilBob) will work on removing references to FC6 in the wiki, since Zod has been banished to the Phantom Zone. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2007-12-06.html 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 jpmahowald at gmail.com Sun Dec 9 22:07:35 2007 From: jpmahowald at gmail.com (John Mahowald) Date: Mon, 10 Dec 2007 16:07:35 +1800 Subject: AWOL John Mahowald? In-Reply-To: <475C5FB2.9000203@poolshark.org> References: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> <475C5FB2.9000203@poolshark.org> Message-ID: <3ea997540712091407u4b1243c5w43767258046895e8@mail.gmail.com> On Dec 10, 2007 3:35 PM, Denis Leroy wrote: > Jonathan Underwood wrote: > > Hi, > > > > Has anyone heard from John Mahowald (jpmahowald at gmail.com) ? He's the > > gnome-compiz-manager maintainer, but hasn't been responding to bug > > reports for some time. I've opened an AWOL bug #417381. Hopefully > > he'll come back. > > Could somebody approve my packagedb ACL request ? I'll then go ahead and > check in the fix. > > I'm here, just behind on things. I did approve Denis, thanks for stepping forward. John From mschwendt.tmp0701.nospam at arcor.de Sun Dec 9 23:36:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 10 Dec 2007 00:36:26 +0100 Subject: FESCo Meeting Summary for 2007-12-06 In-Reply-To: <1197237315.21721.3.camel@kennedy> References: <1197237315.21721.3.camel@kennedy> Message-ID: <20071210003626.2e3ef6b1.mschwendt.tmp0701.nospam@arcor.de> On Sun, 09 Dec 2007 16:55:15 -0500, Brian Pepple wrote: > IRC log can be found at: > http://bpepple.fedorapeople.org/fesco/FESCo-2007-12-06.html | warren f13, after last push, let's be sure we didn't add a terrible new broken dep. | f13 warren: sounds great, when will you have the report in? | warren that's all. | f13 there are currently no broken deps detectable in the push tool for Core 6, I have no idea what Extras looks like | FE6 has been free of broken deps for a long time and still is. Running extras-repoclosure on the needsign repo (and sometimes on updates-testing) prior to doing pushes has served very well. After receiving private mail about any broken deps caused by packages in needsign, most packagers have usually taken action within the next 48 hours. Only in a few cases it was necessary to delete the blocked/unreleased packages when they became older and older without any fix in sight. From Christian.Iseli at licr.org Mon Dec 10 08:25:05 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 10 Dec 2007 09:25:05 +0100 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1197081109.4572.11.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> <1197040134.2303.77.camel@localhost.localdomain> <1197081109.4572.11.camel@localhost.localdomain> Message-ID: <20071210092505.2f24ef8b@ludwig-alpha.unil.ch> On Sat, 08 Dec 2007 08:01:49 +0530, Tom "spot" Callaway wrote: > Rather than dropping bdftruncate entirely, perhaps simply put it in > its own subpackage? You wouldn't need it to Require anything (the > perl deps will be autogenerated), nor would xorg-x11-font-utils need > to Require the bdftruncate subpackage, effectively solving the > problem without dropping (semi) useful code. I know I won't have my pony this time round, but if I could have my druthers: that would be my preference too. Cheers, Christian From jcm at redhat.com Mon Dec 10 10:07:48 2007 From: jcm at redhat.com (Jon Masters) Date: Mon, 10 Dec 2007 05:07:48 -0500 Subject: kerneloops package available? Message-ID: <1197281268.2159.4.camel@perihelion> Yo, Is there any interest in getting the kerneloops[0] package into Fedora? Cheers, Jon. [0] http://www.kerneloops.org/ From frank-buettner at gmx.net Mon Dec 10 10:17:31 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 10 Dec 2007 11:17:31 +0100 Subject: squidGuard at EPEL Message-ID: <475D123B.1060203@gmx.net> Hello, after squidGuard will be developed forward again, I thing the maintainer shut add it to EPEL.:) 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 atkac at redhat.com Mon Dec 10 10:26:28 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 10 Dec 2007 11:26:28 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1197050005.30465.2.camel@localhost.localdomain> References: <1196890738.17277.22.camel@localhost.localdomain> <200712052302.59534.opensource@till.name> <1196986308.28417.8.camel@localhost> <20071207104235.GA7295@traged.englab.brq.redhat.com> <1197026907.4655.6.camel@localhost.localdomain> <20071207125346.GA8298@dspnet.fr.eu.org> <1197038247.10672.2.camel@localhost.localdomain> <20071207171454.GA30635@dspnet.fr.eu.org> <1197050005.30465.2.camel@localhost.localdomain> Message-ID: <20071210102628.GA7973@traged.englab.brq.redhat.com> On Fri, Dec 07, 2007 at 12:53:25PM -0500, Dan Williams wrote: > On Fri, 2007-12-07 at 18:14 +0100, Olivier Galibert wrote: > > On Fri, Dec 07, 2007 at 09:37:27AM -0500, Dan Williams wrote: > > > With the pull method, it _would_ still be done on changes. The things > > > that care listen for signals from NM about when the things change, and > > > when they do, they pull the info out of NM. Nothing here needs to poll > > > to get the info it wants. > > > > Color me confused, if NM sends a message to say "DNS config has > > changed", why doesn't it put the new configuration in the message? > > Why the extra round trip? > > Depends; if it's all the DHCP parameters, that's a lot of information to > spam the bus with when possibly nobody will be listening. Maybe it > doesn't matter because maybe most people DHCP-returned option list isn't > large. > > When I really meant with push vs. pull was that currently, > NetworkManager itself has all the D-Bus code to invoke method calls on > named. That's heavy-pushing, you might almost call it > poking-with-a-telephone-pole. I don't want to do that anymore, not for > named and not for anything else either. > > I'm perfectly fine with pushing out the information in the D-Bus signal. > If We are talking about pull style best will be send only SIGHUP when DNS related information is changed. This approach will avoid linking against libdbus (server oriented upstreams don't like it and keep "DBUS" patches downstream isn't nice solution). With SIGHUP We will siply write scripts to get all information from dbus (for example with dbus-send utility) and from server siply call that script which does all needed work (as Simo wrote). Sounds like best for me because maintenance and scalability of those scripts will be really easy. Adam -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Dec 10 10:37:16 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 10 Dec 2007 11:37:16 +0100 Subject: OMGWTF !! Remote Desktop in Fedora 8 In-Reply-To: <45abe7d80712081728y27eb83e1yf00e9c9cf75ec50d@mail.gmail.com> References: <38080.172.16.34.34.1197116746.squirrel@students.iiit.ac.in> <45abe7d80712081728y27eb83e1yf00e9c9cf75ec50d@mail.gmail.com> Message-ID: <20071210103716.GA9215@traged.englab.brq.redhat.com> On Sat, Dec 08, 2007 at 08:28:08PM -0500, Ray Strode wrote: > Hi, > > On Dec 8, 2007 7:25 AM, Kulbir Saini wrote: > > > > Hi all! > > > > I am using Fedora 7 upgraded to Fedora 8 packages via Yum. I have Remote > > Desktop (System -> Preferences -> Internet & Network -> Remote Desktop ) in > > my packages and using it. > > > > Problem: When I login to my system using 'vncviewer :0', i can access > > everything on the remote pc but the problem is the screen on server system > > (system with ) unlocks and everything that I do remotely is replicated > > on the actual system. > Yea, it's a known issue: > > http://bugzilla.gnome.org/show_bug.cgi?id=311780 It doesn't look like problem for me. I think all works as expected and is designed. I wonder how this will be fixed on gnome side without Xorg hacking. > > It's a pretty hard problem to solve though, and no one has put the > time in to tackle it. > In the mean time, if this is an issue for you, I would suggest using > Xvnc (from the vnc-server package) instead of vino. > > It works by running an entirely different session, separate from the > logged in and locked session. Definitely. Use Xvnc in your case. Adam -- Adam Tkac, Red Hat, Inc. From fedora at leemhuis.info Mon Dec 10 10:38:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Dec 2007 11:38:40 +0100 Subject: squidGuard at EPEL In-Reply-To: <475D123B.1060203@gmx.net> References: <475D123B.1060203@gmx.net> Message-ID: <475D1730.2090403@leemhuis.info> On 10.12.2007 11:17, Frank B?ttner wrote: > after squidGuard will be developed forward again, I thing the maintainer > shut add it to EPEL.:) I incidental send a mail to the squidGuard Fedora maintainer earlier today and asked him for his EPEL plans regarding squidGuard, as it was mentioned on the EPEL wishlist. But please remember, EPEL is voluntary. If he doesn't want to take care of the squidGuard in EPEL you might consider to take care of it in EPEL yourself if you'd like to see it in EPEL -- that's allowed and done a lot, as not all Fedora maintainers have a interest in packages for EL distributions. CU knurd From fedora at leemhuis.info Mon Dec 10 11:51:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Dec 2007 12:51:31 +0100 Subject: EPEL report week 49 2007 Message-ID: <475D2843.5010500@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week49 = Weekly EPEL Summary = Week 49/2007 == Most important happenings == * [:ThorstenLeemhuis:knurd] pushed a lot of packaged from EPEL5/testing to the proper EPEL repo (some were omitted due to broke deps). See these mails for details: * https://www.redhat.com/archives/epel-devel-list/2007-December/msg00009.html * https://www.redhat.com/archives/epel-devel-list/2007-December/msg00029.html * [:ThorstenLeemhuis:knurd] enhanced the wishlist, added lots of packages and send mails to the Fedora owners: * https://www.redhat.com/archives/epel-devel-list/2007-December/msg00037.html == Mailing list == === Noteworthy discussions === * major rework for ClamAV in the works; please see: https://www.redhat.com/archives/epel-devel-list/2007-December/msg00019.html == Meeting == === Next Meeting === 20071219 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === Full log: * https://www.redhat.com/archives/epel-devel-list/2007-December/msg00009.html Attendees: * [:DennisGilmore:dgilmore] * [:ThorstenLeemhuis:knurd] * [:MikeMcGrath:mmcgrath] * [:KevinFenzi:nirik] * [:KarstenWade:quaid] * [:MichaelStahnke:stahnma] Summary: * RHEL 5.1 (and 4.6) for the builders | dgilmore, mmcgrath * mmcgrath will take care of updating the buildroots to 5.1 and do the switch; announcement when happened to the list; 4.6. will be prepared, waiting for CentOS 4.6 * KojiAndBodhiForEpel | unassigned | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel * with FE6 EOL we are the only ones left on plague and the old scripts (and without bodhi) which might become a problem sooner or later * mmcgrath will try to poke the right people to make koji for EPEL hopefully possible sooner; he will also officially take care of this task from now on ("its going to become an Infrastructure priority anyway, count me in as point man") * testing -> stable move for EL5 | knurd | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove * prepared and happened when this summary got written (see above) * update http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies | unassigned | http://fedoraproject.org/wiki/EPEL/Tasks/Misc * page is a bit oputdated; nirik will take a look to bring it up2date * Free discussion around EPEL * nirik> | I'd like to throw out a plea for a reviewer for my clamav for epel package... https://bugzilla.redhat.com/show_bug.cgi?id=396171 nirik> | I'd like to get clamav in, but I fear people are afraid because it's not the same as the fedora package. Or that it is and they would have to review that... * nirik> | I also have been working on getting munin in... cleaned up the fedora package and am working on the requirements for epel. == Stats == === General === Number of EPEL Contributors: 143 We welcome 2 new contributers: dsugar, jlaska === EPEL 5 === Number of source packages: 847 Number of binary packages: 1569 There are 18 new Packages: * dsniff | Tools for network auditing and penetration testing * fbreader | E-book reader * fedora-packager | Tools for setting up a fedora maintainer environment * gqview | Image browser and viewer * libEMF | A library for generating Enhanced Metafiles * libetpan | Portable, efficient middleware for different kinds of mail access * libnids | Implementation of an E-component of Network Intrusion Detection System * pcapy | A Python interface to libpcap * perl-BerkeleyDB | Perl extension for Berkeley DB version 2, 3 or 4 * perl-Jcode | Perl extension interface for converting Japanese text * perl-Unicode-Map8 | Mapping table between 8-bit chars and Unicode for Perl * perl-Unicode-Map | Perl module for mapping charsets from and to utf16 unicode * perl-Unicode-MapUTF8 | Conversions to and from arbitrary character sets and UTF8 * perl-Unicode-String | Perl modules to handle various Unicode issues * plotutils | GNU vector and raster graphics utilities and libraries * pstoedit | Translates PostScript and PDF graphics into other vector formats * python-pydns | Python module for DNS (Domain Name Service) * vala | A modern programming language for GNOME === EPEL 4 === Number of source packages: 470 Number of binary packages: 926 There are 11 new Packages: * aoetools | ATA over Ethernet Tools * dsniff | Tools for network auditing and penetration testing * fedora-packager | Tools for setting up a fedora maintainer environment * libetpan | Portable, efficient middleware for different kinds of mail access * libnids | Implementation of an E-component of Network Intrusion Detection System * perl-BerkeleyDB | Perl extension for Berkeley DB version 2, 3 or 4 * perl-Jcode | Perl extension interface for converting Japanese text * perl-Unicode-Map8 | Mapping table between 8-bit chars and Unicode for Perl * perl-Unicode-Map | Perl module for mapping charsets from and to utf16 unicode * perl-Unicode-MapUTF8 | Conversions to and from arbitrary character sets and UTF8 * perl-Unicode-String | Perl modules to handle various Unicode issues ---- ["CategoryEPELReports"] From sgrubb at redhat.com Mon Dec 10 14:10:34 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 10 Dec 2007 09:10:34 -0500 Subject: alpha/beta software in Fedora 8? In-Reply-To: References: <20071127022448.GB24257@angus.ind.WPI.EDU> <200711280848.24953.sgrubb@redhat.com> Message-ID: <200712100910.34919.sgrubb@redhat.com> Hi, Sorry, I don't think we are quite done flogging this one http://www.bittermancircle.com/my%20images/BeatDeadHorse.gif :) On Friday 30 November 2007 10:35:57 Kevin Kofler wrote: > Steve Grubb redhat.com> writes: > > How about unreleased cvs snapshots? kdepim in F7 failed to work after a > > recent upgrade (and had been working fine) and my problem was only solved > > by upgrading to F8 which had a more recent cvs snapshot that is still > > buggy but > > I'll sched some light on the situation of kdepim: > > Basically, the problem is that the last really stable release of kdepim, > especially KMail, was 3.5.6. When we upgraded KDE to 3.5.7, we were hit by > 2 serious regressions in KMail IMAP filtering, which made IMAP filters > essentially unusable (one of them broke automatic filtering and one manual > filtering). The bugs were reported upstream, but nobody knew how to fix > automatic filtering in 3.5.7. This situation persisted for weeks. At that > point other distributions (at least openSUSE and Kubuntu, probably more) > started shipping kdepim from the enterprise branch, so we tried that, and > found in our testing that it fixed the KMail IMAP regressions. However, > nobody upstream knew how to backport whatever made it work in the > enterprise branch to the regular 3.5 branch, nor did we. So, given how many > complaints we got about those IMAP regressions (complaints of the "you > broke my KMail" type, which weren't unreasonable given what happened), we > decided to rush the enterprise branch update as an F7 update so this gets > finally fixed, as no other fix was in sight. I think I would have voted for sitting on the current package. The enterprise branch is very, very different. > (We considered reverting kdepim to 3.5.6, but there were other changes in > 3.5.7 we didn't want to revert, e.g. in KitchenSync.) You can't - literally. KDE modifies its configuration. You would need the old config saved away on a per version directory. > The current situation is now that: > * the newer snapshot which fixes your problems will be pushed to Fedora 7 > updates (or already was? Which snapshot fixed your problems? I had to upgrade to F8 to fix my problem. The one in F8 crashes anytime the imap server is slow and you start clicking around on other mails to see if anything is alive. I've filed a bz on this, too. > > usable. Rolling back did not work. The only support I got by the Fedora > > maintainer was telling me to report it upstream. Upstream does not > > support it because its a cvs snapshot and not a released version. > > Upstream really should support it because 1. it's scheduled to be merged > into the next release and 2. it's being shipped by several distros. OK, here is what upstream said: >> 1) Is this (kdepim-enterprise-svn20070926.tar.bz2) an officially >> supported release? > >No, it says "svn" which means it was a development snapshot. >We do have some snapshots which we consider good for testing >which which some people use in production (as testing) and packagers >might want to pick up for the "test" builds, check >http://apt.intevation.de/dists/etch/unstable/source/ Question: are we using this as our source? Should we sync up with their recommendations? >> 2) How much testing goes into a tarball like this before a release? > >We did not release this tarball, it seems to have been a snapshot >quality control depends on the one who created it. > >The ones that you can find in the mentioned "unstable" apt directory above >have seen internal testing. This consists of testing towards the new feature >and a basic test that covers some core functionality. So if we pick a random day to get a cvs snapshot, we are completely on our own. >> 3) Did you make any kind of announcement that this was ready to be used >> by end users? > >No. Observation: Since they are not announcing anything about a feature being complete, a snapshot on a random day could catch something half patched. >> 4) Is this release stable enough for a business to run on? > >I cannot say, it depends who created the snapshot >and what promisses were made for it. Probably not. So, if you use Fedora's kmail, the upstream *developers* say it not stable enough to use for production. By taking snaps on random days, we are on our own. I rest my case.... -Steve From buildsys at redhat.com Mon Dec 10 14:15:39 2007 From: buildsys at redhat.com (Build System) Date: Mon, 10 Dec 2007 09:15:39 -0500 Subject: rawhide report: 20071210 changes Message-ID: <200712101415.lBAEFdMu027617@porkchop.devel.redhat.com> New package totem-pl-parser Totem Playlist Parser library Updated Packages: PackageKit-0.1.4-2.fc9 ---------------------- * Sun Dec 09 2007 Matthias Clasen - 0.1.4-2 - Make it build against PolicyKit 0.7 WindowMaker-0.92.0-15.fc9 ------------------------- * Sun Dec 09 2007 Andreas Bierfert - 0.92.0-15 - add patches from #267041 for less wakeup calls - fix multilib stuff #343431 beagle-0.3.0-1.fc9 ------------------ * Wed Dec 05 2007 Matthias Clasen - 0.3.0-1 - Update to 0.3.0 - Drop libbeagle subpackages - Split off a -devel package claws-mail-3.1.0-4.fc9 ---------------------- * Sun Dec 09 2007 Andreas Bierfert - 3.1.0-4 - fix #340871 multilib * Sat Dec 08 2007 Andreas Bierfert - 3.1.0-3 - fix desktop file * Thu Dec 06 2007 Release Engineering - 3.1.0-2 - Rebuild for deps dejavu-fonts-2.22-1.fc9 ----------------------- * Sun Dec 09 2007 ??? 2.22-1 ??? 2.22 final deluge-0.5.7.1-2.fc9 -------------------- * Sun Dec 09 2007 Peter Gordon - 0.5.7.1-2 - Add missing icon cache %post and %postun scriptlets. - Add missing egg-info to the %files list. doodle-0.6.7-1.fc9 ------------------ * Sun Dec 09 2007 Karol Trzcionka - 0.6.7-1 - Update to v0.6.7 firefox-2.0.0.10-4.fc9 ---------------------- * Sun Dec 09 2007 Christopher Aillon 2.0.0.10-4 - Fix up some rpmlint warnings - Use only one pref for the homepage for now - Drop some old patches and some obsolote Obsoletes fnfx-0.3-10.fc9 --------------- * Sun Dec 09 2007 Andreas Bierfert - 0.3-10 - add init LSB support (#246927) gnome-compiz-manager-0.10.4-3.fc9 --------------------------------- * Sun Dec 09 2007 Denis Leroy - 0.10.4-3 - Fix duplicate desktop entries - Made gconf killall silent gnome-schedule-1.2.1-2.fc9 -------------------------- * Sun Dec 09 2007 Frank Arnold 1.2.1-2 - Bump release * Sun Dec 09 2007 Frank Arnold 1.2.1-1 - Update to 1.2.1 gstreamer-plugins-base-0.10.15-1.fc9 ------------------------------------ * Sat Nov 17 2007 - Bastien Nocera - 0.10.15-1 - Update to 0.10.15 gtk-qt-engine-1:0.8-1.fc9 ------------------------- * Sun Dec 09 2007 Rex Dieter 1:0.8-1 - gtk-qt-engine-0.8 * Sun Dec 09 2007 Rex Dieter 0.70-7.20070811svn - BR: kdelibs3-devel hamlib-1.2.6.2-5.fc9 -------------------- * Sun Dec 09 2007 Sindre Pedersen Bj??rdal - 1.2.6.2-5 - use sitearch not sitelib for perl package - Make sure it builds on all arches * Sat Dec 08 2007 Sindre Pedersen Bj??rdal - 1.2.6.2-3 - Clean up BuildRequires - Remove obsolete swig patch * Sat Dec 08 2007 Sindre Pedersen Bj??rdal - 1.2.6.2-2 - Spec file cleanups - Use make install instead of depriciated %makeinstall - Replace make trickery with patched upstream makefiles - enable perl bindings - Patch bindings makefile to install perl to vendor, not site - Merge swig patch with bindings patch - enable tcl bindings - Create doc subpackage, solves #341481 - Remove 2nd bindings patch, not needed as we don't rely on make trickery for bindings anymore - Add patch to install python bindings in proper python dirs - Clean up %files list - Depend on version-release, not just version httrack-3.42-7.fc9 ------------------ * Sun Dec 09 2007 Debarshi Ray - 3.42-7 - Updated 'Requires: openssl = 0.9.8g' and fixed the sources. * Fri Dec 07 2007 Release Engineering - 3.42-6 - Rebuild for deps. * Tue Nov 27 2007 Debarshi Ray - 3.42-4 - Removed Encoding from Desktop Entry for all distributions, except Fedora 7. itpp-4.0.0-2.fc9 ---------------- * Sun Dec 09 2007 Ed Hill - 4.0.0-2 - fix hard-coded libdir error * Sun Dec 09 2007 Ed Hill - 4.0.0-1 - new upstream 4.0.0 jd-1.9.8-0.2.svn1612.fc9 ------------------------ * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.2.svn1612 - svn 1612 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 kdebluetooth-1.0-0.39.beta8.fc9 ------------------------------- * Sun Dec 09 2007 Ville Skytt?? - 1.0-0.39.beta8 - Require kdesu in main package. * Sat Dec 08 2007 Rex Dieter 1.0-0.38.beta8 - BR: kdelibs3-devel kdepim3-devel - drop Requires: kdebase (?) * Thu Nov 08 2007 Gilboa Davara 1.0-0.37.beta8 - Missing BR: automake, autoconf. kdnssd-avahi-0.1.3-0.4.20060713svn.fc9 -------------------------------------- * Sun Dec 09 2007 Rex Dieter 0.1.3-0.4.20060713svn - drop Req: kdelibs3 (no longer worries about conflicts) * Sat Dec 08 2007 Rex Dieter 0.1.3-0.3.20060713svn - BR: kdelibs3-devel - License: LGPLv2+ kernel-2.6.24-0.80.rc4.git6.fc9 ------------------------------- * Sat Dec 08 2007 Dave Jones - 2.6.24-rc4-git6 * Fri Dec 07 2007 Peter Jones - Turn on CONFIG_FB_IMAC . * Fri Dec 07 2007 Dave Jones - 2.6.24-rc4-git5 krusader-1.80.0-3.fc9 --------------------- * Sun Dec 09 2007 Marcin Garski 1.80.0-3 - BR: kdelibs3-devel kdebase3-devel libkdcraw-0.1.2-2.fc9 --------------------- * Sun Dec 09 2007 Marcin Garski 0.1.2-2 - BR: kdelibs3-devel libpreludedb-0.9.11.1-4.fc9 --------------------------- * Sun Dec 09 2007 - 0.9.11.1-4 - Add missing BR: perl-devel * Thu Dec 06 2007 Release Engineering - 0.9.11.1-3 - Rebuild for deps man-pages-it-2.65-7.fc9 ----------------------- * Thu Dec 06 2007 Ding-Yi Chen - 2.65-7 - [Bug 226125] Merge Review: man-page-it (Comment 13) mock-0.9.0-1.fc9 ---------------- * Sun Dec 09 2007 Michael Brown - 0.9.0-1 - drop suid helper and use consolehelper instead. - add unshare() call rather than clone(CLONE_NEWNS...) * Sun Dec 09 2007 Michael Brown - 0.8.16-1 - drop FC6 configs. FC6 no longer supported - add --trace cmdline parameter - make logs slightly less verbose openoffice.org-1:2.3.1-9.9.fc9 ------------------------------ * Sun Dec 09 2007 Caolan McNamara - 1:2.3.1-9.9 - oops perl-Crypt-OpenSSL-RSA-0.25-3.fc9 --------------------------------- * Sun Dec 09 2007 Release Engineering - 0.25-3 - Rebuild for deps * Thu Dec 06 2007 Wes Hardaker - 0.25-2 - Bump to force rebuild with new openssl lib version phpMyAdmin-2.11.3-1.fc9 ----------------------- * Sun Dec 09 2007 Robert Scheck 2.11.2.2-1 - Upstream released 2.11.3 - Removed the RPM scriptlets doing httpd restarts (#227025) - Patched an information disclosure known as CVE-2007-0095 (#221694) - Provide virtual phpmyadmin package and a httpd alias (#231431) pinentry-0.7.4-1.fc9 -------------------- * Sun Dec 09 2007 Rex Dieter - 0.7.4-1 - pinentry-0.7.4 - BR: libcap-devel sabayon-2.20.1-4.fc9 -------------------- * Sun Dec 09 2007 Matthias Clasen - 2.20.1-4 - Don't use gnomesu * Fri Oct 12 2007 Matthias Clasen - 2.20.1-3 - Be more robust when directories are missing (#329471) - Work better with SELinux (#329501) - Move debuglog.py to the -apply package (#330001) * Thu Oct 11 2007 Matthias Clasen - 2.20.1-2 - Require pyxdg (#327851) sane-backends-1.0.18-20.fc9 --------------------------- * Fri Dec 07 2007 Jesse Keating - 1.0.18-20 - undo bootstrap setting now that hplip built. scsi-target-utils-0.0-2.20070803snap.fc9 ---------------------------------------- * Fri Dec 07 2007 Alex Lancaster 0.0-2.20070803snap - Rebuild for new openssl soname bump sofia-sip-1.12.7-1.fc9 ---------------------- thunderbird-2.0.0.9-2.fc9 ------------------------- * Sun Dec 09 2007 Christopher Aillon 2.0.0.9-2 - Fix some rpmlint warnings - Drop some old patches and obsoletes * Thu Nov 15 2007 Christopher Aillon 2.0.0.9-1 - Update to 2.0.0.9 totem-2.21.5-2.fc9 ------------------ * Sun Dec 09 2007 Matthias Clasen - 2.21.5-2 - Make it build * Sun Dec 09 2007 - Bastien Nocera - 2.21.5-1 - Update to 2.21.5 - Remove -devel and -plparser subpackages, they're in totem-pl-parser now * Thu Dec 06 2007 - Bastien Nocera - 2.21.3-3 - The mozilla plugin only need gecko-libs, not devel Thanks to Jeremy Katz for noticing util-linux-ng-2.13.1-0.1.fc9 ---------------------------- * Sun Dec 09 2007 Karel Zak 2.13.1-0.1 - update to the latest upstream stable branch (commit: fda9d11739ee88c3b2f22a73f12ec019bd3b8335) wine-0.9.49-2.fc9 ----------------- * Sun Dec 09 2007 Alex Lancaster - 0.9.49-2 - Rebuild for new openssl/openldap soname bump xorg-x11-drv-i810-2.2.0-2.fc9 ----------------------------- * Mon Dec 10 2007 Dave Airlie 2.2.0-2 - hook up ch7017 (bz#408471) xorg-x11-drv-radeonhd-1.0.0-0.2.20071209git.fc9 ----------------------------------------------- * Sun Dec 09 2007 Hans Ulrich Niedermann - 1.0.0-0.2.20071209git - New snapshot (upstream commit e399d16597e30a6c53c8f70aa122285615fe7d08) - Fix blank screen occuring in some cases. - Initial RS600 support. - Sync and LUT fixes. - Add useful DPI calculation. - Relax xorg-x11-server-utils requirement: Only for F-8 and later, no %{dist}. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.3.0-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 brasero - 0.6.1-2.fc9.i386 requires libbeagle.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libssl.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.i386 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kerry - 0.2.1-4.fc8.i386 requires libbeagle.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 licq - 1.3.4-8.fc9.i386 requires libssl.so.6 licq - 1.3.4-8.fc9.i386 requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libssl.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.i386 requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires liblber-2.3.so.0 sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 anjuta - 1:2.2.0-3.fc8.x86_64 requires liblber-2.3.so.0()(64bit) anjuta - 1:2.2.0-3.fc8.x86_64 requires libldap-2.3.so.0()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.3.0-1.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 brasero - 0.6.1-2.fc9.x86_64 requires libbeagle.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.x86_64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kerry - 0.2.1-4.fc8.x86_64 requires libbeagle.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.x86_64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires liblber-2.3.so.0()(64bit) sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansOblique.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBold.ttf sdljava-demo - 0.9.1-6.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSansBoldOblique.ttf showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.x86_64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.x86_64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.x86_64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.i386 requires libldap-2.3.so.0 subversion - 1.4.4-7.i386 requires libssl.so.6 subversion - 1.4.4-7.i386 requires libcrypto.so.6 subversion - 1.4.4-7.i386 requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.ppc requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.ppc requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.3.0-1.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 brasero - 0.6.1-2.fc9.ppc requires libbeagle.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libssl.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.ppc requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kdesvn - 0.14.1-1.fc9.ppc requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kerry - 0.2.1-4.fc8.ppc requires libbeagle.so.0 kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc requires libssl.so.6 licq - 1.3.4-8.fc9.ppc requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libssl.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc requires libcrypto.so.6 perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc requires libldap-2.3.so.0 subversion - 1.4.4-7.ppc requires libssl.so.6 subversion - 1.4.4-7.ppc requires libcrypto.so.6 subversion - 1.4.4-7.ppc requires liblber-2.3.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.ppc64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc64 requires libcrypto.so.6()(64bit) perl-Crypt-OpenSSL-PKCS10 - 0.06-6.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libcrypto.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires libldap-2.3.so.0()(64bit) subversion - 1.4.4-7.ppc64 requires libssl.so.6()(64bit) subversion - 1.4.4-7.ppc64 requires liblber-2.3.so.0()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libcrypto.so.6()(64bit) From denis at poolshark.org Mon Dec 10 14:52:03 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 10 Dec 2007 15:52:03 +0100 Subject: AWOL John Mahowald? In-Reply-To: <3ea997540712091407u4b1243c5w43767258046895e8@mail.gmail.com> References: <645d17210712091111n7e6c317x15a9d76d6217b09@mail.gmail.com> <475C5FB2.9000203@poolshark.org> <3ea997540712091407u4b1243c5w43767258046895e8@mail.gmail.com> Message-ID: <475D5293.7010908@poolshark.org> John Mahowald wrote: > On Dec 10, 2007 3:35 PM, Denis Leroy wrote: >> Jonathan Underwood wrote: >>> Hi, >>> >>> Has anyone heard from John Mahowald (jpmahowald at gmail.com) ? He's the >>> gnome-compiz-manager maintainer, but hasn't been responding to bug >>> reports for some time. I've opened an AWOL bug #417381. Hopefully >>> he'll come back. >> Could somebody approve my packagedb ACL request ? I'll then go ahead and >> check in the fix. >> >> > > I'm here, just behind on things. > I did approve Denis, thanks for stepping forward. Thanks John, Builds are available for F-8 and devel From tcallawa at redhat.com Sat Dec 8 02:31:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Dec 2007 08:01:49 +0530 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1197040134.2303.77.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> <1197040134.2303.77.camel@localhost.localdomain> Message-ID: <1197081109.4572.11.camel@localhost.localdomain> On Fri, 2007-12-07 at 10:08 -0500, Adam Jackson wrote: > On Fri, 2007-12-07 at 06:12 +0000, Kevin Kofler wrote: > > Adam Jackson redhat.com> writes: > > > I plan to drop bdftruncate from font-utils to get rid of the perl bloat, > > > unless someone has a compelling reason not to. > > > > What's the problem with depending on Perl? It's a useful scripting language, > > used in a lot of packages, thus so many things require it that you'll be > > hard-pressed to find a working system without Perl, especially an X11-enabled > > one. For example, kdelibs requires Perl (it's used for things like > > kconf_update), so any KDE system will always have Perl anyway. > > I'm not arguing against perl qua perl. I am arguing against needless > arcs in the dep graph. This one package has a perl dependency solely > because it provides a single perl script that no one is ever likely to > use. > > Sure, it's just one dep, but every dep counts. The complexity of the > graph directly affects runtime performance for rpm and yum, and the > ability to use trimmed subsets of Fedora for custom purposes. The graph > is important. We argue so much for correcness in initial packaging. We > should be correct at the system level too. Rather than dropping bdftruncate entirely, perhaps simply put it in its own subpackage? You wouldn't need it to Require anything (the perl deps will be autogenerated), nor would xorg-x11-font-utils need to Require the bdftruncate subpackage, effectively solving the problem without dropping (semi) useful code. %package -n bdftruncate Summary: Generate truncated BDF font from ISO 10646-1 encoded BDF font Group: Applications/System %description -n bdftruncate bdftruncate allows one to generate from an ISO10646-1 encoded BDF font other ISO10646-1 BDF fonts in which all characters above a threshold code value are stored unencoded. This is often desirable because the Xlib API and X11 protocol data structures used for representing font metric information are extremely inefficient when handling sparsely populated fonts. ... %files -n bdftruncate %defattr(-,root,root,-) %{_bindir}/bdftruncate %{_mandir}/bdftruncate.* ~spot From paul at xelerance.com Mon Dec 10 15:27:47 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 10 Dec 2007 10:27:47 -0500 (EST) Subject: squidGuard at EPEL In-Reply-To: <475D123B.1060203@gmx.net> References: <475D123B.1060203@gmx.net> Message-ID: On Mon, 10 Dec 2007, Frank B?ttner wrote: > after squidGuard will be developed forward again, I thing the maintainer > shut add it to EPEL.:) I'm glad to see all the license weirdness about squidguard to have been removed from their webpages. I should look into using it now. Paul From paul at xelerance.com Mon Dec 10 15:32:06 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 10 Dec 2007 10:32:06 -0500 (EST) Subject: kerneloops package available? In-Reply-To: <1197281268.2159.4.camel@perihelion> References: <1197281268.2159.4.camel@perihelion> Message-ID: On Mon, 10 Dec 2007, Jon Masters wrote: > Is there any interest in getting the kerneloops[0] package into Fedora? I think that might be useful, though I wouldn't enable it per default for everyone. Paul From rdieter at math.unl.edu Mon Dec 10 15:48:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Dec 2007 09:48:23 -0600 Subject: alpha/beta software in Fedora 8? References: <20071127022448.GB24257@angus.ind.WPI.EDU> <200711280848.24953.sgrubb@redhat.com> <200712100910.34919.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > OK, here is what upstream said: Thanks for the persistence and followup. :) >>> 1) Is this (kdepim-enterprise-svn20070926.tar.bz2) an officially >>> supported release? >> >>No, it says "svn" which means it was a development snapshot. >>We do have some snapshots which we consider good for testing >>which which some people use in production (as testing) and packagers >>might want to pick up for the "test" builds, check >>http://apt.intevation.de/dists/etch/unstable/source/ That's news to me. When I asked, I was told there was no "release" and to pull from subversion. Glad to hear otherwise. > Question: are we using this as our source? Should we sync up with their > recommendations? Makes sense. >>> 2) How much testing goes into a tarball like this before a release? >> >>We did not release this tarball, it seems to have been a snapshot >>quality control depends on the one who created it. >> >>The ones that you can find in the mentioned "unstable" apt directory above >>have seen internal testing. This consists of testing towards the new >>feature and a basic test that covers some core functionality. Make sense +2. I'm curious exactly "internal testing" exactly means, but either way, it's better than a random snapshot with no "internal testing". >>> 3) Did you make any kind of announcement that this was ready to be used >>> by end users? >> >>No. Sorry if you've already heard this before, but it's worth repeating: I was told at akademy of kdepim-enterprise's existence, by several of it's developers, and urged to strongly consider using this (in fedora). > Observation: Since they are not announcing anything about a feature being > complete, a snapshot on a random day could catch something half patched. fwiw, I watch the commits, make an effort to get "good" snapshots, but point taken. >>> 4) Is this release stable enough for a business to run on? >> >>I cannot say, it depends who created the snapshot >>and what promisses were made for it. Probably not. > > So, if you use Fedora's kmail, the upstream *developers* say it not stable > enough to use for production. By taking snaps on random days, we are on > our own. I rest my case.... I think we can all agree that random snapshots are bad, and it's nice to be made aware of uptream's semi-official, internally tested, tarball snapshots. Would switching to their snapshots instead of our own random ones, satisfy most/all of your concerns? -- Rex From ajackson at redhat.com Mon Dec 10 16:32:44 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 10 Dec 2007 11:32:44 -0500 Subject: Planned change to xorg-x11-font-utils In-Reply-To: <1197081109.4572.11.camel@localhost.localdomain> References: <1196976223.2303.51.camel@localhost.localdomain> <1197040134.2303.77.camel@localhost.localdomain> <1197081109.4572.11.camel@localhost.localdomain> Message-ID: <1197304364.21733.24.camel@localhost.localdomain> On Sat, 2007-12-08 at 08:01 +0530, Tom "spot" Callaway wrote: > Rather than dropping bdftruncate entirely, perhaps simply put it in its > own subpackage? You wouldn't need it to Require anything (the perl deps > will be autogenerated), nor would xorg-x11-font-utils need to Require > the bdftruncate subpackage, effectively solving the problem without > dropping (semi) useful code. But the bugs, you see, are in the files. Yeah, okay. bdftruncate is a subpackage now. - ajax From sgrubb at redhat.com Mon Dec 10 16:19:05 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 10 Dec 2007 11:19:05 -0500 Subject: alpha/beta software in Fedora 8? In-Reply-To: References: <20071127022448.GB24257@angus.ind.WPI.EDU> <200712100910.34919.sgrubb@redhat.com> Message-ID: <200712101119.05322.sgrubb@redhat.com> On Monday 10 December 2007 10:48:23 Rex Dieter wrote: > > So, if you use Fedora's kmail, the upstream *developers* say it not > > stable enough to use for production. By taking snaps on random days, we > > are on our own. I rest my case.... > > I think we can all agree that random snapshots are bad, and it's nice to be > made aware of uptream's semi-official, internally tested, tarball > snapshots. I'd try to work out something with upstream that they maybe announce a new testing snapshot in that directory. Someone said other distros are using it, so you can't be alone in wanting some feedback on when you can test a new "release". Somehow I'd think we need to account for that location as the pickup point inside the specfile so others know where this came from. > Would switching to their snapshots instead of our own random ones, satisfy > most/all of your concerns? That depends on if a new kdepim package suddenly quits working for me in F8. :) Thanks, -Steve From kevin.kofler at chello.at Mon Dec 10 16:23:00 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 10 Dec 2007 16:23:00 +0000 (UTC) Subject: alpha/beta software in Fedora 8? References: <20071127022448.GB24257@angus.ind.WPI.EDU> <200711280848.24953.sgrubb@redhat.com> <200712100910.34919.sgrubb@redhat.com> Message-ID: Steve Grubb redhat.com> writes: > I think I would have voted for sitting on the current package. The > enterprise branch is very, very different. We know it is, that's why there was no way to backport whatever fixed the IMAP bug in 3.5.7 (or rather: made it not be there in the first place, AFAIK the enterprise branch never had that particular bug). The IMAP code there is significantly different and the difference which matters here is certainly one of the big internal reorganizations. > > (We considered reverting kdepim to 3.5.6, but there were other changes in > > 3.5.7 we didn't want to revert, e.g. in KitchenSync.) > > You can't - literally. KDE modifies its configuration. You would need the old > config saved away on a per version directory. Actually it depends. In the worst case, yes, reverting leads to broken configurations. In others it works. For 3.5.7->3.5.6, KitchenSync would have been likely to have configuration problems because of the significant changes, KMail not so much. But reverting from the enterprise branch to a 3.5.x would be likely to break things, which is another good reason for continuing with that branch. :-) Kevin Kofler From debarshi.ray at gmail.com Mon Dec 10 16:27:15 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 10 Dec 2007 21:57:15 +0530 Subject: bouml-doc: can't create updates for F-8 and Rawhide after dist tag removal In-Reply-To: <20071208092808.376235ba@redhat.com> References: <3170f42f0712030442n4b847d59l4222b5f2acbf300f@mail.gmail.com> <20071203095802.6541646a@redhat.com> <3170f42f0712031048o8fc7a3bq14b41d831fa9e5fe@mail.gmail.com> <20071203140231.4f1f4fb2@redhat.com> <3170f42f0712031800r63c0fe91k16152e7b01532504@mail.gmail.com> <3170f42f0712080123w12bcfef4s54b26138271fdd68@mail.gmail.com> <1197116126.3820.1.camel@scrappy.miketc.com> <20071208092808.376235ba@redhat.com> Message-ID: <3170f42f0712100827j15625adfgbe46861f4695da7b@mail.gmail.com> Can the same be done for redet-doc: https://admin.fedoraproject.org/updates/F7/pending/redet-doc-8.23-2 ? I have built it for F-7 and requested a push to stable. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jeff at ocjtech.us Mon Dec 10 16:40:39 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 10 Dec 2007 10:40:39 -0600 Subject: Orphaning Ejabberd Message-ID: <935ead450712100840u686d260fx9ec2ff24164f1d1b@mail.gmail.com> Hello, I'd like to find someone to take over ejabberd. I no longer use ejabberd and I don't know Erlang so I can't be the best maintainer for the package. I believe that OLPC intends to/is using ejabberd for some of their backend services so I'm sure that they'd appreciate it if someone could give the package some love. There are two open bugs, the more important of the two is 418131 which is breakage caused by the recent OpenSSL rebase in development. I'm unable to get ejabberd fixed up with a simple "bump release and rebuild" and I don't really have the time/knowledge to look into the details. Here's the list of open bugs: https://bugzilla.redhat.com/show_bug.cgi?id=418131 https://bugzilla.redhat.com/show_bug.cgi?id=227270 Jeff From lemenkov at gmail.com Mon Dec 10 16:45:45 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 10 Dec 2007 19:45:45 +0300 Subject: Orphaning Ejabberd In-Reply-To: <935ead450712100840u686d260fx9ec2ff24164f1d1b@mail.gmail.com> References: <935ead450712100840u686d260fx9ec2ff24164f1d1b@mail.gmail.com> Message-ID: 2007/12/10, Jeffrey Ollie : > Hello, > > I'd like to find someone to take over ejabberd. I will take it. -- With best regards! From oliver at linux-kernel.at Mon Dec 10 16:47:06 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 10 Dec 2007 17:47:06 +0100 Subject: kernel- or glibc-headers in f9 broken? Message-ID: <475D6D8A.80708@linux-kernel.at> fyi. In file included from /usr/include/asm/sigcontext.h:4, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/sys/wait.h:31, from ../include/conf.h:95, from pr_fnmatch.c:38: /usr/include/asm/types.h:6: error: conflicting types for 'mode_t' /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was here make[2]: *** [pr_fnmatch.o] Error 1 Is what I see, if I try to rebuild proftpd in f9. [oliver at pils proftpd]$ rpm -qf /usr/include/sys/types.h /usr/include/asm/types.h glibc-headers-2.7-2 kernel-headers-2.6.24-0.79.rc4.git5.fc9 Funny: [oliver at pils proftpd]$ grep mode_t /usr/include/asm/types.h typedef unsigned short umode_t; This is a i386 box! -of From jeff at ocjtech.us Mon Dec 10 16:54:13 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 10 Dec 2007 10:54:13 -0600 Subject: Orphaning Ejabberd In-Reply-To: References: <935ead450712100840u686d260fx9ec2ff24164f1d1b@mail.gmail.com> Message-ID: <935ead450712100854x19cf97a4l6a11a5e846e19b6b@mail.gmail.com> On 12/10/07, Peter Lemenkov wrote: > 2007/12/10, Jeffrey Ollie : > > > > I'd like to find someone to take over ejabberd. > > I will take it. Thanks for the quick response. I've released ownership in the package database... Jeff From paul at city-fan.org Mon Dec 10 17:40:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Dec 2007 17:40:27 +0000 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <475D6D8A.80708@linux-kernel.at> References: <475D6D8A.80708@linux-kernel.at> Message-ID: <475D7A0B.4000409@city-fan.org> Oliver Falk wrote: > fyi. > > In file included from /usr/include/asm/sigcontext.h:4, > from /usr/include/bits/sigcontext.h:28, > from /usr/include/signal.h:333, > from /usr/include/sys/wait.h:31, > from ../include/conf.h:95, > from pr_fnmatch.c:38: > /usr/include/asm/types.h:6: error: conflicting types for 'mode_t' > /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was > here > make[2]: *** [pr_fnmatch.o] Error 1 > > Is what I see, if I try to rebuild proftpd in f9. > > [oliver at pils proftpd]$ rpm -qf /usr/include/sys/types.h > /usr/include/asm/types.h > glibc-headers-2.7-2 > kernel-headers-2.6.24-0.79.rc4.git5.fc9 > > Funny: > [oliver at pils proftpd]$ grep mode_t /usr/include/asm/types.h > typedef unsigned short umode_t; > > This is a i386 box! The configure script looks for a definition of umode_t via its default set of includes and if it doesn't find it, does this: #define umode_t mode_t This then becomes a problem when the umode_t type is used in the source code after including a header file such as , which *does* pull in a valid definition of umode_t. F9.i386 has recently dropped umode_t from the default include files and this has triggered the problem. I've seen this before on ppc64 when I had a similar problem with gnome-libs. As a workaround, I hacked together the (icky) patch attached this afternoon. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: proftpd-1.3.1-find-umode_t.patch Type: text/x-patch Size: 6785 bytes Desc: not available URL: From dominik at greysector.net Mon Dec 10 18:56:16 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 10 Dec 2007 19:56:16 +0100 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <475D7A0B.4000409@city-fan.org> References: <475D6D8A.80708@linux-kernel.at> <475D7A0B.4000409@city-fan.org> Message-ID: <20071210185615.GA3331@ryvius.greysector.net> On Monday, 10 December 2007 at 18:40, Paul Howarth wrote: [...] > As a workaround, I hacked together the (icky) patch attached this afternoon. > > Paul. [...] > @@ -37144,7 +37296,7 @@ > INSTALL_STRIP="" > else > > - INSTALL_STRIP="-s" > + INSTALL_STRIP="" > fi > > echo "$as_me:$LINENO: checking whether ${CC-cc} accepts -Wno-long-double" >&5 Unrelated? It's better to add INSTALL_STRIP="" to make call 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 smooge at gmail.com Mon Dec 10 19:30:17 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 10 Dec 2007 12:30:17 -0700 Subject: EPEL report week 49 2007 In-Reply-To: <475D2843.5010500@leemhuis.info> References: <475D2843.5010500@leemhuis.info> Message-ID: <80d7e4090712101130k5fcef868y47cde613c60044f7@mail.gmail.com> On Dec 10, 2007 4:51 AM, Thorsten Leemhuis wrote: > > * RHEL 5.1 (and 4.6) for the builders | dgilmore, mmcgrath > > * mmcgrath will take care of updating the buildroots to 5.1 and do the switch; announcement when happened to the list; 4.6. will be prepared, waiting for CentOS 4.6 > CentOS 4.6 should be ready in the coming week or so.. it has been getting a workout from QA people. -- 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 chasd at silveroaks.com Mon Dec 10 21:04:51 2007 From: chasd at silveroaks.com (chasd) Date: Mon, 10 Dec 2007 15:04:51 -0600 Subject: InstantMirror-0.2 Release In-Reply-To: <20071207112734.A748B7344E@hormel.redhat.com> References: <20071207112734.A748B7344E@hormel.redhat.com> Message-ID: <81AA919D-4B80-4A4C-A852-30ED2F2BC0E0@silveroaks.com> > From: "Ed Swierk" > Actually InstantMirror should work just fine in a simple > non-VirtualHost configuration, so perhaps the default Apache > configuration file can leave out the VirtualHost directives and we can > bundle the fancier VirtualHost configuration as an example in the docs > directory. I didn't think a non-VirtualHost config might be more popular, because it is not the way I do things ;) > From: Warren Togami > I personally dislike this idea. It is already fully commented out in > the default InstantMirror.conf. Why don't we: > 1) Keep the contents as-is. > 2) Add a note to other examples the doc directory. > 3) Rename the file to zz-InstantMirror.conf so it never goes first. From my experience and usage, I agree with this. However, we are getting into a territory like ordering in /etc/init.d/ What I did to make the InstantMirror.conf work : 1) Uncomment NameVirtualHost *:80 in /etc/httpd/conf/httpd.conf 2) Create a "Default.conf" in conf.d that contains ServerName your-hostname-here DocumentRoot /var/www/html I named it with an upper case "D" so it loads first. The name leaves something to be desired, but is indicative of containing the config for the default host. 3) Changes to the original InstantMirror.conf #DocumentRoot /var/ftp/pub/linux/fedora DocumentRoot /var/ftp So I didn't get additional directory levels. I added logging ErrorLog logs/mirror-error_log CustomLog logs/mirror-access_log combined >>> If I could make one other suggestion about InstantMirror, it >>> would be >>> to include a sample.repo file in /usr/share/doc/InstantMirror-x/ or >>> throw it into /etc/yum.repos.d/ with enabled=0. >> >> Good idea. > > I'm not sure about this. I might be okay with keeping a > sample.repo in > docs, but not /etc/yum.respo.d/. After I wrote the suggestion for a sample.repo in docs, I couldn't think of a reason not to put one in yum.repos.d. > Also /etc/yum.repos.d/ included in InstantMirror would mean that you > need to install InstantMirror on each of your clients as well. How > much > sense does this make? =) That is a good reason to only provide a sample.repo in docs. > Reportedly Debian has 3 implementations of a reverse proxy mirror, > some > even handle apt metadata in an intelligent way to expire the > repository > contents. Might be worth looking into to get ideas for future > improvement for InstantMirror. Names to save Google time ? Charles Dostale From j.w.r.degoede at hhs.nl Mon Dec 10 22:00:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 10 Dec 2007 23:00:39 +0100 Subject: Need help with ppc64 build error Message-ID: <475DB707.20101@hhs.nl> Hi All, I just tried to build a new version of timidity and I got this build error: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -pthread -L/usr/lib64 -o calcnewt calcnewt.o -lasound -lm -ldl -lpthread -lm -ldl -lpthread -lX11 -lm -ldl -lpthread -lartsc -lpthread -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -lesd -laudiofile -lm -L/usr/lib -lao -L/usr/lib -lFLAC -lm -lncurses -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -ldl -ljack -lpthread -lrt -L/usr/lib -lvorbis -lm -lvorbisenc -L/usr/lib -logg -lspeex -logg ./calcnewt > newton_table.c ./calcnewt: error while loading shared libraries: /usr/lib64/libjack.so.0: R_PPC64_ADDR32 4000110d720 for symbol `' out of range make[2]: *** [newton_table.c] Error 127 make[2]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2/timidity' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.1710 (%build) Does anyone know what this means, I have the feeling the is a SEP (Somebody Elses Problem), but I don't know where to file a bug if any, for the full log see: http://koji.fedoraproject.org/koji/getfile?taskID=286470&name=build.log And the complete koji task is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=286463 Thanks & Regards, Hans From lsof at nodata.co.uk Mon Dec 10 22:47:12 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 10 Dec 2007 23:47:12 +0100 Subject: InstantMirror-0.2 Release In-Reply-To: References: <20071204070618.86E2273167@hormel.redhat.com> <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> Message-ID: <1197326832.15647.8.camel@sb-home> Am Donnerstag, den 06.12.2007, 18:13 -0800 schrieb Ed Swierk: > On 12/4/07, chasd wrote: > > If it was expected that InstantMirror was to be very popular, or > > there was a large number of other packages that would make use of > > directives, it might make sense to modify the default > > apache configuration to be more "virtual host friendly." As it > > stands, I think some prudent suggestions in the provided > > InstantMirror.conf file ( and perhaps renaming it ) is the best plan. > > Actually InstantMirror should work just fine in a simple > non-VirtualHost configuration, That's not very common though, is it? Who has enough ips for that..? From caolanm at redhat.com Mon Dec 10 22:50:52 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 10 Dec 2007 22:50:52 +0000 Subject: Need help with ppc64 build error In-Reply-To: <475DB707.20101@hhs.nl> References: <475DB707.20101@hhs.nl> Message-ID: <1197327052.924.64.camel@Jehannum> On Mon, 2007-12-10 at 23:00 +0100, Hans de Goede wrote: > Hi All, > ./calcnewt: error while loading shared libraries: /usr/lib64/libjack.so.0: > R_PPC64_ADDR32 4000110d720 for symbol `' out of range Does adding -mminimal-toc to your CFLAGS make any difference, though probably not as IIRC that has a specific error. C. From eswierk at arastra.com Tue Dec 11 00:26:01 2007 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 10 Dec 2007 16:26:01 -0800 Subject: InstantMirror-0.2 Release In-Reply-To: <1197326832.15647.8.camel@sb-home> References: <20071204070618.86E2273167@hormel.redhat.com> <23FD0F71-3EAA-4EF0-B17E-5E6F4C1395F3@silveroaks.com> <1197326832.15647.8.camel@sb-home> Message-ID: On 12/10/07, nodata wrote: > That's not very common though, is it? > Who has enough ips for that..? I was thinking users might want to set up an InstantMirror tree in a subdirectory of an existing web host, but it sounds like that's not a likely configuration. I use a VirtualHost myself, so I'm happy to consider it the default :-) --Ed From ngompa13 at gmail.com Tue Dec 11 03:55:14 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 10 Dec 2007 21:55:14 -0600 Subject: Package alien In-Reply-To: <7f692fec0712081824ub407240o54d8b3804aac277f@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> <7f692fec0712081824ub407240o54d8b3804aac277f@mail.gmail.com> Message-ID: <8278b1b0712101955r25c5f080v3176169c8d2aadc7@mail.gmail.com> Not all people accidentally using dpkg would be stupid. Perhaps they are used to a Debian based system, yadda yadda yadda... Anyways, upstream could theoretically be used if a patch was submitted to detect platforms to enable and disable functionality. For instance, on Debian, a dpkg binary would function as the full package manager, with apt as repo manager. On a Fedora machine, dpkg's platform checking would figure out it is fedora and automatically initialize alien functionality, or just fail with an error stating that if you want to use debian packages on this platform, use alien to convert it to the native package format of the platform. On Dec 8, 2007 8:24 PM, Yaakov Nemoy wrote: > On Dec 7, 2007 11:40 AM, Jeff Spaleta wrote: > > On Dec 7, 2007 4:24 AM, Patrice Dumas wrote: > > > The target for dpkg are not casual users, and casual users won't use > it > > > anyway. > > > > And when someone wants to put a dpkg-enabled tool in the distro that > > does target casual users? It's a slippery slope. We avoid > > being on that slope by not having a fully functional dpkg on the system > at all. > > Do you want to hassle most people that have a legitimate use just to > protect everyone else? My level of tolerance is a one time warning, > and then for all security features to *get out of the way*. > > Granted, we probably don't need apt-dpkg in Fedora, and synaptic is a > very bad idea in my book, (although I'm sure someone else would > disagree,) but it seems crazy to have to bend over backwards because > there are stupid people around. > > -Yaakov > > -- > 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 fedora-gmane.00005 at genesis-x.nildram.co.uk Tue Dec 11 04:53:37 2007 From: fedora-gmane.00005 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Tue, 11 Dec 2007 04:53:37 +0000 Subject: Fedora 8 i586 Anaconda issue resolved Message-ID: For all VIA or K6 owners waiting to install Fedora 8, Merry Christmas: http://pilot.genomicscenter.nl/revisor/f8-i386-respin/iso/ Tested and verified. Uses Anaconda backport from Rawhide. Thanks to Jeroen van Meeuwen and Bob Jensen at Fedora Unity. -- Regards, Keith G. Robertson-Turner From oliver at linux-kernel.at Tue Dec 11 08:17:06 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 11 Dec 2007 09:17:06 +0100 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <475D7A0B.4000409@city-fan.org> References: <475D6D8A.80708@linux-kernel.at> <475D7A0B.4000409@city-fan.org> Message-ID: <475E4782.1070409@linux-kernel.at> Matthias (owner of proftpd AFAIK)! Did you see this mail/patch? Thx, Oliver On 12/10/2007 06:40 PM, Paul Howarth wrote: > Oliver Falk wrote: >> fyi. >> >> In file included from /usr/include/asm/sigcontext.h:4, >> from /usr/include/bits/sigcontext.h:28, >> from /usr/include/signal.h:333, >> from /usr/include/sys/wait.h:31, >> from ../include/conf.h:95, >> from pr_fnmatch.c:38: >> /usr/include/asm/types.h:6: error: conflicting types for 'mode_t' >> /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was >> here >> make[2]: *** [pr_fnmatch.o] Error 1 >> >> Is what I see, if I try to rebuild proftpd in f9. >> >> [oliver at pils proftpd]$ rpm -qf /usr/include/sys/types.h >> /usr/include/asm/types.h >> glibc-headers-2.7-2 >> kernel-headers-2.6.24-0.79.rc4.git5.fc9 >> >> Funny: >> [oliver at pils proftpd]$ grep mode_t /usr/include/asm/types.h >> typedef unsigned short umode_t; >> >> This is a i386 box! > > The configure script looks for a definition of umode_t via its default > set of includes and if it doesn't find it, does this: > > #define umode_t mode_t > > This then becomes a problem when the umode_t type is used in the source > code after including a header file such as , which *does* pull > in a valid definition of umode_t. > > F9.i386 has recently dropped umode_t from the default include files and > this has triggered the problem. I've seen this before on ppc64 when I > had a similar problem with gnome-libs. > > As a workaround, I hacked together the (icky) patch attached this > afternoon. > > Paul. > -- Oliver Falk UNIX/Linux Systems Engineer Mail: oliver at linux-kernel.at Phone: +43 (664) 838 59 25 From j.w.r.degoede at hhs.nl Tue Dec 11 08:25:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Dec 2007 09:25:29 +0100 Subject: Need help with ppc64 build error In-Reply-To: <1197327052.924.64.camel@Jehannum> References: <475DB707.20101@hhs.nl> <1197327052.924.64.camel@Jehannum> Message-ID: <475E4979.9000107@hhs.nl> Caolan McNamara wrote: > On Mon, 2007-12-10 at 23:00 +0100, Hans de Goede wrote: >> Hi All, >> ./calcnewt: error while loading shared libraries: /usr/lib64/libjack.so.0: >> R_PPC64_ADDR32 4000110d720 for symbol `' out of range > > Does adding -mminimal-toc to your CFLAGS make any difference, though > probably not as IIRC that has a specific error. > You mean removing it perhaps? As its already there as one can clearly see in the log: http://koji.fedoraproject.org/koji/getfile?taskID=286470&name=build.log Regards, Hans From rc040203 at freenet.de Tue Dec 11 08:35:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Dec 2007 09:35:14 +0100 Subject: Need help with ppc64 build error In-Reply-To: <475DB707.20101@hhs.nl> References: <475DB707.20101@hhs.nl> Message-ID: <1197362114.19022.22.camel@beck.corsepiu.local> On Mon, 2007-12-10 at 23:00 +0100, Hans de Goede wrote: > Hi All, > > I just tried to build a new version of timidity and I got this build error: > gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mminimal-toc -pthread -L/usr/lib64 -o calcnewt > calcnewt.o -lasound -lm -ldl -lpthread -lm -ldl -lpthread -lX11 -lm > -ldl -lpthread -lartsc -lpthread -lgmodule-2.0 -ldl -lgthread-2.0 -lrt > -lglib-2.0 -lesd -laudiofile -lm -L/usr/lib -lao -L/usr/lib -lFLAC -lm > -lncurses -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 > -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl > -lglib-2.0 -ldl -ljack -lpthread -lrt -L/usr/lib -lvorbis -lm > -lvorbisenc -L/usr/lib -logg -lspeex -logg > ./calcnewt > newton_table.c > ./calcnewt: error while loading shared libraries: /usr/lib64/libjack.so.0: > R_PPC64_ADDR32 4000110d720 for symbol `' out of range > make[2]: *** [newton_table.c] Error 127 > make[2]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2/timidity' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2' > make: *** [all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.1710 (%build) I would guess on a multilib screw up. At least the library paths in the compiler call above look suspicious to me. They mix up -L/usr/lib64 and -L/usr/lib. Depending on where these library paths originate from (*.pc's, configure scripts?) the origin could be anywhere (even outside of your package). Ralf From j.w.r.degoede at hhs.nl Tue Dec 11 08:40:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Dec 2007 09:40:32 +0100 Subject: Need help with ppc64 build error In-Reply-To: <1197362114.19022.22.camel@beck.corsepiu.local> References: <475DB707.20101@hhs.nl> <1197362114.19022.22.camel@beck.corsepiu.local> Message-ID: <475E4D00.9010802@hhs.nl> Ralf Corsepius wrote: > On Mon, 2007-12-10 at 23:00 +0100, Hans de Goede wrote: >> Hi All, >> >> I just tried to build a new version of timidity and I got this build error: >> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector >> --param=ssp-buffer-size=4 -m64 -mminimal-toc -pthread -L/usr/lib64 -o calcnewt >> calcnewt.o -lasound -lm -ldl -lpthread -lm -ldl -lpthread -lX11 -lm >> -ldl -lpthread -lartsc -lpthread -lgmodule-2.0 -ldl -lgthread-2.0 -lrt >> -lglib-2.0 -lesd -laudiofile -lm -L/usr/lib -lao -L/usr/lib -lFLAC -lm >> -lncurses -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 >> -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl >> -lglib-2.0 -ldl -ljack -lpthread -lrt -L/usr/lib -lvorbis -lm >> -lvorbisenc -L/usr/lib -logg -lspeex -logg >> ./calcnewt > newton_table.c >> ./calcnewt: error while loading shared libraries: /usr/lib64/libjack.so.0: >> R_PPC64_ADDR32 4000110d720 for symbol `' out of range >> make[2]: *** [newton_table.c] Error 127 >> make[2]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2/timidity' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/builddir/build/BUILD/TiMidity++-2.13.2' >> make: *** [all] Error 2 >> error: Bad exit status from /var/tmp/rpm-tmp.1710 (%build) > > I would guess on a multilib screw up. > > At least the library paths in the compiler call above look suspicious to > me. They mix up -L/usr/lib64 and -L/usr/lib. > > Depending on where these library paths originate from (*.pc's, configure > scripts?) the origin could be anywhere (even outside of your package). > I depend the -L/usr/lib getting thrown in is ugly, but AFAIK ld will simply ignore any non 64 bit libs when linking a 64 bit binary, so this should not be a problem, atleast it is not on x86_64. Regards, Hans From pertusus at free.fr Tue Dec 11 09:14:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 11 Dec 2007 10:14:19 +0100 Subject: Package alien In-Reply-To: <8278b1b0712101955r25c5f080v3176169c8d2aadc7@mail.gmail.com> References: <4756AC21.30104@redhat.com> <4756CFA1.8050605@redhat.com> <7f692fec0712051058u18c6fd0cw8952621946238a53@mail.gmail.com> <8278b1b0712051651q551c8b6dx3701233c97aaea53@mail.gmail.com> <604aa7910712061350n59fc6cdh70bda7b3b7ad171f@mail.gmail.com> <20071207132427.GA2604@free.fr> <604aa7910712070840n57fe9f1ak612be6c98b879455@mail.gmail.com> <7f692fec0712081824ub407240o54d8b3804aac277f@mail.gmail.com> <8278b1b0712101955r25c5f080v3176169c8d2aadc7@mail.gmail.com> Message-ID: <20071211091419.GA3858@free.fr> On Mon, Dec 10, 2007 at 09:55:14PM -0600, King InuYasha wrote: > Not all people accidentally using dpkg would be stupid. Perhaps they are > used to a Debian based system, yadda yadda yadda... Being used to something isn't an excuse for doing something wrong that could have been avoided by understanding what one is doing (and nobody is stupid in my opinion, but some actions are stupid). > Anyways, upstream could > theoretically be used if a patch was submitted to detect platforms to enable > and disable functionality. That could be interesting, indeed. Though detecting the platform is certainly not the way to go. What would be relevant would be to detect a rpm database in the installation root. But then you should want to modify autoconf/automake such that a generated makefile doesn't install in rpm managed directories when a rpm database is detected (or we are in fedora). > For instance, on Debian, a dpkg binary would > function as the full package manager, with apt as repo manager. On a Fedora apt is completely different from dpkg (and the apt in fedora knows .rpm, but not .deb). In fedora the repo manager may be smart, yum, apt and certainly other that I don't know (not to mention that urpmi would certainly work fine). > machine, dpkg's platform checking would figure out it is fedora and > automatically initialize alien functionality, or just fail with an error > stating that if you want to use debian packages on this platform, use alien > to convert it to the native package format of the platform. My guess is that alien doesn't need dpkg at all, but needs dpkg-deb (which even seems to be a different binary). Still not a reason to cripple dpkg. -- Pat From kanarip at kanarip.com Tue Dec 11 10:32:36 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 11 Dec 2007 11:32:36 +0100 Subject: Fedora 8 i586 Anaconda issue resolved In-Reply-To: References: Message-ID: <475E6744.6050309@kanarip.com> Keith G. Robertson-Turner wrote: > For all VIA or K6 owners waiting to install Fedora 8, Merry Christmas: > > http://pilot.genomicscenter.nl/revisor/f8-i386-respin/iso/ > > Tested and verified. Uses Anaconda backport from Rawhide. > > Thanks to Jeroen van Meeuwen and Bob Jensen at Fedora Unity. > Please note the ISOs are not our official release and since I need to do another respin, they will move to http://pilot.genomicscenter.nl/revisor/20071209/ Kind regards, Jeroen van Meeuwen -kanarip From buildsys at redhat.com Tue Dec 11 12:58:48 2007 From: buildsys at redhat.com (Build System) Date: Tue, 11 Dec 2007 07:58:48 -0500 Subject: rawhide report: 20071211 changes Message-ID: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> New package R-BufferedMatrixMethods Microarray Data related methods that utlize BufferedMatrix New package firefox-32 Alternate Launcher for 32bit Firefox New package isomd5sum Utilities for working with md5sum implanted in ISO images New package libepc Easy Publish and Consume library New package libfprint Tool kit for fingerprint scanner New package mfiler2 Two pane file manager under UNIX console New package phpwapmail WAP-based e-mail client Updated Packages: anaconda-11.4.0.8-1 ------------------- * Mon Dec 10 2007 Chris Lumens - 11.4.0.8-1 - Include lshal for debugging (katzj) - Remove isomd5sum in favor of libcheckisomd5. (notting, katzj) - makeDevInode no longer exists. (clumens) - Fix text mode to be able to autopartition (#409301) (katzj) - Fix method-related tracebacks (katzj, clumens) - Load ext2 module to allow installing to ext2 for livecd (#408251) (katzj) - Catch errors from yum, exit on them. (notting) - Switch to full dejavu-fonts, to match the installed OS default. (notting) bluez-libs-3.23-1.fc9 --------------------- * Mon Dec 10 2007 - Bastien Nocera - 3.23-1 - Update to 3.23 bouncycastle-1.38-1.fc9 ----------------------- * Thu Nov 29 2007 Thomas Fitzsimmons - 1.38-1 - Import Bouncy Castle 1.38. - Require junit4 for build. - Require java-1.7.0-icedtea-devel for build. - Wrap lines at 80 columns. - Inline rebuild-security-providers in post and postun sections. - Related: rhbz#260161 brasero-0.6.1-4.fc9 ------------------- * Mon Dec 10 2007 Denis Leroy - 0.6.1-4 - Changed totem-devel req to totem-pl-parser-devel * Sun Dec 09 2007 Denis Leroy - 0.6.1-3 - Rebuild with new libbeagle cups-1:1.3.4-5.fc9 ------------------ * Mon Dec 10 2007 Tim Waugh 1:1.3.4-5 - Rebuilt with higher release number. * Tue Dec 04 2007 Warren Togami 1:1.3.4-3 - rebuild * Fri Nov 30 2007 Tim Waugh - CVE-2007-4045 patch is not necessarily because cupsd_client_t objects are not moved in array operations, only pointers to them. drupal-5.5-1.fc9 ---------------- * Mon Dec 10 2007 Jon Ciesla - 5.5-1 - Upgrade to 5.5, critical fixes. evolution-2.21.3-4.fc9 ---------------------- * Mon Dec 10 2007 Matthew Barnes - 2.21.3-4.fc9 - Split junk filtering plugins into evolution-bogofilter and evolution-spamassassin subpackages, each of which requires the necessary backend packages. (RH bug #377381) * Wed Dec 05 2007 Matthew Barnes - 2.21.3-3.fc9 - Bump eds_version to 2.21.3 and gtkhtml_version to 3.17.3. * Tue Dec 04 2007 Matthias Clasen - 2.21.3-2 - Rebuild against new openssl freenx-0.7.1-3.fc9 ------------------ * Mon Dec 10 2007 Jon Ciesla - 0.7.1-3 - Fix syntax error in logrotate file, BZ 418221. gdb-6.7.1-6.fc9 --------------- * Mon Dec 10 2007 Jan Kratochvil - 6.7.1-6 - Testsuite fixes for more stable/comparable results. * Sat Nov 24 2007 Jan Kratochvil - 6.7.1-5 - Reduce the excessive gcc-* packages dependencies outside of mock/koji. * Fri Nov 16 2007 Jan Kratochvil - 6.7.1-4 - Fix `errno' resolving across separate debuginfo files. - Fix segfault on no file loaded, `set debug solib 1', `info sharedlibrary'. - Extend the testsuite run for all the languages if %{dist} is defined. - Support gdb.fortran/ tests by substituting the g77 compiler by gfortran. gnuplot-4.2.2-7.fc9 ------------------- * Mon Dec 10 2007 Ivana Varekova - 4.2.2-7 - add wxGTK-devel dependency (#405411) gxine-0.5.11-14.fc9 ------------------- * Mon Dec 10 2007 Martin Sourada - 0.5.11-14 - xulrunner not available on F-8 (use js) - js and lirc not available on EL-5 (use firefox-js and drop lirc support) * Mon Dec 10 2007 Martin Sourada - 0.5.11-13 - spec cleanup - prepare for EPEL jd-1.9.8-0.3.beta071210.fc9 --------------------------- * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls * Thu Nov 22 2007 Mamoru Tasaka - 1.9.7-1 - 1.9.7 kdeartwork-3.97.0-1.fc9 ----------------------- * Mon Dec 10 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 - touchup for cvs import - rework subpkg names a bit * Fri Nov 30 2007 Sebastian Vahl 3.96.2-1 - kde-3.96.2 * Fri Nov 23 2007 Sebastian Vahl 3.96.1-1 - kde-3.96.1 kdemultimedia-6:3.97.0-1.fc9 ---------------------------- * Mon Dec 10 2007 Than Ngo 3.97.0-1 - 3.97.0 * Fri Nov 30 2007 Sebastian Vahl 6:3.96.2-1 - kde-3.96.2 * Sat Nov 24 2007 Sebastian Vahl 6:3.96.1-1 - kde-3.96.1 kernel-2.6.24-0.81.rc4.git7.fc9 ------------------------------- * Mon Dec 10 2007 Dave Jones - 2.6.24-rc4-git7 * Sat Dec 08 2007 Dave Jones - 2.6.24-rc4-git6 * Fri Dec 07 2007 Peter Jones - Turn on CONFIG_FB_IMAC . kerry-0.2.1-6.fc9 ----------------- * Mon Dec 10 2007 Sebastian Vahl 0.2.1-6 - prepare configure script for libbeagle-1.0 * Sun Dec 09 2007 Sebastian Vahl 0.2.1-5 - switch BR to kdebase3-devel - omit unneeded BRs - rebuild for new libbeagle libgcrypt-1.4.0-1 ----------------- * Mon Dec 10 2007 Nalin Dahyabhai - 1.4.0-1 - update to 1.4.0 libselinux-2.0.46-1.fc9 ----------------------- * Fri Nov 30 2007 Dan Walsh - 2.0.46-1 - Upgrade to upstream * matchpathcon(8) man page update from Dan Walsh. libsepol-2.0.16-1.fc9 --------------------- * Mon Dec 10 2007 Dan Walsh 2.0.16-1 - Upgrade to latest from NSA * print module magic number in hex on mismatch, from Todd Miller. libtranslate-0.99-12.fc9 ------------------------ * Mon Dec 10 2007 Dmitry Butskoy - 0.99-12 - more updates for services.xml (fix 1800translate, papiamentu, drop tsunami and worldlingo as not useful now). nspluginwrapper-0.9.91.5-15.fc9 ------------------------------- * Mon Dec 10 2007 Martin Stransky 0.9.91.5-15 - updated configure script - gecko selection pam_ssh-1.92-6.fc9 ------------------ * Mon Dec 10 2007 Patrice Dumas 1.92-6 - remove selinux policy module support, since it is in main selinux - Conflicts: selinux-policy-targeted < 3.0.8-55 since it seems to be the first package with included selinux policy * Mon Dec 10 2007 Patrice Dumas 1.92-5 - correct a typo in selinux %postun script * Thu Nov 15 2007 Martin Ebourne - 1.92-3 - Added SELinux policy module perl-Crypt-OpenSSL-PKCS10-0.06-7.fc9 ------------------------------------ * Thu Dec 06 2007 Wes Hardaker - 0.06-7 - Bump to force rebuild with new openssl lib version perl-Test-AutoBuild-1.2.1-2.fc9 ------------------------------- * Mon Dec 10 2007 Daniel P. Berrange - 1.2.1-2.fc9 - Disable subversion dependancy * Sat Dec 08 2007 Daniel P. Berrange - 1.2.1-1.fc9 - Updated to new release * Thu Sep 14 2006 Daniel Berrange - 1.2.0-3 - Added /Test directory to list of owned dirs php-pear-Net-FTP-1.3.4-1.fc9 ---------------------------- policycoreutils-2.0.33-1.fc9 ---------------------------- * Mon Dec 10 2007 Dan Walsh 2.0.33-1 - Upgrade from NSA * Drop verbose output on fixfiles -C from Dan Walsh. * Fix argument handling in fixfiles from Dan Walsh. * Enhance boolean support in semanage, including using the .xml description when available, from Dan Walsh. - Fix handling of final screen in polgengui portaudio-19-4.fc9 ------------------ * Mon Dec 10 2007 Matthias Saou 19-4 - Include portaudiocpp library and headers (#413681). powertop-1.9-1.fc9 ------------------ * Mon Dec 10 2007 Josh Boyer 1.9-1 - Update to latest release psmisc-22.6-2.fc9 ----------------- * Mon Dec 10 2007 Tomas Smetana 22.6-2 - fix #417801 - exclude peekfd on secondary architectures pungi-1.2.4-1.fc9 ----------------- * Mon Dec 10 2007 Jesse Keating 1.2.4-1 - Remove extra files from tarball * Mon Dec 10 2007 Jesse Keating 1.2.3-1 - Use a repoview cache. - Use a createrepo cache. - Change path to isomd5sum - Add egg file to spec pykickstart-1.23-1.fc9 ---------------------- * Mon Dec 10 2007 Chris Lumens - 1.23-1 - Take Makefile improvements from anaconda. - Fix a traceback on F9 zerombr command (#395431). - Update to handle new Python eggs packaging. rhpxl-0.49-2.fc9 ---------------- * Fri Nov 30 2007 Adam Jackson 0.49-2 - rhpxl-0.49-pseries-hatred.patch: Use the same pseries detection everywhere. * Thu Sep 06 2007 Adam Jackson 0.49-1 - rhpxl 0.49. Fixes domainful PPC machines, and avoids probing for serial mice since they make USB devices go boom. - Fix License. - Update URL to point to the new home. * Fri Aug 24 2007 Adam Jackson - 0.47-3 - Rebuild for PPC toolchain bug sdljava-0.9.1-7.fc9 ------------------- * Sun Dec 09 2007 Hans de Goede 0.9.1-7 - And the dejavu-fonts fontfile names changed back again (what fun) - The gcj bug causing us to not compile has been fixed, use gcj again and drop ExclusiveArch - There is no reason for us to run ldconfig! - Sigh we must now define __arch__ ourself as the newer swig doesn't selinux-policy-3.2.3-1.fc9 -------------------------- * Tue Dec 11 2007 Dan Walsh 3.2.3-1 - Add polkit policy - Symplify userdom context, remove automatic per_role changes subversion-1.4.4-11 ------------------- * Mon Dec 10 2007 Warren Togami 1.4.4-11 - temporarily disable test suite * Thu Dec 06 2007 Joe Orton 1.4.4-10 - fix build with swig 1.3.33 (patch by Torsten Landschoff) * Wed Dec 05 2007 Joe Orton 1.4.4-9 - rebuild for OpenLDAP soname bump testdisk-6.8-6.fc9 ------------------ * Mon Dec 10 2007 Christophe Grenier 6.8-6 - Don't disable libewf during compilation texinfo-4.11-4.fc9 ------------------ * Mon Dec 10 2007 Vitezslav Crhonek - 4.11-4 - Don't insert description ("This is...") into the direntry section of some generated files Resolves: #394191 texlive-2007-4.fc9 ------------------ * Mon Dec 10 2007 Jindrich Novy - 2007-4 - update japanese, chinese, korean paths to fonts in vfontmap (#418081, #392221) - create customized cid-x.map for dvipdfmx (#418091) * Tue Dec 04 2007 Jindrich Novy - 2007-3 - try to obsolete tetex correctly * Tue Dec 04 2007 Jindrich Novy - 2007-2 - avoid conflicts with tetex-doc package texlive-texmf-2007-3.fc9 ------------------------ * Mon Dec 10 2007 Jindrich Novy - 2007-3 - readd symlinks to gs maps (#418091) totem-2.21.5-3.fc9 ------------------ * Mon Dec 10 2007 - Bastien Nocera - 2.21.5-3 - Add the mythtv schemas to the mythtv subpackage (#410451) xorg-x11-drv-savage-2.1.3-99.20071210.fc9 ----------------------------------------- * Mon Dec 10 2007 Adam Jackson 2.1.3-1 - Today's git snapshot, for pciaccess goodness. xorg-x11-font-utils-1:7.2-3.fc9 ------------------------------- * Mon Dec 10 2007 Adam Jackson 1:7.2-3 - Move bdftruncate (and its perl dependency) to a subpackage. - %doc for the non-empty READMEs and non-stub COPYINGs. xorg-x11-server-1.4.99.1-0.13.fc9 --------------------------------- * Mon Dec 10 2007 Adam Jackson 1.4.99.1-0.13 - xserver-1.4.99-alloca-poison.patch: Fatal error on {DE,}ALLOCATE_LOCAL so we don't build broken drivers. - xserver-1.4.99-ssh-isnt-local.patch: Try harder to disable MIT-SHM for ssh-forwarded connections. * Mon Dec 03 2007 Adam Jackson 1.4.99.1-0.12 - xserver-1.4.99-apm-typedefs.patch: Temporary hack for broken kernels that don't publish the /dev/apm_bios types. * Wed Nov 28 2007 Adam Jackson 1.4.99.1-0.11 - Today's rebase. - BR on git-core instead of git. - Bump mesa-source BR to cope with extended CreatePixmap signature. - xserver-1.4.99-openchrome.patch: Use openchrome not via when running without a config file. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.3.0-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libssl.so.6 ejabberd - 1.1.4-1.fc8.i386 requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.i386 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kdeaddons-extras - 3.5.8-2.fc8.i386 requires libnoatuncontrols.so.1 kdeaddons-extras - 3.5.8-2.fc8.i386 requires libnoatunarts.so kdeaddons-extras - 3.5.8-2.fc8.i386 requires libartsmoduleseffects.so.0 kdeaddons-extras - 3.5.8-2.fc8.i386 requires libnoatun.so.1 kdeaddons-extras - 3.5.8-2.fc8.i386 requires libnoatuntags.so.1 kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 licq - 1.3.4-8.fc9.i386 requires libssl.so.6 licq - 1.3.4-8.fc9.i386 requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libssl.so.6 licq-msn - 1.3.4-8.fc9.i386 requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.i386 requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 tellico - 1.2.14-4.fc9.i386 requires libkcddb.so.1 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.i386 requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.i386 requires libldap-2.3.so.0 anjuta - 1:2.2.0-3.fc8.x86_64 requires liblber-2.3.so.0()(64bit) anjuta - 1:2.2.0-3.fc8.x86_64 requires libldap-2.3.so.0()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.3.0-1.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libssl.so.6()(64bit) ejabberd - 1.1.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.x86_64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kdeaddons-extras - 3.5.8-2.fc8.x86_64 requires libnoatunarts.so()(64bit) kdeaddons-extras - 3.5.8-2.fc8.x86_64 requires libnoatun.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.x86_64 requires libnoatuncontrols.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.x86_64 requires libnoatuntags.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.x86_64 requires libartsmoduleseffects.so.0()(64bit) kdesvn - 0.14.1-1.fc9.i386 requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.i386 requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.x86_64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.x86_64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.x86_64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) tellico - 1.2.14-4.fc9.x86_64 requires libkcddb.so.1()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.2.0-3.fc8.ppc requires liblber-2.3.so.0 anjuta - 1:2.2.0-3.fc8.ppc requires libldap-2.3.so.0 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.3.0-1.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libssl.so.6 ejabberd - 1.1.4-1.fc8.ppc requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.ppc requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kdeaddons-extras - 3.5.8-2.fc8.ppc requires libnoatuncontrols.so.1 kdeaddons-extras - 3.5.8-2.fc8.ppc requires libnoatunarts.so kdeaddons-extras - 3.5.8-2.fc8.ppc requires libartsmoduleseffects.so.0 kdeaddons-extras - 3.5.8-2.fc8.ppc requires libnoatun.so.1 kdeaddons-extras - 3.5.8-2.fc8.ppc requires libnoatuntags.so.1 kdesvn - 0.14.1-1.fc9.ppc requires libldap-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc requires liblber-2.3.so.0 kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc requires libssl.so.6 licq - 1.3.4-8.fc9.ppc requires libcrypto.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libssl.so.6 licq-msn - 1.3.4-8.fc9.ppc requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires libldap-2.3.so.0 rapidsvn - 0.9.4-6.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 tellico - 1.2.14-4.fc9.ppc requires libkcddb.so.1 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libssl.so.6 xsupplicant - 1.2.8-4.fc9.4.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.ppc64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kdeaddons-extras - 3.5.8-2.fc8.ppc64 requires libnoatunarts.so()(64bit) kdeaddons-extras - 3.5.8-2.fc8.ppc64 requires libnoatun.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.ppc64 requires libnoatuncontrols.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.ppc64 requires libnoatuntags.so.1()(64bit) kdeaddons-extras - 3.5.8-2.fc8.ppc64 requires libartsmoduleseffects.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires libldap-2.3.so.0()(64bit) kdesvn - 0.14.1-1.fc9.ppc64 requires liblber-2.3.so.0()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) licq - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libssl.so.6()(64bit) licq-msn - 1.3.4-8.fc9.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 perl-Crypt-OpenSSL-AES - 0.02-1.fc9.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires libldap-2.3.so.0()(64bit) rapidsvn - 0.9.4-6.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) tellico - 1.2.14-4.fc9.ppc64 requires libkcddb.so.1()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libssl.so.6()(64bit) xsupplicant - 1.2.8-4.fc9.4.ppc64 requires libcrypto.so.6()(64bit) From dominik at greysector.net Tue Dec 11 13:09:10 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 11 Dec 2007 14:09:10 +0100 Subject: rawhide report: 20071211 changes In-Reply-To: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> Message-ID: <20071211130909.GA2872@ryvius.greysector.net> On Tuesday, 11 December 2007 at 13:58, Build System wrote: [...] > New package firefox-32 > Alternate Launcher for 32bit Firefox A what? This package has no business existing IMHO. 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 oliver at linux-kernel.at Tue Dec 11 13:10:39 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 11 Dec 2007 14:10:39 +0100 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <475D7A0B.4000409@city-fan.org> References: <475D6D8A.80708@linux-kernel.at> <475D7A0B.4000409@city-fan.org> Message-ID: <475E8C4F.3060108@linux-kernel.at> On 12/10/2007 06:40 PM, Paul Howarth wrote: > Oliver Falk wrote: >> fyi. >> >> In file included from /usr/include/asm/sigcontext.h:4, >> from /usr/include/bits/sigcontext.h:28, >> from /usr/include/signal.h:333, >> from /usr/include/sys/wait.h:31, >> from ../include/conf.h:95, >> from pr_fnmatch.c:38: >> /usr/include/asm/types.h:6: error: conflicting types for 'mode_t' >> /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was >> here >> make[2]: *** [pr_fnmatch.o] Error 1 >> >> Is what I see, if I try to rebuild proftpd in f9. >> >> [oliver at pils proftpd]$ rpm -qf /usr/include/sys/types.h >> /usr/include/asm/types.h >> glibc-headers-2.7-2 >> kernel-headers-2.6.24-0.79.rc4.git5.fc9 >> >> Funny: >> [oliver at pils proftpd]$ grep mode_t /usr/include/asm/types.h >> typedef unsigned short umode_t; >> >> This is a i386 box! > > The configure script looks for a definition of umode_t via its default > set of includes and if it doesn't find it, does this: > > #define umode_t mode_t > > This then becomes a problem when the umode_t type is used in the source > code after including a header file such as , which *does* pull > in a valid definition of umode_t. > > F9.i386 has recently dropped umode_t from the default include files and > this has triggered the problem. I've seen this before on ppc64 when I > had a similar problem with gnome-libs. > > As a workaround, I hacked together the (icky) patch attached this > afternoon. WorksForMe(tm). :-) -of From fedora at camperquake.de Tue Dec 11 13:18:41 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 11 Dec 2007 14:18:41 +0100 Subject: rawhide report: 20071211 changes In-Reply-To: <20071211130909.GA2872@ryvius.greysector.net> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> <20071211130909.GA2872@ryvius.greysector.net> Message-ID: <20071211141841.7f613ad4@dhcp03.addix.net> Hi. On Tue, 11 Dec 2007 14:09:10 +0100, Dominik 'Rathann' Mierzejewski wrote: > A what? This package has no business existing IMHO. I think this package may be one of the most requested features. From jkeating at redhat.com Tue Dec 11 13:19:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Dec 2007 08:19:55 -0500 Subject: rawhide report: 20071211 changes In-Reply-To: <20071211130909.GA2872@ryvius.greysector.net> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> <20071211130909.GA2872@ryvius.greysector.net> Message-ID: <20071211081955.4884ceee@redhat.com> On Tue, 11 Dec 2007 14:09:10 +0100 "Dominik 'Rathann' Mierzejewski" wrote: > > New package firefox-32 > > Alternate Launcher for 32bit Firefox > > A what? This package has no business existing IMHO. Ugh, this package has pingponged in and out of Fedora... I'm not entirely sure why it showed up again. I'm going to check with Warren. It was blocked from f8-final, but that's not part of the inheritance chain, so I think it was supposed to be blocked from dist-f8 and up. -- 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 caillon at redhat.com Tue Dec 11 13:35:04 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 11 Dec 2007 14:35:04 +0100 Subject: rawhide report: 20071211 changes In-Reply-To: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> Message-ID: <475E9208.60504@redhat.com> On 12/11/2007 01:58 PM, Build System wrote: > New package firefox-32 > Alternate Launcher for 32bit Firefox What the? Why is this back? From paul at city-fan.org Tue Dec 11 13:43:31 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Dec 2007 13:43:31 +0000 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <20071210185615.GA3331@ryvius.greysector.net> References: <475D6D8A.80708@linux-kernel.at> <475D7A0B.4000409@city-fan.org> <20071210185615.GA3331@ryvius.greysector.net> Message-ID: <475E9403.2060607@city-fan.org> Dominik 'Rathann' Mierzejewski wrote: > On Monday, 10 December 2007 at 18:40, Paul Howarth wrote: > [...] >> As a workaround, I hacked together the (icky) patch attached this afternoon. >> >> Paul. > > [...] >> @@ -37144,7 +37296,7 @@ >> INSTALL_STRIP="" >> else >> >> - INSTALL_STRIP="-s" >> + INSTALL_STRIP="" >> fi >> >> echo "$as_me:$LINENO: checking whether ${CC-cc} accepts -Wno-long-double" >&5 > > Unrelated? It's better to add INSTALL_STRIP="" to make call instead. This bit's just autoconf output in the patched configure script; untidy but not directly related to the underlying problem. Paul. From jkeating at redhat.com Tue Dec 11 16:12:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Dec 2007 11:12:35 -0500 Subject: Proposal for automation of MIA maintainer detection/processing Message-ID: <20071211111235.176922bb@redhat.com> I've thrown together a proposal for something we discussed in FESCo in the last couple meetings. FESCo agreed to the idea in principle, but obviously wanted a formal proposal to digest. http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal is said proposal. I'd really like to get a lot of eyes on this and thoughts on this before FESCo pulls the trigger to start seeing some of the development on tools done to accomplish 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 dominik at greysector.net Tue Dec 11 16:38:13 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 11 Dec 2007 17:38:13 +0100 Subject: rawhide report: 20071211 changes In-Reply-To: <20071211141841.7f613ad4@dhcp03.addix.net> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> <20071211130909.GA2872@ryvius.greysector.net> <20071211141841.7f613ad4@dhcp03.addix.net> Message-ID: <20071211163813.GB3267@ryvius.greysector.net> On Tuesday, 11 December 2007 at 14:18, Ralf Ertzinger wrote: > Hi. > > On Tue, 11 Dec 2007 14:09:10 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > A what? This package has no business existing IMHO. > > I think this package may be one of the most requested features. For what purpose? We have native java plugin and we have nspluginwrapper for 32bit binary flash plugin. I don't see any reason for 32bit firefox anymore. 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 paul at city-fan.org Tue Dec 11 16:51:36 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Dec 2007 16:51:36 +0000 Subject: kernel- or glibc-headers in f9 broken? In-Reply-To: <475E9403.2060607@city-fan.org> References: <475D6D8A.80708@linux-kernel.at> <475D7A0B.4000409@city-fan.org> <20071210185615.GA3331@ryvius.greysector.net> <475E9403.2060607@city-fan.org> Message-ID: <475EC018.20700@city-fan.org> Paul Howarth wrote: > Dominik 'Rathann' Mierzejewski wrote: >> On Monday, 10 December 2007 at 18:40, Paul Howarth wrote: >> [...] >>> As a workaround, I hacked together the (icky) patch attached this >>> afternoon. >>> >>> Paul. >> >> [...] >>> @@ -37144,7 +37296,7 @@ >>> INSTALL_STRIP="" >>> else >>> >>> - INSTALL_STRIP="-s" >>> + INSTALL_STRIP="" >>> fi >>> >>> echo "$as_me:$LINENO: checking whether ${CC-cc} accepts >>> -Wno-long-double" >&5 >> >> Unrelated? It's better to add INSTALL_STRIP="" to make call instead. > > This bit's just autoconf output in the patched configure script; untidy > but not directly related to the underlying problem. Sorry, forget what I just said. You're right, this bit's a hangover from a sed run earlier in my %prep, I'd be better off using INSTALL_STRIP="" as you say. Good spot. Cheers, Paul. From pertusus at free.fr Tue Dec 11 16:52:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 11 Dec 2007 17:52:19 +0100 Subject: Proposal for automation of MIA maintainer detection/processing In-Reply-To: <20071211111235.176922bb@redhat.com> References: <20071211111235.176922bb@redhat.com> Message-ID: <20071211165219.GC2532@free.fr> On Tue, Dec 11, 2007 at 11:12:35AM -0500, Jesse Keating wrote: > I've thrown together a proposal for something we discussed in FESCo > in the last couple meetings. FESCo agreed to the idea in principle, > but obviously wanted a formal proposal to digest. > > http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal > > is said proposal. I'd really like to get a lot of eyes on this and > thoughts on this before FESCo pulls the trigger to start seeing some of > the development on tools done to accomplish this. This has already been discussed a long time ago, and a difficulty was that for every kind of issue that could trigger MIA, there can be a reason why the packager hasn't acted. In the wiki the end of the Detection is unclear to me: Upon subsequent runs of the script if a maintainer triggers as MIA a db lookup will be done to determine if the maintainer has already been contacted, and has been given the allowed allotment of time to respond. If the allotment has been consumed without response, the script will kick in to processing mode. The wording of the beginning of this part is unclear to me, and even more unclear is whether a human action is needed or not to declare somebody MIA. My personal point of view is that the final procedure, that is a reporter declares on devel list that another packager is MIA and FESCo accepts seems better to me. Having automated QA bugs done to detect such MIA maintainer and track all the packages at once seems good to me, but as a data gathering process, and maybe to avoid for a real person to have to go through the first steps of the current MIA policy, but it seems to me that it is not right if a maintainter may be considered MIA only by automatic means. -- Pat From jkeating at redhat.com Tue Dec 11 17:00:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Dec 2007 12:00:54 -0500 Subject: Proposal for automation of MIA maintainer detection/processing In-Reply-To: <20071211165219.GC2532@free.fr> References: <20071211111235.176922bb@redhat.com> <20071211165219.GC2532@free.fr> Message-ID: <20071211120054.3c6ca26d@redhat.com> On Tue, 11 Dec 2007 17:52:19 +0100 Patrice Dumas wrote: > This has already been discussed a long time ago, and a difficulty was > that for every kind of issue that could trigger MIA, there can be a > reason why the packager hasn't acted. A simple comment in the bug stating that they've received the report, don't have time to work on it, somebody else please fix it would work perfectly. The maintainer or co-maintainer responded, there is a clear expectation set about the work needed to be done, and the detection would not trigger on that particular bug. > > In the wiki the end of the Detection is unclear to me: > > Upon subsequent runs of the script if a maintainer triggers as MIA > a db lookup will be done to determine if the maintainer has already > been contacted, and has been given the allowed allotment of time to > respond. If the allotment has been consumed without response, the > script will kick in to processing mode. > > The wording of the beginning of this part is unclear to me, and even > more unclear is whether a human action is needed or not to declare > somebody MIA. My personal point of view is that the final procedure, > that is a reporter declares on devel list that another packager is MIA > and FESCo accepts seems better to me. The "human" action to avoid being declared MIA is to respond to the bug. If a bug is responded to, the maintainer would not be considered MIA. > > Having automated QA bugs done to detect such MIA maintainer and track > all the packages at once seems good to me, but as a data gathering > process, and maybe to avoid for a real person to have to go through > the first steps of the current MIA policy, but it seems to me that > it is not right if a maintainter may be considered MIA only by > automatic means. Part of the automated process is to post to the mailing list, as well as directly to the maintainer, and to all the co-maintainers for all said maintainer's packages. Responding to the bugs in question would end the MIA declaration process, just as it would should a human send those messages. -- 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 caillon at redhat.com Tue Dec 11 16:58:01 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 11 Dec 2007 17:58:01 +0100 Subject: rawhide report: 20071211 changes In-Reply-To: <20071211141841.7f613ad4@dhcp03.addix.net> References: <200712111258.lBBCwmwf001719@porkchop.devel.redhat.com> <20071211130909.GA2872@ryvius.greysector.net> <20071211141841.7f613ad4@dhcp03.addix.net> Message-ID: <475EC199.6030602@redhat.com> On 12/11/2007 02:18 PM, Ralf Ertzinger wrote: > Hi. > > On Tue, 11 Dec 2007 14:09:10 +0100, Dominik 'Rathann' Mierzejewski wrote: > >> A what? This package has no business existing IMHO. > > I think this package may be one of the most requested features. "Do foo so I can do bar" means that people want bar, not foo. Just because people said "I want this package so I can use plugins" doesn't mean they want a firefox-32 package. nspluginwrapper solves their real needs in a better way. If for some reason, you still feel like you need a 32 bit browser, I test my x86-32 builds with `setarch i386 firefox` From fangqq at gmail.com Tue Dec 11 18:39:26 2007 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 11 Dec 2007 13:39:26 -0500 Subject: how to use Source1 to add an additional file Message-ID: <475ED95E.9040506@gmail.com> hi I want to add a separate configuration file (61-wqy-bitmapsong.conf) to package wqy-bitmap-fonts, after reading some examples, I used the following syntax to make this change .... Source0: http://url of the upstream package Source1: 61-wqy-bitmapsong.conf # the additional file .... %setup -q -n %{wqyroot} ... %install ... install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ ... then I copied 61-wqy-bitmapsong.conf to "devel" directory, and "cvs add 61-wqy-bitmapsong.conf". However, it failed when I test the build with "make i386", the error message is File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf Installed (but unpackaged) file(s) found /etc/fonts/conf.d/61-wqy-bitmapsong.conf did I miss anything? where should I put the 61-wqy-bitmapsong.conf when commit to cvs? thank you Qianqian From limb at jcomserv.net Tue Dec 11 18:36:59 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 11 Dec 2007 12:36:59 -0600 (CST) Subject: how to use Source1 to add an additional file Message-ID: <63473.63.85.68.164.1197398219.squirrel@mail.jcomserv.net> > hi > > I want to add a separate configuration file (61-wqy-bitmapsong.conf) > to package wqy-bitmap-fonts, after reading some examples, I used > the following syntax to make this change > > .... > Source0: http://url of the upstream package > Source1: 61-wqy-bitmapsong.conf # the additional file > .... > > %setup -q -n %{wqyroot} > ... > %install > ... > install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ > ... > > then I copied 61-wqy-bitmapsong.conf to "devel" directory, > and "cvs add 61-wqy-bitmapsong.conf". However, it failed when > I test the build with "make i386", the error message is > > File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf > Installed (but unpackaged) file(s) found > /etc/fonts/conf.d/http://kronos/wfc/logon > > did I miss anything? where should I put the 61-wqy-bitmapsong.conf > when commit to cvs? make new-sources FILES="/path/to/main/src/file /path/to/61-wqy-bitmapsong.conf" then cvs commit. > thank you > > Qianqian > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lkundrak at redhat.com Tue Dec 11 18:53:00 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Tue, 11 Dec 2007 19:53:00 +0100 Subject: how to use Source1 to add an additional file In-Reply-To: <63473.63.85.68.164.1197398219.squirrel@mail.jcomserv.net> References: <63473.63.85.68.164.1197398219.squirrel@mail.jcomserv.net> Message-ID: <1197399180.14738.2.camel@localhost.localdomain> On Tue, 2007-12-11 at 12:36 -0600, Jon Ciesla wrote: > > hi > > > > I want to add a separate configuration file (61-wqy-bitmapsong.conf) > > to package wqy-bitmap-fonts, after reading some examples, I used > > the following syntax to make this change > > > > .... > > Source0: http://url of the upstream package > > Source1: 61-wqy-bitmapsong.conf # the additional file > > .... > > > > %setup -q -n %{wqyroot} > > ... > > %install > > ... > > install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ > > ... > > > > then I copied 61-wqy-bitmapsong.conf to "devel" directory, > > and "cvs add 61-wqy-bitmapsong.conf". However, it failed when > > I test the build with "make i386", the error message is > > > > File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf > > Installed (but unpackaged) file(s) found > > /etc/fonts/conf.d/http://kronos/wfc/logon > > > > did I miss anything? where should I put the 61-wqy-bitmapsong.conf > > when commit to cvs? > > make new-sources FILES="/path/to/main/src/file > /path/to/61-wqy-bitmapsong.conf" > > then cvs commit. Alternatively, make srpm, then install the srpm, work on the package in your rpmbuild tree and then cvs-import.sh it. In that case you'll not have to worry about adding/removing files to/from cvs and uploading the sources. But it indeed is an overkill for small changes. -- Lubomir Kundrak (Red Hat Security Response Team) From limb at jcomserv.net Tue Dec 11 18:56:46 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 11 Dec 2007 12:56:46 -0600 (CST) Subject: how to use Source1 to add an additional file Message-ID: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> > > On Tue, 2007-12-11 at 12:36 -0600, Jon Ciesla wrote: >> > hi >> > >> > I want to add a separate configuration file (61-wqy-bitmapsong.conf) >> > to package wqy-bitmap-fonts, after reading some examples, I used >> > the following syntax to make this change >> > >> > .... >> > Source0: http://url of the upstream package >> > Source1: 61-wqy-bitmapsong.conf # the additional file >> > .... >> > >> > %setup -q -n %{wqyroot} >> > ... >> > %install >> > ... >> > install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ >> > ... >> > >> > then I copied 61-wqy-bitmapsong.conf to "devel" directory, >> > and "cvs add 61-wqy-bitmapsong.conf". However, it failed when >> > I test the build with "make i386", the error message is >> > >> > File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf >> > Installed (but unpackaged) file(s) found >> > /etc/fonts/conf.d/http://kronos/wfc/logon >> > >> > did I miss anything? where should I put the 61-wqy-bitmapsong.conf >> > when commit to cvs? >> >> make new-sources FILES="/path/to/main/src/file >> /path/to/61-wqy-bitmapsong.conf" >> >> then cvs commit. > > Alternatively, make srpm, then install the srpm, work on the package in > your rpmbuild tree and then cvs-import.sh it. In that case you'll not > have to worry about adding/removing files to/from cvs and uploading the > sources. But it indeed is an overkill for small changes. I've actually been explicitly told not to do that except for the initial import. Plus, I find that the plain cvs commands are faster, especially with ssh-agent. :) > -- > Lubomir Kundrak (Red Hat Security Response Team) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jam at zoidtechnologies.com Tue Dec 11 19:49:37 2007 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Tue, 11 Dec 2007 14:49:37 -0500 Subject: Proposal for automation of MIA maintainer detection/processing In-Reply-To: <20071211165219.GC2532@free.fr> References: <20071211111235.176922bb@redhat.com> <20071211165219.GC2532@free.fr> Message-ID: <20071211194936.GA23061@zoidtechnologies.com> On Tue, Dec 11, 2007 at 05:52:19PM +0100, Patrice Dumas wrote: [...snipped...] > > Having automated QA bugs done to detect such MIA maintainer and track > all the packages at once seems good to me, but as a data gathering > process, and maybe to avoid for a real person to have to go through > the first steps of the current MIA policy, but it seems to me that > it is not right if a maintainter may be considered MIA only by automatic > means. > +1 to have detection software for MIA developers and a human making the decision. > -- > Pat > regards, J -- http://zoidtechnologies.com/ -- websites that suck less From fangqq at gmail.com Tue Dec 11 19:58:53 2007 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 11 Dec 2007 14:58:53 -0500 Subject: how to use Source1 to add an additional file In-Reply-To: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> References: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> Message-ID: <475EEBFD.5060308@gmail.com> hi Jon thank you for the reply, I did as you suggested: make new-sources FILES "upstreamsource.tar.gz 61-wqy-bitmapsong.conf" cvs commit cvs up make i386 strangely, I am getting the same error as before. I also tried to use "cvs add 61-wqy-bitmapsong.conf", but "make i386" failed in the same way. the cvs of the package is at http://cvs.fedoraproject.org/viewcvs/rpms/wqy-bitmap-fonts/devel/ and the .cvsignore and source files do include the new conf file. do you think there could be other places wrong? thank you Qianqian Jon Ciesla wrote: >> On Tue, 2007-12-11 at 12:36 -0600, Jon Ciesla wrote: >> >>>> hi >>>> >>>> I want to add a separate configuration file (61-wqy-bitmapsong.conf) >>>> to package wqy-bitmap-fonts, after reading some examples, I used >>>> the following syntax to make this change >>>> >>>> .... >>>> Source0: http://url of the upstream package >>>> Source1: 61-wqy-bitmapsong.conf # the additional file >>>> .... >>>> >>>> %setup -q -n %{wqyroot} >>>> ... >>>> %install >>>> ... >>>> install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ >>>> ... >>>> >>>> then I copied 61-wqy-bitmapsong.conf to "devel" directory, >>>> and "cvs add 61-wqy-bitmapsong.conf". However, it failed when >>>> I test the build with "make i386", the error message is >>>> >>>> File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf >>>> Installed (but unpackaged) file(s) found >>>> /etc/fonts/conf.d/http://kronos/wfc/logon >>>> >>>> did I miss anything? where should I put the 61-wqy-bitmapsong.conf >>>> when commit to cvs? >>>> >>> make new-sources FILES="/path/to/main/src/file >>> /path/to/61-wqy-bitmapsong.conf" >>> >>> then cvs commit. >>> >> Alternatively, make srpm, then install the srpm, work on the package in >> your rpmbuild tree and then cvs-import.sh it. In that case you'll not >> have to worry about adding/removing files to/from cvs and uploading the >> sources. But it indeed is an overkill for small changes. >> > > I've actually been explicitly told not to do that except for the initial > import. Plus, I find that the plain cvs commands are faster, especially > with ssh-agent. :) > > >> -- >> Lubomir Kundrak (Red Hat Security Response Team) >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > > From nicolas.mailhot at laposte.net Tue Dec 11 20:07:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 11 Dec 2007 21:07:12 +0100 Subject: how to use Source1 to add an additional file In-Reply-To: <475EEBFD.5060308@gmail.com> References: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> <475EEBFD.5060308@gmail.com> Message-ID: <1197403632.7565.3.camel@rousalka.dyndns.org> Hi, Don't hesitate to create a srpm you test locally and then use cvs-import.sh. People will tell you direct cvs use is much faster except you're probably already wasted many times that. And it was your personal time not computer time. Some "optimization". Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From limb at jcomserv.net Tue Dec 11 20:01:06 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 11 Dec 2007 14:01:06 -0600 (CST) Subject: how to use Source1 to add an additional file Message-ID: <26664.63.85.68.164.1197403266.squirrel@mail.jcomserv.net> > hi Jon > > thank you for the reply, I did as you suggested: > > make new-sources FILES "upstreamsource.tar.gz 61-wqy-bitmapsong.conf" > cvs commit > cvs up > make i386 > > strangely, I am getting the same error as before. > I also tried to use "cvs add 61-wqy-bitmapsong.conf", but "make i386" > failed in the same way. > > the cvs of the package is at > http://cvs.fedoraproject.org/viewcvs/rpms/wqy-bitmap-fonts/devel/ > and the .cvsignore and source files do include the new conf file. > > do you think there could be other places wrong? > thank you You have to bump the revision and re-run "make tag". > Qianqian > > > Jon Ciesla wrote: >>> On Tue, 2007-12-11 at 12:36 -0600, Jon Ciesla wrote: >>> >>>>> hi >>>>> >>>>> I want to add a separate configuration file (61-wqy-bitmapsong.conf) >>>>> to package wqy-bitmap-fonts, after reading some examples, I used >>>>> the following syntax to make this change >>>>> >>>>> .... >>>>> Source0: http://url of the upstream package >>>>> Source1: 61-wqy-bitmapsong.conf # the additional file >>>>> .... >>>>> >>>>> %setup -q -n %{wqyroot} >>>>> ... >>>>> %install >>>>> ... >>>>> install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ >>>>> ... >>>>> >>>>> then I copied 61-wqy-bitmapsong.conf to "devel" directory, >>>>> and "cvs add 61-wqy-bitmapsong.conf". However, it failed when >>>>> I test the build with "make i386", the error message is >>>>> >>>>> File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf >>>>> Installed (but unpackaged) file(s) found >>>>> /etc/fonts/conf.d/http://kronos/wfc/logon >>>>> >>>>> did I miss anything? where should I put the 61-wqy-bitmapsong.conf >>>>> when commit to cvs? >>>>> >>>> make new-sources FILES="/path/to/main/src/file >>>> /path/to/61-wqy-bitmapsong.conf" >>>> >>>> then cvs commit. >>>> >>> Alternatively, make srpm, then install the srpm, work on the package in >>> your rpmbuild tree and then cvs-import.sh it. In that case you'll not >>> have to worry about adding/removing files to/from cvs and uploading the >>> sources. But it indeed is an overkill for small changes. >>> >> >> I've actually been explicitly told not to do that except for the initial >> import. Plus, I find that the plain cvs commands are faster, especially >> with ssh-agent. :) >> >> >>> -- >>> Lubomir Kundrak (Red Hat Security Response Team) >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >>> >> >> >> > -- novus ordo absurdum From mschwendt.tmp0701.nospam at arcor.de Tue Dec 11 20:49:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Dec 2007 21:49:33 +0100 Subject: how to use Source1 to add an additional file In-Reply-To: <475EEBFD.5060308@gmail.com> References: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> <475EEBFD.5060308@gmail.com> Message-ID: <20071211214933.0ce8bd3b.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Dec 2007 14:58:53 -0500, Qianqian Fang wrote: > hi Jon > > thank you for the reply, I did as you suggested: > > make new-sources FILES "upstreamsource.tar.gz 61-wqy-bitmapsong.conf" > cvs commit > cvs up > make i386 > > strangely, I am getting the same error as before. It's not strange. It's expected, because you have yet to give your modified files a new tag with "make tag". Don't forget to increase "Release" appropriately. Your last tag is applied to the old files: cvs co -r wqy-bitmap-fonts-0_9_9-1_fc9 wqy-bitmap-fonts From j.w.r.degoede at hhs.nl Tue Dec 11 20:57:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Dec 2007 21:57:57 +0100 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact Message-ID: <475EF9D5.7080702@hhs.nl> Hi, I just received a bug report with a backtrace generated by glibc attached: https://bugzilla.redhat.com/attachment.cgi?id=284591 Looks like a real bug however the reported desn't know exactly what he did to trigger this, so now I want to convert the backtrace glibc generated into one with filenames and line numbers for the addresses of the xfig stack frames. Can anyone tell me how to do this? Regards, Hans From ville.skytta at iki.fi Tue Dec 11 20:59:48 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 11 Dec 2007 22:59:48 +0200 Subject: how to use Source1 to add an additional file In-Reply-To: <475EEBFD.5060308@gmail.com> References: <20917.63.85.68.164.1197399406.squirrel@mail.jcomserv.net> <475EEBFD.5060308@gmail.com> Message-ID: <200712112259.48920.ville.skytta@iki.fi> On Tuesday 11 December 2007, Qianqian Fang wrote: > hi Jon > > thank you for the reply, I did as you suggested: > > make new-sources FILES "upstreamsource.tar.gz 61-wqy-bitmapsong.conf" Unless this was a copy-pasto, there's a '=' missing, try make new-sources FILES="upstreamsource.tar.gz 61-wqy-bitmapsong.conf" From roland at redhat.com Tue Dec 11 21:08:56 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 11 Dec 2007 13:08:56 -0800 (PST) Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: Hans de Goede's message of Tuesday, 11 December 2007 21:57:57 +0100 <475EF9D5.7080702@hhs.nl> References: <475EF9D5.7080702@hhs.nl> Message-ID: <20071211210856.04A0A26F8D4@magilla.localdomain> > Hi, > > I just received a bug report with a backtrace generated by glibc attached: > https://bugzilla.redhat.com/attachment.cgi?id=284591 > > Looks like a real bug however the reported desn't know exactly what he did to > trigger this, so now I want to convert the backtrace glibc generated into one > with filenames and line numbers for the addresses of the xfig stack frames. > > Can anyone tell me how to do this? Use eu-addr2line -e /usr/bin/xfig. From berrange at redhat.com Tue Dec 11 21:15:56 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 11 Dec 2007 21:15:56 +0000 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <475EF9D5.7080702@hhs.nl> References: <475EF9D5.7080702@hhs.nl> Message-ID: <20071211211555.GA23341@redhat.com> On Tue, Dec 11, 2007 at 09:57:57PM +0100, Hans de Goede wrote: > Hi, > > I just received a bug report with a backtrace generated by glibc attached: > https://bugzilla.redhat.com/attachment.cgi?id=284591 > > Looks like a real bug however the reported desn't know exactly what he did > to trigger this, so now I want to convert the backtrace glibc generated > into one with filenames and line numbers for the addresses of the xfig > stack frames. > > Can anyone tell me how to do this? The following seems to work.... # yum --enablerepo=development-debuginfo install xfig-debuginfo # gdb /usr/bin/xfig-plain (gdb) list *0x4a3909 0x4a3909 is in reset_topruler (/usr/include/bits/stdio2.h:34). 29 30 #ifdef __va_arg_pack 31 __extern_always_inline int 32 __NTH (sprintf (char *__restrict __s, __const char *__restrict __fmt, ...)) 33 { 34 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, 35 __bos (__s), __fmt, __va_arg_pack ()); 36 } 37 #elif !defined __cplusplus 38 # define sprintf(str, ...) \ So the code is a sprintf call from the reset_topruler method. Looking at that method, we can see an likely candidate: (gdb) list reset_topruler 1160 /* Note: For reset_top/sideruler to work properly, the value of skip should be 1161 * such that (skip/ruler_unit) is an integer or (ruler_unit/skip) is an integer. 1162 */ 1163 1164 void reset_topruler(void) 1165 { 1166 register int i,k; 1167 register tick_info* tk; 1168 register Pixmap p = topruler_pm; 1169 char number[6]; (gdb) list + 1170 int X0,len; 1171 int tickmod, tickskip; 1172 1173 /* top ruler, adjustments for digits are kludges based on 6x13 char */ 1174 XFillRectangle(tool_d, p, tr_erase_gc, 0, 0, TOPRULER_WD, TOPRULER_HT); 1175 1176 /* set the number of pixels to skip between labels and precision for float */ 1177 get_skip_prec(); 1178 1179 X0 = BACKX(0); (gdb) list + 1180 X0 -= (X0 % skip); 1181 tickmod = (int) round(ruler_unit/appres.userscale); 1182 if (tickmod == 0) 1183 tickmod = 1; 1184 1185 /* see how big a label is to adjust spacing, if necessary */ 1186 sprintf(number, "%d%s", (X0+(int)((TOPRULER_WD/zoomscale)))/tickmod, cur_fig_units); 1187 len = XTextWidth(roman_font, number, strlen(number)); 1188 while (skipx < (len + 5)/zoomscale) { 1189 skip *= 2; Line 1186 is printing a string into a fixed length buffer with no checking. A clear buffer overflow candidate there if the combo of the ruler size & the figure units are longer than 5 characters :-( Regards, 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 skvidal at fedoraproject.org Tue Dec 11 21:17:36 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Dec 2007 16:17:36 -0500 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <20071211211555.GA23341@redhat.com> References: <475EF9D5.7080702@hhs.nl> <20071211211555.GA23341@redhat.com> Message-ID: <1197407856.31537.83.camel@cutter> On Tue, 2007-12-11 at 21:15 +0000, Daniel P. Berrange wrote: > On Tue, Dec 11, 2007 at 09:57:57PM +0100, Hans de Goede wrote: > > Hi, > > > > I just received a bug report with a backtrace generated by glibc attached: > > https://bugzilla.redhat.com/attachment.cgi?id=284591 > > > > Looks like a real bug however the reported desn't know exactly what he did > > to trigger this, so now I want to convert the backtrace glibc generated > > into one with filenames and line numbers for the addresses of the xfig > > stack frames. > > > > Can anyone tell me how to do this? > > The following seems to work.... > > # yum --enablerepo=development-debuginfo install xfig-debuginfo > if you have yum-utils installed you can run: debuginfo-install xfig just a useless tidbit. -sv From Lam at Lam.pl Tue Dec 11 21:22:00 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 11 Dec 2007 22:22:00 +0100 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <475EF9D5.7080702@hhs.nl> References: <475EF9D5.7080702@hhs.nl> Message-ID: <20071211222200.76c4801c@pensja.lam.pl> Dnia 2007-12-11, o godz. 21:57:57 Hans de Goede napisa?(a): > I want to convert the backtrace glibc generated into > one with filenames and line numbers for the addresses of the xfig stack > frames. > > Can anyone tell me how to do this? I don't know the most appropriate command, but: (gdb) l *0819b164 (an asterisk and the address) shows something like: 0x819b164 is in main (lac.c:37). and then shows the line in context, just like any other "list" invocation. There should be some command showing just that, but no other command that I know of (or remember) can resolve the file and line numbers that quickly. If you know a better way, please share your knowledge :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Dec 11 22:41:42 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 11 Dec 2007 23:41:42 +0100 Subject: KDE-SIG weekly report (50/2007) Message-ID: <200712112341.49079.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 50/2007 Time: 2007-12-11 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-11 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-11?action=AttachFile&do=get&target=fedora-kde-sig-2007-12-11.txt ---------------------------------------------------------------------------------- = Participants = - KevinKofler - RexDieter - SebastianVahl ---------------------------------------------------------------------------------- = Agenda = topics to discuss: gcc 4.3 and KDE 4 [1,2] development progress: the road to kde4 extragear packaging recent bugs: /usr/share/doc/HTML/en/common and kdelibs3 - kdelibs-common package [3] = Summary = o gcc 4.3 and KDE 4: - according to upstream gcc 4.3 could miscompile kde4 and may produce unusable kde4 applications - we have to find out when gcc-4.3 is actuall hitting rawhide - after that is done we have to rebuild all packages to figure out the problems and fill bugs o development progress: the road to kde4: - only kdeadmin is left from the normal packages - kde-l10n will maybe finished by ThanNgo tomorrow - KevinKofler suggested to eventually drop most of kdelibs3-devel which isn't usefull anymore - review for extragear-plasma is still ongoing and will be updated to 3.97.0 by SebastianVahl - it will also obsolete kdeaddons since most of the packages/functions are now in extragear-plasma o extragear packaging: - It would be good to package some modules from extragear which were in the base packages in KDE3: - extragear-base (all of it, or all that works, it's Konqueror plugins) - extragear-graphics: at least kiconedit and kcoloredit - extragear-multimedia: at least kmid and kaudiocreator - pim/ksig - if more than one app is in an extragear module it should be named like the module (e.g. extragear-multimedia) - packaging extragear modules won't get our primary attention. We should send a mail to fedora-devel-list with a list of the now missing apps from the base distribution and seek for maintainers who package them from extragear o /usr/share/doc/HTML/en/common and kdelibs3: - kdelibs3 is now missing some things which are in kdelibs - we will prepare a kdelibs-common package (from kdelibs(4)) which is required by kdelibs3 and kdelibs o Open Discussion: - LiveCD: yelp is pulling in firefox (again) which should be fixed (in yelp or in system-config-date which is requireing yelp) - the current package list of the livecd: http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-18 ---------------------------------------------------------------------------------- = Links = [1] http://sourceforge.net/mailarchive/forum.php?thread_name=200712101318.57667.kevin.kofler%40chello.at&forum_name=kde-redhat-devel [2] http://techbase.kde.org/Schedules/KDE4/Upstream_Issues [3] https://bugzilla.redhat.com/show_bug.cgi?id=417251 -------------- 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 ml at deadbabylon.de Tue Dec 11 22:51:40 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 11 Dec 2007 23:51:40 +0100 Subject: KDE-SIG weekly report (50/2007) In-Reply-To: <200712112341.49079.ml@deadbabylon.de> References: <200712112341.49079.ml@deadbabylon.de> Message-ID: <200712112351.41234.ml@deadbabylon.de> Sry. Copy&paste is sometimes not useful: > = Participants = > > - KevinKofler > - RexDieter > - SebastianVahl - PavelShevchuk (Stalwart) - ThanNgo Sebastian -------------- 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 christoph.wickert at nurfuerspam.de Wed Dec 12 00:31:09 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Wed, 12 Dec 2007 01:31:09 +0100 Subject: yum, x86_64 and i386: the never ending story Message-ID: <1197419469.3785.13.camel@wicktop.localdomain> sorry that I bring up this topic once again: why does yum install i386 packages on a x86_64 system during groupinstall? # yum groupinstall XFCE ... Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: Thunar i386 0.8.0-3.fc8 fedora 5.2 M xfce-mcs-plugins x86_64 4.4.1-3.fc8 fedora 593 k xfce-utils x86_64 4.4.1-3.fc8 fedora 346 k xfce4-appfinder x86_64 4.4.1-2.fc8 fedora 264 k xfce4-mailwatch-plugin x86_64 1.0.1-7.fc8 fedora 365 k xfce4-mixer x86_64 4.4.1-3.fc8 fedora 216 k xfce4-session-engines x86_64 4.4.1-2.fc8 fedora 325 k xfprint i386 4.4.1-2.fc8 fedora 584 k xfprint x86_64 4.4.1-2.fc8 fedora 587 k Installing for dependencies: Terminal x86_64 0.2.6-3.fc8 fedora 1.2 M Thunar x86_64 0.8.0-3.fc8 fedora 5.2 M exo i386 0.3.2-3.fc8 fedora 679 k exo x86_64 0.3.2-3.fc8 fedora 681 k libxfce4mcs i386 4.4.1-3.fc8 fedora 46 k libxfce4mcs x86_64 4.4.1-3.fc8 fedora 48 k libxfce4util x86_64 4.4.1-3.fc8 fedora 74 k libxfce4util i386 4.4.1-3.fc8 fedora 73 k libxfcegui4 x86_64 4.4.1-3.fc8 fedora 278 k libxfcegui4 i386 4.4.1-3.fc8 fedora 277 k mousepad x86_64 0.2.12-3.fc8 fedora 89 k xfce-mcs-manager x86_64 4.4.1-3.fc8 fedora 382 k xfce4-panel i386 4.4.1-4.fc8 fedora 530 k xfce4-panel x86_64 4.4.1-4.fc8 fedora 535 k xfce4-session i386 4.4.1-2.fc8 fedora 509 k xfce4-session x86_64 4.4.1-2.fc8 fedora 510 k xfdesktop x86_64 4.4.1-3.fc8 fedora 2.7 M xfwm4 x86_64 4.4.1-3.fc8 fedora 1.3 M To me this looks like xfprint.i386 and Thunar.i386 are installed by accident and then pull in the all the rest. Can anybody explain this to me? I don't think that this behavior is desired by 99 % of the users. Christoph From bnocera at redhat.com Wed Dec 12 00:47:40 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 12 Dec 2007 00:47:40 +0000 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <1197407856.31537.83.camel@cutter> References: <475EF9D5.7080702@hhs.nl> <20071211211555.GA23341@redhat.com> <1197407856.31537.83.camel@cutter> Message-ID: <1197420460.26210.172.camel@cookie.hadess.net> On Tue, 2007-12-11 at 16:17 -0500, seth vidal wrote: > if you have yum-utils installed you can run: > > debuginfo-install xfig Do you have a page full of stuff like that somewhere? Something installing all the deps from a .spec or a specific source file would be grand. /Bastien who uses yum like he did apt-get many moons ago From skvidal at fedoraproject.org Wed Dec 12 00:51:56 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Dec 2007 19:51:56 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197419469.3785.13.camel@wicktop.localdomain> References: <1197419469.3785.13.camel@wicktop.localdomain> Message-ID: <1197420716.31537.91.camel@cutter> On Wed, 2007-12-12 at 01:31 +0100, Christoph Wickert wrote: > sorry that I bring up this topic once again: why does yum install i386 > packages on a x86_64 system during groupinstall? > > # yum groupinstall XFCE > ... > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > Thunar i386 0.8.0-3.fc8 fedora 5.2 M > xfce-mcs-plugins x86_64 4.4.1-3.fc8 fedora 593 k > xfce-utils x86_64 4.4.1-3.fc8 fedora 346 k > xfce4-appfinder x86_64 4.4.1-2.fc8 fedora 264 k > xfce4-mailwatch-plugin x86_64 1.0.1-7.fc8 fedora 365 k > xfce4-mixer x86_64 4.4.1-3.fc8 fedora 216 k > xfce4-session-engines x86_64 4.4.1-2.fc8 fedora 325 k > xfprint i386 4.4.1-2.fc8 fedora 584 k > xfprint x86_64 4.4.1-2.fc8 fedora 587 k > Installing for dependencies: > Terminal x86_64 0.2.6-3.fc8 fedora 1.2 M > Thunar x86_64 0.8.0-3.fc8 fedora 5.2 M > exo i386 0.3.2-3.fc8 fedora 679 k > exo x86_64 0.3.2-3.fc8 fedora 681 k > libxfce4mcs i386 4.4.1-3.fc8 fedora 46 k > libxfce4mcs x86_64 4.4.1-3.fc8 fedora 48 k > libxfce4util x86_64 4.4.1-3.fc8 fedora 74 k > libxfce4util i386 4.4.1-3.fc8 fedora 73 k > libxfcegui4 x86_64 4.4.1-3.fc8 fedora 278 k > libxfcegui4 i386 4.4.1-3.fc8 fedora 277 k > mousepad x86_64 0.2.12-3.fc8 fedora 89 k > xfce-mcs-manager x86_64 4.4.1-3.fc8 fedora 382 k > xfce4-panel i386 4.4.1-4.fc8 fedora 530 k > xfce4-panel x86_64 4.4.1-4.fc8 fedora 535 k > xfce4-session i386 4.4.1-2.fc8 fedora 509 k > xfce4-session x86_64 4.4.1-2.fc8 fedora 510 k > xfdesktop x86_64 4.4.1-3.fc8 fedora 2.7 M > xfwm4 x86_64 4.4.1-3.fc8 fedora 1.3 M > > To me this looks like xfprint.i386 and Thunar.i386 are installed by > accident and then pull in the all the rest. Can anybody explain this to > me? > > I don't think that this behavior is desired by 99 % of the users. I'm pretty sure that that statistic is made up. it's something we'll be working on as a result of the multilib discussion we had early in the beginning of the f9 cycle. -sv From loupgaroublond at gmail.com Wed Dec 12 01:07:42 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 11 Dec 2007 20:07:42 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197420716.31537.91.camel@cutter> References: <1197419469.3785.13.camel@wicktop.localdomain> <1197420716.31537.91.camel@cutter> Message-ID: <7f692fec0712111707h229106fbv99ffed91c5ac9644@mail.gmail.com> On Dec 11, 2007 7:51 PM, seth vidal wrote: > On Wed, 2007-12-12 at 01:31 +0100, Christoph Wickert wrote: > > To me this looks like xfprint.i386 and Thunar.i386 are installed by > > accident and then pull in the all the rest. Can anybody explain this to > > me? > > > > I don't think that this behavior is desired by 99 % of the users. > > I'm pretty sure that that statistic is made up. 88.3% of all statistics are made up on the spot. -loup From fangqq at gmail.com Wed Dec 12 01:12:40 2007 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 11 Dec 2007 20:12:40 -0500 Subject: how to use Source1 to add an additional file In-Reply-To: <26664.63.85.68.164.1197403266.squirrel@mail.jcomserv.net> References: <26664.63.85.68.164.1197403266.squirrel@mail.jcomserv.net> Message-ID: <475F3588.2080606@gmail.com> I did a "make tag" as suggested, and check the cvsweb, and all needed files seem to be tagged correctly (0.9.9-2), then I run "make i386", na! it failed again, hit the same error message! Even I put the 61-*.conf to my local SOURCE directory, and try to build a local srpm as Nicolas suggested, it could not get through either, same error. any other thoughts? btw: can anyone point me to a good rpm manual? I read the UpdatingPackage page from Fedora wiki, and googled a few tutorials, but none of them elaborates on this, or maybe I did not read careful enough? Jon Ciesla wrote: > > You have to bump the revision and re-run "make tag". > From mtasaka at ioa.s.u-tokyo.ac.jp Wed Dec 12 01:25:54 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 12 Dec 2007 10:25:54 +0900 Subject: how to use Source1 to add an additional file In-Reply-To: <475ED95E.9040506@gmail.com> References: <475ED95E.9040506@gmail.com> Message-ID: <475F38A2.4040008@ioa.s.u-tokyo.ac.jp> Qianqian Fang wrote, at 12/12/2007 03:39 AM +9:00: > hi > > I want to add a separate configuration file (61-wqy-bitmapsong.conf) > to package wqy-bitmap-fonts, after reading some examples, I used > the following syntax to make this change > > .... > Source0: http://url of the upstream package > Source1: 61-wqy-bitmapsong.conf # the additional file > .... > > %setup -q -n %{wqyroot} > ... > %install > ... > install -p -m644 %{SOURCE1} %{buildroot}%{fontconfigdir}/ > ... > > then I copied 61-wqy-bitmapsong.conf to "devel" directory, > and "cvs add 61-wqy-bitmapsong.conf". However, it failed when > I test the build with "make i386", the error message is > > File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf > Installed (but unpackaged) file(s) found > /etc/fonts/conf.d/61-wqy-bitmapsong.conf > did I miss anything? where should I put the 61-wqy-bitmapsong.conf > when commit to cvs? Well, the problem is not there. Actually the build log says /etc/fonts/conf.d/61-wqy-bitmapsong.conf is found but your spec file reads: ---------------------------------------------- %files .................... %config(noreplace) %{fontconfdir}/%{SOURCE1} ---------------------------------------------- Here SOURCE1 is expanded to %_sourcedir/`basename %SOURCE1`. As the result %{fontconfdir}/%{SOURCE1} is not found but /etc/fonts/conf.d/61-wqy-bitmapsong.conf is left installed but not registered. Regards, Mamoru Tasaka From laurent.rineau__fedora at normalesup.org Wed Dec 12 01:32:03 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Wed, 12 Dec 2007 02:32:03 +0100 Subject: how to use Source1 to add an additional file In-Reply-To: <475ED95E.9040506@gmail.com> References: <475ED95E.9040506@gmail.com> Message-ID: <200712120232.03382@rineau.tsetse> On Tuesday 11 December 2007 19:39:26 Qianqian Fang wrote: > File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf > Installed (but unpackaged) file(s) found > /etc/fonts/conf.d/61-wqy-bitmapsong.conf I tried to compile your package, and I got the following error: RPM build errors: File not found: /var/tmp/wqy-bitmap-fonts-0.9.9-2.fc9-root-lrineau/etc/fonts/conf.d/home/lrineau/Fedora/wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf Its your %files section that is incorrect! Change this: %config(noreplace) %{fontconfdir}/%{SOURCE1} to that: %config(noreplace) %{fontconfdir}/61-wqy-bitmapsong.conf or even: %config(noreplace) %{fontconfdir}/*.conf The explanation of the error is that ${SOURCE1} is expanded to a full path, and not just a file name. That is why the error log shows a very long path. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From jonathan.underwood at gmail.com Wed Dec 12 02:12:14 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 12 Dec 2007 02:12:14 +0000 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <7f692fec0712111707h229106fbv99ffed91c5ac9644@mail.gmail.com> References: <1197419469.3785.13.camel@wicktop.localdomain> <1197420716.31537.91.camel@cutter> <7f692fec0712111707h229106fbv99ffed91c5ac9644@mail.gmail.com> Message-ID: <645d17210712111812l292bfca9xc826f88975a63767@mail.gmail.com> On 12/12/2007, Yaakov Nemoy wrote: > On Dec 11, 2007 7:51 PM, seth vidal wrote: > > On Wed, 2007-12-12 at 01:31 +0100, Christoph Wickert wrote: > > > To me this looks like xfprint.i386 and Thunar.i386 are installed by > > > accident and then pull in the all the rest. Can anybody explain this to > > > me? > > > > > > I don't think that this behavior is desired by 99 % of the users. > > > > I'm pretty sure that that statistic is made up. > > 88.3% of all statistics are made up on the spot. > So it's all spot's fault. From fangqq at gmail.com Wed Dec 12 02:34:04 2007 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 11 Dec 2007 21:34:04 -0500 Subject: how to use Source1 to add an additional file In-Reply-To: <200712120232.03382@rineau.tsetse> References: <475ED95E.9040506@gmail.com> <200712120232.03382@rineau.tsetse> Message-ID: <475F489C.7070905@gmail.com> hi Laurent and Mamoru thank you so much, that solved the problem! Qianqian Laurent Rineau wrote: > On Tuesday 11 December 2007 19:39:26 Qianqian Fang wrote: > >> File Not found: ..../wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf >> Installed (but unpackaged) file(s) found >> /etc/fonts/conf.d/61-wqy-bitmapsong.conf >> > > I tried to compile your package, and I got the following error: > RPM build errors: > File not > found: /var/tmp/wqy-bitmap-fonts-0.9.9-2.fc9-root-lrineau/etc/fonts/conf.d/home/lrineau/Fedora/wqy-bitmap-fonts/devel/61-wqy-bitmapsong.conf > > > Its your %files section that is incorrect! > > Change this: > %config(noreplace) %{fontconfdir}/%{SOURCE1} > to that: > %config(noreplace) %{fontconfdir}/61-wqy-bitmapsong.conf > or even: > %config(noreplace) %{fontconfdir}/*.conf > > The explanation of the error is that ${SOURCE1} is expanded to a full path, > and not just a file name. That is why the error log shows a very long path. > > From james.antill at redhat.com Wed Dec 12 02:50:56 2007 From: james.antill at redhat.com (James Antill) Date: Tue, 11 Dec 2007 21:50:56 -0500 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <1197420460.26210.172.camel@cookie.hadess.net> References: <475EF9D5.7080702@hhs.nl> <20071211211555.GA23341@redhat.com> <1197407856.31537.83.camel@cutter> <1197420460.26210.172.camel@cookie.hadess.net> Message-ID: <1197427856.12670.71.camel@code.and.org> On Wed, 2007-12-12 at 00:47 +0000, Bastien Nocera wrote: > Something > installing all the deps from a .spec or a specific source file would be > grand. yum-builddep does that, also in yum-utils. -- 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 tcallawa at redhat.com Wed Dec 12 03:43:38 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 11 Dec 2007 22:43:38 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <645d17210712111812l292bfca9xc826f88975a63767@mail.gmail.com> References: <1197419469.3785.13.camel@wicktop.localdomain> <1197420716.31537.91.camel@cutter> <7f692fec0712111707h229106fbv99ffed91c5ac9644@mail.gmail.com> <645d17210712111812l292bfca9xc826f88975a63767@mail.gmail.com> Message-ID: <1197431018.15754.50.camel@localhost.localdomain> On Wed, 2007-12-12 at 02:12 +0000, Jonathan Underwood wrote: > On 12/12/2007, Yaakov Nemoy wrote: > > On Dec 11, 2007 7:51 PM, seth vidal wrote: > > > On Wed, 2007-12-12 at 01:31 +0100, Christoph Wickert wrote: > > > > To me this looks like xfprint.i386 and Thunar.i386 are installed by > > > > accident and then pull in the all the rest. Can anybody explain this to > > > > me? > > > > > > > > I don't think that this behavior is desired by 99 % of the users. > > > > > > I'm pretty sure that that statistic is made up. > > > > 88.3% of all statistics are made up on the spot. > > > > So it's all spot's fault. Blame, blame, blame. You can't prove anything. ~spot From skvidal at fedoraproject.org Wed Dec 12 03:58:29 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Dec 2007 22:58:29 -0500 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <1197427856.12670.71.camel@code.and.org> References: <475EF9D5.7080702@hhs.nl> <20071211211555.GA23341@redhat.com> <1197407856.31537.83.camel@cutter> <1197420460.26210.172.camel@cookie.hadess.net> <1197427856.12670.71.camel@code.and.org> Message-ID: <1197431909.31537.98.camel@cutter> On Tue, 2007-12-11 at 21:50 -0500, James Antill wrote: > On Wed, 2007-12-12 at 00:47 +0000, Bastien Nocera wrote: > > > Something > > installing all the deps from a .spec or a specific source file would be > > grand. > > yum-builddep does that, also in yum-utils. > make sure you get 1.1.9 out of updates-testing b/c yum-builddep in 1.1.8 didn't work so well, or, you know, at all. :) -sv From kevin.kofler at chello.at Wed Dec 12 06:43:10 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 12 Dec 2007 06:43:10 +0000 (UTC) Subject: KDE-SIG weekly report (50/2007) References: <200712112341.49079.ml@deadbabylon.de> Message-ID: Sebastian Vahl deadbabylon.de> writes: > - KevinKofler suggested to eventually drop most of kdelibs3-devel which isn't > usefull anymore You mean kdebase3-devel there. :-) What I want to remove is the libs which are only useful for KWin 3 styles, Konqueror 3 plugins, Kicker applets etc., because those can't be used with the KDE 4 version anyway. Kevin Kofler From d.lesca at solinos.it Wed Dec 12 10:02:37 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 12 Dec 2007 11:02:37 +0100 Subject: f8: NFS mount problem in rescue mode Message-ID: <1197453757.7313.144.camel@lesca.home.solinos.it> If I boot Fedora 8 with DVD in rescue mode I can't mount a NFS share. The problem also happened if I use Fedora 7 Respin, but NON if I use Fedora 7 std. or Fedora Core [6-1]. If I boot with options rescue + askmetod then do an NFS install, Anaconda mount /mnt/source correctly, but from shell if I try to mount another NFS share the mount not work All these problem happened also if I work on VMware-server. Some suggest? -- Dario Lesca From ml at deadbabylon.de Wed Dec 12 10:25:38 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 12 Dec 2007 11:25:38 +0100 Subject: KDE-SIG weekly report (50/2007) In-Reply-To: <200712112341.49079.ml@deadbabylon.de> References: <200712112341.49079.ml@deadbabylon.de> Message-ID: <200712121125.43253.ml@deadbabylon.de> Am Di 11.Dezember 2007 schrieb Sebastian Vahl: > - if more than one app is in an extragear module it should be named like > the module (e.g. extragear-multimedia) After thinking a bit about that I disagree now. Eg. extragear-multimedia contains also amarok, k3b and kplayer which are packaged as single applications a long time (and IMHO supposed to be single apps): http://websvn.kde.org/trunk/extragear/multimedia/ And also they are released as single tarballs (at least for 3.97.0): ftp://ftp.kde.org/pub/kde/unstable/3.97/src/extragear I think we should take the advantage here to package them as single applications. That's also one of the most wanted features from users. And the modules itself could differ in their release cycle. Sebastian -------------- 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 Wed Dec 12 10:51:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 12 Dec 2007 10:51:44 +0000 (UTC) Subject: KDE-SIG weekly report (50/2007) References: <200712112341.49079.ml@deadbabylon.de> <200712121125.43253.ml@deadbabylon.de> Message-ID: Sebastian Vahl deadbabylon.de> writes: > After thinking a bit about that I disagree now. Eg. extragear-multimedia > contains also amarok, k3b and kplayer which are packaged as single > applications a long time (and IMHO supposed to be single apps) I'm not suggesting to ship these as part of extragear-multimedia, also because they aren't really ready for KDE 4 yet (so we'll probably keep shipping the KDE 3 version) and AFAIK explicitly opted not to be included in the central extragear releases. > And also they are released as single tarballs (at least for 3.97.0): > ftp://ftp.kde.org/pub/kde/unstable/3.97/src/extragear That's a good argument for keeping them separate though. Kevin Kofler From rjones at redhat.com Wed Dec 12 11:11:14 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 12 Dec 2007 11:11:14 +0000 Subject: GnuTLS missing SRP functions Message-ID: <475FC1D2.5000909@redhat.com> After much messing around working out why this function: gnutls_srp_base64_decode_alloc is declared in but not actually present in libgnutls.so, I have discovered that GnuTLS in Fedora uses a "special" version of the library with all the SRP functions removed. Apparently this is because of some patent issue, see this posting and its follow-ups: http://lists.gnupg.org/pipermail/gnutls-dev/2005-January/000812.html I really think this should at least be documented. Nothing in /usr/share/doc/gnutls-1.6.3 mentions it. The functions ought to be removed from the header file if they are not in the library. There are questions about whether the SRP code really infringes on any patent. And as an example Debian's GnuTLS ships with the SRP functions intact. 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 tcallawa at redhat.com Wed Dec 12 12:23:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 12 Dec 2007 07:23:37 -0500 Subject: GnuTLS missing SRP functions In-Reply-To: <475FC1D2.5000909@redhat.com> References: <475FC1D2.5000909@redhat.com> Message-ID: <1197462218.15754.53.camel@localhost.localdomain> On Wed, 2007-12-12 at 11:11 +0000, Richard W.M. Jones wrote: > There are questions about whether the SRP code really infringes on any > patent. And as an example Debian's GnuTLS ships with the SRP functions > intact. I consulted with RH Legal on this one not too long ago, and they confirmed that we should not be shipping SRP in anything. Debian isn't a good reference example for patent compliance, keep in mind that they still ship mp3. ~spot From buildsys at redhat.com Wed Dec 12 13:19:17 2007 From: buildsys at redhat.com (Build System) Date: Wed, 12 Dec 2007 08:19:17 -0500 Subject: rawhide report: 20071212 changes Message-ID: <200712121319.lBCDJHoP020684@porkchop.devel.redhat.com> New package 8Kingdoms 8 Kingdoms is a 3D turn-based fantasy strategic game New package WebKit Web content engine library New package bib2html Converting bibTeX file to HTML New package geekcode Geek Code generator New package kaider Computer-aided translation system focusing on productivity and performance New package pioneers Turnbased board strategy game (colonize an island) New package ruby-revolution Ruby binding for the Evolution email client New package xenwatch Virtualization utilities, mostly for Xen Removed package firefox-32 Updated Packages: alexandria-0.6.2-0.3.b2.fc9 --------------------------- * Wed Dec 12 2007 Mamoru Tasaka - 0.6.2-0.3.b2 - Also require ruby(revolution) anacron-2.3-57.fc9 ------------------ * Mon Dec 10 2007 Marcela Maslanova 2.3-57 - 0anacron.{daily,weekly,monthly} check whether they are on battery - rhbz#387301 anjuta-1:2.2.0-4.fc9 -------------------- * Fri Dec 07 2007 Alex Lancaster 1:2.2.0-4 - Rebuild for new openssl * Wed Aug 29 2007 Fedora Release Engineering - 1:2.2.0-3 - Rebuild for selinux ppc32 issue. * Sat Jul 21 2007 Matej Cepl - 1:2.2.0-2 - Exclude architecutre ppc64 aspell-bg-50:4.1-1.fc9 ---------------------- * Tue Dec 11 2007 Ivana Varekova - 50:4.1-1 - update to 4.1 audacious-plugins-1.4.2-1.fc9 ----------------------------- * Tue Dec 04 2007 Ralf Ertzinger 1.4.2-1 - Update to 1.4.2 bluez-utils-3.23-1.fc9 ---------------------- * Mon Dec 10 2007 - Bastien Nocera - 3.23-1 - Update to 3.23 bzr-1.0-0.1.rc3.fc9 ------------------- * Tue Dec 11 2007 Toshio Kuratomi - 1.0-0.1.rc3 - Update to 1.0rc3 - The new rawhide python package generates egg-info files. * Fri Nov 30 2007 Toshio Kuratomi - 1.0-0.1.rc2 - Update to 1.0rc2 * Tue Aug 28 2007 Toshio Kuratomi - 0.91-1 - Update to 0.91. + Fixes some issues with using tag-enabled branches. bzr-gtk-0.93.0-2.fc9 -------------------- * Tue Dec 11 2007 Toshio Kuratomi 0.93-2 - Move the egg-info into sitearch along with the module. * Tue Dec 11 2007 Toshio Kuratomi 0.93-1 - Update to bzr-1.0 compatible package. bzrtools-1.0.0-2.fc9 -------------------- * Fri Dec 07 2007 Toshio Kuratomi 1.0.0-2 - Move the egg-info into sitearch alongside the module * Fri Dec 07 2007 Toshio Kuratomi 1.0.0-1 - Update to 1.0. codeblocks-1.0-0.28.20071210svn4719.fc9 --------------------------------------- * Tue Dec 11 2007 Dan Horak 1.0-0.28.20071210svn4719 - update to revision 4719 - fix multiarch problem with contrib subpackage (#340911) - set a fixed timestamp on all installed data files - preserve timestamps on updated files cpanspec-1.74-1.fc9 ------------------- * Tue Dec 11 2007 Steven Pritchard 1.74-1 - Update to 1.74. - Update License tag. docbook-style-xsl-1.73.2-8.fc9 ------------------------------ * Tue Dec 11 2007 Ondrej Vasik 1.73.2-8 - remove entries from xmlcatalog only on removal of package (required because of the change with droping release -caused drop of catalog entries during update) doulos-fonts-4.100-1.fc9 ------------------------ * Tue Dec 11 2007 Roozbeh Pournader - 4.100-1 - Update main font to 4.100, keep old Doulos Literacy which is latest - Change license tag to OFL ejabberd-1.1.4-3.fc9 -------------------- * Tue Dec 11 2007 Matej Cepl 1.1.4-3 - debug shouldn't be enabled on distributed package. * Tue Dec 11 2007 Matej Cepl 1.1.4-2 - rebuild against new ssl library. - rebuild against the newest erlang (see Patch - fix %changelog fontforge-20071110-1.fc9 ------------------------ * Sun Dec 02 2007 Roozbeh Pournader - 20071110-1 - Update to upstream 20071110 freeglut-2.4.0-12.fc9 --------------------- * Tue Dec 11 2007 Hans de Goede 2.4.0-12 - Add manpages to the -devel package (from openglut, bz 409651) ghostscript-8.61-6.fc9 ---------------------- * Tue Dec 11 2007 Tim Waugh 8.61-6 - Applied upstream patch for bug #416321. * Fri Nov 30 2007 Tim Waugh 8.61-5 - Fixed runlibfileifexists patch. * Fri Nov 30 2007 Tim Waugh 8.61-4 - Revert previous change, but define .runlibfileifexists, not just runlibfileifexists. gnome-games-1:2.21.3-2.fc9 -------------------------- * Tue Dec 11 2007 Hans de Goede - 1:2.21.3-2 - Fix rpm --verify complaining about the highscore files once a highscore has been added (bz 418991) gtk2-2.12.3-2.fc9 ----------------- * Tue Dec 11 2007 Matthias Clasen - 2.12.3-2 - Fix yet another notebook tab related crash * Wed Dec 05 2007 Matthias Clasen - 2.12.3-1 - Update to 2.12.3 * Mon Nov 26 2007 Matthias Clasen - 2.12.2-1 - Update to 2.12.2 highlight-2.6.6-1.fc9 --------------------- * Tue Dec 11 2007 Jochen Schmitt 2.6.6-1 - New upstream release * Mon Oct 29 2007 Jochen Schmitt 2.6.5-1 - New upstream release hunspell-de-0.20071211-1.fc9 ---------------------------- * Tue Dec 11 2007 Caolan McNamara - 0.20071211-1 - latest version icu-3.8-5.fc9 ------------- * Tue Dec 11 2007 Caolan McNamara - 3.8-5 - Resolves: rhbz#415541 icu.icu6084.zwnj.notdef.patch kde-filesystem-4-4.fc9 ---------------------- * Tue Dec 11 2007 Kevin Kofler 4-4 - set INCLUDE_INSTALL_DIR in %cmake_kde4 * Tue Dec 11 2007 Kevin Kofler 4-3 - actually create the directory listed in the file list * Tue Dec 11 2007 Kevin Kofler 4-2 - set kde4_includedir to %_kde4_prefix/include/kde4 kdeaddons-3.5.8-3.fc9 --------------------- * Tue Dec 11 2007 Kevin Kofler 3.5.8-4 - disable noatun plugins (F9+) kdeadmin-7:3.97.0-1.fc9 ----------------------- * Thu Dec 06 2007 Than Ngo 3.97.0-1 - 3.97.0 * Fri Nov 30 2007 Sebastian Vahl 7:3.96.2-1 - kde-3.96.2 * Fri Nov 23 2007 Sebastian Vahl 7:3.96.1-1 - kde-3.96.1 - also use epoch in changelog (also backwards) kdebase-workspace-3.97.0-2.fc9 ------------------------------ * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir kdebindings-3.97.0-6.fc9 ------------------------ * Tue Dec 11 2007 Kevin Kofler 3.97.0-6 - use patch to override PYTHON_SITE_PACKAGES_DIR (cmake -D doesn't work) * Tue Dec 11 2007 Kevin Kofler 3.97.0-5 - override PYTHON_SITE_PACKAGES_DIR * Tue Dec 11 2007 Kevin Kofler 3.97.0-4 - rewrite libsmokeqt-lib64 patch so it actually works - add PyKDE4 files to file list - specify minimum versions of sip-devel and PyQt4-devel - require PyQt4 in main package, PyQt4-devel in -devel - fix unowned Qt and KDE directories under ruby_sitelib kdegames-6:3.97.0-2.fc9 ----------------------- * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 * Thu Nov 29 2007 Rex Dieter 3.96.2-1 - kde-3.96.2 kdegraphics-7:3.97.0-4.fc9 -------------------------- * Tue Dec 11 2007 Kevin Kofler 3.97.0-4 - rebuild for changed _kde4_includedir kdelibs-6:3.97.0-6.fc9 ---------------------- * Tue Dec 11 2007 Than Ngo 3.97.0-6 - enable subversion again * Tue Dec 11 2007 Kevin Kofler 3.97.0-5 - rebuild for changed _kde4_includedir * Thu Dec 06 2007 Rex Dieter 3.97.0-4 - drop Req: kdebase-runtime oxygen-icon-theme (at least for now) kdelibs3-3.5.8-18.fc9 --------------------- * Tue Dec 11 2007 Kevin Kofler - 3.5.8-18 - set include_crystalsvg to 0 on F9+ (it comes from kdeartwork now) kdepimlibs-3.97.0-2.fc9 ----------------------- * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir kdesdk-3.97.0-4.fc9 ------------------- * Tue Dec 11 2007 Kevin Kofler 3.97.0-4 - build Kompare's static convenience libraries with -fPIC * Mon Dec 10 2007 Kevin Kofler 3.97.0-3 - updated fix-kompare patch (rev 6) * Mon Dec 10 2007 Kevin Kofler 3.97.0-2 - updated fix-kompare patch (rev 5) kdesvn-0.14.1-3.fc9 ------------------- * Tue Dec 11 2007 Alex Lancaster - 0.14.1-3 - BuildRequires: kdelibs-devel -> kdelibs3-devel * Tue Dec 11 2007 Alex Lancaster - 0.14.1-2 - Rebuild for new openssl/openldap kdevelop-9:3.5.0-5.fc9 ---------------------- * Thu Dec 06 2007 Kevin Kofler - 9:3.5.0-5 - drop CVS integration in F9+ for now because it requires kdesdk3 kernel-2.6.24-0.83.rc5.fc9 -------------------------- * Tue Dec 11 2007 Kyle McMartin - 2.6.24-rc5 - remove linux-2.6-firewire-ohci-1.0-iso-receive.patch, merged in -rc5 * Mon Dec 10 2007 Dave Jones - Rename PAE-debug flavour to PAEdebug (#388321) * Mon Dec 10 2007 Dave Jones - 2.6.24-rc4-git7 libtcd-2.2.3-1.fc9 ------------------ * Wed Dec 12 2007 Mamoru Tasaka - 2.2.3-1 - 2.2.3 licq-1.3.4-10.fc9 ----------------- * Tue Dec 11 2007 Jiri Moskovcak 1.3.4-10 - spec file cleanup * Thu Dec 06 2007 Adam Tkac 1.3.4-9 - rebuild against new openssl lynx-2.8.6-10.fc9 ----------------- * Tue Dec 11 2007 Ivana Varekova - 2.8.6-10 - add default-colors option, change default setting (#409211) mfiler2-4.0.0-1.fc9 ------------------- mkinitrd-6.0.20-1.fc9 --------------------- * Tue Dec 11 2007 Peter Jones - 6.0.20-1 - Add encrypted root filesystem support (Patch from dlehman) mock-0.9.1-1.fc9 ---------------- * Tue Dec 11 2007 Michael Brown - 0.9.1-1 - fix 'mock shell' command when passing more than one arg. - add --orphanskill mode which only does orphankill - make 'mock --shell' noninteractive and logged to root.log - fix for file-based BuildRequires - add sparcs to constant list for auto-setarch moreutils-0.26-1.fc9 -------------------- * Wed Dec 12 2007 Marc Bradshaw 0.26-1.fc9 - Docboox dtd path will now be found using xmlcatalog. - New upstream version released with these changes - isutf8: Correct inverted exit code when passed a file to check. nss_db-2.2-39 ------------- * Tue Nov 06 2007 Nalin Dahyabhai - 2.2-39 - when setting file contexts for creation of new files, only fail outright if we were in enforcing mode and the file needed to be given a specific label (#368501) openjpeg-1.2-4.20071211svn484.fc9 --------------------------------- * Tue Dec 11 2007 Callum Lerwick 1.2-4.20071211svn484 - New snapshot. Fixes bz420811. * Wed Nov 14 2007 Callum Lerwick 1.2-3.20071114svn480 - Build using cmake. - New snapshot. * Thu Aug 09 2007 Callum Lerwick 1.2-2.20070808svn - Put binaries in main package, move libraries to -libs subpackage. perl-Apache-LogRegex-1.4-3.fc9 ------------------------------ * Tue Dec 11 2007 Steven Pritchard 1.4-3 - Update License tag. - BR Test::More. perl-Cache-Mmap-0.09-3.fc9 -------------------------- perl-Crypt-OpenSSL-AES-0.02-3.fc9 --------------------------------- * Sun Dec 09 2007 Release Engineering - 0.02-3 - Rebuild for deps * Thu Dec 06 2007 Wes Hardaker - 0.02-2 - Bump to force rebuild with new openssl lib version perl-DateTime-1:0.41-2.fc9 -------------------------- * Tue Dec 11 2007 Steven Pritchard 1:0.41-2 - Update License tag. - Update to DateTime::TimeZone 0.70. * 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. perl-ExtUtils-CBuilder-0.21-1.fc9 --------------------------------- * Tue Dec 11 2007 Steven Pritchard 0.21-1 - Update to 0.21. - Use fixperms macro instead of our own chmod incantation. - Reformat to more closely match cpanspec output (but don't use Module::Build, since that would create a dependency loop). - Package README. perl-File-Find-Rule-0.30-4.fc9 ------------------------------ * Tue Dec 11 2007 Ralf Cors??pius - 0.30-4 - Add BR: perl(Test::More) (BZ 419631). perl-IPC-Cmd-0.40-1.fc9 ----------------------- * Tue Dec 11 2007 Steven Pritchard 0.40-1 - Update to 0.40. perl-Imager-0.62-1.fc9 ---------------------- * Tue Dec 11 2007 Steven Pritchard 0.62-1 - Update to 0.62. - Update License tag. perl-Test-Expect-0.30-2.fc9 --------------------------- perl-UNIVERSAL-isa-0.06-3.fc9 ----------------------------- * Tue Dec 11 2007 Ralf Cors??pius - 0.06-3 - Add BR: perl(Test::More). perl-YAML-Tiny-1.21-1.fc9 ------------------------- * Tue Dec 11 2007 Steven Pritchard 1.21-1 - Update to 1.21. - Update License tag. - BR Test::MinimumVersion. * Thu Aug 23 2007 Steven Pritchard 1.14-1 - Update to 1.14. pilot-link-2:0.12.3-2.fc9 ------------------------- * Tue Dec 11 2007 Ivana Varekova - 2:0.12.3-2 - fix md5 header file policycoreutils-2.0.33-2.fc9 ---------------------------- * Tue Dec 11 2007 Dan Walsh 2.0.33-2 - Add Russion Man pages python-enchant-1.3.1-1.fc9 -------------------------- * Tue Dec 11 2007 Roozbeh Pournader - 1.3.1-1 - Update to 1.3.1 - Change license tag to LGPLv2+ python-iniparse-0.2.3-3.fc9 --------------------------- * Tue Dec 11 2007 Tim Lauridsen - 0.2.3-3 - handle egg-info too * Tue Dec 11 2007 Tim Lauridsen - 0.2.3-2 - removed patch source line * Tue Dec 11 2007 Tim Lauridsen - 0.2.3-1 - Updates to release 0.2.3 - removed empty ini file patch, it is included in 0.2.3 python-sqlalchemy-0.4.1-1.fc9 ----------------------------- * Tue Dec 11 2007 Toshio Kuratomi 0.4.1-1 - Update to 0.4.1. * Wed Oct 17 2007 Toshio Kuratomi 0.4.0-1 - SQLAlchemy-0.4.0 final - Run the testsuite * Wed Oct 03 2007 Luke Macken 0.4.0-0.4.beta6 - SQLAlchemy-0.4.0beta6 rapidsvn-0.9.4-7.fc9 -------------------- * Thu Dec 06 2007 Tim Jackson 0.9.4-7 - rebuild for new OpenLDAP rhpl-0.212-1 ------------ * Tue Dec 11 2007 Jeremy Katz - 0.212-1 - fix broken build * Fri Dec 07 2007 Jeremy Katz - 0.211-1 - package review cleanups (#226372) (katzj) - git-ify the makefile, remove the ChangeLog (katzj) - Add Efika detection to getPPCMachine() (dwmw2) - Update Romanian keyboard layout (#386861). (clumens) - remove py-compile; we haven't used it for a long time (katzj) - Run make in build section (#353751) (katzj) - removed sr at Latn translation (kmilos) - Remove obsolete translation (#332231). (clumens) scponly-4.6-8.fc9 ----------------- * Tue Dec 11 2007 Toshio Kuratomi - 4.6-8 - Disable rsync support due to security concerns: RH BZ#418201 timidity++-2.13.2-6.fc9 ----------------------- * Tue Dec 11 2007 Hans de Goede 2.13.2-6 - Disable building of the jack output on powerpc64, as that mysteriously fails to build there. * Mon Dec 10 2007 Hans de Goede 2.13.2-5 - Add patches to fix detect and compile of speex and flac outputs - Add various bugfixes from Debian - Enable ogg, flac, speex, libao and jack output formats (bz 412431) - Make libao the default output as libao support pulseaudio directly tracker-0.6.4-1.fc9 ------------------- * Tue Dec 11 2007 Deji Akingunola - 0.6.4-1 - Version 0.6.4 winpdb-1.3.2-1.fc9 ------------------ * Tue Dec 11 2007 Tom "spot" Callaway - 1.3.2-1 - bump to 1.3.2 wqy-bitmap-fonts-0.9.9-4.fc9 ---------------------------- * Tue Dec 11 2007 Qianqian Fang 0.9.9-4 - used tag 0.9.9-3 due to previous mistake, have to bump release to tag * Tue Dec 11 2007 Qianqian Fang 0.9.9-3 - replace /builddir/build/SOURCES/61-wqy-bitmapsong.conf by actual config file name * Tue Dec 11 2007 Qianqian Fang 0.9.9-2 - fontconfig file was rewriten to minimize impact to non-CJK users (#381311) wxMaxima-0.7.4-2.fc9 -------------------- * Tue Dec 11 2007 Rex Dieter 0.7.4-2 - fix app icon handling/packaging * Fri Dec 07 2007 Rex Dieter 0.7.4-1 - wxMaxima-0.7.4 xsupplicant-1.2.8-5.fc9.2 ------------------------- * Tue Dec 11 2007 Tom "spot" Callaway - 1.2.8-5.2 - give up on trying to build the docs * Tue Dec 11 2007 Tom "spot" Callaway - 1.2.8-5.1 - Fix docs patch so docs regenerate * Thu Dec 06 2007 Release Engineering - 1.2.8-5 - Rebuild for deps xtide-2.9.5-1.fc9 ----------------- * Wed Dec 12 2007 Mamoru Tasaka - 2.9.5-1 - 2.9.5 Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.3.0-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.i386 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 krusader - 1.80.0-3.fc9.i386 requires libkjsembed.so.1 kst - 1.5.0-1.fc9.i386 requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 tellico - 1.2.14-4.fc9.i386 requires libkcddb.so.1 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.3.0-1.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.x86_64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.x86_64 requires libkjsembed.so.1()(64bit) kst - 1.5.0-1.fc9.i386 requires libkjsembed.so.1 kst - 1.5.0-1.fc9.x86_64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) tellico - 1.2.14-4.fc9.x86_64 requires libkcddb.so.1()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.3.0-1.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 erlang-esdl - 0.96.0626-1.fc7.ppc requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.ppc requires libkjsembed.so.1 kst - 1.5.0-1.fc9.ppc64 requires libkjsembed.so.1()(64bit) kst - 1.5.0-1.fc9.ppc requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 tellico - 1.2.14-4.fc9.ppc requires libkcddb.so.1 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) erlang-esdl - 0.96.0626-1.fc7.ppc64 requires erlang = 0:R11B gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.ppc64 requires libkjsembed.so.1()(64bit) kst - 1.5.0-1.fc9.ppc64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) tellico - 1.2.14-4.fc9.ppc64 requires libkcddb.so.1()(64bit) From mschwendt.tmp0701.nospam at arcor.de Wed Dec 12 13:19:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 12 Dec 2007 14:19:03 +0100 Subject: 17 builds marked for deletion In-Reply-To: <200712120126.lBC1Qi0D019838@koji.fedora.phx.redhat.com> References: <200712120126.lBC1Qi0D019838@koji.fedora.phx.redhat.com> Message-ID: <20071212141903.ef44fb2e.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Dec 2007 18:26:44 -0700, Koji Build System wrote: > The following build(s) are unreferenced and have been marked for > deletion. They will be held in the trashcan tag for a grace period. > At the end of that period they will be deleted permanently. This > garbage collection is a normal part of build system operation. > Please see the following url for more information: > > http://fedoraproject.org/wiki/Koji/GarbageCollection -snip- > If you would like to protect any of these builds from deletion, please > refer to the document linked above for instructions. How do I know whether I may want to protect any of these builds? The list states no branch information at all. May I trust the buildsys that it does the right thing? For each package that is to be deleted, can you please list the "latest" package that is tagged for branches that undergo garbage collection. From jkeating at redhat.com Wed Dec 12 13:28:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 08:28:19 -0500 Subject: 17 builds marked for deletion In-Reply-To: <20071212141903.ef44fb2e.mschwendt.tmp0701.nospam@arcor.de> References: <200712120126.lBC1Qi0D019838@koji.fedora.phx.redhat.com> <20071212141903.ef44fb2e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071212082819.00b81d93@redhat.com> On Wed, 12 Dec 2007 14:19:03 +0100 Michael Schwendt wrote: > How do I know whether I may want to protect any of these builds? > The list states no branch information at all. > May I trust the buildsys that it does the right thing? Yes. No latest builds from any branch are taken. The reason you are shown a list is just in case you were making use of an older build or providing said older build to folks for whatever reason. Admittedly this makes a lot more sense /inside/ Red Hat for RHEL like products than it does for Fedora. > > For each package that is to be deleted, can you please list the > "latest" package that is tagged for branches that undergo garbage > collection. That's a fairly reasonable suggestion, I've passed it along to Mike McLean who has been working on the garbage collection stuff. -- 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 pbrobinson at gmail.com Wed Dec 12 13:30:40 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 12 Dec 2007 13:30:40 +0000 Subject: rawhide report: 20071212 changes In-Reply-To: <200712121319.lBCDJHoP020684@porkchop.devel.redhat.com> References: <200712121319.lBCDJHoP020684@porkchop.devel.redhat.com> Message-ID: <5256d0b0712120530q38936180kfa205ad26a1b363a@mail.gmail.com> > New package WebKit > Web content engine library Cool. Any chance of getting a Firefox 3 beta in at some stage, or is there an alt repo where it can be sucked from? Pete From fedora at dm.cobite.com Wed Dec 12 14:47:38 2007 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 12 Dec 2007 09:47:38 -0500 Subject: request for update of libbonobo to 2.20.2 Message-ID: <1197470858.2954.20.camel@gandalf.cobite.com> Hi All. Sorry if this is the wrong way to do it, but I would like to request an update from 2.20.1 to 2.20.2 (released today ;-) of libbonobo, for Fedora 8 etc. It contains a fix (provided by me) that I've been chasing for weeks that prevents freenx and vncserver etc. from working correctly with gnome if the user is also logged in locally (i.e two concurrent gnome sessions for the same user fail). Also many other miscellaneous problems are fixed by this one change. I searched for info on fedora wiki on how to request this but there is no info there that I could find. Thanks, David From mclasen at redhat.com Wed Dec 12 14:55:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 12 Dec 2007 09:55:50 -0500 Subject: request for update of libbonobo to 2.20.2 In-Reply-To: <1197470858.2954.20.camel@gandalf.cobite.com> References: <1197470858.2954.20.camel@gandalf.cobite.com> Message-ID: <1197471350.2958.2.camel@localhost.localdomain> On Wed, 2007-12-12 at 09:47 -0500, David Mansfield wrote: > Hi All. > > Sorry if this is the wrong way to do it, but I would like to request an > update from 2.20.1 to 2.20.2 (released today ;-) of libbonobo, for > Fedora 8 etc. It contains a fix (provided by me) that I've been chasing > for weeks that prevents freenx and vncserver etc. from working correctly > with gnome if the user is also logged in locally (i.e two concurrent > gnome sessions for the same user fail). Also many other miscellaneous > problems are fixed by this one change. > > I searched for info on fedora wiki on how to request this but there is > no info there that I could find. It will generally happen on its own. If you have reason to ask for this to be handled as a priority (as you certainly do in this case), filing a bug is one way to request the update. Since we are all drowning in bugspam, tracking down the maintainer (or the person who has been doing the last few updates) and sending direct mail may be more effective. I'll take care of libbonobo sometime this week. From dwmw2 at infradead.org Wed Dec 12 15:09:15 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Dec 2007 10:09:15 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197419469.3785.13.camel@wicktop.localdomain> References: <1197419469.3785.13.camel@wicktop.localdomain> Message-ID: <1197472155.2957.91.camel@shinybook.infradead.org> On Wed, 2007-12-12 at 01:31 +0100, Christoph Wickert wrote: > sorry that I bring up this topic once again: why does yum install i386 > packages on a x86_64 system during groupinstall? Because we haven't fixed bug 235756 yet. But won't worry, we're planning to fix it for Fedora 9. -- dwmw2 From mmcgrath at redhat.com Wed Dec 12 14:51:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Dec 2007 08:51:52 -0600 Subject: Outage Notification (Buildsystem) - 2008-12-13 03:45 UTC Message-ID: <475FF588.1040105@redhat.com> There will be an outage starting at 2008-12-13 04:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-12-13 03:45 UTC' Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Ticket Link: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/277 Reason for Outage: koji.fedoraproject.org is on a machine that is no longer under warranty and recently had a drive fail. We will be koji to new hardware. NOTE TO PACKAGERS: If you have to build a package that typically takes over an hour to build, please make sure to start your job so it is not still running during the outage. We will be disabling the builders one by one and will try to let builds finish but won't wait forever. 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 d.lesca at solinos.it Wed Dec 12 16:23:30 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 12 Dec 2007 17:23:30 +0100 Subject: f8: NFS mount problem in rescue mode In-Reply-To: <1197453757.7313.144.camel@lesca.home.solinos.it> References: <1197453757.7313.144.camel@lesca.home.solinos.it> Message-ID: <1197476610.23359.51.camel@lesca.home.solinos.it> Il giorno mer, 12/12/2007 alle 11.02 +0100, Dario Lesca ha scritto: > If I boot Fedora 8 with DVD in rescue mode I can't mount a NFS share. Please, someone can do this test and tell me if the problem happened only to me? Thanks. -- Dario Lesca From a.badger at gmail.com Mon Dec 10 22:20:26 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 10 Dec 2007 14:20:26 -0800 Subject: Python Eggs & distutils in Rawhide Message-ID: <475DBBAA.7030605@gmail.com> Just a small heads up for those of you packaging python modules. python-2.5.1-18, just built for rawhide, has reverted a small patch we were carrying that disabled generation of egg-info for modules created by distutils. That means that python modules built against rawhide will now create an extra file of metadata in the python_sitelib and python_sitearch directories. You'll need to include those in your %files section if it's not already pulled in via a wildcard. For more information on what these files give us, take a look at the Python Egg Guidelines on: http://fedoraproject.org/wiki/Packaging/Python/Eggs -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 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 caolanm at redhat.com Wed Dec 12 16:53:08 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 12 Dec 2007 16:53:08 +0000 Subject: openoffice-pyuno and external python programs In-Reply-To: References: Message-ID: <1197478388.924.220.camel@Jehannum> On Tue, 2007-10-16 at 13:06 +0200, Zoltan Kota wrote: > The openoffice.org-pyuno package installs uno.py and other files > under /usr/lib/openoffice.org/program/, so with the default installations > and settings importing uno.py from external python programs gives an > import error. And how about in rawhide now, does that work for you as you wanted... [caolan at Jehannum ~]$ python -c "import uno" [caolan at Jehannum ~]$ C. From kzak at redhat.com Wed Dec 12 17:09:26 2007 From: kzak at redhat.com (Karel Zak) Date: Wed, 12 Dec 2007 18:09:26 +0100 Subject: f8: NFS mount problem in rescue mode In-Reply-To: <1197476610.23359.51.camel@lesca.home.solinos.it> References: <1197453757.7313.144.camel@lesca.home.solinos.it> <1197476610.23359.51.camel@lesca.home.solinos.it> Message-ID: <20071212170926.GD10894@petra.dvoda.cz> On Wed, Dec 12, 2007 at 05:23:30PM +0100, Dario Lesca wrote: > Il giorno mer, 12/12/2007 alle 11.02 +0100, Dario Lesca ha scritto: > > If I boot Fedora 8 with DVD in rescue mode I can't mount a NFS share. > > Please, someone can do this test and tell me if the problem happened > only to me? do you have /sbin/mount.nfs (in rescue mode)? Karel -- Karel Zak From nicolas.mailhot at laposte.net Wed Dec 12 17:35:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Dec 2007 18:35:56 +0100 Subject: Argyll color management system integration Message-ID: <1197480956.22091.15.camel@rousalka.dyndns.org> Hi all, The FLOSS color management scene (calibrating screens for pictures or video) is very small. In fact there is only one reference application every other project depends on or compares itself to: Argyll CMS. Argyll is free, supports many common (commercial and do-it-yourself) color meters, has been actively developed for more than a decade. It was on the Fedora package wishlist. Unfortunately its main author is not following best release practises and has chosen to use a non-standard unmaintained make replacement (jam), with static linking, private copies of common libraries, and all kinds of things distributions are not fond of. As a result no first-level distribution shipped Argyll. Despite the fact every color management HOWTO on the net points to it. I started untangling the mess in October but gave up after a frustrating week. Fortunately I had the good idea to put the result on fedorapeople, and lately Fr?d?ric Crozat from Mandriva googled it and completed the work. On hindsight it seems I had stopped just short of the finish line. http://twinpeaks.dyndns.org/blog/general/2007/12/11/monitor-calibration-epilogue Since it'd be a shame to let my packaging work end up in Mandriva only, I picked up his package, changed back a few bits, added some stuff I had planned but not done yet, and pushed the result in the review queue: https://bugzilla.redhat.com/show_bug.cgi?id=421921 I'd appreciate if a friendly reviewer looked at the result. The following work has been done: ? link against system libs, not built-in copies ? build with modular X ? remove the shell wrapper that was hiding build errors from rpm ? reorder build logic to fix those errors ? hal/pam/udev logic so colorimeters do not need root access The result is IMHO good enough to be merged. However, since this software has suffered from a secluded life due to the aforementioned problems, it would probably be a good idea if more clueful people than me checked the following points: ? go over the build logs, ?check if the warnings are really harmless and fix the code if needed (where is the list of people that wanted to do this kind of work a few months ago?) http://nim.fedorapeople.org/argyllcms/build.log I doubt argyllcms was ever built with a modern gcc with all the fancy options we use and for all the architectures we target ? check if I got the hal/pam/udev logic right, push bits upstream if needed (I didn't find two Fedora packages that did it the same way, all I can say the way I did it works on my system) ? check if upstream didn't mess up licensing as it did the code Then we'll have one key app for photographers and video buffs nailed, and there will only be the matter of pushing fixes upstream. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From berrange at redhat.com Wed Dec 12 17:46:58 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 12 Dec 2007 17:46:58 +0000 Subject: Argyll color management system integration In-Reply-To: <1197480956.22091.15.camel@rousalka.dyndns.org> References: <1197480956.22091.15.camel@rousalka.dyndns.org> Message-ID: <20071212174658.GD978@redhat.com> On Wed, Dec 12, 2007 at 06:35:56PM +0100, Nicolas Mailhot wrote: > I started untangling the mess in October but gave up after a frustrating > week. Fortunately I had the good idea to put the result on fedorapeople, > and lately Fr?d?ric Crozat from Mandriva googled it and completed the > work. On hindsight it seems I had stopped just short of the finish line. > http://twinpeaks.dyndns.org/blog/general/2007/12/11/monitor-calibration-epilogue > > Since it'd be a shame to let my packaging work end up in Mandriva only, > I picked up his package, changed back a few bits, added some stuff I had > planned but not done yet, and pushed the result in the review queue: > https://bugzilla.redhat.com/show_bug.cgi?id=421921 > > I'd appreciate if a friendly reviewer looked at the result. I've had a crack at packaging argylcms too but also gave up with the crazy JAM and static linking stuff. I'll give your packages a once-over. > The following work has been done: > ??? link against system libs, not built-in copies > ??? build with modular X > ??? remove the shell wrapper that was hiding build errors from rpm > ??? reorder build logic to fix those errors > ??? hal/pam/udev logic so colorimeters do not need root access > > The result is IMHO good enough to be merged. However, since this > software has suffered from a secluded life due to the aforementioned > problems, it would probably be a good idea if more clueful people than > me checked the following points: > > ??? go over the build logs, ???check if the warnings are really harmless and > fix the code if needed (where is the list of people that wanted to do > this kind of work a few months ago?) > http://nim.fedorapeople.org/argyllcms/build.log > I doubt argyllcms was ever built with a modern gcc with all the fancy > options we use and for all the architectures we target > > ??? check if I got the hal/pam/udev logic right, push bits upstream if > needed (I didn't find two Fedora packages that did it the same way, all > I can say the way I did it works on my system) I've got a Optix XR instrument which I can test the udev bits with. 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 bpepple at fedoraproject.org Wed Dec 12 17:47:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 12 Dec 2007 12:47:24 -0500 Subject: Plan for tomorrows (20071213) FESCO meeting Message-ID: <1197481644.506.4.camel@nixon> 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 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic MISC - Automated MIA Proposal - http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal - f13 /topic FESCO-Meeting -- List of packages to complete Merge Reviews by F9 -- tibbs. nirik /topic FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat * http://fedoraproject.org/wiki/Features/VirtAuthentication * http://fedoraproject.org/wiki/Features/VirtPolicyKit * http://fedoraproject.org/wiki/Releases/FeatureMoreNetworkManager /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, since we have a pretty full schedule). 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... 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 nicolas.mailhot at laposte.net Wed Dec 12 18:12:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Dec 2007 19:12:09 +0100 Subject: Argyll color management system integration In-Reply-To: <20071212174658.GD978@redhat.com> References: <1197480956.22091.15.camel@rousalka.dyndns.org> <20071212174658.GD978@redhat.com> Message-ID: <1197483129.22526.3.camel@rousalka.dyndns.org> Le mercredi 12 d?cembre 2007 ? 17:46 +0000, Daniel P. Berrange a ?crit : > I've had a crack at packaging argylcms too but also gave up with the crazy > JAM and static linking stuff. I'll give your packages a once-over. Many thanks! > > ??? check if I got the hal/pam/udev logic right, push bits upstream if > > needed (I didn't find two Fedora packages that did it the same way, all > > I can say the way I did it works on my system) > > I've got a Optix XR instrument which I can test the udev bits with. Same as me then, would be good to have testers with other hardware. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dominik at greysector.net Wed Dec 12 18:27:51 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 12 Dec 2007 19:27:51 +0100 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197419469.3785.13.camel@wicktop.localdomain> References: <1197419469.3785.13.camel@wicktop.localdomain> Message-ID: <20071212182751.GA3360@ryvius.greysector.net> On Wednesday, 12 December 2007 at 01:31, Christoph Wickert wrote: > sorry that I bring up this topic once again: why does yum install i386 > packages on a x86_64 system during groupinstall? Doesn't # yum install yum-basearchonly help in this case? 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 j.w.r.degoede at hhs.nl Wed Dec 12 19:39:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Dec 2007 20:39:41 +0100 Subject: Howto resolv addresses in *** buffer overflow detected *** Backtrace after the fact In-Reply-To: <20071211211555.GA23341@redhat.com> References: <475EF9D5.7080702@hhs.nl> <20071211211555.GA23341@redhat.com> Message-ID: <476038FD.10007@hhs.nl> Daniel P. Berrange wrote: > On Tue, Dec 11, 2007 at 09:57:57PM +0100, Hans de Goede wrote: >> Hi, >> >> I just received a bug report with a backtrace generated by glibc attached: >> https://bugzilla.redhat.com/attachment.cgi?id=284591 >> >> Looks like a real bug however the reported desn't know exactly what he did >> to trigger this, so now I want to convert the backtrace glibc generated >> into one with filenames and line numbers for the addresses of the xfig >> stack frames. >> >> Can anyone tell me how to do this? > > The following seems to work.... > > # yum --enablerepo=development-debuginfo install xfig-debuginfo > > # gdb /usr/bin/xfig-plain > > (gdb) list *0x4a3909 > 0x4a3909 is in reset_topruler (/usr/include/bits/stdio2.h:34). > 29 > 30 #ifdef __va_arg_pack > 31 __extern_always_inline int > 32 __NTH (sprintf (char *__restrict __s, __const char *__restrict __fmt, ...)) > 33 { > 34 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, > 35 __bos (__s), __fmt, __va_arg_pack ()); > 36 } > 37 #elif !defined __cplusplus > 38 # define sprintf(str, ...) \ > > > So the code is a sprintf call from the reset_topruler method. > > Looking at that method, we can see an likely candidate: > > (gdb) list reset_topruler > 1160 /* Note: For reset_top/sideruler to work properly, the value of skip should be > 1161 * such that (skip/ruler_unit) is an integer or (ruler_unit/skip) is an integer. > 1162 */ > 1163 > 1164 void reset_topruler(void) > 1165 { > 1166 register int i,k; > 1167 register tick_info* tk; > 1168 register Pixmap p = topruler_pm; > 1169 char number[6]; > (gdb) list + > 1170 int X0,len; > 1171 int tickmod, tickskip; > 1172 > 1173 /* top ruler, adjustments for digits are kludges based on 6x13 char */ > 1174 XFillRectangle(tool_d, p, tr_erase_gc, 0, 0, TOPRULER_WD, TOPRULER_HT); > 1175 > 1176 /* set the number of pixels to skip between labels and precision for float */ > 1177 get_skip_prec(); > 1178 > 1179 X0 = BACKX(0); > (gdb) list + > 1180 X0 -= (X0 % skip); > 1181 tickmod = (int) round(ruler_unit/appres.userscale); > 1182 if (tickmod == 0) > 1183 tickmod = 1; > 1184 > 1185 /* see how big a label is to adjust spacing, if necessary */ > 1186 sprintf(number, "%d%s", (X0+(int)((TOPRULER_WD/zoomscale)))/tickmod, cur_fig_units); > 1187 len = XTextWidth(roman_font, number, strlen(number)); > 1188 while (skipx < (len + 5)/zoomscale) { > 1189 skip *= 2; > > > Line 1186 is printing a string into a fixed length buffer with no > checking. A clear buffer overflow candidate there if the combo of > the ruler size & the figure units are longer than 5 characters :-( > > Regards, > Dan. Many thanks! A fixed version is building now :) Regards, Hans From wtogami at redhat.com Wed Dec 12 19:37:07 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Dec 2007 14:37:07 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197419469.3785.13.camel@wicktop.localdomain> References: <1197419469.3785.13.camel@wicktop.localdomain> Message-ID: <47603863.7030303@redhat.com> Christoph Wickert wrote: > sorry that I bring up this topic once again: why does yum install i386 > packages on a x86_64 system during groupinstall? You can avoid nearly all multilib install problems with yum-basearchonly. The only drawback is if you really do need something .i386 you need to name it manually to install it. Warren From wtogami at redhat.com Wed Dec 12 19:41:44 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Dec 2007 14:41:44 -0500 Subject: SDL pulseaudio workaround hack In-Reply-To: <474D2D2F.5030308@noltec.org> References: <474B7512.3080408@redhat.com> <474D2D2F.5030308@noltec.org> Message-ID: <47603978.8030902@redhat.com> Christian Nolte wrote: > > Please consider putting the workaround in the SDL-Package as not every > program which uses SDL has a dependency on SDL_mixer. See BUG #343911. > Nobody has pointed out a single SDL package that has sound output that does not pull in SDL_mixer. Warren Togami wtogami at redhat.com From tibbs at math.uh.edu Wed Dec 12 20:00:51 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 14:00:51 -0600 Subject: Plan for tomorrows (20071213) FESCO meeting In-Reply-To: <1197481644.506.4.camel@nixon> References: <1197481644.506.4.camel@nixon> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> /topic FESCO-Meeting -- List of packages to complete Merge Reviews BP> by F9 tibbs. nirik For everyone's information, the initial proposal is at http://fedoraproject.org/wiki/JasonTibbitts/MergeReviews - J< From wtogami at redhat.com Wed Dec 12 20:11:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Dec 2007 15:11:49 -0500 Subject: flash-plugin-9.0.115.0 v. nspluginwrapper Message-ID: <47604085.8060700@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=360891 Ever since Adobe released 9.0.115.0 a few days ago, it has had tremendous new problems especially with nspluginwrapper. We are currently not able to isolate the problem to nspluginwrapper or Adobe Flash. https://bugzilla.redhat.com/show_bug.cgi?id=360891#c25 Can other people please test these four scenarios for themselves and report back here in this list thread? Warren Togami wtogami at redhat.com From drago01 at gmail.com Wed Dec 12 20:34:07 2007 From: drago01 at gmail.com (drago01) Date: Wed, 12 Dec 2007 21:34:07 +0100 Subject: flash-plugin-9.0.115.0 v. nspluginwrapper In-Reply-To: <47604085.8060700@redhat.com> References: <47604085.8060700@redhat.com> Message-ID: On Dec 12, 2007 9:11 PM, Warren Togami wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=360891 > Ever since Adobe released 9.0.115.0 a few days ago, it has had > tremendous new problems especially with nspluginwrapper. We are > currently not able to isolate the problem to nspluginwrapper or Adobe Flash. > > https://bugzilla.redhat.com/show_bug.cgi?id=360891#c25 > Can other people please test these four scenarios for themselves and > report back here in this list thread? I can reproduce it on my box and laptop. From bpepple at fedoraproject.org Wed Dec 12 20:56:09 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 12 Dec 2007 15:56:09 -0500 Subject: Links to some new proposals for FESCo (was: Plan for tomorrows (20071213) FESCO meeting) In-Reply-To: <1197481644.506.4.camel@nixon> References: <1197481644.506.4.camel@nixon> Message-ID: <1197492969.506.12.camel@nixon> On Wed, 2007-12-12 at 12:47 -0500, Brian Pepple wrote: > > /topic Status Update: FESCo Proposal Template - f13 Jesse has written up a template which can be found here: http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal > You want something to be discussed? Jesse also has this proposal ready to be look at: http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal 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 jkeating at redhat.com Wed Dec 12 21:09:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 16:09:48 -0500 Subject: Links to some new proposals for FESCo (was: Plan for tomorrows (20071213) FESCO meeting) In-Reply-To: <1197492969.506.12.camel@nixon> References: <1197481644.506.4.camel@nixon> <1197492969.506.12.camel@nixon> Message-ID: <20071212160948.5afe06fd@redhat.com> On Wed, 12 Dec 2007 15:56:09 -0500 Brian Pepple wrote: > > /topic Status Update: FESCo Proposal Template - f13 > > Jesse has written up a template which can be found here: > http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal Heh, that should be: http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft -- 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 tibbs at math.uh.edu Wed Dec 12 21:11:05 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 15:11:05 -0600 Subject: Links to some new proposals for FESCo (was: Plan for tomorrows (20071213) FESCO meeting) In-Reply-To: <1197492969.506.12.camel@nixon> References: <1197481644.506.4.camel@nixon> <1197492969.506.12.camel@nixon> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> Jesse has written up a template which can be found here: BP> http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal I think that's http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft which I should try to use for the "replace @base and @core with a truly minimal install" proposal that I need to write up. - J< From Matt_Domsch at dell.com Wed Dec 12 21:40:10 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 12 Dec 2007 15:40:10 -0600 Subject: GPG Keysigning at FUDCon Message-ID: <20071212214010.GA20896@auslistsprd01.us.dell.com> I'm volunteering to run a GPG keysigning party at the FUDCon in Raleigh in January. Keysignings are good ways to get to meet people face-to-face (with a government-issued photo ID to boot!), and serves to extend the GPG Web of Trust. See http://barcamp.org/FUDConRaleigh2008 for details on how to send me your keys beforehand. hanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bpepple at fedoraproject.org Wed Dec 12 21:43:08 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 12 Dec 2007 16:43:08 -0500 Subject: Links to some new proposals for FESCo (was: Plan for tomorrows (20071213) FESCO meeting) In-Reply-To: References: <1197481644.506.4.camel@nixon> <1197492969.506.12.camel@nixon> Message-ID: <1197495788.506.15.camel@nixon> On Wed, 2007-12-12 at 15:11 -0600, Jason L Tibbitts III wrote: > >>>>> "BP" == Brian Pepple writes: > > BP> Jesse has written up a template which can be found here: > BP> http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal > > I think that's > http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft Yeah, obviously I screwed up on the cut n' paste. Thanks for the catch. /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 kwizart at gmail.com Wed Dec 12 21:47:28 2007 From: kwizart at gmail.com (KH KH) Date: Wed, 12 Dec 2007 22:47:28 +0100 Subject: Argyll color management system integration In-Reply-To: <1197480956.22091.15.camel@rousalka.dyndns.org> References: <1197480956.22091.15.camel@rousalka.dyndns.org> Message-ID: 2007/12/12, Nicolas Mailhot : > Hi all, > > The FLOSS color management scene (calibrating screens for pictures or > video) is very small. In fact there is only one reference application > every other project depends on or compares itself to: Argyll CMS. Argyll > is free, supports many common (commercial and do-it-yourself) color > meters, has been actively developed for more than a decade. It was on > the Fedora package wishlist. > > Unfortunately its main author is not following best release practises > and has chosen to use a non-standard unmaintained make replacement > (jam), with static linking, private copies of common libraries, and all > kinds of things distributions are not fond of. As a result no > first-level distribution shipped Argyll. Despite the fact every color > management HOWTO on the net points to it. > > I started untangling the mess in October but gave up after a frustrating > week. Fortunately I had the good idea to put the result on fedorapeople, > and lately Fr?d?ric Crozat from Mandriva googled it and completed the > work. On hindsight it seems I had stopped just short of the finish line. > http://twinpeaks.dyndns.org/blog/general/2007/12/11/monitor-calibration-epilogue > > Since it'd be a shame to let my packaging work end up in Mandriva only, > I picked up his package, changed back a few bits, added some stuff I had > planned but not done yet, and pushed the result in the review queue: > https://bugzilla.redhat.com/show_bug.cgi?id=421921 > > I'd appreciate if a friendly reviewer looked at the result. > > The following work has been done: > ? link against system libs, not built-in copies > ? build with modular X > ? remove the shell wrapper that was hiding build errors from rpm > ? reorder build logic to fix those errors > ? hal/pam/udev logic so colorimeters do not need root access > > The result is IMHO good enough to be merged. However, since this > software has suffered from a secluded life due to the aforementioned > problems, it would probably be a good idea if more clueful people than > me checked the following points: > > ? go over the build logs, check if the warnings are really harmless and > fix the code if needed (where is the list of people that wanted to do > this kind of work a few months ago?) > http://nim.fedorapeople.org/argyllcms/build.log > I doubt argyllcms was ever built with a modern gcc with all the fancy > options we use and for all the architectures we target > > ? check if I got the hal/pam/udev logic right, push bits upstream if > needed (I didn't find two Fedora packages that did it the same way, all > I can say the way I did it works on my system) > > ? check if upstream didn't mess up licensing as it did the code > > Then we'll have one key app for photographers and video buffs nailed, > and there will only be the matter of pushing fixes upstream. > > Regards, I have submitted some packages that are related to color management.. xcalib - not feature complete but https://bugzilla.redhat.com/show_bug.cgi?id=285351 oyranos - used to managed icc profiles within cinepaint (only for now) https://bugzilla.redhat.com/show_bug.cgi?id=239936 As i've understood, this package do not use lcms but i wonder if it can produce icc profiles... As such, I wonder where to put system icc profiles ? (probably in /usr/share/color/icc but it may need to be added to the filesystem package or a special package for icc/icm profiles...) This question is probably more related to the package i've submitted.. Nicolas (kwizart) > -- > Nicolas Mailhot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From nicolas.mailhot at laposte.net Wed Dec 12 22:02:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Dec 2007 23:02:19 +0100 Subject: Argyll color management system integration In-Reply-To: References: <1197480956.22091.15.camel@rousalka.dyndns.org> Message-ID: <1197496939.23262.18.camel@rousalka.dyndns.org> Le mercredi 12 d?cembre 2007 ? 22:47 +0100, KH KH a ?crit : > I have submitted some packages that are related to color management.. > xcalib - not feature complete but > https://bugzilla.redhat.com/show_bug.cgi?id=285351 > oyranos - used to managed icc profiles within cinepaint (only for now) > https://bugzilla.redhat.com/show_bug.cgi?id=239936 > As I understand it, both of them rely on argyll for icc file creation, so they are indeed closely related. With Little CMS and its derivative lprof I think that's the alpha and omega of Linux color management. Argyll is sufficient for my simple needs, but I guess that if it went in that'll motivate people to review your packages (I dislike the non-GTK widgets the others use) > As such, I wonder where to put system icc > profiles ? (probably in /usr/share/color/icc but it may need to be > added to the filesystem package or a special package for icc/icm > profiles...) IMHO it should as it's as close to a standard dir as we'll get from icc folks. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From laxathom at fedoraproject.org Wed Dec 12 22:23:07 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 12 Dec 2007 23:23:07 +0100 Subject: f8: NFS mount problem in rescue mode In-Reply-To: <20071212170926.GD10894@petra.dvoda.cz> References: <1197453757.7313.144.camel@lesca.home.solinos.it> <1197476610.23359.51.camel@lesca.home.solinos.it> <20071212170926.GD10894@petra.dvoda.cz> Message-ID: <62bc09df0712121423r19c2f817q6a1af6bddf917c9c@mail.gmail.com> 2007/12/12, Karel Zak : > > On Wed, Dec 12, 2007 at 05:23:30PM +0100, Dario Lesca wrote: > > Il giorno mer, 12/12/2007 alle 11.02 +0100, Dario Lesca ha scritto: > > > If I boot Fedora 8 with DVD in rescue mode I can't mount a NFS share. > > > > Please, someone can do this test and tell me if the problem happened > > only to me? > > do you have /sbin/mount.nfs (in rescue mode)? Also, paste your output error Karel > > -- > Karel Zak > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Wed Dec 12 22:27:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 12 Dec 2007 16:27:19 -0600 Subject: SDL pulseaudio workaround hack In-Reply-To: <47603978.8030902@redhat.com> References: <474B7512.3080408@redhat.com> <474D2D2F.5030308@noltec.org> <47603978.8030902@redhat.com> Message-ID: <1197498439.12411.15.camel@localhost> On Wed, 2007-12-12 at 14:41 -0500, Warren Togami wrote: > Christian Nolte wrote: > > > > Please consider putting the workaround in the SDL-Package as not every > > program which uses SDL has a dependency on SDL_mixer. See BUG #343911. > > > > Nobody has pointed out a single SDL package that has sound output that > does not pull in SDL_mixer. We just had a discussion on fedora-games: http://www.redhat.com/archives/fedora-games-list/2007-December/msg00017.html Basically OpenAL has been overlooked in the whole Pulseaudio integration project. (and hell, ALSA integration) It defaults to OSS, and has been since the beginning. Which doesn't work. It also does not work with Pulse's ALSA redirection. SDL works. The consensus was to make OpenAL default to using SDL in F8+. (It also needs to default to ALSA in F7-) A bug was filed, and it seems there is an update in testing: https://bugzilla.redhat.com/show_bug.cgi?id=420991 So basically, anything using OpenAL is going to start needing SDL (but not SDL_mixer) very soon. The list of things needing OpenAL, just looking at my own systems, includes: rss-glx openarena blender quake3 secondlife -------------- 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 floss at lex.hider.name Wed Dec 12 23:21:57 2007 From: floss at lex.hider.name (Lex Hider) Date: Thu, 13 Dec 2007 10:21:57 +1100 Subject: Hal issue with kde4 ? [Fwd: Re: Shall I test KDE4 already ?] Message-ID: <47606D15.1040503@lex.hider.name> With latest kde 4 compiled by hand, there is an issue with the filemanager dolphin, and mounting removable media. According to the kde guys, this is a fedora problem and not a kde problem. See the email message below. Note that the error I now get with latest F8 is: "An error occurred while accessing 'name_of_media', the system said: org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.mount-removable no <-- (action,result)"H -------- Original Message -------- Subject: Re: Shall I test KDE4 already ? Date: Wed, 31 Oct 2007 07:42:07 -0600 From: Aaron J. Seigo Reply-To: kde-core-devel at kde.org To: kde-core-devel at kde.org References: <200710281853.10502.m.koller at surfeu.at> <200710301955.33762.peter.penz at gmx.at> <4727C54F.30402 at lex.hider.name> On Tuesday 30 October 2007, lexual wrote: > Like I said, I'm running under Fedora 7 compiled from svn. > Issue is with mounting usb drives/keys. > The device shows up in left hand Places. > Clicking on it gives the following error: > > An error occurred while accessing 'Volume (vfat)' the system said: > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active > session this is a problem with ConsoleKit / fedora packages / your OS setup, not dolphin. -------------- next part -------------- A non-text attachment was scrubbed... Name: file:///tmp/nsmail-1.tmp Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From floss at lex.hider.name Wed Dec 12 23:40:05 2007 From: floss at lex.hider.name (Lex Hider) Date: Thu, 13 Dec 2007 10:40:05 +1100 Subject: Hal issue with kde 4 ? Message-ID: <47607155.9050406@lex.hider.name> Hi, There is an issue with mounting removable media in kde4's file manager dolphin. According to the kde guys, this is a fedora problem and not a kde one. I'm running latest kde4 compiled from hand, with F8. Note that the error message below now comes up as: "An error occurred while accessing 'name_of_media', the system said: org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.mount-removable no <--(action,result) Lex. -------- Original Message -------- Subject: Re: Shall I test KDE4 already ? Date: Wed, 31 Oct 2007 07:42:07 -0600 From: Aaron J. Seigo Reply-To: kde-core-devel at kde.org To: kde-core-devel at kde.org References: <200710281853.10502.m.koller at surfeu.at> <200710301955.33762.peter.penz at gmx.at> <4727C54F.30402 at lex.hider.name> On Tuesday 30 October 2007, lexual wrote: > Like I said, I'm running under Fedora 7 compiled from svn. > Issue is with mounting usb drives/keys. > The device shows up in left hand Places. > Clicking on it gives the following error: > > An error occurred while accessing 'Volume (vfat)' the system said: > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active > session this is a problem with ConsoleKit / fedora packages / your OS setup, not dolphin. From jon at fedoraunity.org Wed Dec 12 22:59:12 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Wed, 12 Dec 2007 15:59:12 -0700 Subject: Zope/Plone F7+ Message-ID: <20071212155912.5b0ee214@damaestrojr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 12 Dec 2007 14:42:14 -0500 "Thomas J. Baker" wrote: > > Hello, > > What have you been doing for your sites with plone/zope since FC6 is > now EOL'd? I have always had a hard time not pushing updates, I almost pushed Plone 3.0.4 to FC6, but have decided to follow policy on this one. > Do you have unofficial F8 packages anywhere that include a > python-compat or something similar? Yes. I have the full stack needed to run Zope2/Plone for both F7 and F8. I just have compat-python24-setuptools left, which will enable the installation of most any python egg/module/etc (for those with needs outside of the stack I'm willing to maintain.) I'll do this now, as it has needed to be done for some time. The goal is to stick them in RPMFusion. I suppose I should just stick them in Livna for now. They have passed review, I just need to start building. I currently have them in my personal repo, which has a poor upload and I prefer to not host them from there. > > I've had my plone site on a Xen instance of FC6 but F8 Xen is not > running that FC6 instance very well. I'm trying to figure out what to > do next. As indicated below, you have a few options. > > Thanks, > > tjb Some options for Zope/Plone: Run RHEL/Centos 5, EPEL will be updated promptly. I run this for my production sites. Run FC6, rebuilding your own updates from the srpms for EPEL5. Run F7 with the compat stack. Fun F8 with the compat stack, I do this currently. Use the Plone unified installer which includes everything needed, including it's own python. - -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHYGazrRJs5w2Gr1kRAv/UAJwKyefSDaqi62xnkJSsxDqRNg4oZgCdEvfL hlG7jV1XpxQOyRZSH9ZSWtk= =NbIh -----END PGP SIGNATURE----- From kevin.kofler at chello.at Thu Dec 13 00:06:48 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Dec 2007 00:06:48 +0000 (UTC) Subject: Hal issue with kde 4 ? References: <47607155.9050406@lex.hider.name> Message-ID: Lex Hider lex.hider.name> writes: > > An error occurred while accessing 'Volume (vfat)' the system said: > > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active > > session As Aaron J. Seigo correctly said, that one was ConsoleKit-related. What login manager were you using? If it was something other than KDM (with Fedora patches) or GDM, it's not even expected to work, as those are still the only ones with ConsoleKit integration. > Note that the error message below now comes up as: > "An error occurred while accessing 'name_of_media', the system said: > org.freedesktop.Hal.Device.PermissionDeniedByPolicy: > org.freedesktop.hal.storage.mount-removable no <--(action,result) I'm not sure whether this is the same error and HAL uses a different (IMHO less useful for debugging) error message or whether it is a different bug. What this says is that PolicyKit is denying the permission to mount the medium. This is of course broken, but the message doesn't tell us why exactly it's denying that. It might be because it isn't detecting an active session (-> ConsoleKit) or it might be that the policy just doesn't allow it to anyone. In the first case, it's probably a problem with KDM (unless you're using some other login manager which doesn't support ConsoleKit at all), in the second, it's the PolicyKit policies which are screwed up, so we need to know. Can you run this please: ck-list-sessions and tell us the output? That will tell us if there's a valid session running and should help us discerning who's at fault here. Kevin Kofler From floss at lex.hider.name Thu Dec 13 00:41:40 2007 From: floss at lex.hider.name (Lex Hider) Date: Thu, 13 Dec 2007 11:41:40 +1100 Subject: Hal issue with kde 4 ? In-Reply-To: References: <47607155.9050406@lex.hider.name> Message-ID: <47607FC4.60304@lex.hider.name> Kevin Kofler wrote: > Lex Hider lex.hider.name> writes: >> > An error occurred while accessing 'Volume (vfat)' the system said: >> > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active >> > session > > As Aaron J. Seigo correctly said, that one was ConsoleKit-related. What login > manager were you using? If it was something other than KDM (with Fedora > patches) or GDM, it's not even expected to work, as those are still the only > ones with ConsoleKit integration. > GDM, I'll test with kdm and report back. >> Note that the error message below now comes up as: >> "An error occurred while accessing 'name_of_media', the system said: >> org.freedesktop.Hal.Device.PermissionDeniedByPolicy: >> org.freedesktop.hal.storage.mount-removable no <--(action,result) > > I'm not sure whether this is the same error and HAL uses a different (IMHO less > useful for debugging) error message or whether it is a different bug. What this > says is that PolicyKit is denying the permission to mount the medium. This is > of course broken, but the message doesn't tell us why exactly it's denying > that. It might be because it isn't detecting an active session (-> ConsoleKit) > or it might be that the policy just doesn't allow it to anyone. In the first > case, it's probably a problem with KDM (unless you're using some other login > manager which doesn't support ConsoleKit at all), in the second, it's the > PolicyKit policies which are screwed up, so we need to know. > > Can you run this please: > ck-list-sessions > and tell us the output? That will tell us if there's a valid session running > and should help us discerning who's at fault here. Session7: uid = '500' realname = 'Lex Hider' seat = 'Seat1' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2007-12-12T22:50:54Z' Session3: uid = '500' realname = 'Lex Hider' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2007-12-12T10:33:53Z' Session5: uid = '500' realname = 'Lex Hider' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/tty1' remote-host-name = '' is-local = TRUE on-since = '2007-12-12T22:47:56Z' idle-since-hint = '2007-12-12T22:48:35Z' > > Kevin Kofler > From lightsolphoenix at gmail.com Thu Dec 13 00:41:47 2007 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Wed, 12 Dec 2007 19:41:47 -0500 Subject: libflashsupport - Shouldn't this be libflashsupport-pulse or something like that? Message-ID: <47607FCB.6000905@gmail.com> It just seems to me that there is a good chance for conflict if there is another plugin for Flash sound ever added to the repository; technically, any sound extension is providing libflashsupport... Wouldn't it be better to call the package libflashsupport-pulse and have it "Provides: libflashsupport" or something along those lines? From wtogami at redhat.com Thu Dec 13 00:45:15 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Dec 2007 19:45:15 -0500 Subject: libflashsupport - Shouldn't this be libflashsupport-pulse or something like that? In-Reply-To: <47607FCB.6000905@gmail.com> References: <47607FCB.6000905@gmail.com> Message-ID: <4760809B.90301@redhat.com> Kelly Miller wrote: > It just seems to me that there is a good chance for conflict if there is > another plugin for Flash sound ever added to the repository; > technically, any sound extension is providing libflashsupport... > > Wouldn't it be better to call the package libflashsupport-pulse and have > it "Provides: libflashsupport" or something along those lines? > If you want to add other abilities to libflashsupport, implement it as patches for the libflashsupport package itself and we can issue Fedora updates. The only criteria is to NOT change the current default behavior. You would need to use /etc/sysconfig/libflashsupport or an environment variable or something to select alternative behaviors. I suggested to Adobe to create a centralized upstream project around libflashsupport in order to prevent splintering of many forks in distributions, but they seem to have given up on the idea. (Last asked them 2-3 months ago, no response.) Warren Togami wtogami at redhat.com From floss at lex.hider.name Thu Dec 13 00:57:45 2007 From: floss at lex.hider.name (Lex Hider) Date: Thu, 13 Dec 2007 11:57:45 +1100 Subject: Hal issue with kde 4 ? In-Reply-To: <47607FC4.60304@lex.hider.name> References: <47607155.9050406@lex.hider.name> <47607FC4.60304@lex.hider.name> Message-ID: <47608389.6090809@lex.hider.name> Lex Hider wrote: > Kevin Kofler wrote: >> Lex Hider lex.hider.name> writes: >>> > An error occurred while accessing 'Volume (vfat)' the system said: >>> > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in >>> active >>> > session >> >> As Aaron J. Seigo correctly said, that one was ConsoleKit-related. >> What login manager were you using? If it was something other than KDM >> (with Fedora patches) or GDM, it's not even expected to work, as those >> are still the only ones with ConsoleKit integration. >> > > GDM, I'll test with kdm and report back. > Problem only occurs with gdm. No problem when using kdm. >>> Note that the error message below now comes up as: >>> "An error occurred while accessing 'name_of_media', the system said: >>> org.freedesktop.Hal.Device.PermissionDeniedByPolicy: >>> org.freedesktop.hal.storage.mount-removable no <--(action,result) >> >> I'm not sure whether this is the same error and HAL uses a different >> (IMHO less useful for debugging) error message or whether it is a >> different bug. What this says is that PolicyKit is denying the >> permission to mount the medium. This is of course broken, but the >> message doesn't tell us why exactly it's denying that. It might be >> because it isn't detecting an active session (-> ConsoleKit) or it >> might be that the policy just doesn't allow it to anyone. In the first >> case, it's probably a problem with KDM (unless you're using some other >> login manager which doesn't support ConsoleKit at all), in the second, >> it's the PolicyKit policies which are screwed up, so we need to know. >> >> Can you run this please: >> ck-list-sessions >> and tell us the output? That will tell us if there's a valid session >> running and should help us discerning who's at fault here. > > Session7: > uid = '500' > realname = 'Lex Hider' > seat = 'Seat1' > session-type = '' > active = FALSE > x11-display = ':0' > x11-display-device = '/dev/tty7' > display-device = '' > remote-host-name = '' > is-local = TRUE > on-since = '2007-12-12T22:50:54Z' > Session3: > uid = '500' > realname = 'Lex Hider' > seat = 'Seat1' > session-type = '' > active = TRUE > x11-display = ':0' > x11-display-device = '/dev/tty7' > display-device = '' > remote-host-name = '' > is-local = TRUE > on-since = '2007-12-12T10:33:53Z' > Session5: > uid = '500' > realname = 'Lex Hider' > seat = 'Seat1' > session-type = '' > active = FALSE > x11-display = '' > x11-display-device = '' > display-device = '/dev/tty1' > remote-host-name = '' > is-local = TRUE > on-since = '2007-12-12T22:47:56Z' > idle-since-hint = '2007-12-12T22:48:35Z' > >> >> Kevin Kofler >> > From christoph.wickert at nurfuerspam.de Thu Dec 13 01:46:11 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 13 Dec 2007 02:46:11 +0100 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <20071212182751.GA3360@ryvius.greysector.net> References: <1197419469.3785.13.camel@wicktop.localdomain> <20071212182751.GA3360@ryvius.greysector.net> Message-ID: <1197510371.3349.28.camel@wicktop.localdomain> Am Mittwoch, den 12.12.2007, 19:27 +0100 schrieb Dominik 'Rathann' Mierzejewski: > On Wednesday, 12 December 2007 at 01:31, Christoph Wickert wrote: > > sorry that I bring up this topic once again: why does yum install i386 > > packages on a x86_64 system during groupinstall? > > Doesn't > # yum install yum-basearchonly > help in this case? Unfortunately not! # rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n \*xf\* | grep i386 libXxf86vm-1.0.1-4.fc8-i386 libXxf86misc-1.0.1-4.fc8-i386 So obviously I have no i386 Xfce packages installed. Now I'd like to test the Xfce 4.4.2 packages Kevin and me rolled out yesterday: # yum install yum-basearchonly ... Installed: yum-basearchonly.noarch 0:1.1.8-1.fc8 Complete! # yum --enablerepo=updates-testing groupupdate XFCE Loading "basearchonly" plugin updates-testing 100% |=========================| 2.3 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 fedora-debuginfo 100% |=========================| 2.1 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 adobe-linux-i386 100% |=========================| 951 B 00:00 updates 100% |=========================| 2.3 kB 00:00 primary.sqlite.bz2 100% |=========================| 1.1 MB 00:01 Excluding Packages in global exclude list Finished Setting up Group Process comps-f8.xml 100% |=========================| 1.2 MB 00:01 Package xfce4-session - 4.4.1-2.fc8.x86_64 already installed and latest version Package xfdesktop - 4.4.1-3.fc8.x86_64 already installed and latest version Package Thunar - 0.8.0-3.fc8.x86_64 already installed and latest version Package xfce-utils - 4.4.1-3.fc8.x86_64 already installed and latest version Package libxfce4util - 4.4.1-3.fc8.x86_64 already installed and latest version Package libxfce4mcs - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfce4-session-engines - 4.4.1-2.fc8.x86_64 already installed and latest version Package libxfcegui4 - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfce4-panel - 4.4.1-4.fc8.x86_64 already installed and latest version Package xfwm4 - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfce4-mixer - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfce4-mailwatch-plugin - 1.0.1-7.fc8.x86_64 already installed and latest version Package xfce4-icon-theme - 4.4.1-3.fc8.noarch already installed and latest version Package xfce-mcs-manager - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfce4-appfinder - 4.4.1-2.fc8.x86_64 already installed and latest version Package xfce-mcs-plugins - 4.4.1-3.fc8.x86_64 already installed and latest version Package xfprint - 4.4.1-2.fc8.x86_64 already installed and latest version Package mousepad - 0.2.12-3.fc8.x86_64 already installed and latest version Resolving Dependencies --> Running transaction check ---> Package libxfce4mcs.i386 0:4.4.1-3.fc8 set to be updated ---> Package libxfcegui4.i386 0:4.4.1-3.fc8 set to be updated ---> Package xfce4-session.i386 0:4.4.1-2.fc8 set to be updated ---> Package xfce4-panel.i386 0:4.4.1-4.fc8 set to be updated ---> Package Thunar.i386 0:0.8.0-3.fc8 set to be updated --> Processing Dependency: libexo-hal-0.3.so.0 for package: Thunar --> Processing Dependency: libexo-0.3.so.0 for package: Thunar ---> Package libxfce4util.i386 0:4.4.1-3.fc8 set to be updated ---> Package xfprint.i386 0:4.4.1-2.fc8 set to be updated --> Running transaction check ---> Package exo.i386 0:0.3.2-3.fc8 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: Thunar i386 0.8.0-3.fc8 fedora 5.2 M xfce4-session i386 4.4.1-2.fc8 fedora 509 k xfprint i386 4.4.1-2.fc8 fedora 584 k Installing for dependencies: exo i386 0.3.2-3.fc8 fedora 679 k libxfce4mcs i386 4.4.1-3.fc8 fedora 46 k libxfce4util i386 4.4.1-3.fc8 fedora 73 k libxfcegui4 i386 4.4.1-3.fc8 fedora 277 k xfce4-panel i386 4.4.1-4.fc8 fedora 530 k Transaction Summary ============================================================================= Install 8 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 7.9 M Is this ok [y/N]: n Exiting on user Command Complete! The whole group process seems really broken to me. Chris From skvidal at fedoraproject.org Thu Dec 13 01:52:43 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Dec 2007 20:52:43 -0500 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197510371.3349.28.camel@wicktop.localdomain> References: <1197419469.3785.13.camel@wicktop.localdomain> <20071212182751.GA3360@ryvius.greysector.net> <1197510371.3349.28.camel@wicktop.localdomain> Message-ID: <1197510763.8989.25.camel@cutter> On Thu, 2007-12-13 at 02:46 +0100, Christoph Wickert wrote: > Am Mittwoch, den 12.12.2007, 19:27 +0100 schrieb Dominik 'Rathann' > Mierzejewski: > > On Wednesday, 12 December 2007 at 01:31, Christoph Wickert wrote: > > > sorry that I bring up this topic once again: why does yum install i386 > > > packages on a x86_64 system during groupinstall? > > > > Doesn't > > # yum install yum-basearchonly > > help in this case? > > Unfortunately not! > > # rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n \*xf\* | grep i386 > libXxf86vm-1.0.1-4.fc8-i386 > libXxf86misc-1.0.1-4.fc8-i386 > > So obviously I have no i386 Xfce packages installed. Now I'd like to > test the Xfce 4.4.2 packages Kevin and me rolled out yesterday: > > # yum install yum-basearchonly > ... > Installed: yum-basearchonly.noarch 0:1.1.8-1.fc8 > Complete! > > # yum --enablerepo=updates-testing groupupdate XFCE > Loading "basearchonly" plugin > updates-testing 100% |=========================| 2.3 kB 00:00 > livna 100% |=========================| 2.1 kB 00:00 > fedora-debuginfo 100% |=========================| 2.1 kB 00:00 > fedora 100% |=========================| 2.1 kB 00:00 > adobe-linux-i386 100% |=========================| 951 B 00:00 > updates 100% |=========================| 2.3 kB 00:00 > primary.sqlite.bz2 100% |=========================| 1.1 MB 00:01 > Excluding Packages in global exclude list > Finished > Setting up Group Process > comps-f8.xml 100% |=========================| 1.2 MB 00:01 > Package xfce4-session - 4.4.1-2.fc8.x86_64 already installed and latest version > Package xfdesktop - 4.4.1-3.fc8.x86_64 already installed and latest version > Package Thunar - 0.8.0-3.fc8.x86_64 already installed and latest version > Package xfce-utils - 4.4.1-3.fc8.x86_64 already installed and latest version > Package libxfce4util - 4.4.1-3.fc8.x86_64 already installed and latest version > Package libxfce4mcs - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfce4-session-engines - 4.4.1-2.fc8.x86_64 already installed and latest version > Package libxfcegui4 - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfce4-panel - 4.4.1-4.fc8.x86_64 already installed and latest version > Package xfwm4 - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfce4-mixer - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfce4-mailwatch-plugin - 1.0.1-7.fc8.x86_64 already installed and latest version > Package xfce4-icon-theme - 4.4.1-3.fc8.noarch already installed and latest version > Package xfce-mcs-manager - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfce4-appfinder - 4.4.1-2.fc8.x86_64 already installed and latest version > Package xfce-mcs-plugins - 4.4.1-3.fc8.x86_64 already installed and latest version > Package xfprint - 4.4.1-2.fc8.x86_64 already installed and latest version > Package mousepad - 0.2.12-3.fc8.x86_64 already installed and latest version > Resolving Dependencies > --> Running transaction check > ---> Package libxfce4mcs.i386 0:4.4.1-3.fc8 set to be updated > ---> Package libxfcegui4.i386 0:4.4.1-3.fc8 set to be updated > ---> Package xfce4-session.i386 0:4.4.1-2.fc8 set to be updated > ---> Package xfce4-panel.i386 0:4.4.1-4.fc8 set to be updated > ---> Package Thunar.i386 0:0.8.0-3.fc8 set to be updated > --> Processing Dependency: libexo-hal-0.3.so.0 for package: Thunar > --> Processing Dependency: libexo-0.3.so.0 for package: Thunar > ---> Package libxfce4util.i386 0:4.4.1-3.fc8 set to be updated > ---> Package xfprint.i386 0:4.4.1-2.fc8 set to be updated > --> Running transaction check > ---> Package exo.i386 0:0.3.2-3.fc8 set to be updated > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > Thunar i386 0.8.0-3.fc8 fedora 5.2 M > xfce4-session i386 4.4.1-2.fc8 fedora 509 k > xfprint i386 4.4.1-2.fc8 fedora 584 k > Installing for dependencies: > exo i386 0.3.2-3.fc8 fedora 679 k > libxfce4mcs i386 4.4.1-3.fc8 fedora 46 k > libxfce4util i386 4.4.1-3.fc8 fedora 73 k > libxfcegui4 i386 4.4.1-3.fc8 fedora 277 k > xfce4-panel i386 4.4.1-4.fc8 fedora 530 k > > Transaction Summary > ============================================================================= > Install 8 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > > Total download size: 7.9 M > Is this ok [y/N]: n > Exiting on user Command > Complete! > > The whole group process seems really broken to me. yum list installed \*.i386 just curious what you do have installed. groupcommands increase the weirdness since they offer no arch specification at all. -sv From christoph.wickert at nurfuerspam.de Thu Dec 13 02:55:58 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 13 Dec 2007 03:55:58 +0100 Subject: yum, x86_64 and i386: the never ending story In-Reply-To: <1197510763.8989.25.camel@cutter> References: <1197419469.3785.13.camel@wicktop.localdomain> <20071212182751.GA3360@ryvius.greysector.net> <1197510371.3349.28.camel@wicktop.localdomain> <1197510763.8989.25.camel@cutter> Message-ID: <1197514559.3349.36.camel@wicktop.localdomain> Am Mittwoch, den 12.12.2007, 20:52 -0500 schrieb seth vidal: > On Thu, 2007-12-13 at 02:46 +0100, Christoph Wickert wrote: > > Am Mittwoch, den 12.12.2007, 19:27 +0100 schrieb Dominik 'Rathann' > > Mierzejewski: > > > On Wednesday, 12 December 2007 at 01:31, Christoph Wickert wrote: > > > > sorry that I bring up this topic once again: why does yum install i386 > > > > packages on a x86_64 system during groupinstall? > > > > > > Doesn't > > > # yum install yum-basearchonly > > > help in this case? > > > > Unfortunately not! > > > > # rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n \*xf\* | grep i386 > > libXxf86vm-1.0.1-4.fc8-i386 > > libXxf86misc-1.0.1-4.fc8-i386 > > > > So obviously I have no i386 Xfce packages installed. Now I'd like to > > test the Xfce 4.4.2 packages Kevin and me rolled out yesterday: > > > > # yum install yum-basearchonly > > ... > > Installed: yum-basearchonly.noarch 0:1.1.8-1.fc8 > > Complete! > > > > # yum --enablerepo=updates-testing groupupdate XFCE > > Loading "basearchonly" plugin > > updates-testing 100% |=========================| 2.3 kB 00:00 > > livna 100% |=========================| 2.1 kB 00:00 > > fedora-debuginfo 100% |=========================| 2.1 kB 00:00 > > fedora 100% |=========================| 2.1 kB 00:00 > > adobe-linux-i386 100% |=========================| 951 B 00:00 > > updates 100% |=========================| 2.3 kB 00:00 > > primary.sqlite.bz2 100% |=========================| 1.1 MB 00:01 > > Excluding Packages in global exclude list > > Finished > > Setting up Group Process > > comps-f8.xml 100% |=========================| 1.2 MB 00:01 > > Package xfce4-session - 4.4.1-2.fc8.x86_64 already installed and latest version > > Package xfdesktop - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package Thunar - 0.8.0-3.fc8.x86_64 already installed and latest version > > Package xfce-utils - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package libxfce4util - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package libxfce4mcs - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfce4-session-engines - 4.4.1-2.fc8.x86_64 already installed and latest version > > Package libxfcegui4 - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfce4-panel - 4.4.1-4.fc8.x86_64 already installed and latest version > > Package xfwm4 - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfce4-mixer - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfce4-mailwatch-plugin - 1.0.1-7.fc8.x86_64 already installed and latest version > > Package xfce4-icon-theme - 4.4.1-3.fc8.noarch already installed and latest version > > Package xfce-mcs-manager - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfce4-appfinder - 4.4.1-2.fc8.x86_64 already installed and latest version > > Package xfce-mcs-plugins - 4.4.1-3.fc8.x86_64 already installed and latest version > > Package xfprint - 4.4.1-2.fc8.x86_64 already installed and latest version > > Package mousepad - 0.2.12-3.fc8.x86_64 already installed and latest version > > Resolving Dependencies > > --> Running transaction check > > ---> Package libxfce4mcs.i386 0:4.4.1-3.fc8 set to be updated > > ---> Package libxfcegui4.i386 0:4.4.1-3.fc8 set to be updated > > ---> Package xfce4-session.i386 0:4.4.1-2.fc8 set to be updated > > ---> Package xfce4-panel.i386 0:4.4.1-4.fc8 set to be updated > > ---> Package Thunar.i386 0:0.8.0-3.fc8 set to be updated > > --> Processing Dependency: libexo-hal-0.3.so.0 for package: Thunar > > --> Processing Dependency: libexo-0.3.so.0 for package: Thunar > > ---> Package libxfce4util.i386 0:4.4.1-3.fc8 set to be updated > > ---> Package xfprint.i386 0:4.4.1-2.fc8 set to be updated > > --> Running transaction check > > ---> Package exo.i386 0:0.3.2-3.fc8 set to be updated > > --> Finished Dependency Resolution > > > > Dependencies Resolved > > > > ============================================================================= > > Package Arch Version Repository Size > > ============================================================================= > > Installing: > > Thunar i386 0.8.0-3.fc8 fedora 5.2 M > > xfce4-session i386 4.4.1-2.fc8 fedora 509 k > > xfprint i386 4.4.1-2.fc8 fedora 584 k > > Installing for dependencies: > > exo i386 0.3.2-3.fc8 fedora 679 k > > libxfce4mcs i386 4.4.1-3.fc8 fedora 46 k > > libxfce4util i386 4.4.1-3.fc8 fedora 73 k > > libxfcegui4 i386 4.4.1-3.fc8 fedora 277 k > > xfce4-panel i386 4.4.1-4.fc8 fedora 530 k > > > > Transaction Summary > > ============================================================================= > > Install 8 Package(s) > > Update 0 Package(s) > > Remove 0 Package(s) > > > > Total download size: 7.9 M > > Is this ok [y/N]: n > > Exiting on user Command > > Complete! > > > > The whole group process seems really broken to me. > > yum list installed \*.i386 > > just curious what you do have installed. No problem: # yum list installed \*.i386 Loading "basearchonly" plugin Excluding Packages in global exclude list Finished Installed Packages MFC5440CNlpr.i386 1.0.2-1 installed alsa-lib.i386 1.0.15-1.fc8 installed atk.i386 1.20.0-1.fc8 installed brmfcfaxcups.i386 1.0.0-1 installed brmfcfaxlpd.i386 1.0.0-1 installed brscan2.i386 0.2.3-0 installed cairo.i386 1.4.12-1.fc8 installed compat-libstdc++-296.i386 2.96-139 installed compat-libstdc++-33.i386 3.2.3-62 installed cups-libs.i386 1:1.3.4-4.fc8 installed cupswrapperMFC5440CN.i386 1.0.0-1 installed dbus-glib.i386 0.73-4.fc8 installed dbus-libs.i386 1.1.2-7.fc8 installed device-mapper-libs.i386 1.02.22-1.fc8 installed e2fsprogs-libs.i386 1.40.2-11.fc8 installed expat.i386 2.0.1-2 installed flash-plugin.i386 9.0.115.0-release installed fontconfig.i386 2.4.2-5.fc8 installed freetype.i386 2.3.5-3.fc8 installed glib2.i386 2.14.4-1.fc8 installed gnutls.i386 1.6.3-2.fc8 installed gtk-nodoka-engine.i386 0.6-5.fc8 installed gtk2.i386 2.12.1-5.fc8 installed gtk2-engines.i386 2.12.2-1.fc8 installed keyutils-libs.i386 1.2-2.fc6 installed krb5-libs.i386 1.6.2-9.fc8 installed lcms.i386 1.17-2.fc8 installed libICE.i386 1.0.4-2.fc8 installed libSM.i386 1.0.2-4.fc8 installed libX11.i386 1.1.3-4.fc8 installed libXau.i386 1.0.3-3.fc8 installed libXaw.i386 1.0.4-1.fc8 installed libXcursor.i386 1.1.9-1.fc8 installed libXdamage.i386 1.1.1-3.fc8 installed libXdmcp.i386 1.0.2-4.fc8 installed libXext.i386 1.0.1-4.fc8 installed libXfixes.i386 4.0.3-2.fc8 installed libXft.i386 2.1.12-3.fc8 installed libXi.i386 1.1.3-1.fc8 installed libXinerama.i386 1.0.2-3.fc8 installed libXmu.i386 1.0.3-3.fc8 installed libXp.i386 1.0.0-8.fc8 installed libXpm.i386 3.5.7-1.fc8 installed libXrandr.i386 1.2.2-1.fc8 installed libXrender.i386 0.9.4-1.fc8 installed libXt.i386 1.0.4-3.fc8 installed libXtst.i386 1.0.3-1.fc8 installed libXxf86vm.i386 1.0.1-4.fc8 installed libcap.i386 1.10-30 installed libdrm.i386 2.3.0-7.fc8 installed libflashsupport.i386 000-0.1.svn20070904 installed libgcc.i386 4.1.2-33 installed libgcrypt.i386 1.2.4-6 installed libgpg-error.i386 1.5-6 installed libjpeg.i386 6b-39.fc8 installed libmng.i386 1.0.9-5.1 installed libpng.i386 2:1.2.22-1.fc8 installed libselinux.i386 2.0.43-1.fc8 installed libsepol.i386 2.0.15-1.fc8 installed libsigc++20.i386 2.0.18-1 installed libtiff.i386 3.8.2-9.fc8 installed libxcb.i386 1.0-4.fc8 installed lightscribe.i386 1.4.136.1-0 installed mesa-libGL.i386 7.0.1-7.fc8 installed mesa-libGLU.i386 7.0.1-7.fc8 installed nas.i386 1.9.1-2.fc8 installed nspluginwrapper.i386 0.9.91.5-12.fc8 installed nspr.i386 4.6.7-3.fc8 installed pango.i386 1.18.3-1.fc8 installed pulseaudio-libs.i386 0.9.7-0.17.svn20071017 installed qt4.i386 4.3.2-4.fc8 installed qt4-x11.i386 4.3.2-4.fc8 installed unace.i386 2.50-2.lvn8 installed zlib.i386 1.2.3-14.fc8 installed None of the above can be removed without removing the i386 packages I really need/want (acrobat, flash, skype, unace, printer/scanner drivers...) it's all the nonfree bits that are not available for x86_64 > > groupcommands increase the weirdness since they offer no arch > specification at all. obviously ;( Christoph From louisg00 at bellsouth.net Thu Dec 13 03:02:11 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Wed, 12 Dec 2007 22:02:11 -0500 Subject: flash-plugin-9.0.115.0 v. nspluginwrapper Message-ID: <1197514931.4641.3.camel@tiger> Just to be clear, nspluginwrapper is useless on i386 systems? This is for x86_64. -Louis From jkeating at redhat.com Thu Dec 13 03:07:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 22:07:02 -0500 Subject: flash-plugin-9.0.115.0 v. nspluginwrapper In-Reply-To: <1197514931.4641.3.camel@tiger> References: <1197514931.4641.3.camel@tiger> Message-ID: <20071212220702.0ed15390@redhat.com> On Wed, 12 Dec 2007 22:02:11 -0500 Louis E Garcia II wrote: > Just to be clear, nspluginwrapper is useless on i386 systems? This is > for x86_64. Not useless at all. The wrapper can act as a buffer between your browser and the plugin. If the plugin crashes, it won't take your browser with 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 loupgaroublond at gmail.com Thu Dec 13 04:05:05 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 12 Dec 2007 23:05:05 -0500 Subject: RFC for Smolt features Message-ID: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> Hey List, After thinking it over, I've decided that having a Privacy Policy for Smolt would be a great experiment as a community process. The rules are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions tend to get made by the people coding, but we are looking for input to see what people want out of Smolt. This way, we know what kind of information gathering is desired, and which kinds are considered too invasive. So I present two RFCs to you guys. The first is the actual Privacy Policy, which can be found here: https://fedorahosted.org/smolt/wiki/PrivacyPolicy It needs legal review, and has the word Fedora in it way too much. I think I might have been a bit to detail oriented, even for a New Englander, but I hope it agrees with everyone. Please remember to direct all your flames to noone at cares.com ;-) Second is a request for a feature that came in today. One of the developers of kerneloops http://kerneloops.org/ wants to integrate kerneloops and smolt. kerneloops.org maintains a similar privacy policy to that of smolts.org, namely, they do not store IP address information. All submissions are anonymous. The integration would try to maintain anonymity as much as possible. Smolt would generate a secondary public UUID that is not mathematically related to the primary UUID. (They should both be random actually.) In technical terms, it would be the join key between a kerneloops.org record and a smolts.org record. In non technical terms, a kerneloops.org user could click on a link 'show me the hardware' and be directed to a smolts.org site with that hardware profile. Just as Smolt is an opt-in process, we would include a second opt-in for kerneloops. The rules would be the same. The only technical concern is that there would have to be some kerneloops related code embedded in firstboot. If Release People don't want to make this a standard package on every install, we'll have to do a bit of funny hacking, but let us know what we can do. So those are the two new RFCs. Cheers, Yaakov From smooge at gmail.com Thu Dec 13 05:24:15 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Dec 2007 22:24:15 -0700 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> Message-ID: <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> On Dec 12, 2007 9:05 PM, Yaakov Nemoy wrote: > Hey List, > > After thinking it over, I've decided that having a Privacy Policy for > Smolt would be a great experiment as a community process. The rules > are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck > avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions > tend to get made by the people coding, but we are looking for input to > see what people want out of Smolt. This way, we know what kind of > information gathering is desired, and which kinds are considered too > invasive. > > So I present two RFCs to you guys. > > The first is the actual Privacy Policy, which can be found here: > https://fedorahosted.org/smolt/wiki/PrivacyPolicy It needs legal > review, and has the word Fedora in it way too much. I think I might > have been a bit to detail oriented, even for a New Englander, but I > hope it agrees with everyone. Please remember to direct all your > flames to noone at cares.com ;-) > Why is it called Smoon and sometimes Smolt.. did I miss the memo? In all actuallity I think having the privacy policy is a good thing. I will try to read through this a bit more when I am more awake. > -- 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 loupgaroublond at gmail.com Thu Dec 13 05:29:05 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 13 Dec 2007 00:29:05 -0500 Subject: RFC for Smolt features In-Reply-To: <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> Message-ID: <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> On Dec 13, 2007 12:24 AM, Stephen John Smoogen wrote: > Why is it called Smoon and sometimes Smolt.. did I miss the memo? In > all actuallity I think having the privacy policy is a good thing. I > will try to read through this a bit more when I am more awake. Smoon is the server. Smolt is the program and the client. You could always claim we named it after you ;) From seg at haxxed.com Thu Dec 13 05:57:04 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 12 Dec 2007 23:57:04 -0600 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> Message-ID: <1197525424.12411.36.camel@localhost> On Wed, 2007-12-12 at 23:05 -0500, Yaakov Nemoy wrote: > After thinking it over, I've decided that having a Privacy Policy for > Smolt would be a great experiment as a community process. The rules > are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck > avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions > tend to get made by the people coding, but we are looking for input to > see what people want out of Smolt. This way, we know what kind of > information gathering is desired, and which kinds are considered too > invasive. I was recently wishing Smolt collected more detailed CPU information. This would basically consist of collecting the flags: line in /proc/cpuinfo. Personally I'd like to know how many machines have cmov, sse and sse2. This would mostly be unique to i386, x86_64 is always going to have them, and PPC doesn't even have a flags: line... Also, the ram/swap/cpu mhz graphs on the web site are IMHO too coarse to be very useful. -------------- 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 braden at endoframe.com Thu Dec 13 07:11:55 2007 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 13 Dec 2007 02:11:55 -0500 Subject: doxygen updates Message-ID: <1197529915.23147.4.camel@hinge.endoframe.net> F-8/doxygen.spec is at 1.5.3-1; though it seems no update corresponding to this was built/pushed. How come? Meanwhile, devel/doxygen.spec is at 1.5.4; any reason that can't be pushed to F-8? -- Braden McDaniel e-mail: Jabber: From andreas.bierfert at lowlatency.de Thu Dec 13 08:27:23 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 13 Dec 2007 09:27:23 +0100 Subject: Outage Notification (Buildsystem) - 2008-12-13 03:45 UTC In-Reply-To: <475FF588.1040105@redhat.com> References: <475FF588.1040105@redhat.com> Message-ID: <20071213092723.235dff39@alkaid.a.lan> On Wed, 12 Dec 2007 08:51:52 -0600 Mike McGrath wrote: > 2008-12-13 04:00 UTC Cool that you tell us 1 year in advance ;) - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d.lesca at solinos.it Thu Dec 13 10:01:18 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 13 Dec 2007 11:01:18 +0100 Subject: f8: NFS mount problem in rescue mode In-Reply-To: <20071212170926.GD10894@petra.dvoda.cz> References: <1197453757.7313.144.camel@lesca.home.solinos.it> <1197476610.23359.51.camel@lesca.home.solinos.it> <20071212170926.GD10894@petra.dvoda.cz> Message-ID: <1197540078.4674.128.camel@lesca.home.solinos.it> Il giorno mer, 12/12/2007 alle 18.09 +0100, Karel Zak ha scritto: > On Wed, Dec 12, 2007 at 05:23:30PM +0100, Dario Lesca wrote: > > Il giorno mer, 12/12/2007 alle 11.02 +0100, Dario Lesca ha scritto: > > > If I boot Fedora 8 with DVD in rescue mode I can't mount a NFS share. > > > > Please, someone can do this test and tell me if the problem happened > > only to me? > > do you have /sbin/mount.nfs (in rescue mode)? > > Karel Karel, all guys NOT have this command in rescue mode. sh-3.2# ls -l /sbin/mount.nfs ls: cannot access /sbin/mount.nfs: No such file or directory Thanks -- Dario Lesca From d.lesca at solinos.it Thu Dec 13 10:54:55 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 13 Dec 2007 11:54:55 +0100 Subject: f8: NFS mount problem in rescue mode In-Reply-To: <1197484036.29325.9.camel@prophead.corp.publichost.com> References: <1197453757.7313.144.camel@lesca.home.solinos.it> <1197484036.29325.9.camel@prophead.corp.publichost.com> Message-ID: <1197543295.4674.147.camel@lesca.home.solinos.it> Il giorno mer, 12/12/2007 alle 10.27 -0800, Rick Stevens ha scritto: > Can you please specify what "not work" means? What error messages are > you seeing? Start PC with Fedora-8-i386-rescuecd start network = yes IpV4 yes, ipv6 = no, Use DHCP Mount existing filesystem = yes then shell is open ... sh-3.2# ip a s dev eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:16:36:db:84:63 brd ff:ff:ff:ff:ff:ff inet 10.39.66.82/20 brd 10.39.79.255 scope global eth0 inet6 fe80::216:36ff:fedb:8463/64 scope link valid_lft forever preferred_lft forever sh-3.2# ip r 10.39.64.0/20 dev eth0 proto kernel scope link src 10.39.66.82 default via 10.39.64.10 dev eth0 sh-3.2# ping 10.39.66.100 PING 10.39.66.100 (10.39.66.100) 56(84) bytes of data. 64 bytes from 10.39.66.100: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 10.39.66.100: icmp_seq=2 ttl=64 time=0.066 ms 64 bytes from 10.39.66.100: icmp_seq=3 ttl=64 time=0.068 ms 64 bytes from 10.39.66.100: icmp_seq=4 ttl=64 time=0.062 ms --- 10.39.66.100 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.062/0.067/0.074/0.009 ms sh-3.2# ssh 10.39.66.100 The authenticity of host '10.39.64.100 (10.39.64.100)' can't be established. RSA key fingerprint is 3x:4x:2x:x7:dx:x1:4d:c8:16:b4:x7:45:97:d4:8d:a6. Are you sure you want to continue connecting (yes/no)? no sh-3.2# mkdir /tmp/f8 sh-3.2# ls -ld /tmp/f8 drwxr-xr-x 2 root root 4096 13 dic 10:33 /tmp/f8 sh-3.2# mount -tnfs 10.39.66.100:/u/f8 /tmp/f8 (wait 20/30 seconds.....) mount: mounting 10.39.66.100:/u/f8 on /tmp/f8 failed If I "tcpdump -i eth0 host 10.39.66.87" on host 10.39.66.100 I see nothing. This is the error: mount in rescue mode not work. (note which mount is a s-link to busybox) For resolve the problem I must run this command: sh-3.2# /mnt/sysimage/sbin/mount.nfs 10.39.66.100:/u/f8 /tmp/f8 -onolock sh-3.2# df /tmp/f8 Filesystem blocchi di 1K Usati Disponib. Uso% Montato su 10.39.66.100:/u/f8 30726144 28232448 907776 97% /tmp/f8 sh-3.2# sed 1q /tmp/f8/RPM-GPG-KEY The following public key can be used to verify RPM packages built and In this way, my nfs is mounted, but is this the right way to do that? > a) the network isn't started Network is started > b) your IP address isn't set properly IP is set properly > or c) the DNS system isn't responding so you're getting "unknown host" errors. I not use DNS in this case, it's not necessary. > - Rick Stevens Thanks Rick! Now I work around my problem (PXE+kickstart setup) to copy the mount.nfs into f8 structure, then use this command for mount my needed fs. Some other suggest? Thanks to all! -- Dario Lesca From rdieter at math.unl.edu Thu Dec 13 13:15:38 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Dec 2007 07:15:38 -0600 Subject: Hal issue with kde 4 ? References: <47607155.9050406@lex.hider.name> Message-ID: Kevin Kofler wrote: > Lex Hider lex.hider.name> writes: >> > An error occurred while accessing 'Volume (vfat)' the system said: >> > org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active >> > session > > As Aaron J. Seigo correctly said, that one was ConsoleKit-related. What > login manager were you using? If it was something other than KDM (with > Fedora patches) fwiw, we've been working on getting kdm/ConsoleKit integration pushed upstream, http://bugs.kde.org/147790 -- Rex From snecklifter at gmail.com Thu Dec 13 15:18:50 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 13 Dec 2007 15:18:50 +0000 Subject: RFC for Smolt features In-Reply-To: <1197525424.12411.36.camel@localhost> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <1197525424.12411.36.camel@localhost> Message-ID: <47614D5A.9040808@gmail.com> Callum Lerwick wrote: > On Wed, 2007-12-12 at 23:05 -0500, Yaakov Nemoy wrote: > >> After thinking it over, I've decided that having a Privacy Policy for >> Smolt would be a great experiment as a community process. The rules >> are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck >> avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions >> tend to get made by the people coding, but we are looking for input to >> see what people want out of Smolt. This way, we know what kind of >> information gathering is desired, and which kinds are considered too >> invasive. >> > > I was recently wishing Smolt collected more detailed CPU information. > This would basically consist of collecting the flags: line > in /proc/cpuinfo. Personally I'd like to know how many machines have > cmov, sse and sse2. This would mostly be unique to i386, x86_64 is > always going to have them, and PPC doesn't even have a flags: line... > > Also, the ram/swap/cpu mhz graphs on the web site are IMHO too coarse to > be very useful. > +1 as this would help in bug reports. Due to the high marketing profile Smolt has had, people are already using their smolt UUID's to augment their bug reports so verbosity at the hardware level would be desirable. I'll leave it to the greater debate as to what should be left out (e.g. MAC address) for security/privacy concerns. I would also love to see the removal of the nag window from Anaconda. I can't remember if this was still the case for F8 but at some point checking the 'Do Not Send Profile' button and attempting to continue would bring up an 'Are You Sure' dialog. Yes, I am sure and please don't nag me about it. The fewer clicks during install the better. Apologies if this is no longer the case however. Other than that, awesome work! Cheers Chris From sandeen at redhat.com Thu Dec 13 15:20:49 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 13 Dec 2007 09:20:49 -0600 Subject: RFC for Smolt features In-Reply-To: <1197525424.12411.36.camel@localhost> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <1197525424.12411.36.camel@localhost> Message-ID: <47614DD1.8060301@redhat.com> Callum Lerwick wrote: > On Wed, 2007-12-12 at 23:05 -0500, Yaakov Nemoy wrote: >> After thinking it over, I've decided that having a Privacy Policy for >> Smolt would be a great experiment as a community process. The rules >> are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck >> avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions >> tend to get made by the people coding, but we are looking for input to >> see what people want out of Smolt. This way, we know what kind of >> information gathering is desired, and which kinds are considered too >> invasive. > > I was recently wishing Smolt collected more detailed CPU information. > This would basically consist of collecting the flags: line > in /proc/cpuinfo. Personally I'd like to know how many machines have > cmov, sse and sse2. This would mostly be unique to i386, x86_64 is > always going to have them, and PPC doesn't even have a flags: line... > > Also, the ram/swap/cpu mhz graphs on the web site are IMHO too coarse to > be very useful. > /me reiterates the request for filesystem information too :) Popular tool you guys have here! ;) -Eric From chasd at silveroaks.com Thu Dec 13 17:03:22 2007 From: chasd at silveroaks.com (chasd) Date: Thu, 13 Dec 2007 11:03:22 -0600 Subject: Argyll color management system integration In-Reply-To: <20071212214353.B49E473310@hormel.redhat.com> References: <20071212214353.B49E473310@hormel.redhat.com> Message-ID: <367FBFC6-47AD-46C0-B98B-186080E20CF3@silveroaks.com> >> I've got a Optix XR instrument which I can test the udev bits with. > > Same as me then, would be good to have testers with other hardware. I have a GretagMacBeth EyeOne. I'll try to find the time to test it, but this time of year that will be difficult for me. Charles Dostale From caillon at redhat.com Thu Dec 13 18:01:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 13 Dec 2007 19:01:22 +0100 Subject: /etc/bash_completion.d Message-ID: <47617372.7010407@redhat.com> % rpm -qf /etc/bash_completion.d rpmlint-0.82-2.fc9 I don't use bash, nor bash-completion. But we have this directory here and packages are starting to drop files in there (notably, PackageKit, and PolicyKit doesn't yet but it should[1]). I'm not sure they should require bash-completion, though. Would it make sense to add this directory to the filesystem package? [1] https://bugzilla.redhat.com/418471 From mclasen at redhat.com Thu Dec 13 18:06:40 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 13 Dec 2007 13:06:40 -0500 Subject: /etc/bash_completion.d In-Reply-To: <47617372.7010407@redhat.com> References: <47617372.7010407@redhat.com> Message-ID: <1197569200.4093.3.camel@localhost.localdomain> On Thu, 2007-12-13 at 19:01 +0100, Christopher Aillon wrote: > % rpm -qf /etc/bash_completion.d > rpmlint-0.82-2.fc9 > > I don't use bash, nor bash-completion. But we have this directory here > and packages are starting to drop files in there (notably, PackageKit, > and PolicyKit doesn't yet but it should[1]). I'm not sure they should > require bash-completion, though. Would it make sense to add this > directory to the filesystem package? Wouldn't bash be a more logical home for it ? From caillon at redhat.com Thu Dec 13 18:10:53 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 13 Dec 2007 19:10:53 +0100 Subject: /etc/bash_completion.d In-Reply-To: <1197569200.4093.3.camel@localhost.localdomain> References: <47617372.7010407@redhat.com> <1197569200.4093.3.camel@localhost.localdomain> Message-ID: <476175AD.6080606@redhat.com> On 12/13/2007 07:06 PM, Matthias Clasen wrote: > On Thu, 2007-12-13 at 19:01 +0100, Christopher Aillon wrote: >> % rpm -qf /etc/bash_completion.d >> rpmlint-0.82-2.fc9 >> >> I don't use bash, nor bash-completion. But we have this directory here >> and packages are starting to drop files in there (notably, PackageKit, >> and PolicyKit doesn't yet but it should[1]). I'm not sure they should >> require bash-completion, though. Would it make sense to add this >> directory to the filesystem package? > > Wouldn't bash be a more logical home for it ? The bash-completion package is what actually provides the functionality for the completion stuff, which I for one don't have installed.... It might still make sense for bash to actually provide this directory, but I am trying to avoid having e.g. PolicyKit require bash-completion (or worse, rpmlint). :-) From Lam at Lam.pl Thu Dec 13 18:20:24 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 13 Dec 2007 19:20:24 +0100 Subject: /etc/bash_completion.d In-Reply-To: <476175AD.6080606@redhat.com> References: <47617372.7010407@redhat.com> <1197569200.4093.3.camel@localhost.localdomain> <476175AD.6080606@redhat.com> Message-ID: <20071213192024.76c4b80a@pensja.lam.pl> Dnia 2007-12-13, o godz. 19:10:53 Christopher Aillon napisa?(a): > The bash-completion package is what actually provides the functionality > for the completion stuff I don't use bash myself, but looking into /etc/bash_completion.d I've noticed that mercurial provides rules (in mercurial.sh) conflicting with the ones from bash-completion (hg). It would be a catastrophy if it required bash-completion, at the same time conflicting with it :) Don't ask me to file a bug, I don't care about bash :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pekkas at netcore.fi Thu Dec 13 18:54:22 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 13 Dec 2007 20:54:22 +0200 (EET) Subject: how is pulseaudio supposed to work? Message-ID: Hi, Fedora 8 was working fine until I reinstalled it (but keeping my home dir intact). How sound doesn't work on many applications. This is likely a pulseaudio issue. Having looked at PulseAudio documentation, I haven't found out "the big picture", i.e., how it is supposed to work. Should there be a daemon running or something? Lot of docs also say "pulseaudio is now default" but I haven't found out where this can be configured i.e. where you can turn it off again [1] if you don't like it or check that everything is configured as required. The error messages from non-working apps give a hint that a daemon should be running or that permissions are somehow off. $ xmms * *** PULSEAUDIO: Unable to connect: Connection refused ** WARNING **: alsa_setup(): Failed to open pcm device (default): Connection refused $ mplayer * .... *** PULSEAUDIO: Unable to connect: Connection refused [AO_ALSA] Playback open error: Connection refused Could not open/initialize audio device -> no sound. Audio: no sound Video: no video .... The solution isn't as simple as starting pulseaudio, though: $ pulseaudio W: alsa-util.c: Cannot find mixer control "Master". E: module-alsa-source.c: Error opening PCM device hw:0: No such file or directory E: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1002_4383_alsa_capture_0"): initialization failed. When you background the process and run xmms again, you get: Message: alsa_setup(): Cannot set mmap'ed mode: Invalid argument. falling back to direct write .. and xmms starts playing but there is no sound. No error message on mplayer, but again there is no sound. [1] this seems to give a lead though: http://www.redhat.com/archives/fedora-test-list/2007-October/msg01325.html -- 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 mszpak at wp.pl Thu Dec 13 19:09:31 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Thu, 13 Dec 2007 20:09:31 +0100 Subject: Package flip-flop in Koji Message-ID: Hi, Yesterday I requested to my package from testing into stable. At 3:53 I've got an email: isomaster-1.2-2.fc8 successfully moved from dist-f8-updates-testing into dist-f8-updates by lmacken At 7:11: isomaster-1.2-2.fc8 successfully moved from dist-f8-updates into dist-f8-updates-testing by lmacken At 7:15: isomaster-1.2-2.fc8 successfully moved from dist-f8-updates-testing into dist-f8-updates by lmacken The same happened with a package for fc7. Similar situation occurred a few times with my other packages in the past. Am I lonely in that? Regards Marcin From lightsolphoenix at gmail.com Thu Dec 13 19:05:45 2007 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Thu, 13 Dec 2007 14:05:45 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: References: Message-ID: <47618289.2090809@gmail.com> The problem you're getting is obviously that something else is claiming the hardware and preventing PulseAudio from taking it. Are you running KDE? If not, is ESound running in the background? Yes, PulseAudio is a daemon. It should be started when the desktop is loaded using the command pulseaudio -D From wwoods at redhat.com Thu Dec 13 19:23:28 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 13 Dec 2007 19:23:28 +0000 Subject: how is pulseaudio supposed to work? In-Reply-To: References: Message-ID: <1197573808.2917.13.camel@metroid.rdu.redhat.com> On Thu, 2007-12-13 at 20:54 +0200, Pekka Savola wrote: > Hi, > > Fedora 8 was working fine until I reinstalled it (but keeping my home > dir intact). How sound doesn't work on many applications. This is > likely a pulseaudio issue. > > Having looked at PulseAudio documentation, I haven't found out "the > big picture", i.e., how it is supposed to work. Should there be a > daemon running or something? Lot of docs also say "pulseaudio is now > default" but I haven't found out where this can be configured i.e. > where you can turn it off again [1] if you don't like it or check that > everything is configured as required. The default setup works like this: 1) /etc/alsa/pulse-default.conf makes pcm.pulse the default ALSA device. - This file is provided by alsa-plugins-pulseaudio. 2) When you log in through gdm/kdm, HAL grants you read/write access to the ALSA device nodes. - This is handled by ConsoleKit, but wdm/xdm don't support it properly. - Strictly speaking this has nothing to do with PulseAudio. 3) When GNOME/KDE/etc start up, they start pulseaudio. - Actually, GNOME starts ESD, but /usr/bin/esd -> esdcompat - esdcompat is provided by pulseaudio-esound-compat - kde-settings-pulseaudio provides /etc/kde/env/pulseaudio.sh 4) Sound-using apps use ALSA/ESD as usual. - It's all actually going through pulseaudio, though. So - if you're not using GNOME or KDE, or if you're logging in through xdm or wdm, or if you're missing some packages, audio might not work right. If you upgraded your system, the easiest thing to do is: # sudo yum groupupdate sound-and-video gnome-desktop kde-desktop (you can remove GNOME or KDE at your discretion) Oh, and if something else has already claimed the ALSA device, pulseaudio won't start properly. So you will want to make sure you get the packages set up right and *then* log out and back in, or reboot. If you really *must* disable PulseAudio, removing or renaming /etc/alsa/pulse-default.conf is the easiest way. Hope that helps, -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 jkeating at redhat.com Thu Dec 13 19:26:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Dec 2007 14:26:01 -0500 Subject: Package flip-flop in Koji In-Reply-To: References: Message-ID: <20071213142601.168494b0@redhat.com> On Thu, 13 Dec 2007 20:09:31 +0100 Marcin Zaj?czkowski wrote: > Am I lonely in that? No, we're having push issues. Working through 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 fedora at camperquake.de Thu Dec 13 19:29:02 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 13 Dec 2007 20:29:02 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197573808.2917.13.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: <20071213202902.5698898e@lain.camperquake.de> Hi. On Thu, 13 Dec 2007 19:23:28 +0000, Will Woods wrote > 4) Sound-using apps use ALSA/ESD as usual. > - It's all actually going through pulseaudio, though. Wait, wait. Since pulseaudio does not, actually, talk to the hardware, applications using ALSA will be rerouted through pulseaudio, which in turn talks to ALSA to produce sound, is that right? From Lam at Lam.pl Thu Dec 13 19:36:02 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 13 Dec 2007 20:36:02 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071213202902.5698898e@lain.camperquake.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> Message-ID: <20071213203602.723472d2@pensja.lam.pl> Dnia 2007-12-13, o godz. 20:29:02 Ralf Ertzinger napisa?(a): > Wait, wait. Since pulseaudio does not, actually, talk to the hardware, > applications using ALSA will be rerouted through pulseaudio, which in turn > talks to ALSA to produce sound, is that right? Bingo! Lam -------------- 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 Dec 13 19:34:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Dec 2007 12:34:16 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071213202902.5698898e@lain.camperquake.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> Message-ID: <1197574456.28242.0.camel@localhost6.localdomain6> On Thu, 2007-12-13 at 20:29 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 13 Dec 2007 19:23:28 +0000, Will Woods wrote > > > 4) Sound-using apps use ALSA/ESD as usual. > > - It's all actually going through pulseaudio, though. > > Wait, wait. Since pulseaudio does not, actually, talk to the hardware, > applications using ALSA will be rerouted through pulseaudio, which in turn > talks to ALSA to produce sound, is that right? Sounds like pretty standard wrapping technique, if it is. -- Richi Plana From mszpak at wp.pl Thu Dec 13 19:38:56 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Thu, 13 Dec 2007 20:38:56 +0100 Subject: Reminder from Koji after testing phase Message-ID: Hi, There are to suggested to keep package in the updates-testing repository for at least one week. A few times I completely forgot about my packages and they stick there. I think it would be nice to have an ability (a checkbox in "New update" form) to set a reminder which would be send after 7 days (or as an option after specified number of days). What do you think about that? Regards Marcin From pekkas at netcore.fi Thu Dec 13 19:42:29 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 13 Dec 2007 21:42:29 +0200 (EET) Subject: how is pulseaudio supposed to work? In-Reply-To: <1197573808.2917.13.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: I guess I'm having a couple of problems.. On Thu, 13 Dec 2007, Will Woods wrote: > 1) /etc/alsa/pulse-default.conf makes pcm.pulse the default ALSA device. > - This file is provided by alsa-plugins-pulseaudio. This is OK. > 2) When you log in through gdm/kdm, HAL grants you read/write access to > the ALSA device nodes. > - This is handled by ConsoleKit, but wdm/xdm don't support it properly. > - Strictly speaking this has nothing to do with PulseAudio. I'm using gdm (default config), but /dev/dsp, /dev/audio and don't give me perms, I guess this is a problem: crw-rw----+ 1 root root 14, 3 2007-12-12 20:14 /dev/dsp > 3) When GNOME/KDE/etc start up, they start pulseaudio. > - Actually, GNOME starts ESD, but /usr/bin/esd -> esdcompat > - esdcompat is provided by pulseaudio-esound-compat > - kde-settings-pulseaudio provides /etc/kde/env/pulseaudio.sh Right -- I''m using XFCE so I think I'm hosed. I guess in the xfce rpms should start up something like this in their init scripts (but don't). I wonder if there could have been some Conflicts: or other magic in the RPMs that would prevent making pulseaudio default if the user has a setup which is known not to work. -- 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 denis at poolshark.org Thu Dec 13 19:51:42 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 13 Dec 2007 20:51:42 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197574456.28242.0.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> Message-ID: <47618D4E.3080107@poolshark.org> Richi Plana wrote: > On Thu, 2007-12-13 at 20:29 +0100, Ralf Ertzinger wrote: >> Hi. >> >> On Thu, 13 Dec 2007 19:23:28 +0000, Will Woods wrote >> >>> 4) Sound-using apps use ALSA/ESD as usual. >>> - It's all actually going through pulseaudio, though. >> Wait, wait. Since pulseaudio does not, actually, talk to the hardware, >> applications using ALSA will be rerouted through pulseaudio, which in turn >> talks to ALSA to produce sound, is that right? > > Sounds like pretty standard wrapping technique, if it is. How much extra latency are we getting from this ? I've noticed the extra lag in some of our games. From Matt_Domsch at dell.com Thu Dec 13 19:59:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 13 Dec 2007 13:59:45 -0600 Subject: Reminder from Koji after testing phase In-Reply-To: References: Message-ID: <20071213195945.GB5138@auslistsprd01.us.dell.com> On Thu, Dec 13, 2007 at 08:38:56PM +0100, Marcin Zaj?czkowski wrote: > Hi, > > > There are to suggested to keep package in the updates-testing repository > for at least one week. A few times I completely forgot about my packages > and they stick there. > I think it would be nice to have an ability (a checkbox in "New update" > form) to set a reminder which would be send after 7 days (or as an > option after specified number of days). bodhi sends such emails after ~2 weeks, at least I've received them. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From wwoods at redhat.com Thu Dec 13 20:01:08 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 13 Dec 2007 15:01:08 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: <1197576068.10057.6.camel@metroid.rdu.redhat.com> On Thu, 2007-12-13 at 21:42 +0200, Pekka Savola wrote: > I'm using gdm (default config), but /dev/dsp, /dev/audio and don't > give me perms, I guess this is a problem: > > crw-rw----+ 1 root root 14, 3 2007-12-12 20:14 /dev/dsp 1) /dev/dsp is for the deprecated OSS interface. The ALSA stuff lives in /dev/snd/. 2) the '+' indicates that there are ACLs on the file. Try: $ getfacl /dev/dsp and you should see something like this: getfacl: Removing leading '/' from absolute path names # file: dev/dsp # owner: root # group: root user::rw- user:gdm:rw- user:wwoods:rw- group::rw- mask::rw- other::--- Notice that my user (wwoods) has rw access, so that's OK. > > 3) When GNOME/KDE/etc start up, they start pulseaudio. > > - Actually, GNOME starts ESD, but /usr/bin/esd -> esdcompat > > - esdcompat is provided by pulseaudio-esound-compat > > - kde-settings-pulseaudio provides /etc/kde/env/pulseaudio.sh > > Right -- I''m using XFCE so I think I'm hosed. Not really - you just have to start pulseaudio yourself, in one of the various startup scripts. > I guess in the xfce rpms should start up something like this in their > init scripts (but don't). Yeah - same for fluxbox and other such windowmanagers. > I wonder if there could have been some Conflicts: or other magic in > the RPMs that would prevent making pulseaudio default if the user has > a setup which is known not to work. Fixing it in the packaging system seems like the wrong way to approach it. It'd be best to fix the ALSA config so pulse is only the default *when it's running*. -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 Lam at Lam.pl Thu Dec 13 20:02:09 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 13 Dec 2007 21:02:09 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: <20071213210209.651bd6b5@pensja.lam.pl> Dnia 2007-12-13, o godz. 21:42:29 Pekka Savola napisa?(a): > I'm using gdm (default config), but /dev/dsp, /dev/audio and don't > give me perms, I guess this is a problem: > > crw-rw----+ 1 root root 14, 3 2007-12-12 20:14 /dev/dsp getfacl /dev/dsp /dev/snd/controlC* and so on And HAL is resposible for the magic here. Are you sure you're not stuck with a broken pilot-link package? :) Lam -------------- 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 camperquake.de Thu Dec 13 20:04:25 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 13 Dec 2007 21:04:25 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197574456.28242.0.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> Message-ID: <20071213210425.626dd1a0@lain.camperquake.de> Hi. On Thu, 13 Dec 2007 12:34:16 -0700, Richi Plana wrote > Sounds like pretty standard wrapping technique, if it is. And what exactly do we gain from all this shuffling around? From myfedora at richip.dhs.org Thu Dec 13 20:05:14 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Dec 2007 13:05:14 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <47618D4E.3080107@poolshark.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> Message-ID: <1197576314.28623.1.camel@localhost6.localdomain6> On Thu, 2007-12-13 at 20:51 +0100, Denis Leroy wrote: > Richi Plana wrote: > > On Thu, 2007-12-13 at 20:29 +0100, Ralf Ertzinger wrote: > >> Hi. > >> > >> On Thu, 13 Dec 2007 19:23:28 +0000, Will Woods wrote > >> > >>> 4) Sound-using apps use ALSA/ESD as usual. > >>> - It's all actually going through pulseaudio, though. > >> Wait, wait. Since pulseaudio does not, actually, talk to the hardware, > >> applications using ALSA will be rerouted through pulseaudio, which in turn > >> talks to ALSA to produce sound, is that right? > > > > Sounds like pretty standard wrapping technique, if it is. > > How much extra latency are we getting from this ? I've noticed the extra > lag in some of our games. For Lennart, I presume. Additionally, is there a way to get real-time (or even close to RT) support either via PA API or over ALSA API? -- Richi Plana From drago01 at gmail.com Thu Dec 13 20:07:04 2007 From: drago01 at gmail.com (drago01) Date: Thu, 13 Dec 2007 21:07:04 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071213210425.626dd1a0@lain.camperquake.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <20071213210425.626dd1a0@lain.camperquake.de> Message-ID: On Dec 13, 2007 9:04 PM, Ralf Ertzinger wrote: > Hi. > > On Thu, 13 Dec 2007 12:34:16 -0700, Richi Plana wrote > > > Sounds like pretty standard wrapping technique, if it is. > > And what exactly do we gain from all this shuffling around? * Per application volumes * Networked audio * Audio hotplug * Move sound streams between devices * Output same stream to multiple devices .... From myfedora at richip.dhs.org Thu Dec 13 20:09:30 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Dec 2007 13:09:30 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071213210425.626dd1a0@lain.camperquake.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <20071213210425.626dd1a0@lain.camperquake.de> Message-ID: <1197576570.28623.5.camel@localhost6.localdomain6> On Thu, 2007-12-13 at 21:04 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 13 Dec 2007 12:34:16 -0700, Richi Plana wrote > > > Sounds like pretty standard wrapping technique, if it is. > > And what exactly do we gain from all this shuffling around? Why, PulseAudio . http://en.wikipedia.org/wiki/PulseAudio http://www.linux.com/feature/119926 -- Richi Plana From ndbecker2 at gmail.com Thu Dec 13 20:23:42 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 13 Dec 2007 15:23:42 -0500 Subject: texlive + tex4ht Message-ID: Is there a tex4ht package compatible with texlive on F8? From seg at haxxed.com Thu Dec 13 20:24:14 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 13 Dec 2007 14:24:14 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <47618D4E.3080107@poolshark.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> Message-ID: <1197577454.12411.40.camel@localhost> On Thu, 2007-12-13 at 20:51 +0100, Denis Leroy wrote: > Richi Plana wrote: > > On Thu, 2007-12-13 at 20:29 +0100, Ralf Ertzinger wrote: > >> Hi. > >> > >> On Thu, 13 Dec 2007 19:23:28 +0000, Will Woods wrote > >> > >>> 4) Sound-using apps use ALSA/ESD as usual. > >>> - It's all actually going through pulseaudio, though. > >> Wait, wait. Since pulseaudio does not, actually, talk to the hardware, > >> applications using ALSA will be rerouted through pulseaudio, which in turn > >> talks to ALSA to produce sound, is that right? > > > > Sounds like pretty standard wrapping technique, if it is. > > How much extra latency are we getting from this ? I've noticed the extra > lag in some of our games. Probably because SDL is going through ESD? And OpenAL is going to go through SDL? Which is a completely bogus situation IMHO but it works for now. Pulse's ALSA wrapper needs to be fixed to work with SDL and OpenAL and/or SDL and OpenAL need to get native Pulse support. -------------- 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 bos at serpentine.com Thu Dec 13 20:32:28 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 13 Dec 2007 12:32:28 -0800 Subject: texlive + tex4ht In-Reply-To: References: Message-ID: <476196DC.9040304@serpentine.com> Neal Becker wrote: > Is there a tex4ht package compatible with texlive on F8? No. The texlive package in rawhide has had the errant tex4ht-related files stripped out, but Jindrich's F8 repo hasn't been updated with this. References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> Message-ID: <1197579247.10057.15.camel@metroid.rdu.redhat.com> On Thu, 2007-12-13 at 14:24 -0600, Callum Lerwick wrote: > > Richi Plana wrote: > > How much extra latency are we getting from this ? I've noticed the extra > > lag in some of our games. > > Probably because SDL is going through ESD? And OpenAL is going to go > through SDL? Which is a completely bogus situation IMHO but it works for > now. Right. If I understand correctly, SDL choked when trying to use PulseAudio as its ALSA device, so we used a last-minute workaround of forcing it to use ESD. See this thread for details: http://article.gmane.org/gmane.linux.redhat.fedora.devel/70224/ > Pulse's ALSA wrapper needs to be fixed to work with SDL and OpenAL > and/or SDL and OpenAL need to get native Pulse support. A preliminary driver was written in April: http://www.nabble.com/PulseAudio-output-for-SDL-to10047401.html I dunno what the status of that is now, but Lennart has said that we'll get native support by F9. Let's hope. -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 Lam at Lam.pl Thu Dec 13 21:22:15 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 13 Dec 2007 22:22:15 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197579247.10057.15.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> <1197579247.10057.15.camel@metroid.rdu.redhat.com> Message-ID: <20071213222215.26099efc@pensja.lam.pl> Dnia 2007-12-13, o godz. 15:54:07 Will Woods napisa?(a): > A preliminary driver was written in April: > http://www.nabble.com/PulseAudio-output-for-SDL-to10047401.html > I dunno what the status of that is now, but Lennart has said that we'll > get native support by F9. Let's hope. Replies to the message you've shown state that it got included a month after. It's also a prominent number one item in SDL change log at http://www.libsdl.org/release/changes-1.2.html (1.2.12 is in F8). Was there a problem with it, or simply noone noticed the option of setenv SDL_AUDIODRIVER pulse? Lam -------------- 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 Dec 13 21:48:44 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 13 Dec 2007 22:48:44 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <1197573808.2917.13.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: On Thu, 13 Dec 2007, Will Woods wrote: > 3) When GNOME/KDE/etc start up, they start pulseaudio. > - Actually, GNOME starts ESD, but /usr/bin/esd -> esdcompat > - esdcompat is provided by pulseaudio-esound-compat Actually, I had an old /home so the old GNOME config was OF COURSE not set to start ESD, since it was krap. So I've been launching pulseaudio manually in a cmdline window until today, when I learnt that ESD is PA. :-) Prhaps we could make this a bit more obvious... Linus From mspevack at redhat.com Thu Dec 13 22:55:11 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 13 Dec 2007 17:55:11 -0500 (EST) Subject: FUDCon hotel information Message-ID: https://barcamp.pbwiki.com/FUDConRaleigh2008#TRAVEL In short, go to www.brownstonehotel.com Use their online reservations page. In the "Group, Corporate, etc" section enter the code RED (case sensitive) in order to get our corporate rates. Cheapest rooms are $89 per night, and can have either 1 bed or 2, depending on whether or not you want/need a roommate. --Max From seg at haxxed.com Thu Dec 13 23:33:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 13 Dec 2007 17:33:51 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071213222215.26099efc@pensja.lam.pl> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> <1197579247.10057.15.camel@metroid.rdu.redhat.com> <20071213222215.26099efc@pensja.lam.pl> Message-ID: <1197588832.12411.49.camel@localhost> On Thu, 2007-12-13 at 22:22 +0100, Leszek Matok wrote: > Dnia 2007-12-13, o godz. 15:54:07 Will Woods napisa?(a): > > > A preliminary driver was written in April: > > http://www.nabble.com/PulseAudio-output-for-SDL-to10047401.html > > I dunno what the status of that is now, but Lennart has said that we'll > > get native support by F9. Let's hope. > Replies to the message you've shown state that it got included a month after. > It's also a prominent number one item in SDL change log at > http://www.libsdl.org/release/changes-1.2.html > (1.2.12 is in F8). Was there a problem with it, or simply noone noticed the > option of setenv SDL_AUDIODRIVER pulse? Well it appears it slipped in under the radar... setenv will not work, Pulse support is not compiled in at all. This should do it: --- SDL.spec 2007-11-06 10:18:15.000000000 -0600 +++ SDL.spec 2007-12-13 17:25:16.000000000 -0600 @@ -19,6 +19,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-root BuildRequires: arts-devel audiofile-devel BuildRequires: esound-devel alsa-lib-devel +BuildRequires: pulseaudio-libs-devel BuildRequires: libXext-devel libX11-devel BuildRequires: libGL-devel libGLU-devel BuildRequires: libXrender-devel libXrandr-devel gettext-devel @@ -73,6 +74,7 @@ --enable-dlopen \ --enable-arts-shared \ --enable-esd-shared \ + --enable-pulseaudio-shared \ --enable-alsa \ --disable-rpath make %{?_smp_mflags} I suppose I'll build me a package and see what happens... -------------- 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 Thu Dec 13 23:40:11 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 14 Dec 2007 00:40:11 +0100 Subject: Strangest BZ Message-ID: <4761C2DB.7000808@poolshark.org> Ok, does anyone understand this strange bugzilla entry ? https://bugzilla.redhat.com/show_bug.cgi?id=375221 Looks like 2 or 3 differents bugs mixed into one. :-) From tibbs at math.uh.edu Thu Dec 13 23:54:49 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Dec 2007 17:54:49 -0600 Subject: Strangest BZ In-Reply-To: <4761C2DB.7000808@poolshark.org> References: <4761C2DB.7000808@poolshark.org> Message-ID: >>>>> "DL" == Denis Leroy writes: DL> https://bugzilla.redhat.com/show_bug.cgi?id=375221 DL> Looks like 2 or 3 differents bugs mixed into one. :-) Looks like someone mistyped a bug number into a bodhi request, which explains the pirut push notifications, and then mistyped the same bug number when 393741 was closed as a duplicate. But the weird component looks to have been chosen by the submitter, as I can see no record of it being changed. - J< From smooge at gmail.com Thu Dec 13 23:58:28 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 13 Dec 2007 16:58:28 -0700 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> Message-ID: <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> On Dec 12, 2007 10:29 PM, Yaakov Nemoy wrote: > On Dec 13, 2007 12:24 AM, Stephen John Smoogen wrote: > > Why is it called Smoon and sometimes Smolt.. did I miss the memo? In > > all actuallity I think having the privacy policy is a good thing. I > > will try to read through this a bit more when I am more awake. > > Smoon is the server. Smolt is the program and the client. > > You could always claim we named it after you ;) Ah that would be nice... What I would like is a better plugin system into the smolt and smoon server. There are a ton of privacy concerns that come up everytime this project comes up with "who has the data", "I want to be counted by why the hell do you need to know my CPU unless I am filling in a bug report", etc.. While some of these people do were tin (not Aluminum) hats, there are people who do have legitimate reasons for the questions (I just tend to forget them.) So here is what I would like to see smolt/smoon do. 1) Smolt by itself collects a certain amount of data that is known, documented and clear. It is the minimum amount of data that would help the various distros and desktops to get sample data. 2) Smolt allows for seperate packages to be installed that collect additional data. This would allow for a disk-layout plugin, a deep-hardware plugin, a group plugin etc to be written and used by the people who need it or want to share it, etc. It would allow for someone to write an Selinux audit plugin that might be useful for a particular site but not something you would want to have enabled or pushed out from the central Smolt servers. -- 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 loupgaroublond at gmail.com Fri Dec 14 01:15:35 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 13 Dec 2007 20:15:35 -0500 Subject: RFC for Smolt features In-Reply-To: <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> Message-ID: <7f692fec0712131715p11e58a8u939182dcbd9b73d3@mail.gmail.com> On Dec 13, 2007 6:58 PM, Stephen John Smoogen wrote: > What I would like is a better plugin system into the smolt and smoon > server. There are a ton of privacy concerns that come up everytime > this project comes up with "who has the data", "I want to be counted > by why the hell do you need to know my CPU unless I am filling in a > bug report", etc.. While some of these people do were tin (not > Aluminum) hats, there are people who do have legitimate reasons for > the questions (I just tend to forget them.) > > So here is what I would like to see smolt/smoon do. > > 1) Smolt by itself collects a certain amount of data that is known, > documented and clear. It is the minimum amount of data that would help > the various distros and desktops to get sample data. > 2) Smolt allows for seperate packages to be installed that collect > additional data. This would allow for a disk-layout plugin, a > deep-hardware plugin, a group plugin etc to be written and used by the > people who need it or want to share it, etc. It would allow for > someone to write an Selinux audit plugin that might be useful for a > particular site but not something you would want to have enabled or > pushed out from the central Smolt servers. I had a simpler solution, which is on my TODO list for Fedora 9. Every field in Smolt (the client) is controlled by a boolean, that is what allows it to be sent out. There will be a well published default config (see the privacy policy for that list, which actually sends you off to the "Scope" document.) that is standard on standard Fedora builds. These standard builds also submit to the standard server. The server is also configurable. If an organisation wants to run a Smoon server, they can configure all their clients to submit information to there. The smoon server will then be able to export its information to another server, or our server. Again, through a series of booleans, the server can be configured to only send specific information. The default configuration on Smoon is the same as Smolt. -Yaakov From loupgaroublond at gmail.com Fri Dec 14 01:18:40 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 13 Dec 2007 20:18:40 -0500 Subject: RFC for Smolt features In-Reply-To: <1197525424.12411.36.camel@localhost> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <1197525424.12411.36.camel@localhost> Message-ID: <7f692fec0712131718l2b7bac3t1ba2beadaa36c86f@mail.gmail.com> On Dec 13, 2007 12:57 AM, Callum Lerwick wrote: > I was recently wishing Smolt collected more detailed CPU information. > This would basically consist of collecting the flags: line > in /proc/cpuinfo. Personally I'd like to know how many machines have > cmov, sse and sse2. This would mostly be unique to i386, x86_64 is > always going to have them, and PPC doesn't even have a flags: line... Any proposals what to collect, and where to find it? We could draft up a new RFC for it. > Also, the ram/swap/cpu mhz graphs on the web site are IMHO too coarse to > be very useful. What numbers are you looking for? Changing this is trivial. -Yaakov From loupgaroublond at gmail.com Fri Dec 14 01:21:11 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 13 Dec 2007 20:21:11 -0500 Subject: RFC for Smolt features In-Reply-To: <47614D5A.9040808@gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <1197525424.12411.36.camel@localhost> <47614D5A.9040808@gmail.com> Message-ID: <7f692fec0712131721v36e46ad8ve0b6628b74f1fbd3@mail.gmail.com> On Dec 13, 2007 10:18 AM, Christopher Brown wrote: > I would also love to see the removal of the nag window from Anaconda. I > can't remember if this was still the case for F8 but at some point > checking the 'Do Not Send Profile' button and attempting to continue > would bring up an 'Are You Sure' dialog. Yes, I am sure and please don't > nag me about it. The fewer clicks during install the better. Apologies > if this is no longer the case however. We really do want to see Smolt integrated as much as possible everywhere. If you really don't mind, I'm going to wait to see if there are enough widespread complaints about it. Most of the time, when I read blog reports about Fedora X, there's rarely any major complaints about that one feature. > Other than that, awesome work! Thank you! -Yaakov From loupgaroublond at gmail.com Fri Dec 14 01:22:52 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 13 Dec 2007 20:22:52 -0500 Subject: RFC for Smolt features In-Reply-To: <47614DD1.8060301@redhat.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <1197525424.12411.36.camel@localhost> <47614DD1.8060301@redhat.com> Message-ID: <7f692fec0712131722m3f2c2a88pe288f34a36ec6345@mail.gmail.com> On Dec 13, 2007 10:20 AM, Eric Sandeen wrote: > /me reiterates the request for filesystem information too :) I put the RFC up on the mailing list a while ago, and there weren't any serious objections that weren't "Smolt is invasive of privacy". It was that whole discussion that led me to think this all through. Let me see what I have the time for; I'm also interested in adding some amount of FS information. -Yaakov From seg at haxxed.com Fri Dec 14 02:40:30 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 13 Dec 2007 20:40:30 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197588832.12411.49.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> <1197579247.10057.15.camel@metroid.rdu.redhat.com> <20071213222215.26099efc@pensja.lam.pl> <1197588832.12411.49.camel@localhost> Message-ID: <1197600031.12411.59.camel@localhost> On Thu, 2007-12-13 at 17:33 -0600, Callum Lerwick wrote: > I suppose I'll build me a package and see what happens... Okay, got it working but there's some problems. Quake 3 is very stuttery. It seems it runs its audio engine at 22050 which probably has something to do with it: ------ Initializing Sound ------ Initializing SDL audio driver... SDL audio driver is "pulse". SDL_AudioSpec: Format: AUDIO_S16LSB Freq: 22050 Samples: 512 Channels: 2 Starting SDL audio callback... SDL audio initialized. ----- Sound Info ----- 1 stereo 16384 samples 16 samplebits 1 submission_chunk 22050 speed 0xa587640 dma buffer No background file. ---------------------- Sound initialization successful. I discovered a problem with OpenAL. It dlopen()s libSDL.so, which means it fails if SDL-devel is not installed, in which case it falls back to OSS. With SDL-devel installed, Second Life and OpenArena seem to work okay. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Lam at Lam.pl Fri Dec 14 08:09:40 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 14 Dec 2007 09:09:40 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197573808.2917.13.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: <20071214090940.5b34c5f2@pensja.lam.pl> Dnia 2007-12-13, o godz. 19:23:28 Will Woods napisa?(a): > If you really *must* disable PulseAudio, removing or renaming > /etc/alsa/pulse-default.conf is the easiest way. The more correct answer would be: rpm -e alsa-plugins-pulseaudio I guess. Lam -------------- 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 Fri Dec 14 08:11:18 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 14 Dec 2007 09:11:18 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197600031.12411.59.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> <1197579247.10057.15.camel@metroid.rdu.redhat.com> <20071213222215.26099efc@pensja.lam.pl> <1197588832.12411.49.camel@localhost> <1197600031.12411.59.camel@localhost> Message-ID: <20071214091118.547aeee5@pensja.lam.pl> Dnia 2007-12-13, o godz. 20:40:30 Callum Lerwick napisa?(a): > Okay, got it working but there's some problems. Quake 3 is very > stuttery. It seems it runs its audio engine at 22050 which probably has > something to do with it: Have you tried snd_speed 44100? It needs a restart (not snd_restart) to take effect on my Q3. I haven't tried with PA since I don't (or can't) use it. Lam -------------- 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 Dec 14 09:04:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Dec 2007 10:04:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: <1197623064.4349.17.camel@rousalka.dyndns.org> Le jeudi 13 d?cembre 2007 ? 22:48 +0100, Linus Walleij a ?crit : > On Thu, 13 Dec 2007, Will Woods wrote: > > > 3) When GNOME/KDE/etc start up, they start pulseaudio. > > - Actually, GNOME starts ESD, but /usr/bin/esd -> esdcompat > > - esdcompat is provided by pulseaudio-esound-compat > > Actually, I had an old /home so the old GNOME config was OF COURSE not set > to start ESD, since it was krap. > > So I've been launching pulseaudio manually in a cmdline window until > today, when I learnt that ESD is PA. :-) Same here. Please kill the whole esd emulation thing and do a clean break. (or at least make the system work for non-esd users) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lordmorgul at gmail.com Fri Dec 14 09:09:11 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 14 Dec 2007 01:09:11 -0800 Subject: Hal issue with kde4 ? [Fwd: Re: Shall I test KDE4 already ?] In-Reply-To: <47606D15.1040503@lex.hider.name> References: <47606D15.1040503@lex.hider.name> Message-ID: <47624837.6000503@gmail.com> Lex Hider wrote: > With latest kde 4 compiled by hand, there is an issue with the > filemanager dolphin, and mounting removable media. > > According to the kde guys, this is a fedora problem and not a kde problem. I would think the best thing for you to do if you really want to test kde4 is to go ahead and install whatever is necessary to get the rawhide kde4 build into your f8 (going to take replacing alot), and if you're concerned about keeping the machine somewhat usable after that just avoid installing any more of rawhide than necessary. (or just go all out!) I would not waste 10 minutes attempting to make a hand compiled kde4 work with f8 when its being done officially for f9 and already 'usable'. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From nicolas.mailhot at laposte.net Fri Dec 14 09:12:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Dec 2007 10:12:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197600031.12411.59.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197577454.12411.40.camel@localhost> <1197579247.10057.15.camel@metroid.rdu.redhat.com> <20071213222215.26099efc@pensja.lam.pl> <1197588832.12411.49.camel@localhost> <1197600031.12411.59.camel@localhost> Message-ID: <1197623544.4349.27.camel@rousalka.dyndns.org> Le jeudi 13 d?cembre 2007 ? 20:40 -0600, Callum Lerwick a ?crit : > On Thu, 2007-12-13 at 17:33 -0600, Callum Lerwick wrote: > > I suppose I'll build me a package and see what happens... > > Okay, got it working but there's some problems. Quake 3 is very > stuttery. I get massive stuttering in every pulseaudio-enabled app when trying to read video streams from a pvr150 directly. It's so bad the video players freeze while trying to sync audio and video after a few minutes, do not recover and have to be killed. The same applications perform flawlessly on the same system, even with things like kernel builds or massive software sync in the background, when configured to talk to alsa directly with no pulseaudio server running. (The system is dual-core with variable cpu frequency, HPET, good audio card, preempt hrt-timer kernel pretty much the perfect environment to do good audio) I read both 44k and 48k audio streams so setting an explicit snd_speed setting is a no-go -- 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 Fri Dec 14 10:59:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 14 Dec 2007 11:59:44 +0100 Subject: Heads up: openssl and gnutls rebase in rawhide In-Reply-To: <1196343620.3047.21.camel@vespa.kabelta.loc> References: <1196343620.3047.21.camel@vespa.kabelta.loc> Message-ID: <20071214115944.7f8c3274.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Nov 2007 14:40:20 +0100, Tomas Mraz wrote: > I have decided to complete the dependency breakage which will be caused > by the openldap update because many packages which depend on openldap > libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild > cycles I will do openssl and gnutls rebase in sync. There should not be > any API changes so simple rebuild will be sufficient. > > I'm still undecided whether we should have a compat package for openssl > in Fedora so if you know any 3rd party software which will be broken by > the openssl libraries SONAME change and which is actively used on > current Fedoras, please let me know. Since this OpenSSL upgrade in rawhide, using the PyOpenSSL-based Plague buildsys fails with a handshake problem. Server code throws Error: [('SSL routines', 'SSL3_GET_CLIENT_HELLO', 'length mismatch')] https://www.redhat.com/archives/epel-devel-list/2007-December/msg00071.html From tmraz at redhat.com Fri Dec 14 12:31:06 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 14 Dec 2007 13:31:06 +0100 Subject: Heads up: openssl and gnutls rebase in rawhide In-Reply-To: <20071214115944.7f8c3274.mschwendt.tmp0701.nospam@arcor.de> References: <1196343620.3047.21.camel@vespa.kabelta.loc> <20071214115944.7f8c3274.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1197635466.4341.23.camel@vespa.frost.loc> On Fri, 2007-12-14 at 11:59 +0100, Michael Schwendt wrote: > On Thu, 29 Nov 2007 14:40:20 +0100, Tomas Mraz wrote: > > > I have decided to complete the dependency breakage which will be caused > > by the openldap update because many packages which depend on openldap > > libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild > > cycles I will do openssl and gnutls rebase in sync. There should not be > > any API changes so simple rebuild will be sufficient. > > > > I'm still undecided whether we should have a compat package for openssl > > in Fedora so if you know any 3rd party software which will be broken by > > the openssl libraries SONAME change and which is actively used on > > current Fedoras, please let me know. > > Since this OpenSSL upgrade in rawhide, using the PyOpenSSL-based Plague > buildsys fails with a handshake problem. Server code throws > Error: [('SSL routines', 'SSL3_GET_CLIENT_HELLO', 'length mismatch')] > > https://www.redhat.com/archives/epel-devel-list/2007-December/msg00071.html Please try the latest build - openssl-0.9.8g-3.fc9. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mschwendt.tmp0701.nospam at arcor.de Fri Dec 14 12:45:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 14 Dec 2007 13:45:25 +0100 Subject: Heads up: openssl and gnutls rebase in rawhide In-Reply-To: <1197635466.4341.23.camel@vespa.frost.loc> References: <1196343620.3047.21.camel@vespa.kabelta.loc> <20071214115944.7f8c3274.mschwendt.tmp0701.nospam@arcor.de> <1197635466.4341.23.camel@vespa.frost.loc> Message-ID: <20071214134525.0b447c47.mschwendt.tmp0701.nospam@arcor.de> On Fri, 14 Dec 2007 13:31:06 +0100, Tomas Mraz wrote: > > Since this OpenSSL upgrade in rawhide, using the PyOpenSSL-based Plague > > buildsys fails with a handshake problem. Server code throws > > Error: [('SSL routines', 'SSL3_GET_CLIENT_HELLO', 'length mismatch')] > > > > https://www.redhat.com/archives/epel-devel-list/2007-December/msg00071.html > > Please try the latest build - openssl-0.9.8g-3.fc9. Works for me. It was bug #422081 From caolanm at redhat.com Fri Dec 14 12:53:35 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 14 Dec 2007 12:53:35 +0000 Subject: OpenOffice.org linguistic bits Message-ID: <1197636815.924.449.camel@Jehannum> So the split out of OOo linguistic bits is complete, i.e. * dictionaries, i.e. all those hunspell-foo dictionaries * thesauri, i.e. all those mythes-foo things and * hyphenation rules, i.e. all those hyphen-foo things. I've only imported the ones that already existed inside the OOo 2.3.1 tarball and I'm personally not actively adding any other languages. But if you're a native language speaker of a language e.g. Swedish and you feel e.g. hyphenation sucks or that you want Ooo to find misspellings in your language then http://wiki.services.openoffice.org/wiki/Dictionaries is a good first port of call to start tracking back to the canonical source for a suitable hyphenation or spelling dictionary. Let me know if such a new package is imported and I can set the matching OOo langpack to depend on it. Wrt. grammar, I had hoped that we might get some grammar checking for F9, but the best option languagetool at http://www.languagetool.org/ is a bit messed up for the moment, can't be really built cleanly from source, doesn't really seem to work with gcj all that well, and not 100% deployable as a OOo shared system-extension rather than a per-user one. Though it does give relatively sane grammar suggestions for english at least, e.g. detecting word doubling and some of the crackpot uses of their/they're/there. C. From buildsys at redhat.com Fri Dec 14 14:10:58 2007 From: buildsys at redhat.com (Build System) Date: Fri, 14 Dec 2007 09:10:58 -0500 Subject: rawhide report: 20071214 changes Message-ID: <200712141410.lBEEAwC4024126@porkchop.devel.redhat.com> Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.3.1-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 ghc681-gtk2hs - 0.9.12.1-7.fc9.i386 requires ghc681 gnubiff - 2.2.7-2.fc8.i386 requires libssl.so.6 gnubiff - 2.2.7-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 krusader - 1.80.0-3.fc9.i386 requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 plplot-octave - 5.8.0-3.fc9.i386 requires octave(api) = 0:api-v30 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.3.1-1.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 ghc681-gtk2hs - 0.9.12.1-7.fc9.x86_64 requires ghc681 gnubiff - 2.2.7-2.fc8.x86_64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) ice - 3.2.1-13.fc9.i386 requires libssl.so.6 ice - 3.2.1-13.fc9.i386 requires libcrypto.so.6 ice - 3.2.1-13.fc9.x86_64 requires libcrypto.so.6()(64bit) ice - 3.2.1-13.fc9.x86_64 requires libssl.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.i386 requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.i386 requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.x86_64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.x86_64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.x86_64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-3.fc9.x86_64 requires octave(api) = 0:api-v30 proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.3.1-1.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 ghc681-gtk2hs - 0.9.12.1-7.fc9.ppc requires ghc681 gnubiff - 2.2.7-2.fc8.ppc requires libssl.so.6 gnubiff - 2.2.7-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libssl.so.6 ice - 3.2.1-13.fc9.ppc requires libcrypto.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libssl.so.6 kftpgrabber - 0.8.1-3.fc8.ppc requires libcrypto.so.6 kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.ppc requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 plplot-octave - 5.8.0-3.fc9.ppc requires octave(api) = 0:api-v30 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libcrypto.so.6()(64bit) gnubiff - 2.2.7-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libcrypto.so.6()(64bit) kftpgrabber - 0.8.1-3.fc8.ppc64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.ppc64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-3.fc9.ppc64 requires octave(api) = 0:api-v30 ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) From jdieter at gmail.com Fri Dec 14 17:22:09 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 14 Dec 2007 19:22:09 +0200 Subject: Attaching rpm signature to deltarpm after deltarpm creation Message-ID: <1197652929.3290.10.camel@jndwidescreen.lesbg.loc> A few of us have been throwing around some ideas on how to generate deltarpms in the Fedora build system. See http://fedoraproject.org/wiki/Infrastructure/PrestoBuildsysIntegration for more information. We've hit an interesting problem, though. Currently in the build system, rpms are (1) built, (2) queued for update and then (3) signed. The problem is that we want to generate the deltarpms after either (1) or (2), but there is no easy way of attaching the rpm's signature to a deltarpm *after* the deltarpm has been created. Any thoughts or advice? 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 mls at suse.de Fri Dec 14 17:47:04 2007 From: mls at suse.de (Michael Schroeder) Date: Fri, 14 Dec 2007 18:47:04 +0100 Subject: Attaching rpm signature to deltarpm after deltarpm creation In-Reply-To: <1197652929.3290.10.camel@jndwidescreen.lesbg.loc> References: <1197652929.3290.10.camel@jndwidescreen.lesbg.loc> Message-ID: <20071214174704.GA3555@suse.de> On Fri, Dec 14, 2007 at 07:22:09PM +0200, Jonathan Dieter wrote: > A few of us have been throwing around some ideas on how to generate > deltarpms in the Fedora build system. See > http://fedoraproject.org/wiki/Infrastructure/PrestoBuildsysIntegration > for more information. We've hit an interesting problem, though. > > Currently in the build system, rpms are (1) built, (2) queued for update > and then (3) signed. The problem is that we want to generate the > deltarpms after either (1) or (2), but there is no easy way of attaching > the rpm's signature to a deltarpm *after* the deltarpm has been created. > > Any thoughts or advice? Combinedelatrpm is your friend here: If you sign the deltas later on, you can use combinedeltarpm to patch the new signature into the deltas. Here's an example: makedeltarpm old.rpm new.rpm delta.drpm sign new.rpm combinedeltarpm -S new.rpm delta.drpm deltasigned.drpm (There's actually another way: you can create a "rpm-only no diff" delta rpm containing just the signature and then use combinedeltarpm to create a delta containing the signature: makedeltarpm -r -u new.rpm newsig.drpm combinedeltarpm delta.drpm newsig.drpm deltasigned.drpm This results in the same drpm as with the -S option.) Cheers, Michael. -- Michael Schroeder mls at suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From mspevack at redhat.com Fri Dec 14 19:29:06 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 14 Dec 2007 14:29:06 -0500 (EST) Subject: FUDCon -- considering switching Fri/Sat schedules Message-ID: All, As we try to finalize the logistics for FUDCon, it looks like it will be a lot easier from a space point of view if we make the actual barcamp day Saturday (instead of Friday), and use Friday and Sunday for the Hackfests. I also think we can get a better turnout at bar camp if it is on Saturday. What we want to know is: does this totally mess up anyone's plans? None of the dates actually change, just the agenda a little bit. Let me know off-list. If there's no major concerns, we'll turn this from 'proposal' to 'official' on Monday and update the main barcamp page. Thanks, Max _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mmcgrath at redhat.com Fri Dec 14 20:22:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 14 Dec 2007 14:22:13 -0600 Subject: Wiki Migration Message-ID: <4762E5F5.4010206@redhat.com> Ok, I'm just throwing this out there for discussion. We would like to migrate from Moin to another wiki. We have yet to find any valid migration scripts that convert users, histories, etc. What would YOU say if we made the current wiki read only, and made the teams and people migrate important relevant content over to a blank wiki by hand (copy and paste)? I think this would also allow us to trim up the wiki a bit. So the question I'm asking is if we decided to go this route. How many of you would hate the Infrastructure group? -Mike From jspaleta at gmail.com Fri Dec 14 20:35:30 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Dec 2007 11:35:30 -0900 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> On Dec 14, 2007 11:22 AM, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? > > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? If we were going to do it this way, is there any a-priori restructuring that should be done in terms of wiki page namespace in an effort to organize the content a bit? Id hate to take the same pile and just move it into another room so that it still looks like the same pile of stuff..but in a different room. -jef From skvidal at fedoraproject.org Fri Dec 14 21:19:21 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 14 Dec 2007 16:19:21 -0500 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <1197667161.19509.23.camel@cutter> On Fri, 2007-12-14 at 14:22 -0600, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? > > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? I'd love to know what feature set we want and what's available among the other wiki software out there. Just to make sure we're not going from one pile of problems to another one. :) -sv From berrange at redhat.com Fri Dec 14 21:27:17 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 14 Dec 2007 21:27:17 +0000 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <20071214212717.GK9211@redhat.com> On Fri, Dec 14, 2007 at 02:22:13PM -0600, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. Why ? Not that I'm a fan of Moin, but it'd be useful to know what the perceived problems with Fedora's current Wiki are, and what we expect to gain from a new solution before going through the migration pain. 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 mclasen at redhat.com Fri Dec 14 21:43:01 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 14 Dec 2007 16:43:01 -0500 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <1197668581.2786.0.camel@localhost.localdomain> On Fri, 2007-12-14 at 14:22 -0600, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? I would say: screw it, maintaining wiki pages is painful enough. I'm not going to manually copy stuff over. From mmcgrath at redhat.com Fri Dec 14 21:39:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 14 Dec 2007 15:39:53 -0600 Subject: Wiki Migration In-Reply-To: <1197668581.2786.0.camel@localhost.localdomain> References: <4762E5F5.4010206@redhat.com> <1197668581.2786.0.camel@localhost.localdomain> Message-ID: <4762F829.1000109@redhat.com> Matthias Clasen wrote: > On Fri, 2007-12-14 at 14:22 -0600, Mike McGrath wrote: > >> Ok, I'm just throwing this out there for discussion. >> >> We would like to migrate from Moin to another wiki. >> >> We have yet to find any valid migration scripts that convert users, >> histories, etc. >> >> What would YOU say if we made the current wiki read only, and made the >> teams and people migrate important relevant content over to a blank wiki >> by hand (copy and paste)? >> > > I would say: screw it, maintaining wiki pages is painful enough. > I'm not going to manually copy stuff over. > Considering the wiki is some 4000-5000 pages big right now, I'd hope some would share this helpful pruning sentiment :) -Mike From triad at df.lth.se Fri Dec 14 21:48:18 2007 From: triad at df.lth.se (Linus Walleij) Date: Fri, 14 Dec 2007 22:48:18 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> Message-ID: On Thu, 13 Dec 2007, Linus Walleij wrote: > Prhaps we could make this a bit more obvious... OK so getting PulseAudio to work involves (to me): System/Settings/Hardware/Sound, second tab, activate "Sound Server (ESD)". So, I'm filing: https://bugzilla.redhat.com/show_bug.cgi?id=425501 (Get that changed to PulseAudio) But we need something else too: if the user logs in and has (like me) deactivated ESD previously, s/he should be prompted to activate PulseAudio (NOT ESD) to have sound working properly with apps. (Because packages are now adapting to PA.) Could have a "No thanks, I'm sure, don't prompt me again" tickbox. ... similar to the popups requesting you to rename folders in $HOME when you switch language. Linus From adrian at lisas.de Fri Dec 14 21:49:16 2007 From: adrian at lisas.de (Adrian Reber) Date: Fri, 14 Dec 2007 22:49:16 +0100 Subject: FYI: License change for source-highlight Message-ID: <20071214214916.GA7590@lisas.de> Starting with source-highlight 2.8 the license of it has changed to GPLv3. According to repoquery nothing depends on source-highlight so that it should be no problem. Adrian From mmcgrath at redhat.com Fri Dec 14 21:42:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 14 Dec 2007 15:42:33 -0600 Subject: Wiki Migration In-Reply-To: <20071214212717.GK9211@redhat.com> References: <4762E5F5.4010206@redhat.com> <20071214212717.GK9211@redhat.com> Message-ID: <4762F8C9.1020809@redhat.com> Daniel P. Berrange wrote: > On Fri, Dec 14, 2007 at 02:22:13PM -0600, Mike McGrath wrote: > >> Ok, I'm just throwing this out there for discussion. >> >> We would like to migrate from Moin to another wiki. >> > > Why ? > > Not that I'm a fan of Moin, but it'd be useful to know what the > perceived problems with Fedora's current Wiki are, and what we expect > to gain from a new solution before going through the migration pain. > We've been down this path, its not been fruitful: http://fedoraproject.org/wiki/MikeMcGrath/MoinIssues -Mike From poelstra at redhat.com Fri Dec 14 21:53:00 2007 From: poelstra at redhat.com (John Poelstra) Date: Fri, 14 Dec 2007 13:53:00 -0800 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <4762FB3C.4040306@redhat.com> Mike McGrath said the following on 12/14/2007 12:22 PM Pacific Time: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. +1 > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? +1 > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? -1 From smooge at gmail.com Fri Dec 14 22:10:09 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 14 Dec 2007 15:10:09 -0700 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712131715p11e58a8u939182dcbd9b73d3@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> <7f692fec0712131715p11e58a8u939182dcbd9b73d3@mail.gmail.com> Message-ID: <80d7e4090712141410y3537eabew5cd7d286e19ae3e3@mail.gmail.com> On Dec 13, 2007 6:15 PM, Yaakov Nemoy wrote: > On Dec 13, 2007 6:58 PM, Stephen John Smoogen wrote: > > What I would like is a better plugin system into the smolt and smoon > > server. There are a ton of privacy concerns that come up everytime > > this project comes up with "who has the data", "I want to be counted > > by why the hell do you need to know my CPU unless I am filling in a > > bug report", etc.. While some of these people do were tin (not > > Aluminum) hats, there are people who do have legitimate reasons for > > the questions (I just tend to forget them.) > > > > So here is what I would like to see smolt/smoon do. > > > > 1) Smolt by itself collects a certain amount of data that is known, > > documented and clear. It is the minimum amount of data that would help > > the various distros and desktops to get sample data. > > 2) Smolt allows for seperate packages to be installed that collect > > additional data. This would allow for a disk-layout plugin, a > > deep-hardware plugin, a group plugin etc to be written and used by the > > people who need it or want to share it, etc. It would allow for > > someone to write an Selinux audit plugin that might be useful for a > > particular site but not something you would want to have enabled or > > pushed out from the central Smolt servers. > > I had a simpler solution, which is on my TODO list for Fedora 9. > Every field in Smolt (the client) is controlled by a boolean, that is > what allows it to be sent out. There will be a well published default > config (see the privacy policy for that list, which actually sends you > off to the "Scope" document.) that is standard on standard Fedora > builds. These standard builds also submit to the standard server. > The server is also configurable. > > If an organisation wants to run a Smoon server, they can configure all > their clients to submit information to there. The smoon server will > then be able to export its information to another server, or our > server. Again, through a series of booleans, the server can be > configured to only send specific information. The default > configuration on Smoon is the same as Smolt. > Hmmm I would prefer a plugin technology because flipping booleans is not that hard.. and some people would prefer not to have XYZ Selinux, Shadow Password reporting items on their system at all. While some other organization might. -- 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 dennis at ausil.us Fri Dec 14 22:30:16 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 14 Dec 2007 16:30:16 -0600 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC Message-ID: <200712141630.20467.dennis@ausil.us> There will be an outage starting at 2007-12-16 16:00 UTC, which will last approximately 10 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2007-12-16 16:00 UTC' Affected Services: ? ? Buildsystem Unaffected Services: ? ? Websites ? ? CVS / Source Control ? ? Database ? ? DNS ? ? Mail ? ? Torrent Ticket Link: ? https://fedorahosted.org/fedora-infrastructure/ticket/264 Reason for Outage: the current buildsystem is run on FC-6 we are doing an OS refresh on all build related systems. At the same time koji and mock will be updated to the latest stable codebase's NOTE TO PACKAGERS: If you have to build a package that typically takes over an hour to build, please make sure to start your job so it is not still running during the outage. ?We will be disabling the builders one by one and will try to let builds finish but won't wait forever. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -------------- 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 a.badger at gmail.com Fri Dec 14 23:06:01 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 14 Dec 2007 15:06:01 -0800 Subject: Wiki Migration In-Reply-To: <4762F8C9.1020809@redhat.com> References: <4762E5F5.4010206@redhat.com> <20071214212717.GK9211@redhat.com> <4762F8C9.1020809@redhat.com> Message-ID: <47630C59.5070801@gmail.com> Mike McGrath wrote: > Daniel P. Berrange wrote: >> On Fri, Dec 14, 2007 at 02:22:13PM -0600, Mike McGrath wrote: >> >>> Ok, I'm just throwing this out there for discussion. >>> >>> We would like to migrate from Moin to another wiki. >>> >> >> Why ? >> >> Not that I'm a fan of Moin, but it'd be useful to know what the >> perceived problems with Fedora's current Wiki are, and what we expect >> to gain from a new solution before going through the migration pain. >> > > We've been down this path, its not been fruitful: > > http://fedoraproject.org/wiki/MikeMcGrath/MoinIssues > Just a note: We have a patch for issue 1 (page saves). Issue 3 (searches) might be fixed when moin eventually releases their next version. Issue 4 (categories) could be fixed with a patch similar to #1. To me, the primary problem with Moin has been our inability to get upstream interested in our problems and willing to accept patches from us. A secondary problem has been that upstream's release schedule just keeps slipping. MrBawb has recently taken up the task of trying to get our patch for #1 accepted upstream. If he's successful then that's a good step towards resolving our primary problem. The second problem boils down to whether we're comfortable patching our install with things we know are upstream but may not make it out until they accumulate the will to put out a new release. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lsof at nodata.co.uk Fri Dec 14 23:07:46 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 15 Dec 2007 00:07:46 +0100 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <1197673666.2833.0.camel@sb-home> Am Freitag, den 14.12.2007, 14:22 -0600 schrieb Mike McGrath: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. Or fix moin. From mschwendt.tmp0701.nospam at arcor.de Fri Dec 14 23:23:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 15 Dec 2007 00:23:38 +0100 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <200712141630.20467.dennis@ausil.us> References: <200712141630.20467.dennis@ausil.us> Message-ID: <20071215002338.4798b2b3.mschwendt.tmp0701.nospam@arcor.de> On Fri, 14 Dec 2007 16:30:16 -0600, Dennis Gilmore wrote: > There will be an outage starting at 2007-12-16 16:00 UTC, which will last > approximately 10 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2007-12-16 16:00 UTC' > > Affected Services: > > ? ? Buildsystem > > Unaffected Services: > ? ? Websites > ? ? CVS / Source Control > ? ? Database > ? ? DNS > ? ? Mail > ? ? Torrent > > Ticket Link: ? > https://fedorahosted.org/fedora-infrastructure/ticket/264 > > Reason for Outage: > the current buildsystem is run on FC-6 we are doing an OS refresh on all > build related systems. At the same time koji and mock will be updated to the > latest stable codebase's > > NOTE TO PACKAGERS: > If you have to build a package that typically takes over an hour to > build, please make sure to start your job so it is not still running > during the outage. ?We will be disabling the builders one by one and > will try to let builds finish but won't wait forever. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email > to track the status of this outage. Note that plague is broken on anything newer than FC-6. You may need something like http://mschwendt.fedorapeople.org/plague/ From jon at fedoraunity.org Fri Dec 14 23:24:51 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Fri, 14 Dec 2007 16:24:51 -0700 Subject: Wiki Migration In-Reply-To: <47630C59.5070801@gmail.com> References: <4762E5F5.4010206@redhat.com> <20071214212717.GK9211@redhat.com> <4762F8C9.1020809@redhat.com> <47630C59.5070801@gmail.com> Message-ID: <20071214162451.002fcd90@damaestro> On Fri, 14 Dec 2007 15:06:01 -0800 Toshio Kuratomi wrote: > Mike McGrath wrote: > > Daniel P. Berrange wrote: > >> On Fri, Dec 14, 2007 at 02:22:13PM -0600, Mike McGrath wrote: > >> > >>> Ok, I'm just throwing this out there for discussion. > >>> > >>> We would like to migrate from Moin to another wiki. > >>> > >> > >> Why ? > >> > >> Not that I'm a fan of Moin, but it'd be useful to know what the > >> perceived problems with Fedora's current Wiki are, and what we > >> expect to gain from a new solution before going through the > >> migration pain. > > > > We've been down this path, its not been fruitful: > > > > http://fedoraproject.org/wiki/MikeMcGrath/MoinIssues > > > Just a note: > We have a patch for issue 1 (page saves). > Issue 3 (searches) might be fixed when moin eventually releases their > next version. Or we can just use our own search system and not use the wiki search system. I can (and have planned to for some time, just out of $freetime) revive searchfedora.org using the existing datapark search (http://dataparksearch.org/) code or we can use an experimental indexing system I'm working on in python that uses Xapian and some custom python to feed the indexer, as Xapian doesn't have it's own robots (http://www.xapian.org/). Datapark search scales very well. I've not been the most impressed with xapian, but moreso with it's indexing strategy rather then it's true purpose as an indexing framework (as best I can tell.) IIRC, MoinMoin has xapian plugins, but I would recommend a completely external search system. Let me know if reviving searchfedora.org should be moved up on my todo list. -- Jonathan Steffan daMaestro Fedora Unity - http://fedoraunity.org/ GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From seg at haxxed.com Fri Dec 14 23:45:59 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 14 Dec 2007 17:45:59 -0600 Subject: Wiki Migration In-Reply-To: <20071214162451.002fcd90@damaestro> References: <4762E5F5.4010206@redhat.com> <20071214212717.GK9211@redhat.com> <4762F8C9.1020809@redhat.com> <47630C59.5070801@gmail.com> <20071214162451.002fcd90@damaestro> Message-ID: <1197675959.12411.61.camel@localhost> On Fri, 2007-12-14 at 16:24 -0700, Jonathan Steffan wrote: > Or we can just use our own search system and not use the wiki search > system. I can (and have planned to for some time, just out of > $freetime) revive searchfedora.org using the existing datapark search > (http://dataparksearch.org/) code or we can use an experimental indexing > system I'm working on in python that uses Xapian and some custom python > to feed the indexer, as Xapian doesn't have it's own > robots (http://www.xapian.org/). Datapark search scales very well. I've > not been the most impressed with xapian, but moreso with it's indexing > strategy rather then it's true purpose as an indexing framework (as > best I can tell.) IIRC, MoinMoin has xapian plugins, but I would > recommend a completely external search system. Let me know if reviving > searchfedora.org should be moved up on my todo list. Why not just let Google do it? I know I've run into sites that do this. I don't know the details though. Presumably you put a site:fedoraproject.org in there... -------------- 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 dennis at ausil.us Fri Dec 14 23:51:35 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 14 Dec 2007 17:51:35 -0600 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <20071215002338.4798b2b3.mschwendt.tmp0701.nospam@arcor.de> References: <200712141630.20467.dennis@ausil.us> <20071215002338.4798b2b3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200712141751.41506.dennis@ausil.us> On Friday 14 December 2007, Michael Schwendt wrote: > On Fri, 14 Dec 2007 16:30:16 -0600, Dennis Gilmore wrote: > > Please join #fedora-admin in irc.freenode.net or respond to this email > > to track the status of this outage. > > Note that plague is broken on anything newer than FC-6. You may need > something like http://mschwendt.fedorapeople.org/plague/ Builders will be RHEL5 so should be fine. Testing will be completed before hand. im more concerned about mock compatabilities 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 loupgaroublond at gmail.com Sat Dec 15 00:30:10 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 14 Dec 2007 19:30:10 -0500 Subject: RFC for Smolt features In-Reply-To: <80d7e4090712141410y3537eabew5cd7d286e19ae3e3@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> <7f692fec0712131715p11e58a8u939182dcbd9b73d3@mail.gmail.com> <80d7e4090712141410y3537eabew5cd7d286e19ae3e3@mail.gmail.com> Message-ID: <7f692fec0712141630o6c1ff7b7gf234dac1413dea07@mail.gmail.com> On Dec 14, 2007 5:10 PM, Stephen John Smoogen wrote: > Hmmm I would prefer a plugin technology because flipping booleans is > not that hard.. and some people would prefer not to have XYZ Selinux, > Shadow Password reporting items on their system at all. While some > other organization might. Both require root access. Both publish the same data. Both garner the same criticism. Both require the same published privacy policy. But plugins gain us the ability for an over eager client to send the server something we're not prepared to deal with. Plugins definitely offer some potential, but then they have to be implemented on a server level, either through forks, or some fundamental change to our server's source code, because storing plugin related information means changing the data model on a web based application. But you're right, flipping booleans is not hard. I'd rather people were flipping booleans than flipping digits at us. -Yaakov From dakingun at gmail.com Sat Dec 15 00:53:13 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 14 Dec 2007 19:53:13 -0500 Subject: FYI: gegl and babl license change Message-ID: Hi all, The license for both gegl and babl has been changed from GPLv2+ and LGPLv2+ to GPLv3+ and LGPLv3+. Right now, the only package in Fedora that depends on any (and both) of these 2 is gnome-scan which has a LGPLv2+ license. Hope to update these two packages to the latest release with the new license soon. Cheers, Deji From ngompa13 at gmail.com Sat Dec 15 02:22:37 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 14 Dec 2007 20:22:37 -0600 Subject: Wiki Migration In-Reply-To: <1197675959.12411.61.camel@localhost> References: <4762E5F5.4010206@redhat.com> <20071214212717.GK9211@redhat.com> <4762F8C9.1020809@redhat.com> <47630C59.5070801@gmail.com> <20071214162451.002fcd90@damaestro> <1197675959.12411.61.camel@localhost> Message-ID: <8278b1b0712141822l25ab09f0g2c402f18f79ac8f@mail.gmail.com> As for a new wiki system, I am all for that. Personally, I have found Moin to be very frustrating, and I would be more than happy to help with migration to a new system. My friend and I could probably investigate this a bit further and report about it. On Dec 14, 2007 5:45 PM, Callum Lerwick wrote: > > On Fri, 2007-12-14 at 16:24 -0700, Jonathan Steffan wrote: > > Or we can just use our own search system and not use the wiki search > > system. I can (and have planned to for some time, just out of > > $freetime) revive searchfedora.org using the existing datapark search > > (http://dataparksearch.org/) code or we can use an experimental indexing > > system I'm working on in python that uses Xapian and some custom python > > to feed the indexer, as Xapian doesn't have it's own > > robots (http://www.xapian.org/). Datapark search scales very well. I've > > not been the most impressed with xapian, but moreso with it's indexing > > strategy rather then it's true purpose as an indexing framework (as > > best I can tell.) IIRC, MoinMoin has xapian plugins, but I would > > recommend a completely external search system. Let me know if reviving > > searchfedora.org should be moved up on my todo list. > > Why not just let Google do it? I know I've run into sites that do this. > I don't know the details though. Presumably you put a > site:fedoraproject.org in there... > > -- > 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 davej at redhat.com Sat Dec 15 04:44:23 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 14 Dec 2007 23:44:23 -0500 Subject: FUDCon hotel information In-Reply-To: References: Message-ID: <20071215044423.GA2468@redhat.com> On Thu, Dec 13, 2007 at 05:55:11PM -0500, Max Spevack wrote: > https://barcamp.pbwiki.com/FUDConRaleigh2008#TRAVEL > > In short, go to www.brownstonehotel.com > > Use their online reservations page. > > In the "Group, Corporate, etc" section enter the code RED (case > sensitive) in order to get our corporate rates. I get "Invalid Corporate ID" when I added that. I tried it in the 'Worldwide Corp. Account#' field and in the 'Group Booking Code:' field. Dave -- http://www.codemonkey.org.uk From tim.lauridsen at googlemail.com Sat Dec 15 06:59:34 2007 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Sat, 15 Dec 2007 07:59:34 +0100 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <47637B56.2040905@googlemail.com> Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. Why a new wiki, why not a CMS system like plone. It is important to set up a feature list. What do we want the new system to do. * export to docbook * page subscription * integration with FAS(2) * good search feature * scalable (multi server setup, clustering) * Security (many PHP based system is a security nightmare) * Add you own I also need to describe what content we want in the system and how we want to organize it. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? If we cant find anything, we have to make the scripts. Manual copy & paste will just piss off a lot of people, so we end up with an outdated read only wiki and a new system with lacking content. A good plan for reorganizing the content is needed. > > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? > > -Mike > I there is to much work for the people and teams there could be used better in other places, then people will hate you :)). This issue is just like changing the packaging SCM, what is the benefits and are they worth the effort. We know the current system have some problems, but it gets the job done. Just my 5 cents. Tim From jnovy at redhat.com Sat Dec 15 08:57:28 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Sat, 15 Dec 2007 09:57:28 +0100 Subject: texlive + tex4ht In-Reply-To: <476196DC.9040304@serpentine.com> References: <476196DC.9040304@serpentine.com> Message-ID: <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> On Thu, Dec 13, 2007 at 12:32:28PM -0800, Bryan O'Sullivan wrote: > Neal Becker wrote: > > Is there a tex4ht package compatible with texlive on F8? > > No. The texlive package in rawhide has had the errant tex4ht-related > files stripped out, but Jindrich's F8 repo hasn't been updated with this. > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any more (version 2007-2 and on). I will only rarely update the F8 repository. I think you can still use: yum update texlive texlive-latex --enablerepo=development even on F8 to fix the tex4ht conflicts. There's also a possibility to create a F8 texlive branch and to obsolete F8 tetex as well if there would be an interest (and poppler-devel > 0.6.2-2 will occur in stable F8 updates). Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From nicolas.mailhot at laposte.net Sat Dec 15 09:18:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 15 Dec 2007 10:18:14 +0100 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <1197710294.25152.2.camel@rousalka.dyndns.org> Le vendredi 14 d?cembre 2007 ? 14:22 -0600, Mike McGrath a ?crit : > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? tar, feathers, pitchforks, 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 pbrobinson at gmail.com Sat Dec 15 10:43:09 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 15 Dec 2007 10:43:09 +0000 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> On Dec 14, 2007 8:22 PM, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? > > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? The X guys are looking at moving from Moin to MediaWiki. There's a post about some conversion tools here => http://lists.freedesktop.org/archives/xorg/2007-December/031007.html Looks like to tools need a bit of work but as they say many hands make light work so maybe some coders could help out that tool and save a whole lot of pain for a number of people. Pete From buildsys at redhat.com Sat Dec 15 12:40:49 2007 From: buildsys at redhat.com (Build System) Date: Sat, 15 Dec 2007 07:40:49 -0500 Subject: rawhide report: 20071215 changes Message-ID: <200712151240.lBFCenav012673@porkchop.devel.redhat.com> New package cwrite A small text editor New package g2clib GRIB2 encoder/decoder and search/indexing routines in C Updated Packages: bc-1.06-31.fc9 -------------- * Fri Dec 14 2007 Stepan Kasal 1.06-31 - Remove bc-1.06-flex.patch - do not run autofoo - fix the Licence tag centerim-1:4.22.2-2.fc9 ----------------------- * Fri Dec 14 2007 Lubomir Kundrak - 1:4.22.2-2 - Replace centericq cmake-2.4.8-0.rc4.fc9 --------------------- * Fri Dec 14 2007 Orion Poplawski - 2.4.8-0.rc4 - Update to 2.4.8 RC-4 dates-0.4.5-1.fc9 ----------------- * Fri Dec 14 2007 Denis Leroy - 0.4.5-1 - Update to upstream 0.4.5 - Updated URL - Header files no longer installed, obsoleting devel package docbook-style-xsl-1.73.2-9.fc9 ------------------------------ * Fri Dec 14 2007 Ondrej Vasik 1.73.2-9 - added fixes for passivetex extension and list-item-body (#161371) ecryptfs-utils-33-1.fc9 ----------------------- * Fri Dec 14 2007 Mike Halcrow 33-1 - Add files to package * Fri Dec 14 2007 Mike Halcrow 33-0 - update to version 33 * Thu Dec 13 2007 Karsten Hopp 32-1 - update to version 32 gdm-1:2.21.2-0.2007.11.20.6.fc9 ------------------------------- * Fri Dec 14 2007 Ray Strode - 1:2.21.2-0.2007.11.20.6 - Fix an uninitialized variable that makes the session list stop growing before its finished sometimes ghex-2.20.1-1.1 --------------- * Fri Dec 14 2007 Thorsten Leemhuis - 2.20.1-1 - Update to 2.20.1 glibc-2.7.90-1 -------------- * Wed Dec 12 2007 Jakub Jelinek 2.7.90-1 - update to trunk - fix __USE_STRING_INLINES on i?86 (#408731, #371711) - fix *scanf (#388751) * Wed Oct 17 2007 Jakub Jelinek 2.7-1 - glibc 2.7 release - fix tzfile.c for times after last transition (#333561) - fix sem_post at GLIBC_2.0 on i?86 - appease valgrind in libpthread.so initialization - misc fixes (BZ#3425, BZ#5184, BZ#5186) * Mon Oct 15 2007 Jakub Jelinek 2.6.90-21 - fix getgr{name,gid}{,_r} with nscd gnome-power-manager-2.20.2-1.fc9 -------------------------------- * Fri Dec 14 2007 Matthias Clasen - 2.20.2-1 - Update to 2.20.2 gnubiff-2.2.7-3.fc9 ------------------- * Thu Dec 06 2007 Release Engineering - 2.2.7-3 - Rebuild for deps gtk2hs-0.9.12.1-8.fc9 --------------------- gtkterm-0.99.5-8.fc9 -------------------- * Sun Dec 09 2007 Dan Horak 0.99.5-8 - update the scrollback patch - close port after unsuccesful read of control signals (#414811) hunspell-pt-0.20071212-1.fc9 ---------------------------- * Fri Dec 14 2007 Caolan McNamara - 0.20071212-1 - latest version ice-3.2.1-14.fc9 ---------------- * Wed Dec 05 2007 Mary Ellen Foster 3.2.1-14 - Version bump to rebuild because of changed OpenSSL in rawhide * Tue Nov 20 2007 Mary Ellen Foster 3.2.1-13 - Enable the IceGrid GUI - Fix a problem with Python on 64-bit systems (bz #392751) - Incorporate one more Mono patch from ZeroC * Tue Oct 30 2007 Mary Ellen Foster 3.2.1-12 - Put the slice2java classes into a .jar file instead of as bare classes - Incorporate all Ice 3.2.1 patches from ZeroC - Fix templates path in icegridregistry.conf kdebase-6:3.97.0-4.fc9 ---------------------- * Fri Dec 14 2007 Rex Dieter 3.97.0-4 - Obsoletes: -extras (f9+) * Wed Dec 12 2007 Kevin Kofler 3.97.0-3 - rebuild for changed _kde4_includedir * Sun Dec 09 2007 Kevin Kofler 3.97.0-2 - rm konsoleprofile when building as kdebase4, does nothing with KDE 3 konsole kdeedu-3.97.0-4.fc9 ------------------- * Fri Dec 14 2007 Rex Dieter 3.97.0-4 - -devel: Obsoletes: marble-devel (#394011) kdegraphics-7:3.97.0-7.fc9 -------------------------- * Fri Dec 14 2007 Rex Dieter 3.97.0-7 - License: GPLv2 - Obsoletes: -extras(-libs) - cleanup BR's, scriptlets - omit devel symlink hacks kdemultimedia-6:3.97.0-3.fc9 ---------------------------- * Fri Dec 14 2007 Rex Dieter 3.97.0-3 - -libs: Obsoletes: -extras(-libs) - cleanup BR's - omit parallel-install symlink hacks kdenetwork-7:3.97.0-5.fc9 ------------------------- * Fri Dec 14 2007 Rex Dieter 3.97.0-5 - Obsoletes: -extras ... - Requires: rdesktop (#420801), for krdc - Requires: ppp , for kppp - Requires: jasper , for kopete kdeutils-6:3.97.0-3.fc9 ----------------------- * Fri Dec 14 2007 Rex Dieter 6:3.97.0-3 - libs subpkg - Obsoletes: -extras - omit parallel-install symlink hack kernel-2.6.24-0.107.rc5.git3.fc9 -------------------------------- * Fri Dec 14 2007 David Woodhouse - Fix OProfile on non-Cell ppc64 - Fix EHCI on PS3 to allow rebooting * Fri Dec 14 2007 Dave Jones - Anaconda still needs the old sysfs files, so reenable SYSFS_DEPRECATED for now. * Fri Dec 14 2007 David Woodhouse - Enable PS3 wireless again now that it's saner - Update powermac suspend via /sys/power/state patches kftpgrabber-0.8.1-5.fc9 ----------------------- * Fri Dec 14 2007 Rex Dieter 0.8.1-5 - BR: kdelibs3-devel openssl-devel - omit .desktop Icon= munging - fixup scriptlets, Requires(post,postun): /sbin/ldconfig coreutils - (re)include plugin .la files - %summary,%description: s/for KDE// - %configure: --enable-new-ldflags koji-1.2.3-1.fc9 ---------------- * Fri Dec 14 2007 jkeating 1.2.3-1 - New upstream release with lots of updates, bugfixes, and enhancements. * Tue Jun 05 2007 Mike Bonnet - 1.2.2-1 - only allow admins to perform non-scratch builds from srpm - bug fixes to the cmd-line and web UIs * Thu May 31 2007 Mike Bonnet - 1.2.1-1 - don't allow ExclusiveArch to expand the archlist (bz#239359) - add a summary line stating whether the task succeeded or failed to the end of the "watch-task" output - add a search box to the header of every page in the web UI - new koji download-build command (patch provided by Dan Berrange) libopm-0.1-6.20050731cvs.fc9 ---------------------------- * Fri Dec 14 2007 Robert Scheck 0.1-6.20050731cvs - Solved multilib problems by removing doxygen timestamps (#342301) mkinitrd-6.0.24-1.fc9 --------------------- * Sat Dec 15 2007 Jeremy Katz - 6.0-24-1 - And fix other stupid error for root on LVM on encrypted PV * Fri Dec 14 2007 Peter Jones - 6.0.23-1 - Fix syntax error from 6.0.22-1 netdump-server-0.7.16-21.fc9 ---------------------------- * Fri Dec 14 2007 Neil Horman - 0.7.16-21 - Updating build flags to properly pass smp flags numactl-1.0.2-1.fc9 ------------------- * Fri Dec 14 2007 Neil Horman - 1.0.2-1 - Update numactl to latest version (bz 425281) openvrml-0.16.7-3.fc9 --------------------- * Tue Dec 04 2007 Martin Stransky - 0.16.7-3 - rebuilt against xulrunner (gecko-libs 1.9) * Tue Nov 27 2007 Braden McDaniel - 0.16.7-2 - Updated gecko-libs dependency to 1.8.1.10. perl-MooseX-AttributeHelpers-0.06-1.fc9 --------------------------------------- * Fri Dec 14 2007 Chris Weyl 0.06-1 - update to 0.06 perl-Net-DNS-0.61-3.fc9 ----------------------- * Fri Dec 14 2007 Robin Norwood - 0.61-3 - Split Nameserver.pm into subpackage, per recommendation from upstream maintainer Dick Franks. - Separates the server bits from the client bits. - Removes the dependancy on perl(Net::IP) from perl-Net-DNS - Add BR for perl(Test::Pod) and perl(Digest::BubbleBabble) plplot-5.8.0-4.fc9 ------------------ * Fri Dec 14 2007 - Orion Poplawski - 5.8.0-4 - Rebuild for new octave api puppet-0.24.0-1.fc9 ------------------- * Fri Dec 14 2007 David Lutterkort - 0.24.0-1 - Fixed license - Munge examples/ to make rpmlint happier rss2email-2.61-1.1 ------------------ * Fri Dec 14 2007 Thorsten Leemhuis - 2.61-1 - Update to 2.61 scim-sinhala-0.2.0-4.fc9 ------------------------ * Fri Dec 14 2007 Pravin Satpute - 0.2.0-4.fc9 - implemented preedit in scim sinhala(#217065) source-highlight-2.8-1.fc9 -------------------------- * Fri Dec 14 2007 Adrian Reber - 2.8-1 - updated to 2.8 - license changed to GPLv3+ squashfs-tools-3.3-1 -------------------- * Fri Dec 14 2007 Jeremy Katz - 3.3-1 - Update to 3.3 squirrelmail-1.4.13-1.fc9 ------------------------- * Fri Dec 14 2007 Kevin Fenzi - 1.4.13-1 - upgrade to new upstream 1.4.13 - note that this package was never vulnerable to CVE-2007-6348 tmpwatch-2.9.12-2 ----------------- * Fri Dec 14 2007 Miloslav Trma?? - 2.9.12-2 - --atime is -u. Doh. * Fri Dec 14 2007 Miloslav Trma?? - 2.9.12-1 - Fix --nosymlinks description in the man page - Use the maximum of atime, mtime and ctime when checking whether a file is obsolete Resolves: #373301 tracker-0.6.4-2.fc9 ------------------- * Fri Dec 14 2007 Deji Akingunola - 0.6.4-2 - Backport crasher fixes from upstream svn trunk Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 beagle - 0.3.1-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 krusader - 1.80.0-3.fc9.i386 requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) beagle - 0.3.1-1.fc9.x86_64 requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.x86_64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 beagle - 0.3.1-1.fc9.ppc requires mono(gsf-sharp) = 0:0.0.0.7 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 krusader - 1.80.0-3.fc9.ppc requires libkjsembed.so.1 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) krusader - 1.80.0-3.fc9.ppc64 requires libkjsembed.so.1()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) From debarshi.ray at gmail.com Sat Dec 15 12:41:59 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 15 Dec 2007 18:11:59 +0530 Subject: Orphaning packages In-Reply-To: <20071128090938.M51926@all-the-johnsons.co.uk> References: <20071128090938.M51926@all-the-johnsons.co.uk> Message-ID: <3170f42f0712150441p402266dakc505b6ad768e6cba@mail.gmail.com> I would also like to take gnome-build. The anjuta and anjuta-gdl packages held by me are related to it, and it looks like the package is lagging behind a few upstream releases. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Sat Dec 15 12:43:45 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 15 Dec 2007 18:13:45 +0530 Subject: Renaming anjuta-gdl to libgdl Message-ID: <3170f42f0712150443g535cc4c4u34c73cfb0726e964@mail.gmail.com> I propose to rename the anjuta-gdl package to lbgdl. The prefix anjuta- seems to imply that the package is dependent on the main anjuta (owned by me) package , which is not the case. In fact, it is the other way round. Even then, it is not anjuta specific and being the GNOME Devtools Library which can be used by other applications also. Currently the gnome-python2-gdl (owned by Matthew Barnes) package provides Python bindings to this library, and would be affected by this change. The gnome-build (previously held by Paul F. Johnson) package also depends on anjuta-gdl. $ repoquery --repoid development --alldeps --whatrequires anjuta-gdl gnome-build-0:0.1.4-2.fc7.x86_64 anjuta-gdl-devel-0:0.7.3-2.fc9.x86_64 anjuta-gdl-0:0.7.3-2.fc9.i386 gnome-build-0:0.1.4-2.fc7.i386 anjuta-1:2.2.0-4.fc9.i386 anjuta-1:2.2.0-4.fc9.x86_64 gnome-python2-gdl-0:2.19.1-12.fc9.x86_64 anjuta-gdl-devel-0:0.7.3-2.fc9.i386 anjuta-gdl-0:0.7.3-2.fc9.x86_64 The %changelog tells us that the name anjuta-gdl was chosen instead of gdl since there already exists a package called gdl. Debian and Ubuntu call it libgdl. Comments? Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From pbrobinson at gmail.com Sat Dec 15 12:50:15 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 15 Dec 2007 12:50:15 +0000 Subject: rawhide report: 20071215 changes In-Reply-To: <200712151240.lBFCenav012673@porkchop.devel.redhat.com> References: <200712151240.lBFCenav012673@porkchop.devel.redhat.com> Message-ID: <5256d0b0712150450t78c711a7o83d48388c5a59fdb@mail.gmail.com> Could someone poke these for a rebuild. It looks like a poke of half a dozen packages would rebuild the majority of this list against the newer openssl/openldap packages and get rid of most of the cruft. Cheers, Pete > Broken deps for i386 > ---------------------------------------------------------- > bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 > bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 > beagle - 0.3.1-1.fc9.i386 requires mono(gsf-sharp) = 0:0.0.0.7 > callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 > callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 > callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 > callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 > callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 > callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 > d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 > d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 > gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 > gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 > grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 > grass - 6.2.2-2.fc8.i386 requires libssl.so.6 > kannel - 1.4.1-5.i386 requires libssl.so.6 > kannel - 1.4.1-5.i386 requires libcrypto.so.6 > krusader - 1.80.0-3.fc9.i386 requires libkjsembed.so.1 > mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 > mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 > mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 > mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 > mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 > mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 > nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 > nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 > octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 > php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 > php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 > proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 > proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 > proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 > proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 > showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 > showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 > subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 > subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 > subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 > subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 > taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 > xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 From jkeating at redhat.com Sat Dec 15 13:03:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 15 Dec 2007 08:03:01 -0500 Subject: rawhide report: 20071215 changes In-Reply-To: <5256d0b0712150450t78c711a7o83d48388c5a59fdb@mail.gmail.com> References: <200712151240.lBFCenav012673@porkchop.devel.redhat.com> <5256d0b0712150450t78c711a7o83d48388c5a59fdb@mail.gmail.com> Message-ID: <20071215080301.0c90ba7c@redhat.com> On Sat, 15 Dec 2007 12:50:15 +0000 "Peter Robinson" wrote: > Could someone poke these for a rebuild. It looks like a poke of half a > dozen packages would rebuild the majority of this list against the > newer openssl/openldap packages and get rid of most of the cruft. The builds that are left have genuine build problems. If it were just a simple rebuild they would have been done when I rebuilt everything else. These were tried, and failed due to various reasons. I do believe I've filed bugs for all of them, and some were fixed, these haven't been yet. -- 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 users.sourceforge.net Sat Dec 15 13:21:30 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 15 Dec 2007 06:21:30 -0700 Subject: rawhide report: 20071215 changes In-Reply-To: <5256d0b0712150450t78c711a7o83d48388c5a59fdb@mail.gmail.com> (Peter Robinson's message of "Sat\, 15 Dec 2007 12\:50\:15 +0000") References: <200712151240.lBFCenav012673@porkchop.devel.redhat.com> <5256d0b0712150450t78c711a7o83d48388c5a59fdb@mail.gmail.com> Message-ID: <1d3au4t7ol.fsf@allele2.eebweb.arizona.edu> >>>>> "PR" == Peter Robinson writes: PR> Could someone poke these for a rebuild. It looks like a poke of PR> half a dozen packages would rebuild the majority of this list PR> against the newer openssl/openldap packages and get rid of most of PR> the cruft. If only it was that easy... Most of the packages that were just a matter of simple rebuild have already been done. The package left are those are failing to rebuild after the openssl/openssl soname version bump for reasons other than the version bump (e.g. changed build environment, stricter checking). A few are waiting for responses from unresponsive maintainers and/or have ACLs that prevent other contributors (other than rel-eng) from fixing them. Some haven't been rebuilt since F-7 and thus have never been exposed to the new build environment/dep chain that exists in rawhide (this is the sort of thing that Matt Domsch's rebuild script can detect). Alex From ndbecker2 at gmail.com Sat Dec 15 14:51:49 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 15 Dec 2007 09:51:49 -0500 Subject: qscintilla2, eric4? Message-ID: I'm interested in eric4. It needs qscintilla >= 2.1, while F8 has 1.7.1. Anyone looking into this? From ndbecker2 at gmail.com Sat Dec 15 15:05:48 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 15 Dec 2007 10:05:48 -0500 Subject: texlive + tex4ht References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> Message-ID: Jindrich Novy wrote: > On Thu, Dec 13, 2007 at 12:32:28PM -0800, Bryan O'Sullivan wrote: >> Neal Becker wrote: >> > Is there a tex4ht package compatible with texlive on F8? >> >> No. The texlive package in rawhide has had the errant tex4ht-related >> files stripped out, but Jindrich's F8 repo hasn't been updated with this. >> > > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any > more (version 2007-2 and on). I will only rarely update the F8 > repository. I think you can still use: > > yum update texlive texlive-latex --enablerepo=development > > even on F8 to fix the tex4ht conflicts. There's also a possibility to > create a F8 texlive branch and to obsolete F8 tetex as well if there > would be an interest (and poppler-devel > 0.6.2-2 will occur in stable > F8 updates). > I have texlive installed on F8, but not tex4ht. I can just install the F8 tex4ht package on top? From ngompa13 at gmail.com Sat Dec 15 15:23:34 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sat, 15 Dec 2007 09:23:34 -0600 Subject: Wiki Migration In-Reply-To: <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> Message-ID: <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> If we do decide to move to a CMS, I would like to suggest that we go with Enano CMS. The conversion utilities could probably be adapted from the mediawiki version to Enano because Enano shares syntax with MediaWiki. Enano's own model of security is much more advanced from other systems, and is less likely to get hacked to bits. Enano provides fine-grained ACLS, and a better model for managing categories than Moin. It also recently started using a new search algorithm that is much faster than the original one. The searching also seems to be faster in Enano than in Moin. http://enanocms.orgis the main website. On Dec 15, 2007 4:43 AM, Peter Robinson wrote: > On Dec 14, 2007 8:22 PM, Mike McGrath wrote: > > Ok, I'm just throwing this out there for discussion. > > > > We would like to migrate from Moin to another wiki. > > > > We have yet to find any valid migration scripts that convert users, > > histories, etc. > > > > What would YOU say if we made the current wiki read only, and made the > > teams and people migrate important relevant content over to a blank wiki > > by hand (copy and paste)? > > > > I think this would also allow us to trim up the wiki a bit. So the > > question I'm asking is if we decided to go this route. How many of you > > would hate the Infrastructure group? > > The X guys are looking at moving from Moin to MediaWiki. There's a > post about some conversion tools here => > http://lists.freedesktop.org/archives/xorg/2007-December/031007.html > > Looks like to tools need a bit of work but as they say many hands make > light work so maybe some coders could help out that tool and save a > whole lot of pain for a number of people. > > Pete > > -- > 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 Sat Dec 15 15:25:50 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sat, 15 Dec 2007 09:25:50 -0600 Subject: Wiki Migration In-Reply-To: <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> Message-ID: <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> Also I would like to note that there is a very nice Fedora theme for Enano CMS that was made available since Fedora 8 came out. :) On Dec 15, 2007 9:23 AM, King InuYasha wrote: > If we do decide to move to a CMS, I would like to suggest that we go with > Enano CMS. The conversion utilities could probably be adapted from the > mediawiki version to Enano because Enano shares syntax with MediaWiki. > Enano's own model of security is much more advanced from other systems, and > is less likely to get hacked to bits. Enano provides fine-grained ACLS, and > a better model for managing categories than Moin. It also recently started > using a new search algorithm that is much faster than the original one. The > searching also seems to be faster in Enano than in Moin. > http://enanocms.org is the main website. > > > On Dec 15, 2007 4:43 AM, Peter Robinson wrote: > > > On Dec 14, 2007 8:22 PM, Mike McGrath < mmcgrath at redhat.com> wrote: > > > Ok, I'm just throwing this out there for discussion. > > > > > > We would like to migrate from Moin to another wiki. > > > > > > We have yet to find any valid migration scripts that convert users, > > > histories, etc. > > > > > > What would YOU say if we made the current wiki read only, and made the > > > teams and people migrate important relevant content over to a blank > > wiki > > > by hand (copy and paste)? > > > > > > I think this would also allow us to trim up the wiki a bit. So the > > > question I'm asking is if we decided to go this route. How many of > > you > > > would hate the Infrastructure group? > > > > The X guys are looking at moving from Moin to MediaWiki. There's a > > post about some conversion tools here => > > http://lists.freedesktop.org/archives/xorg/2007-December/031007.html > > > > Looks like to tools need a bit of work but as they say many hands make > > light work so maybe some coders could help out that tool and save a > > whole lot of pain for a number of people. > > > > Pete > > > > -- > > 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 mjs at CLEMSON.EDU Sat Dec 15 15:30:25 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 15 Dec 2007 10:30:25 -0500 Subject: texlive + tex4ht In-Reply-To: <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> Message-ID: <1197732625.8686.6.camel@vincent52.localdomain> On Sat, 2007-12-15 at 09:57 +0100, Jindrich Novy wrote: > There's also a possibility to > create a F8 texlive branch and to obsolete F8 tetex as well if there > would be an interest (and poppler-devel > 0.6.2-2 will occur in stable > F8 updates). I'd vote for that. > > Jindrich > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mschwendt.tmp0701.nospam at arcor.de Sat Dec 15 16:04:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 15 Dec 2007 17:04:44 +0100 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <200712141751.41506.dennis@ausil.us> References: <200712141630.20467.dennis@ausil.us> <20071215002338.4798b2b3.mschwendt.tmp0701.nospam@arcor.de> <200712141751.41506.dennis@ausil.us> Message-ID: <20071215170444.f23c2441.mschwendt.tmp0701.nospam@arcor.de> On Fri, 14 Dec 2007 17:51:35 -0600, Dennis Gilmore wrote: > On Friday 14 December 2007, Michael Schwendt wrote: > > On Fri, 14 Dec 2007 16:30:16 -0600, Dennis Gilmore wrote: > > > > Please join #fedora-admin in irc.freenode.net or respond to this email > > > to track the status of this outage. > > > > Note that plague is broken on anything newer than FC-6. You may need > > something like http://mschwendt.fedorapeople.org/plague/ > > Builders will be RHEL5 so should be fine. Testing will be completed before > hand. im more concerned about mock compatabilities http://mschwendt.fedorapeople.org/plague/plague-0.4.4.1-6.el5.src.rpm That one works for me with mock from EPEL5 (which gives a harmless traceback when run). It's not the latest 0.8.x mock, however, but the latest cannot be installed for EPEL5 due to missing python pkgs. From martin.sourada at seznam.cz Sat Dec 15 16:34:40 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 15 Dec 2007 17:34:40 +0100 Subject: Renaming anjuta-gdl to libgdl In-Reply-To: <3170f42f0712150443g535cc4c4u34c73cfb0726e964@mail.gmail.com> References: <3170f42f0712150443g535cc4c4u34c73cfb0726e964@mail.gmail.com> Message-ID: <1197736480.7633.6.camel@pc-notebook> On Sat, 2007-12-15 at 13:43 +0100, Debarshi 'Rishi' Ray wrote: > I propose to rename the anjuta-gdl package to lbgdl. > > The prefix anjuta- seems to imply that the package is dependent on the > main anjuta (owned by me) package , which is not the case. In fact, it > is the other way round. Even then, it is not anjuta specific and being > the GNOME Devtools Library which can be used by other applications > also. > > Currently the gnome-python2-gdl (owned by Matthew Barnes) package > provides Python bindings to this library, and would be affected by > this change. The gnome-build (previously held by Paul F. Johnson) > package also depends on anjuta-gdl. > > $ repoquery --repoid development --alldeps --whatrequires anjuta-gdl > gnome-build-0:0.1.4-2.fc7.x86_64 > anjuta-gdl-devel-0:0.7.3-2.fc9.x86_64 > anjuta-gdl-0:0.7.3-2.fc9.i386 > gnome-build-0:0.1.4-2.fc7.i386 > anjuta-1:2.2.0-4.fc9.i386 > anjuta-1:2.2.0-4.fc9.x86_64 > gnome-python2-gdl-0:2.19.1-12.fc9.x86_64 > anjuta-gdl-devel-0:0.7.3-2.fc9.i386 > anjuta-gdl-0:0.7.3-2.fc9.x86_64 > > The %changelog tells us that the name anjuta-gdl was chosen instead of > gdl since there already exists a package called gdl. Debian and Ubuntu > call it libgdl. > > Comments? > > Cheers, > Debarshi +1 for this. I always wondered why it is named anjuta-gdl while libgdl seems better name for it, and as a matter of fact I had around 'libgdl' (I was well aware of the name clash with gdl) package of mine when the review request was on progress. But at that time I wasn't fedora contributor, so I didn't comment on the name... 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 Sat Dec 15 18:02:23 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 15 Dec 2007 18:02:23 +0000 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <364d303b0712151002w537cbdabh5cab91f40a75e4b7@mail.gmail.com> On 14/12/2007, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. Please dear god yes. Mediawiki would get my vote for scalability, one less set of markup to remember and because newcomers may know it from wikipedia. > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? I'm happy to help copying the stuff over that I use. > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? Not me. Trimming the wiki would reduce replication, particularly in areas such as packaging where the duplication and sparseness is pretty horrific at times. This needs to be done and sooner rather than later I feel. As the responsiveness improves so will the overall quality. Cheers -- Christopher Brown http://www.chruz.com From bos at serpentine.com Sat Dec 15 18:38:42 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat, 15 Dec 2007 10:38:42 -0800 Subject: texlive + tex4ht In-Reply-To: <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> Message-ID: <47641F32.7080306@serpentine.com> Jindrich Novy wrote: > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any > more (version 2007-2 and on). By the way, someone pointed out that we should be packaging the tex4ht that ships with texlive instead of using the old version. As the old version of tex4ht seems to produce bad HTML files when used with the texlive packages, I think it's worth a try. References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> Message-ID: <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> On 15/12/2007, Bryan O'Sullivan wrote: > Jindrich Novy wrote: > > > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any > > more (version 2007-2 and on). > > By the way, someone pointed out that we should be packaging the tex4ht > that ships with texlive instead of using the old version. As the old > version of tex4ht seems to produce bad HTML files when used with the > texlive packages, I think it's worth a try. Well, to clarify, the options are: 1) remove the --without-tex4htk when building texlive so that the tex4ht binaries get built or 2) Continue to have an add-on package for tex4ht, which will require updating this package. This is a case where the Fedora "stick to upstream" doesn't resolve the dilemna - on the one hand texlive is an upstream, on the other, texlive4ht is an upstream. I do notice that upstream tex4ht has updates beyond the version included in texlive. That's true of many packages though, and it would be mad to start splitting everything out. Jindrich's call I guess. J. From markg85 at gmail.com Sat Dec 15 22:10:25 2007 From: markg85 at gmail.com (Mark) Date: Sat, 15 Dec 2007 14:10:25 -0800 Subject: qscintilla2, eric4? In-Reply-To: References: Message-ID: <6e24a8e80712151410y354ec602qdc1a074e904652af@mail.gmail.com> 2007/12/15, Neal Becker : > I'm interested in eric4. It needs qscintilla >= 2.1, while F8 has 1.7.1. > Anyone looking into this? My guess is that qscintilla isn't really a high priority for fedora right now (how can i see who the package maintainers are for a certain package??) so you might want to try to grab the .src.rpm of the last rpm [1] made by fedora and upgrade it yourself. to do this: rpm -ivh packagename.src.rpm go to /usr/src/redhat/SPECS/ run rpmbuild -ba the_specfile.spec (this is just to see that it builds. if it's not building it will likely give you a list of packages that you need in order to build it.) When the building works than you can start adjusting the package to your demands. open up the specfile (for example in nano, vi, gedit, kate etc) and look for the source url (probably [2]). than you have to follow it, download the latest version, put it the ../SOURCES dir (assuming your still in the SPECS dir) and than adjust your specfile. Now if your lucky than the build works and you have a new RPM which you can install.. (don't count on it) Good luck making it. [1] = http://koji.fedoraproject.org/packages/qscintilla/1.7.1/3.fc8/src/qscintilla-1.7.1-3.fc8.src.rpm [2] = http://www.riverbankcomputing.co.uk/qscintilla/download.php From stickster at gmail.com Sat Dec 15 22:28:00 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 15 Dec 2007 17:28:00 -0500 Subject: FUDCon hotel information In-Reply-To: <20071215044423.GA2468@redhat.com> References: <20071215044423.GA2468@redhat.com> Message-ID: <1197757680.9916.34.camel@localhost.localdomain> On Fri, 2007-12-14 at 23:44 -0500, Dave Jones wrote: > On Thu, Dec 13, 2007 at 05:55:11PM -0500, Max Spevack wrote: > > https://barcamp.pbwiki.com/FUDConRaleigh2008#TRAVEL > > > > In short, go to www.brownstonehotel.com > > > > Use their online reservations page. > > > > In the "Group, Corporate, etc" section enter the code RED (case > > sensitive) in order to get our corporate rates. > > I get "Invalid Corporate ID" when I added that. > I tried it in the 'Worldwide Corp. Account#' field and in the > 'Group Booking Code:' field. Hm, it worked for me yesterday -- the return invoice showed "Red Hat" for the group identification. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 jcm at redhat.com Sun Dec 16 02:09:21 2007 From: jcm at redhat.com (Jon Masters) Date: Sat, 15 Dec 2007 21:09:21 -0500 Subject: Fedora 8 i586 Anaconda issue resolved In-Reply-To: <475E6744.6050309@kanarip.com> References: <475E6744.6050309@kanarip.com> Message-ID: <1197770961.26990.0.camel@perihelion> On Tue, 2007-12-11 at 11:32 +0100, Jeroen van Meeuwen wrote: > Keith G. Robertson-Turner wrote: > > For all VIA or K6 owners waiting to install Fedora 8, Merry Christmas: > > > > http://pilot.genomicscenter.nl/revisor/f8-i386-respin/iso/ > > > > Tested and verified. Uses Anaconda backport from Rawhide. > > > > Thanks to Jeroen van Meeuwen and Bob Jensen at Fedora Unity. > > > > Please note the ISOs are not our official release and since I need to do > another respin, they will move to > http://pilot.genomicscenter.nl/revisor/20071209/ Neither address is accessible. Jon. From peter at thecodergeek.com Sun Dec 16 03:58:17 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 15 Dec 2007 19:58:17 -0800 Subject: Offline: 2007-12-22 Through 2007-12-30 Message-ID: <1197777497.8676.14.camel@tuxhugs> As I'm sure many others will do, I am going to be taking a [much needed] vacation with my family for the upcoming holidays. I'll be gone from December 22 (one week from today) through the 30th. I'll be out of the country and will not have any Net access at all while I am gone. Thus, I kindly ask that the Fedora development community watch over my packages [1] for any bug fixes, security issues, and the like that may arise during my absence. [1] http://fedoraproject.org/wiki/PeterGordon#StuffIMaintain Thanks very much; and Happy Holidays! -- 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 sundaram at fedoraproject.org Sun Dec 16 09:28:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 14:58:09 +0530 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> Message-ID: <4764EFA9.2080807@fedoraproject.org> Yaakov Nemoy wrote: > Hey List, > > After thinking it over, I've decided that having a Privacy Policy for > Smolt would be a great experiment as a community process. The rules > are pretty simple. Mike McGrath is a BDFL (That is not a Braised Duck > avec Foie gras sous Liqueur', as tasty as it might sound.) Decisions > tend to get made by the people coding, but we are looking for input to > see what people want out of Smolt. This way, we know what kind of > information gathering is desired, and which kinds are considered too > invasive. > > So I present two RFCs to you guys. This RFE is already filed but I would like to see the ability to optionally report installed package lists to Smolt similar to what popcon does in Debian. Smolt already collects the kernel version so this is just a extension of that. It has not been done before because Mugshot was doing something similar but I don't see Mugshot have a overlapping feature as a problem in this instance since better stats would allow us to integrate nice features into the package management system showing which packages are popular among other things. Rahul From debarshi.ray at gmail.com Sun Dec 16 10:00:39 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 16 Dec 2007 15:30:39 +0530 Subject: qscintilla2, eric4? In-Reply-To: <6e24a8e80712151410y354ec602qdc1a074e904652af@mail.gmail.com> References: <6e24a8e80712151410y354ec602qdc1a074e904652af@mail.gmail.com> Message-ID: <3170f42f0712160200o17abb3ffh317557e1daaceac9@mail.gmail.com> > (how can i see who the package maintainers are for a certain > package??) Using PackageDB. eg., https://admin.fedoraproject.org/pkgdb/packages/name/qscintilla > so you might want to try to grab the .src.rpm of the last > rpm [1] made by fedora and upgrade it yourself. My guess is that Rex Dieter is busy with KDE4. So instead of just making a package and keeping it for yourself, you can consider updating it in Fedora itself. That way your effort will benefit more souls than just yours. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at redhat.com Sun Dec 16 11:15:46 2007 From: buildsys at redhat.com (Build System) Date: Sun, 16 Dec 2007 06:15:46 -0500 Subject: rawhide report: 20071216 changes Message-ID: <200712161115.lBGBFkSV030108@porkchop.devel.redhat.com> New package asterisk The Open Source PBX New package libopendaap Library for connection to iTunes music shares New package openser Open Source SIP Server Updated Packages: TurboGears-1.0.3.2-7.fc9 ------------------------ * Sat Dec 15 2007 Luke Macken 1.0.3.2-7 - Add TurboGears-1.0.3.2-paginate.patch backported from upstream http://trac.turbogears.org/ticket/1629 anaconda-11.4.0.10-1 -------------------- * Sat Dec 15 2007 Jeremy Katz - 11.4.0.10-1 - Add support for encryption via autopart. (katzj) - Avoid unnecessary downloading and caching by not setting mediaid (#422801). (clumens) - Don't copy the stage2 image over for NFS installs. (clumens) - Remove an unused function. (clumens) - Allow going back to package selection after transaction errors. (clumens) - Add file conflicts to the transaction errors we show the user. (clumens) - Remove isomd5sum/.gitignore (dcantrell) atmel-firmware-1.3-4 -------------------- * Sat Dec 15 2007 kwizart < kwizart at gmail.com > - 1.3-4 - Prevent timestamps changes. cyphesis-0.5.14-2.fc9 --------------------- * Sat Dec 15 2007 Wart 0.5.14-2 - Change shell for cyphesis user on existing installs (BZ #425798) eclipse-rpm-editor-0.2.1-1.fc9 ------------------------------ * Sat Dec 15 2007 Alphonse Van Assche 0.2.1-1 - RFE eclipse spec editor should allow users to configure the format of the changelog entry (#421881) emacs-auctex-11.84-4.fc9 ------------------------ * Sun Dec 16 2007 Jonathan G. Underwood - 11.84-4 - Add macros for automatic detection of Emacs version, site-lisp directory etc - Make building of tex-preview subpackage optional, and disable for now - Adjust Requires and BuildRequires for texlive - Remove auctex-init.el since not needed - Make RELEASE utf8 ftgl-2.1.2-7.fc9 ---------------- * Sat Dec 15 2007 kwizart < kwizart at gmail.com > - 2.1.2-7 - Add -docs to fix multiarch conflicts #341191 - Fix libGL requirement. - Project Moved to sourceforge gsf-sharp-0.8.1-6.fc9 --------------------- * Sat Dec 15 2007 Christopher Aillon - 0.8.1-6 - Rebuild to pick up proper mono rpm provides jd-1.9.8-0.3.svn1637.fc9 ------------------------ * Sun Dec 16 2007 Mamoru Tasaka - 1.9.8-0.3.svn1637 - svn 1637 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls jfbterm-0.4.7-14.fc9 -------------------- * Sun Dec 16 2007 Mamoru Tasaka - 0.4.7-14 - Remove previous workaround patch for glibc >= 2.7.90 - Remove unneeded autoconf call kdesdk-3.97.0-7.fc9 ------------------- * Sun Dec 16 2007 Kevin Kofler 3.97.0-7 - don't look for libkompare*part.so in %{_kde4_libdir} - don't list D-Bus interfaces twice in file list - build Kompare documentation * Sun Dec 16 2007 Kevin Kofler 3.97.0-6 - update Kompare from SVN (rev 748928) - Kompare now installs unversioned (private) shared libs, package them properly krusader-1.80.0-4.fc9 --------------------- * Sat Dec 15 2007 Marcin Garski 1.80.0-4 - Remove kdebindings-devel dependency (#425081) libexif-0.6.15-5.fc9 -------------------- * Sat Dec 15 2007 Matthias Clasen - 0.6.15-5 - Add patch for CVE-2007-6351. Fixes bug #425641 - Add patch for CVE-2007-6352. Fixes bug #425641 libgnomekbd-2.21.4-1.fc9 ------------------------ * Thu Dec 13 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 openal-0.0.9-0.13.20060204cvs.fc9 --------------------------------- * Sat Dec 15 2007 Andreas Bierfert - 0.0.9-0.13.20060204 - directly require sdl perl-Class-MOP-0.49-1.fc9 ------------------------- * Sat Dec 15 2007 Chris Weyl 0.49-1 - update to 0.49 - note that we're now arch-specific, as there's XS-speedup goodness! - note also that 0.49 BREAKS Moose < 0.33! pyclutter-0.4.2-2.fc9 --------------------- * Sat Dec 15 2007 Daniel P. Berrange - 0.4.2-2.fc9 - Added sub-packages for gtk and gst bindings (rhbz #365981) python-fedora-0.2.90.22-1.fc9 ----------------------------- * Thu Dec 13 2007 Luke Macken - 0.2.90.22-1 - Convert fasLDAP to get its connection information fedora-db-access. - Add requirements for python-feedparser and python-bugzilla - Add fedora.tg.widgets module containing a few proof-of-concept Fedora TurboGears widgets - Add a new method to fas: get_users() that returns common public information about all users. python-lxml-1.3.6-1.fc9 ----------------------- * Sun Nov 04 2007 Jeffrey C. Ollie - 1.3.6-1 - Update to 1.3.6. python-openid-2.1.1-2.fc9 ------------------------- * Sat Dec 15 2007 Jeffrey C. Ollie - 2.1.1-2 - Ensure that python-lxml is present for ElementTree API support. python-turbocheetah-1.0-2.fc9 ----------------------------- * Sat Dec 15 2007 Luke Macken - 1.0-2 - Require python-cheetah >= 2.0.1 tclpro-1.5.0-10.20061030cvs.fc9 ------------------------------- * Sat Dec 15 2007 Wart 1.5.0-10.20061030cvs - Fix startup bug with procompile (BZ #425807) telepathy-mission-control-4.51-1.fc9 ------------------------------------ * Sat Dec 15 2007 Peter Gordon - 4.51-1 - Update to new upstream release (4.51) Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 lyx - 1.5.2-1.fc8.i386 requires tetex-preview mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.i386 requires libssl.so.6 subcommander - 1.2.2-8.fc9.i386 requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.i386 requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) lyx - 1.5.2-1.fc8.x86_64 requires tetex-preview mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.x86_64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 lyx - 1.5.2-1.fc8.ppc requires tetex-preview mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires libldap-2.3.so.0 subcommander - 1.2.2-8.fc9.ppc requires libssl.so.6 subcommander - 1.2.2-8.fc9.ppc requires libcrypto.so.6 subcommander - 1.2.2-8.fc9.ppc requires liblber-2.3.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) lyx - 1.5.2-1.fc8.ppc64 requires tetex-preview mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libcrypto.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libldap-2.3.so.0()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires libssl.so.6()(64bit) subcommander - 1.2.2-8.fc9.ppc64 requires liblber-2.3.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) From sundaram at fedoraproject.org Sun Dec 16 11:55:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 17:25:42 +0530 Subject: Are there any policy in creating SIGs? In-Reply-To: References: Message-ID: <4765123E.7010509@fedoraproject.org> Peter Lemenkov wrote: > Hello All! > I think there is demand for Fedora Erlang SIG, because there are some > erlangers using Fedora, RHEL and derivatives. > > So I've got a question - is it enough just to create proper wiki-page > (SIGs/Erlang) or I need pass some formal procedure? There are some details at http://fedoraproject.org/wiki/DefiningProjects Rahul From fedora at leemhuis.info Sun Dec 16 12:21:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 16 Dec 2007 13:21:00 +0100 Subject: EPEL report week 50 2007 Message-ID: <4765182C.50708@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week50 = Weekly EPEL Summary = Week 50/2007 == Most important happenings == * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00052.html Builders now use RHEL 5.1] * Lots of new packages (see below) -- most of them afaics thx to the wishlist processing; roozbeh added a bunch of perl-packages (some for example needed for rt3) to the wishlist; Fedora owners got a mail for those as well. == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00087.html EPEL for IA64] * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00096.html Tracker bug and bugs for broken deps in EPEL5] == Meeting == === Next Meeting === 20071219 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === Non scheduled == Stats == === General === Number of EPEL Contributors: 155 We welcome 12 new contributors: abompard garrick grenier jnovy mbarnes mgarski mso nhorman pawsa s4504kr somlo wwoods === EPEL 5 === Number of source packages: 890 Number of binary packages: 1649 There are 40 new Packages: * aalib | ASCII art library * antiword | MS Word to ASCII/Postscript converter * balsa | Mail Client * bogofilter | Fast anti-spam filtering by Bayesian statistical analysis * brasero | Gnome CD/DVD burning application * bsdiff | Binary diff/patch utility * codeblocks | An open source, cross platform, free C++ IDE * ddd | GUI for several command-line debuggers * dkms | Dynamic Kernel Module Support Framework * dvdisaster | Additional error protection for CD/DVD media * enca | Character set analyzer and detector * enigma | Clone of the ATARI game Oxyd * g2clib | GRIB2 encoder/decoder and search/indexing routines in C * gstreamer-python | Python bindings for GStreamer * gtranslator | Gettext po file editor for GNOME * gxine | GTK frontend for the xine multimedia library * inkscape | Vector-based drawing program using SVG * iozone | Filesystem benchmarking utility * iperf | Measurement tool for TCP/UDP bandwidth performance * kyum | Graphical User Frontend (GUI) for yum * libburn | Library for reading, mastering and writing optical discs * libesmtp | SMTP client library * libkexiv2 | A library to manipulate EXIF/IPTC information * libtunepimp | A library for creating MusicBrainz enabled tagging applications * netdump-server | Server for network kernel message logging and crash dumps * pcapdiff | Compares packet captures, detects forged, dropped or mangled packets * perl-Authen-SASL | SASL Authentication framework for Perl * perl-GSSAPI | Perl extension providing access to the GSSAPIv2 library * perl-IO-Interface | Perl extension for accessing network card configuration information * perl-Parse-Yapp | Perl extension for generating and using LALR parsers * perl-XML-XQL | Perl module for querying XML tree structures with XQL * phpldapadmin | Web-based tool for managing LDAP servers * php-pear-Image-GraphViz | Interface to AT&T's GraphViz tools * pygpgme | Python module for working with OpenPGP messages * python-fpconst | Python module for handling IEEE 754 floating point special values * shorewall | An iptables front end for firewall configuration * snake | Smart Network Automated Kickstart Environment * SOAPpy | Full-featured SOAP library for Python * taglib | Audio Meta-Data Library * testdisk | Tool to check and undelete partition === EPEL 4 === Number of source packages: 503 Number of binary packages: 973 There are 32 new Packages: * aalib | An ASCII art library. * bsdiff | Binary diff/patch utility * dkms | Dynamic Kernel Module Support Framework * dvdisaster | Additional error protection for CD/DVD media * enca | Character set analyzer and detector * enigma | Clone of the ATARI game Oxyd * g2clib | GRIB2 encoder/decoder and search/indexing routines in C * gtranslator | Gettext po file editor for GNOME * inkscape | Vector-based drawing program using SVG * iozone | Filesystem benchmarking utility * iperf | Measurement tool for TCP/UDP bandwidth performance * net6 | A TCP protocol abstraction for library C++ * obby | A library which provides synced document buffers * perl-Authen-SASL | SASL Authentication framework for Perl * perl-GSSAPI | Perl extension providing access to the GSSAPIv2 library * perl-IO-Interface | Perl extension for accessing network card configuration information * phpldapadmin | Web-based tool for managing LDAP servers * plotutils | GNU vector and raster graphics utilities and libraries * python-cherrypy | A pythonic, object-oriented web development framework * python-decoratortools | Use class and function decorators -- even in Python 2.3 * python-formencode | HTML form validation, generation, and convertion package * python-json | A JSON reader and writer for Python * python-nose | A discovery-based unittest extension for Python * python-paste-script | A pluggable command-line frontend * python-ruledispatch | A generic function package for Python * python-sqlobject | SQLObject -Object-Relational Manager, aka database wrapper * python-tgfastdata | Automatic user interface generation for TurboGears * python-turbojson | Python template plugin that supports json * python-turbokid | Python template plugin that supports Kid templates * shorewall | An iptables front end for firewall configuration * testdisk | Tool to check and undelete partition * TurboGears | Back-to-front web development in Python ---- ["CategoryEPELReports"] From sundaram at fedoraproject.org Sun Dec 16 13:27:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 18:57:49 +0530 Subject: Proposal for automation of MIA maintainer detection/processing In-Reply-To: <20071211111235.176922bb@redhat.com> References: <20071211111235.176922bb@redhat.com> Message-ID: <476527D5.7070502@fedoraproject.org> Jesse Keating wrote: > I've thrown together a proposal for something we discussed in FESCo > in the last couple meetings. FESCo agreed to the idea in principle, > but obviously wanted a formal proposal to digest. > > http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal > > is said proposal. I'd really like to get a lot of eyes on this and > thoughts on this before FESCo pulls the trigger to start seeing some of > the development on tools done to accomplish this. Might want to take a good look at http://lwn.net/SubscriberLink/261833/fffb675b3527f7af/ and referenced mentioned within that article. Rahul From ndbecker2 at gmail.com Sun Dec 16 13:52:31 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 16 Dec 2007 08:52:31 -0500 Subject: qscintilla2, eric4? References: <6e24a8e80712151410y354ec602qdc1a074e904652af@mail.gmail.com> <3170f42f0712160200o17abb3ffh317557e1daaceac9@mail.gmail.com> Message-ID: Debarshi 'Rishi' Ray wrote: >> (how can i see who the package maintainers are for a certain >> package??) > > Using PackageDB. eg., > https://admin.fedoraproject.org/pkgdb/packages/name/qscintilla > >> so you might want to try to grab the .src.rpm of the last >> rpm [1] made by fedora and upgrade it yourself. > > My guess is that Rex Dieter is busy with KDE4. So instead of just > making a package and keeping it for yourself, you can consider > updating it in Fedora itself. That way your effort will benefit more > souls than just yours. :-) > > Cheers, > Debarshi Here is my start at qscintilla2. It so far builds/installs the qt4 part. Question: Should we build 1 set of packages for qt3, and a second set for qt4? (A set here means qscintilla, qscintilla-designer, qscintilla-devel), as in: Wrote: /home/nbecker/RPM/RPMS/x86_64/qscintilla-snapshot.20071205-3.fc8.x86_64.rpm Wrote: /home/nbecker/RPM/RPMS/x86_64/qscintilla-designer-snapshot.20071205-3.fc8.x86_64.rpm Wrote: /home/nbecker/RPM/RPMS/x86_64/qscintilla-devel-snapshot.20071205-3.fc8.x86_64.rpm https://nbecker/RPM/qscintilla-snapshot.20071205-3.fc8.src.rpm From ndbecker2 at gmail.com Sun Dec 16 13:53:56 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 16 Dec 2007 08:53:56 -0500 Subject: qscintilla2, eric4? References: <6e24a8e80712151410y354ec602qdc1a074e904652af@mail.gmail.com> <3170f42f0712160200o17abb3ffh317557e1daaceac9@mail.gmail.com> Message-ID: Oops, make that: https://nbecker.dyndns.org/RPM/qscintilla-snapshot.20071205-3.fc8.src.rpm From andreas.bierfert at lowlatency.de Sun Dec 16 14:30:13 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 16 Dec 2007 15:30:13 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197576068.10057.6.camel@metroid.rdu.redhat.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> Message-ID: <20071216153013.3358dda9@alkaid.a.lan> On Thu, 13 Dec 2007 15:01:08 -0500 Will Woods wrote: > > I guess in the xfce rpms should start up something like this in their > > init scripts (but don't). > > Yeah - same for fluxbox and other such windowmanagers. Sorry for hopping into the discussion this late but I still think that it is NOT the duty of window managers to setup pulse correctly. Sound is something inherent to the system and not a user session. Since prominent(tm) opinion seems to diverge from this we should at least take care that these things are handled by the system automatically. By adding support for this to all window manager packages we will just work around the general problem but not solve it. One good solution would be to make a general requirement for window managers in fedora to execute some config setup script when they launch. This script then takes all relevant items for the current config and starts them up. This way future changes to pulse can be handled but also on a more global scope addition of future magic can be handled gracefully via /etc/sysconfig where it belongs and not by hoping that all package maintainers will correctly fix up their packages in time. This will however not solve the problem for CLI users but ok, that is a different story... Regards, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From loupgaroublond at gmail.com Sun Dec 16 15:12:42 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 16 Dec 2007 10:12:42 -0500 Subject: RFC for Smolt features In-Reply-To: <4764EFA9.2080807@fedoraproject.org> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <4764EFA9.2080807@fedoraproject.org> Message-ID: <7f692fec0712160712w57006728r35286842f2c35f4e@mail.gmail.com> On Dec 16, 2007 4:28 AM, Rahul Sundaram wrote: > This RFE is already filed but I would like to see the ability to > optionally report installed package lists to Smolt similar to what > popcon does in Debian. It's been asked for before, and knocked down for a number of concerns. Some people just don't want it, although, personally I do like the idea. But so far we've tried to keep Smolt's scope limited to hardware related details, or details about the overall machine. > Smolt already collects the kernel version so this is just a extension of > that. It has not been done before because Mugshot was doing something > similar but I don't see Mugshot have a overlapping feature as a problem > in this instance since better stats would allow us to integrate nice > features into the package management system showing which packages are > popular among other things. The kernel version is related to driver information that is also stored. We want to know that if someone had a problem with their foo-widget it's because they were using the older version of the driver, and not the liberated one that Fedora has worked hard for. Popcon is a great idea, but right now, I'm figuring there would be a few problems if we went ahead with it. Not to mention, there are only so many dev hours in a day, and I have some other fun things for Smolt first. -Yaakov From sundaram at fedoraproject.org Sun Dec 16 15:21:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 20:51:49 +0530 Subject: New package cvs requests. opt out of cvsextras commit rather than in? In-Reply-To: <20071205104120.3c9a9c9d@redhat.com> References: <20071204163625.6cda6f82@redhat.com> <20071204221031.GC30509@psilocybe.teonanacatl.org> <1196856166.13978.468.camel@pmac.infradead.org> <4756989C.5040605@leemhuis.info> <1196859556.15639.133.camel@localhost.localdomain> <4756A762.7070107@leemhuis.info> <4756B5D5.6030204@redhat.com> <20071205101041.2c5840cb@redhat.com> <4756C402.8090503@leemhuis.info> <20071205104120.3c9a9c9d@redhat.com> Message-ID: <4765428D.6060508@fedoraproject.org> Jesse Keating wrote: > An alternative that has been talked about before, which I see some > value in, is that a new group is created, cvsnewbies if you will, and > members of those groups only have access to the packages they own. > They over time can be promoted to cvspkgs or cvsextras or whatever > we're going to call it. Insert some criteria for promotion here. Refer http://www.debian.org/vote/2007/vote_003 Rahul From myfedora at richip.dhs.org Sun Dec 16 16:46:04 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 16 Dec 2007 09:46:04 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071216153013.3358dda9@alkaid.a.lan> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> Message-ID: <1197823564.29354.25.camel@localhost6.localdomain6> On Sun, 2007-12-16 at 15:30 +0100, Andreas Bierfert wrote: > Sorry for hopping into the discussion this late but I still think that it is > NOT the duty of window managers to setup pulse correctly. Sound is something > inherent to the system and not a user session. Since prominent(tm) opinion > seems to diverge from this we should at least take care that these things are > handled by the system automatically. By adding support for this to all window > manager packages we will just work around the general problem but not solve it. > > One good solution would be to make a general requirement for window managers in > fedora to execute some config setup script when they launch. This script then > takes all relevant items for the current config and starts them up. This way > future changes to pulse can be handled but also on a more global scope addition > of future magic can be handled gracefully via /etc/sysconfig where it belongs > and not by hoping that all package maintainers will correctly fix up their > packages in time. No, no, no. First of all, ideally, any service should be started by the app that actually needs it, either implicitly or automatically. You're right that it's not the duty of the window manager to start a sound server like PA, but I don't think the wm is what's starting it in this case. I believe it's the session manager, which makes sense because the session manager is a part of a bigger app (the DE) that knows it will actually use the sound server. If you want to run a script each time X is started, that's what xinitrc does, but there's no call for an X session to start the sound server, unless, say, it were part of the X protocol like they were planning on doing with MAS (http://www.mediaapplicationserver.net/). Again, ideally, services (including system ones) should 1) only be started and 2) actually be started when it is called for. Something similar to the way kernel modules are autoloaded when there's a need for the service. Or xinetd does for some services which use it (though with an option to actually stay resident). The question is how will this automation be inserted into PA. Will it be by inference when the pulse libs are used? Or when an attempt is made to open the network socket? It's not exactly rocket science determining WHEN the need for PA is upon the system. I'm sure it's just a matter of time before an approach is decided, but if an interim solution for Fedora is called for ... hmmm ... maybe I will backpedal. Maybe xinitrc might not be a bad place. -- Richi Plana From pertusus at free.fr Sun Dec 16 17:53:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 16 Dec 2007 18:53:13 +0100 Subject: texlive + tex4ht In-Reply-To: <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> Message-ID: <20071216175313.GB2540@free.fr> On Sat, Dec 15, 2007 at 08:12:05PM +0000, Jonathan Underwood wrote: > > This is a case where the Fedora "stick to upstream" doesn't resolve > the dilemna - on the one hand texlive is an upstream, on the other, > texlive4ht is an upstream. I do notice that upstream tex4ht has > updates beyond the version included in texlive. That's true of many > packages though, and it would be mad to start splitting everything > out. I disagree. It is mad to have something monolithic when there are different upstreams. The aim of texlive is to build a TeX distribution, the aim of fedora is to build a distribution too. So the texlive choices are not necessarily right for fedora. In the tex4ht case, the tetex-tex4ht package (I maintain) is much newer than texlive (at least in rawhide). -- Pat From seg at haxxed.com Sun Dec 16 18:30:21 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 16 Dec 2007 12:30:21 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197823564.29354.25.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> Message-ID: <1197829821.5869.3.camel@localhost> On Sun, 2007-12-16 at 09:46 -0700, Richi Plana wrote: > No, no, no. > > First of all, ideally, any service should be started by the app that > actually needs it, either implicitly or automatically. You're right that > it's not the duty of the window manager to start a sound server like PA, > but I don't think the wm is what's starting it in this case. Yes yes yes. > I believe > it's the session manager, which makes sense because the session manager > is a part of a bigger app (the DE) that knows it will actually use the > sound server. No no no. The Pulseaudio library should take care of starting the damn daemon. Like esd did. -------------- 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 at scrye.com Sun Dec 16 19:01:41 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 16 Dec 2007 12:01:41 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197829821.5869.3.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> Message-ID: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> Yeah, I guess I should setup something to start pulseaudio in Xfce, which I was really hoping to avoid. I was under the mistaken impression that if pulseaudio wasn't running, then things would fall back to raw alsa and just work as before. ;( Sadly, that doesn't seem to be the case. Hopefully bug 411151 will get fixed in the f9 cycle. Not sure if it's worth pushing a f8 update with a pulseaudio starting script or not. ;( Ideally, I would like to see ConsoleKit and pulseaudio expand to handle cases like: - user logging in on vty. - user logging in on vty and running startx/xinit - startup processes that need to be able to make sounds. - sound available in the gdm login screen - system processes that need to generate sounds on the console. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sun Dec 16 19:07:28 2007 From: drago01 at gmail.com (drago01) Date: Sun, 16 Dec 2007 20:07:28 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> Message-ID: On Dec 16, 2007 8:01 PM, Kevin Fenzi wrote: > sure if it's > worth pushing a f8 update with a pulseaudio starting script or not. ;( it is ;) nosound vs sound its an easy choice ;) (well uninstalling pa would work too but how are the users supposed to know this and its installed by default) From myfedora at richip.dhs.org Sun Dec 16 19:08:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 16 Dec 2007 12:08:06 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197829821.5869.3.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> Message-ID: <1197832086.29354.33.camel@localhost6.localdomain6> On Sun, 2007-12-16 at 12:30 -0600, Callum Lerwick wrote: > > I believe > > it's the session manager, which makes sense because the session manager > > is a part of a bigger app (the DE) that knows it will actually use the > > sound server. > > No no no. The Pulseaudio library should take care of starting the damn > daemon. Like esd did. Just for clarification's sake: I'm not saying I support the session manager starting the sound server daemon ... just that that's how I believe it's currently implemented. Using the library was one of the approaches I mentioned and seems to be the least work-intensive to implement, though doing service starting with associated well-known server ports a'la xinetd is generic enough that if everybody started doing it, we may actually appease all those users who keep clamoring for no-switching on of unneeded services which are currently done by default. (I know I've had to switch of some services like isdn, hplip, bluetooth, hidd, lm_sensors, etc.) -- Richi Plana From paul at all-the-johnsons.co.uk Sun Dec 16 19:24:43 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 16 Dec 2007 19:24:43 +0000 Subject: Unable to get s-c-display up Message-ID: <1197833083.5868.10.camel@T7.Linux> Hi, I'm currently restricted to 800x600 as s-c-d is having problems running and manually editing xorg.conf is getting me no-where. When I run s-c-display, I get the following File "/usr/share/system-config-display/xconf.py", line 294, in vc = rhpxl.videocard.VideoCardInfo() File "/usr/lib64/python2.5/site-packages/rhpxl/videocard.py", line 149, in __init__ elif rhpl.arch.getCanonArch() == "ppc64pseries": AttributeError: 'module' object has no attribute 'arch' I'm on an x86_64 box, using the nv driver and rawhide (updated today). Any help appreciated. xorg.conf file reads # Xorg configuration created by system-config-display Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "gb" EndSection Section "Device" Identifier "Videocard0" Driver "nv" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 16 SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" EndSubSection SubSection "Display" Viewport 0 0 Depth 16 Modes "800x600" EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection EndSection When I login, I get an error that the gnome-settings-daemon is unable to start something which means some backgrounds, sounds etc may not work and will restart next log in (which I get also on the next login!) 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 bos at serpentine.com Sun Dec 16 19:37:06 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun, 16 Dec 2007 11:37:06 -0800 Subject: texlive + tex4ht In-Reply-To: <20071216175313.GB2540@free.fr> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> <20071216175313.GB2540@free.fr> Message-ID: <47657E62.10403@serpentine.com> Patrice Dumas wrote: > I disagree. It is mad to have something monolithic when there are > different upstreams. Perhaps there could be a little less squabbling about which upstream is theoretically better, and a little more focus on the problem that the current combination of texlive with tetex-tex4ht produces unusable garbage? I get a big sweep of white space instead of a table of contents. This doesn't happen on Fedora 7 or 6. Hi, Just a note before I start, I'm talking mostly about Gnome but this may apply to KDE or XFCE users. I know alacarte is there for a reason, but I was wondering if others agree the system menus could use some restructuring. The generic names like 'Movie Player' are great because you can search for programs by function but what when 2+ desktop environments are installed? Which 'File Brower' am I opening - XFCE, Gnome or KDE's? It turns out that 'File Browser' opens up Nautilus, while 'File Brower - Super User Mode' pulls up konqueror. In rawhide there are two identical 'System Monitor' entries if you have KDE and Gnome installed. The only way you can tell them apart is that the entry which opens ksysgaurd doesn't have a comment. Sorting menus alphabetically and by DE (Gnome apps, ?divider, KDE apps, divider, XFCE apps) would solve this, or just use the generic names along with the program name ("Nautilus File Browser" or "Ksysguard System Monitor"). "KDE System Monitor" would work too, but there's still room for ambiguity in there. As well, I've got 29 applications listed under 'System Tools'. I understand that not everyone does because it obviously depends on which packages you have installed, but many entries do similar tasks (Terminal, Konsole, Konsole Super User Mode). A lot of space could be saved by putting them into a submenu. Regards, Stewart From kanarip at kanarip.com Sun Dec 16 19:56:33 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 16 Dec 2007 20:56:33 +0100 Subject: Fedora 8 i586 Anaconda issue resolved In-Reply-To: <1197770961.26990.0.camel@perihelion> References: <475E6744.6050309@kanarip.com> <1197770961.26990.0.camel@perihelion> Message-ID: <476582F1.5080804@kanarip.com> Jon Masters wrote: > On Tue, 2007-12-11 at 11:32 +0100, Jeroen van Meeuwen wrote: >> Keith G. Robertson-Turner wrote: >>> For all VIA or K6 owners waiting to install Fedora 8, Merry Christmas: >>> >>> http://pilot.genomicscenter.nl/revisor/f8-i386-respin/iso/ >>> >>> Tested and verified. Uses Anaconda backport from Rawhide. >>> >>> Thanks to Jeroen van Meeuwen and Bob Jensen at Fedora Unity. >>> >> Please note the ISOs are not our official release and since I need to do >> another respin, they will move to >> http://pilot.genomicscenter.nl/revisor/20071209/ > > Neither address is accessible. > You're right, they're not -on purpose. These ISO images were not our official release, they were out there for our testers. Another spin is in our testing process now and solves different issues too. If anyone is interested in actually testing the images, please contact Fedora Unity via the test-team mailing list at http://lists.fedoraunity.org/mailman/listinfo/test-team and provide your fedoraunity.org website account name so we can give you the appropriate access to the appropriate files. The more testers, the sooner this spin can be released. Kind regards, Jeroen van Meeuwen -kanarip From mschwendt.tmp0701.nospam at arcor.de Sun Dec 16 20:07:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 16 Dec 2007 21:07:02 +0100 Subject: Unable to get s-c-display up In-Reply-To: <1197833083.5868.10.camel@T7.Linux> References: <1197833083.5868.10.camel@T7.Linux> Message-ID: <20071216210702.1cccbcf1.mschwendt.tmp0701.nospam@arcor.de> On Sun, 16 Dec 2007 19:24:43 +0000, Paul wrote: > Hi, > > I'm currently restricted to 800x600 as s-c-d is having problems running > and manually editing xorg.conf is getting me no-where. > > When I run s-c-display, I get the following > > File "/usr/share/system-config-display/xconf.py", line 294, in > vc = rhpxl.videocard.VideoCardInfo() > File "/usr/lib64/python2.5/site-packages/rhpxl/videocard.py", line 149, > in __init__ > elif rhpl.arch.getCanonArch() == "ppc64pseries": > AttributeError: 'module' object has no attribute 'arch' It's a bug. An interface incompatibility between the "rhpl" Python module and the xconf.py code. From smooge at gmail.com Sun Dec 16 20:33:51 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 16 Dec 2007 13:33:51 -0700 Subject: RFC for Smolt features In-Reply-To: <7f692fec0712141630o6c1ff7b7gf234dac1413dea07@mail.gmail.com> References: <7f692fec0712122005u991b8d2vd7161b8ed50dddd@mail.gmail.com> <80d7e4090712122124k7318f8a5k2ff84a837ff2c836@mail.gmail.com> <7f692fec0712122129w75f742f7h8aec087d34fbfccd@mail.gmail.com> <80d7e4090712131558l35625354n71eec848835053ca@mail.gmail.com> <7f692fec0712131715p11e58a8u939182dcbd9b73d3@mail.gmail.com> <80d7e4090712141410y3537eabew5cd7d286e19ae3e3@mail.gmail.com> <7f692fec0712141630o6c1ff7b7gf234dac1413dea07@mail.gmail.com> Message-ID: <80d7e4090712161233k419151c1x88578d8ea40ccf1b@mail.gmail.com> On Dec 14, 2007 5:30 PM, Yaakov Nemoy wrote: > On Dec 14, 2007 5:10 PM, Stephen John Smoogen wrote: > > Hmmm I would prefer a plugin technology because flipping booleans is > > not that hard.. and some people would prefer not to have XYZ Selinux, > > Shadow Password reporting items on their system at all. While some > > other organization might. > > Both require root access. Both publish the same data. Both garner > the same criticism. Both require the same published privacy policy. > > But plugins gain us the ability for an over eager client to send the > server something we're not prepared to deal with. Plugins definitely > offer some potential, but then they have to be implemented on a server > level, either through forks, or some fundamental change to our > server's source code, because storing plugin related information means > changing the data model on a web based application. > Well I guess you could go with a structure like the following: Client -> Server Hi I am smolt client [public-key XYZ] Server -> Client Hi I am a smoon server [public-key ABC] Client determines if that is a server on its ok list to talk to. Server determines if that is a client on its ok list to talk to. Client says "I can tell you A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V" Server says "Thanks. I listen for D,E,I,K" Client sends D,E,I,K and does not send the rest. I am fudging various stuff where you would work out a mutual trust mechanism and a mutual filter mechanism. Or it could be: Client -> Server Hi I am smolt client [public-key XYZ] Server -> Client Hi I am a smoon server [public-key ABC] Client determines if that is a server on its ok list to talk to. Server determines if that is a client on its ok list to talk to. Client asks for what plugins the server wants it to get. Server sends down the plugins. Client tests that the plugins are signed by mutual 3rd party key. Client test that it can run the plugins. Client runs the plugins and sends the data to the server. > But you're right, flipping booleans is not hard. I'd rather people > were flipping booleans than flipping digits at us. > > > -Yaakov > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Sun Dec 16 20:43:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 16 Dec 2007 21:43:36 +0100 Subject: texlive + tex4ht In-Reply-To: <47657E62.10403@serpentine.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> <20071216175313.GB2540@free.fr> <47657E62.10403@serpentine.com> Message-ID: <20071216204336.GC2540@free.fr> On Sun, Dec 16, 2007 at 11:37:06AM -0800, Bryan O'Sullivan wrote: > Patrice Dumas wrote: > > > I disagree. It is mad to have something monolithic when there are > > different upstreams. > > Perhaps there could be a little less squabbling about which upstream is > theoretically better, and a little more focus on the problem that the > current combination of texlive with tetex-tex4ht produces unusable > garbage? I am focused on this. The tex4ht version is more up to date that the one that comes with texlive. > I get a big sweep of white space instead of a table of > contents. This doesn't happen on Fedora 7 or 6. Bugzilla is a better place for these discussion, please file a bug, with the document (if possible), the command-line and the output. Also did you tried the tex4ht version bundled with texlive and produced a correct document or is it a guess? -- Pat From abo at kth.se Sun Dec 16 21:21:46 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 16 Dec 2007 22:21:46 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197834610.32070.47.camel@Diffingo.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: <1197840106.28367.64.camel@home.alexander.bostrom.net> s?n 2007-12-16 klockan 14:50 -0500 skrev Stewart Adam: > As well, I've got 29 applications listed under 'System Tools'. I > understand that not everyone does because it obviously depends on which > packages you have installed, but many entries do similar tasks > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > saved by putting them into a submenu. In some environments (multi-user machines, many machines the with same configuration) it's today very tempting to install lots of packages which only few people will use. This makes the menus extremely cluttered though. In those cases it really would help if some apps were given preference by pushing the other apps to sub-sub-menus. The fact that some apps have launchers in the default panel helps a bit, though. /abo From paul at all-the-johnsons.co.uk Sun Dec 16 21:56:31 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 16 Dec 2007 21:56:31 +0000 Subject: Unable to get s-c-display up In-Reply-To: <20071216210702.1cccbcf1.mschwendt.tmp0701.nospam@arcor.de> References: <1197833083.5868.10.camel@T7.Linux> <20071216210702.1cccbcf1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1197842191.5868.13.camel@T7.Linux> Hi, > > File "/usr/share/system-config-display/xconf.py", line 294, in > > vc = rhpxl.videocard.VideoCardInfo() > > File "/usr/lib64/python2.5/site-packages/rhpxl/videocard.py", line 149, > > in __init__ > > elif rhpl.arch.getCanonArch() == "ppc64pseries": > > AttributeError: 'module' object has no attribute 'arch' > > It's a bug. An interface incompatibility between the "rhpl" Python module > and the xconf.py code. Is there a simple work around? 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 jspaleta at gmail.com Sun Dec 16 22:36:49 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 16 Dec 2007 13:36:49 -0900 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197834610.32070.47.camel@Diffingo.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> On Dec 16, 2007 10:50 AM, Stewart Adam wrote: > As well, I've got 29 applications listed under 'System Tools'. I > understand that not everyone does because it obviously depends on which > packages you have installed, but many entries do similar tasks > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > saved by putting them into a submenu. submenus... by default for all usage cases? I don't think this makes any sense at all. How common is it to have KDE and GNOME installed? Are we talking about fixing an issue that maybe 1% of userbase has to be annoyed by? And if we did have submenus are you talking about hiding all similar applications down in a submenu exposing no application choices at all in the System tools menu? That also seems very wrong for a default. Doesn't pretty much mean people are going to reach for alacarte to place their prefered applications in the higher level menu to avoid navigating the submenus for every application? I don't see how pushing duplicates into submenus by default avoids the need to customize the menu layouts thanks to the bounty of too many choices. What we need to do is start tracking things like recently used, or most used, or preferred in a meaningful way on a per user basis to give users the ability to quickly access things they (or the community at large) commonly use. Isn't the online desktop initiative playing around with that sort of application sorting? For multi-seat... don't we already have sabayon for administrators to tailor exactly what the initial desktop experience setup is for a new user on the system? With sabayon the admin can make a judgment as to what the menu configuration should look like, capture that in a profile and use that profile when the user is created on the system, doing the customization of the menus just once. I'm really not sure there is a good fit default menu configuration that is going to please a large enough segment of the community. Consistent use of generic and program names, I think we can all agree helps avoid confusion, but I'm not sure there will be consensus on what a default menu should look like for a cluttered install which deviates from a default selection of packages for in Spin. -jef From kevin.kofler at chello.at Sun Dec 16 22:50:14 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 16 Dec 2007 22:50:14 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: Stewart Adam diffingo.com> writes: > I know alacarte is there for a reason, but I was wondering if others > agree the system menus could use some restructuring. The generic names > like 'Movie Player' are great because you can search for programs by > function but what when 2+ desktop environments are installed? Which > 'File Brower' am I opening - XFCE, Gnome or KDE's? That's indeed a problem, but submenus aren't the answer, inserting the real name of the application is. We KDE SIG folks have been fighting for that for a while, with moderate results. > It turns out that 'File Browser' opens up Nautilus, while 'File Brower - > Super User Mode' pulls up konqueror. The entry for Konqueror is labeled "Konqueror (Systemverwaltungsmodus)" here (KDE 3.5.8, de_AT.UTF-8 locale). If there's such a vague name, that would be a bug, we normally don't use vague names in KDE .desktop files. We can patch this. > In rawhide there are two identical > 'System Monitor' entries if you have KDE and Gnome installed. The only > way you can tell them apart is that the entry which opens ksysgaurd > doesn't have a comment. That's bad too, we really have to add KSysGuard to the name there. Kevin Kofler From paul at all-the-johnsons.co.uk Mon Dec 17 00:25:00 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 17 Dec 2007 00:25:00 +0000 Subject: gtksourceview-sharp packaging problem Message-ID: <1197851100.5868.20.camel@T7.Linux> Hi, I've hit a snag when packaging a newer version of gtksourceview-sharp. The package name is currently incorrect and it should really be gtksourceview-sharp-2.0-0.10-25 (or as it is now 2.0-0.11-1). The problem is that you can't have a - sign as part of the version. Currently, the hack used is to define extra as 0.10 and then setup -q -n to set up the directories. This is wrong, but I'm not sure how to get the package name correct. Is there a way to glob the bits together to create the correct name? 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 lordmorgul at gmail.com Mon Dec 17 01:20:55 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 16 Dec 2007 17:20:55 -0800 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> Message-ID: <4765CEF7.70002@gmail.com> Jeff Spaleta wrote: > On Dec 16, 2007 10:50 AM, Stewart Adam wrote: >> As well, I've got 29 applications listed under 'System Tools'. I >> understand that not everyone does because it obviously depends on which >> packages you have installed, but many entries do similar tasks >> (Terminal, Konsole, Konsole Super User Mode). A lot of space could be >> saved by putting them into a submenu. > > submenus... by default for all usage cases? I don't think this makes > any sense at all. How common is it to have KDE and GNOME installed? > Are we talking about fixing an issue that maybe 1% of userbase has to > be annoyed by? And if we did have submenus are you talking about > hiding all similar applications down in a submenu exposing no > application choices at all in the System tools menu? That also seems > very wrong for a default. Doesn't pretty much mean people are going > to reach for alacarte to place their prefered applications in the > higher level menu to avoid navigating the submenus for every > application? I don't see how pushing duplicates into submenus by > default avoids the need to customize the menu layouts thanks to the > bounty of too many choices. I suppose the argument that users should just customize their own menus is a valid one, but we could use some improvements for the UIs available to do that. I wouldn't want a massive quantity of submenus, such as 'Text Editor' and 'Other Text Editors', etc, for each and every place there is duplication. But for separation of the basic *GTK based* versus *QT based* applications a submenu would work nicely, see next comment. > What we need to do is start tracking things like recently used, or > most used, or preferred in a meaningful way on a per user basis to > give users the ability to quickly access things they (or the community > at large) commonly use. Isn't the online desktop initiative playing > around with that sort of application sorting? I despise menu setups that change dynamically... hiding less used features takes more time when they are used and you know where they *should be* but are not. The Windows dynamic start menu is practically useless for instance when you access a great number of applications each day, and hidden menu items likewise takes longer if you know it should have been 20 items down the menu but is hidden. I think the more familiar a user becomes with a menu system the less effective this type of a priori guesswork is. Why couldn't we have KDE menus defaulted to a submenu when logged into Gnome, and vice versa? For instance, have: Games -> submenu 'KDE Games' -> listing of KDE games one per entry -> listing of Gnome games one per entry This way access to KDE games is fast enough because the submenu is at the top of the list, and gnome games are shown in the primary menu when you select Games, just one listing lower (or two if you have something for XFCE as well). > I'm really not sure there is a good fit default menu configuration > that is going to please a large enough segment of the community. > Consistent use of generic and program names, I think we can all agree > helps avoid confusion, but I'm not sure there will be consensus on > what a default menu should look like for a cluttered install which > deviates from a default selection of packages for in Spin. You're probably right that concensus will be difficult, but the current clutter doesn't really make any more sense than using prolific submenus does. At the minimum there needs to be a way to tell which desktop the listing originated from, even if its nothing more than a background color or different menu font, an asterisk at the front of those desktop files that come from another desktop ui (in gnome all kde menus have *, in kde all gnome menus have *), or anything else. A marker of some kind would make sense. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jonathan.underwood at gmail.com Mon Dec 17 01:57:35 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 17 Dec 2007 01:57:35 +0000 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197834610.32070.47.camel@Diffingo.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> On 16/12/2007, Stewart Adam wrote: > As well, I've got 29 applications listed under 'System Tools'. I > understand that not everyone does because it obviously depends on which > packages you have installed, but many entries do similar tasks > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > saved by putting them into a submenu. Related to this is something that is currently driving me utterly crazy with F-8 (not sure if this has changed in rawhide) - why do we have Application->System Tools and System->Preferences->System and System->Administration. Most users will not understand the distinction (if indeed there even is one). This is in pretty bad need of being rationalised. For example, one that always catches me out is the SElinux management stuff - it used to be under System->Administration, but is now under Applications->System Tools. There should be one and only one entry somewhere for System Admin tools. To my mind, the first step is ridding ourselves of Applications->System tools. Where we go from that point is then a big discussion. Personally, I think the only clear distinction is the following - between all the system stuff which refers to the users desktop environment and application configurations, and system wide configuration. This distinction is more or less reflected in the split between System->Preferences and System->Administration respectively. They're not great names though. Jonathan. From kevin.kofler at chello.at Mon Dec 17 02:14:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 17 Dec 2007 02:14:15 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> Message-ID: Andrew Farris gmail.com> writes: > Text Editors', etc, for each and every place there is duplication. But for > separation of the basic *GTK based* versus *QT based* applications a submenu > would work nicely, see next comment. I think that's an absolutely terrible criterion to group things by. GTK+/GNOME apps work fine under KDE, Qt/KDE apps work fine under GNOME. While for basic tasks, there's usually both a KDE and a GNOME app (still I'd like the choice! OnlyShowIn sucks!), for more advanced tasks there's often only one application, and I think that's a good thing. It doesn't make sense to waste time rewriting all applications in Qt/KDE for no reason other than "GNOME sucks" (independently of whether that's true or not) or the opposite. So I think the current "clutter" (as you call it), i.e. offering all applications in the same menu, is the best solution. Kevin Kofler From lordmorgul at gmail.com Mon Dec 17 02:58:59 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 16 Dec 2007 18:58:59 -0800 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> Message-ID: <4765E5F3.1050007@gmail.com> Kevin Kofler wrote: > Andrew Farris gmail.com> writes: >> Text Editors', etc, for each and every place there is duplication. But for >> separation of the basic *GTK based* versus *QT based* applications a submenu >> would work nicely, see next comment. > > I think that's an absolutely terrible criterion to group things by. GTK+/GNOME > apps work fine under KDE, Qt/KDE apps work fine under GNOME. While for basic > tasks, there's usually both a KDE and a GNOME app (still I'd like the choice! > OnlyShowIn sucks!), for more advanced tasks there's often only one application, > and I think that's a good thing. It doesn't make sense to waste time rewriting > all applications in Qt/KDE for no reason other than "GNOME sucks" > (independently of whether that's true or not) or the opposite. So I think the > current "clutter" (as you call it), i.e. offering all applications in the same > menu, is the best solution. > > Kevin Kofler My suggestion has nothing at all to do with Gnome/KDE suckage. I'm one of the few using both regularly/simutaneously. I never suggested that we *OnlyShowIn* at all... I suggested that items which essentially come WITH/FOR one desktop or the other be marked as such, or placed in submenus since its much more common to NOT used KDE apps while in Gnome (and vice versa) than it is to use them rather than the available 'native' app to your chosen desktop. I would also recommend that is only done where there is *duplicate entries*... in the case of an app like Kile, or Scribus (for which there aren't common exact replacements in GTK yet) those should be shown in the base menu whether you're in KDE or Gnome. And once that basic default layout is in place anyone could still edit the menus as they pleased, as Jeff was saying. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From s.adam at diffingo.com Mon Dec 17 03:09:54 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sun, 16 Dec 2007 22:09:54 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: <1197860994.5612.6.camel@Diffingo.localdomain> On Sun, 2007-12-16 at 22:50 +0000, Kevin Kofler wrote: > That's indeed a problem, but submenus aren't the answer, inserting the real > name of the application is. We KDE SIG folks have been fighting for that for a > while, with moderate results. > > The entry for Konqueror is labeled "Konqueror (Systemverwaltungsmodus)" here > (KDE 3.5.8, de_AT.UTF-8 locale). If there's such a vague name, that would be a > bug, we normally don't use vague names in KDE .desktop files. We can patch > this. Excellent - If any more turn up I'll file bugs right away. Would it be possible to get this type of naming scheme working for Gnome too? Something as simple as turning 'File Browser' into 'Nautilus File Browser' will do a lot. Stewart From s.adam at diffingo.com Mon Dec 17 03:26:58 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sun, 16 Dec 2007 22:26:58 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> Message-ID: <1197862018.5612.23.camel@Diffingo.localdomain> On Mon, 2007-12-17 at 01:57 +0000, Jonathan Underwood wrote: > On 16/12/2007, Stewart Adam wrote: > > As well, I've got 29 applications listed under 'System Tools'. I > > understand that not everyone does because it obviously depends on which > > packages you have installed, but many entries do similar tasks > > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > > saved by putting them into a submenu. > > Related to this is something that is currently driving me utterly > crazy with F-8 (not sure if this has changed in rawhide) - why do we > have > > Application->System Tools and > System->Preferences->System and > System->Administration. > > Most users will not understand the distinction (if indeed there even > is one). This is in pretty bad need of being rationalised. > > For example, one that always catches me out is the SElinux management > stuff - it used to be under System->Administration, but is now under > Applications->System Tools. Yup, it's been moved to System Tools. This is one of the reasons I mentioned submenus as an interesting solution, as under System Tools or Administration if ther was "Security" menu firewall, SELinux, and password related programs could be placed under it. I agree with what Jeff mentioned earlier, creating default for all installs is hard. Creating too many becomes redundant as well. Although grouping 5+ entries may be of value IMHO (The PulseAudio tools come to mind here as well). Stewart From s.adam at diffingo.com Mon Dec 17 03:33:05 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sun, 16 Dec 2007 22:33:05 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> Message-ID: <1197862385.5612.30.camel@Diffingo.localdomain> On Mon, 2007-12-17 at 02:14 +0000, Kevin Kofler wrote: > Andrew Farris gmail.com> writes: > > Text Editors', etc, for each and every place there is duplication. But for > > separation of the basic *GTK based* versus *QT based* applications a submenu > > would work nicely, see next comment. > > I think that's an absolutely terrible criterion to group things by. GTK+/GNOME > apps work fine under KDE, Qt/KDE apps work fine under GNOME. While for basic > tasks, there's usually both a KDE and a GNOME app (still I'd like the choice! > OnlyShowIn sucks!), for more advanced tasks there's often only one application, > and I think that's a good thing. It doesn't make sense to waste time rewriting > all applications in Qt/KDE for no reason other than "GNOME sucks" > (independently of whether that's true or not) or the opposite. So I think the > current "clutter" (as you call it), i.e. offering all applications in the same > menu, is the best solution. > > Kevin Kofler I'm just pitching the idea, but maybe it would be interesting to keep the applications listed under a single menu but sort by function as well. For example: --- Media Players --- <-- Dividers are grey ?Amarok ?Audacious ?Rhythmbox ?Totem VLC ?--- Authoring Tools --- ?Audacity ?Avidemux K3B Pitivi --- Sound Tools --- ??PulseAudio Device Chooser ?PulseAudio Manager PulseAudio Volume Meter --- Misc. --- ... One problem I can see already though is there would be a lot piling up under the Misc. section. Stewart From lordmorgul at gmail.com Mon Dec 17 04:10:08 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 16 Dec 2007 20:10:08 -0800 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197862385.5612.30.camel@Diffingo.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <1197862385.5612.30.camel@Diffingo.localdomain> Message-ID: <4765F6A0.3000206@gmail.com> Stewart Adam wrote: > I'm just pitching the idea, but maybe it would be interesting to keep the > applications listed under a single menu but sort by function as well. snip > One problem I can see already though is there would be a lot piling up > under the Misc. section. Another issue with that is the overall size of the menus when you've got that many separators; with the current menus, especially in gnome, the icon size makes each entry much too tall to use the same size separators, so you'd need to have very thin separators (maybe a much smaller font?). I don't think its that bad to have each entry in one menu as long as they are different, just adding the actual application name to the front or back of the menu text would be fine: Text Editor - GEdit Text Editor - Mousepad Mousepad - Text Editor Gedit - Text Editor We've already got that type of setup going on many menus, like gThumb Image Viewer and Xpdf PDF Viewer, and both Firefox Web Browser and Epiphany Web Browser. Either way works fine really and avoids submenus, I just agree with you Stewart that the general naming is a bit out of hand when you end up with exact duplicates and can't tell what is what until you try it. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Mon Dec 17 04:33:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 16 Dec 2007 23:33:32 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <4765F6A0.3000206@gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <1197862385.5612.30.camel@Diffingo.localdomain> <4765F6A0.3000206@gmail.com> Message-ID: <1197866012.2962.18.camel@localhost.localdomain> On Sun, 2007-12-16 at 20:10 -0800, Andrew Farris wrote: > I don't think its that bad to have each entry in one menu as long as they are > different, just adding the actual application name to the front or back of the > menu text would be fine: > Text Editor - GEdit > Text Editor - Mousepad > > Mousepad - Text Editor > Gedit - Text Editor > > We've already got that type of setup going on many menus, like gThumb Image > Viewer and Xpdf PDF Viewer, and both Firefox Web Browser and Epiphany Web Browser. > > Either way works fine really and avoids submenus, I just agree with you Stewart > that the general naming is a bit out of hand when you end up with exact > duplicates and can't tell what is what until you try it. We may indeed have to give up the generic naming that was very nice while we had the luxury to define the menu layout for a single default install. In the new multi-spin world order, we may have to accept the "name - generic name" style, even if it break localization to a certain degree. For the general problem of menu overcrowding in everything or k+g installations, I believe that only moving to a dynamic menu system like bigboard will significantly improve the situation. Matthias From skvidal at fedoraproject.org Mon Dec 17 06:13:55 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Dec 2007 01:13:55 -0500 Subject: accessing package info from koji Message-ID: <1197872035.18618.6.camel@cutter> I've been working on a new version of createrepo that uses the yum modules to read in the package metadata. It's not really changing createrepo fundamentally it just simplifies the code and reduces a lot of duplication b/t createrepo and yum. However, one of the things that comes out of this is the ability to create 'fake' yum package objects comprised of data sucked directly out of koji. The idea is that instead of getting a list of pkgs, getting the metadata from them, then putting that metadata into the repodata xml format you could just connect to koji with a list of specific packages you wanted, request where the packages exist on disk (or a url to retrieve them) and all the package metadata directly. anyway -for simplicity purposes it would be most convenient to do this by forming an xml-rpc connection to koji and asking it for all the required metadata for any particular package. Right now the simplest way would be to have the xml-rpc connecting module create a yum packgeobject and just submit it to the existing class. So, what I'm wondering is: 1. is all of this info available from inside koji? 2. is it possible to connect to the xml-rpc interface anonymously? 3. will it actually be faster or at least better to do this at all? -sv From kevin.kofler at chello.at Mon Dec 17 07:31:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 17 Dec 2007 07:31:41 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> <1197860994.5612.6.camel@Diffingo.localdomain> Message-ID: Stewart Adam diffingo.com> writes: > > The entry for Konqueror is labeled "Konqueror (Systemverwaltungsmodus)" > > here (KDE 3.5.8, de_AT.UTF-8 locale). If there's such a vague name, that > > would be a bug, we normally don't use vague names in KDE .desktop files. We > > can patch this. > Excellent - If any more turn up I'll file bugs right away. I have to ask this so I know what to fix: What kdebase version and what locale did you get the vague name in? > Would it be possible to get this type of naming scheme working for Gnome > too? Something as simple as turning 'File Browser' into 'Nautilus File > Browser' will do a lot. I cannot answer this one, this is a question for the Fedora Desktop Team (the folks who handle GNOME in Fedora). Kevin Kofler From jnovy at redhat.com Mon Dec 17 07:50:01 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 17 Dec 2007 08:50:01 +0100 Subject: texlive + tex4ht In-Reply-To: References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> Message-ID: <20071217075000.GA5029@dhcp-lab-186.brq.redhat.com> On Sat, Dec 15, 2007 at 10:05:48AM -0500, Neal Becker wrote: > Jindrich Novy wrote: > > > On Thu, Dec 13, 2007 at 12:32:28PM -0800, Bryan O'Sullivan wrote: > >> Neal Becker wrote: > >> > Is there a tex4ht package compatible with texlive on F8? > >> > >> No. The texlive package in rawhide has had the errant tex4ht-related > >> files stripped out, but Jindrich's F8 repo hasn't been updated with this. > >> > > > > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any > > more (version 2007-2 and on). I will only rarely update the F8 > > repository. I think you can still use: > > > > yum update texlive texlive-latex --enablerepo=development > > > > even on F8 to fix the tex4ht conflicts. There's also a possibility to > > create a F8 texlive branch and to obsolete F8 tetex as well if there > > would be an interest (and poppler-devel > 0.6.2-2 will occur in stable > > F8 updates). > > > > I have texlive installed on F8, but not tex4ht. I can just install the F8 > tex4ht package on top? > Yes, but with texlive-texmf >= 2007-2. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From bbbush.yuan at gmail.com Mon Dec 17 08:23:47 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Mon, 17 Dec 2007 16:23:47 +0800 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197866012.2962.18.camel@localhost.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <1197862385.5612.30.camel@Diffingo.localdomain> <4765F6A0.3000206@gmail.com> <1197866012.2962.18.camel@localhost.localdomain> Message-ID: <76e72f800712170023p2ab07a8tb45452a72d84d406@mail.gmail.com> Hi, What about an completely new applet that can configure favourite apps and provide some default ones based on system installed packages? And one can choose if applications could update the entries automatically. I think there is such an applet somewhere on the web. The generic names are essential to this, like icon naming spec of freedesktop. Maybe this kind of thing (construct personal menus easier + pre-defined templates) will not require a new applet? -- bbbush ^_^ From j.w.r.degoede at hhs.nl Mon Dec 17 08:44:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Dec 2007 09:44:33 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <4765CEF7.70002@gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> Message-ID: <476636F1.9030102@hhs.nl> Andrew Farris wrote: > For instance, have: > Games -> submenu 'KDE Games' -> listing of KDE games one per entry > -> listing of Gnome games one per entry > > This way access to KDE games is fast enough because the submenu is at the top of > the list, and gnome games are shown in the primary menu when you select Games, > just one listing lower (or two if you have something for XFCE as well). Actually, in the case of games, the way too long menu when you install lots of games (and who doesn't) has long been fixed, a simple "yum install games-menus" will change your games applications menu (under all fdo menuspec compliant environments) to have categorized submenu's using the official fdo spec Game categories. Unfortunately the gnome app menu grabs the keyboard so pressing printscreen to make a screenshot doesn't work, I know there are delayed screenshot tools, but I'm too lazy to go figure all that out, just do: "yum install games-menus" And check it out yourselves. Similar packages could be make using the fdo menuspec's "Additional Categories" in .desktop files to create categorized submenu entries in other top level application menu's, this way people with lots of packages installed can install these submenu's please packages, and others can have the current simple layout. Notice that the bulk of the work though, is not in creating the package which installs the desktop dir's as the menuspec calls them, but in patching all .desktop file to specify sane Additional Categories. Maybe desktop-file-install should complain if not atleast one Additional Categories is present in a .desktop file? Regards, Hans From j.w.r.degoede at hhs.nl Mon Dec 17 08:47:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Dec 2007 09:47:01 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <476636F1.9030102@hhs.nl> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> Message-ID: <47663785.1010509@hhs.nl> p.s. For more technical info on the menuspec and categories see: http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry From oliver at linux-kernel.at Mon Dec 17 08:48:16 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 17 Dec 2007 09:48:16 +0100 Subject: accessing package info from koji In-Reply-To: <1197872035.18618.6.camel@cutter> References: <1197872035.18618.6.camel@cutter> Message-ID: <476637D0.7030407@linux-kernel.at> On 12/17/2007 07:13 AM, seth vidal wrote: > I've been working on a new version of createrepo that uses the yum > modules to read in the package metadata. It's not really changing > createrepo fundamentally it just simplifies the code and reduces a lot > of duplication b/t createrepo and yum. However, one of the things that > comes out of this is the ability to create 'fake' yum package objects > comprised of data sucked directly out of koji. > > The idea is that instead of getting a list of pkgs, getting the metadata > from them, then putting that metadata into the repodata xml format you > could just connect to koji with a list of specific packages you wanted, > request where the packages exist on disk (or a url to retrieve them) and > all the package metadata directly. > > anyway -for simplicity purposes it would be most convenient to do this > by forming an xml-rpc connection to koji and asking it for all the > required metadata for any particular package. > > Right now the simplest way would be to have the xml-rpc connecting > module create a yum packgeobject and just submit it to the existing > class. > > So, what I'm wondering is: > 1. is all of this info available from inside koji? > 2. is it possible to connect to the xml-rpc interface anonymously? > 3. will it actually be faster or at least better to do this at all? Well. What info do you need? You might have a look into koji list-api! Basic info: [oliver at tuborg ~]$ koji rpminfo openssl-0.9.8b-17.fc8.alpha RPM: openssl-0.9.8b-17.fc8.alpha [34056] RPM Path: /mnt/koji/packages/openssl/0.9.8b/17.fc8/alpha/openssl-0.9.8b-17.fc8.alpha.rpm SRPM: openssl-0.9.8b-17.fc8 [12593] SRPM Path: /mnt/koji/packages/openssl/0.9.8b/17.fc8/src/openssl-0.9.8b-17.fc8.src.rpm Built: Thu, 25 Oct 2007 04:36:26 CEST Payload: fc0d712476cfa8d19984a7a96fc355f3 Size: 1625947 Build ID: 12593 And eg for dependencies: [oliver at tuborg ~]$ koji call getRPMDeps 34056 [{'flags': 16384, 'name': '/bin/sh', 'type': 0, 'version': ''}, {'flags': 1344, 'name': '/sbin/ldconfig', 'type': 0, 'version': ''}, {'flags': 4416, 'name': '/sbin/ldconfig', 'type': 0, 'version': ''}, {'flags': 268435464, 'name': 'config(openssl)', 'type': 0, 'version': '0.9.8b-17.fc8'}, {'flags': 16384, 'name': 'libc.so.6.1', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.0)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.1)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.1.3)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.3)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.3.4)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.4)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libcom_err.so.2', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libcrypto.so.6', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libdl.so.2.1', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libdl.so.2.1(GLIBC_2.0)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libdl.so.2.1(GLIBC_2.1)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libgssapi_krb5.so.2', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libk5crypto.so.3', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libk5crypto.so.3(k5crypto_3_MIT)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libkrb5.so.3', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libkrb5.so.3(krb5_3_MIT)', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libresolv.so.2.1', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libssl.so.6', 'type': 0, 'version': ''}, {'flags': 16384, 'name': 'libz.so.1', 'type': 0, 'version': ''}, {'flags': 0, 'name': 'mktemp', 'type': 0, 'version': ''}, {'flags': 16777290, 'name': 'rpmlib(CompressedFileNames)', 'type': 0, 'version': '3.0.4-1'}, {'flags': 16777290, 'name': 'rpmlib(PayloadFilesHavePrefix)', 'type': 0, 'version': '4.0-1'}, {'flags': 16384, 'name': 'rtld(GNU_HASH)', 'type': 0, 'version': ''}, {'flags': 268435464, 'name': 'config(openssl)', 'type': 1, 'version': '0.9.8b-17.fc8'}, {'flags': 32768, 'name': 'lib4758cca.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libaep.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libatalla.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libchil.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libcrypto.so.6', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libcswift.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libgmp.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libnuron.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libssl.so.6', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libsureware.so', 'type': 1, 'version': ''}, {'flags': 32768, 'name': 'libubsec.so', 'type': 1, 'version': ''}, {'flags': 8, 'name': 'openssl', 'type': 1, 'version': '0.9.8b-17.fc8'}] -of From jnovy at redhat.com Mon Dec 17 08:50:49 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 17 Dec 2007 09:50:49 +0100 Subject: texlive + tex4ht In-Reply-To: <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> Message-ID: <20071217085049.GB5029@dhcp-lab-186.brq.redhat.com> On Sat, Dec 15, 2007 at 08:12:05PM +0000, Jonathan Underwood wrote: > On 15/12/2007, Bryan O'Sullivan wrote: > > Jindrich Novy wrote: > > > > > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any > > > more (version 2007-2 and on). > > > > By the way, someone pointed out that we should be packaging the tex4ht > > that ships with texlive instead of using the old version. As the old > > version of tex4ht seems to produce bad HTML files when used with the > > texlive packages, I think it's worth a try. > > Well, to clarify, the options are: > > 1) remove the --without-tex4htk when building texlive so that the > tex4ht binaries get built > > or > > 2) Continue to have an add-on package for tex4ht, which will require > updating this package. > > This is a case where the Fedora "stick to upstream" doesn't resolve > the dilemna - on the one hand texlive is an upstream, on the other, > texlive4ht is an upstream. I do notice that upstream tex4ht has > updates beyond the version included in texlive. That's true of many > packages though, and it would be mad to start splitting everything > out. > > Jindrich's call I guess. > > J. I vote for 2) generally. Considering that TeXLive is mostly a set of collections gathered from multiple upstreams at some time, it makes perfectly sense to separate the most frequently used bits to their own packages and let them updated/maintained separately by their own separate maintainers. The ideal situation IMO would be to have only core TeX/LaTeX bits in the base TeXLive installation and most of the collections that need to be updated more frequently than TeXLive release cycle (~once per 2 years) out of it. To keep consistency with TeXLive, the main texlive/texlive-texmf packages could Requires: bits packaged separately as soon as someone decides to maintain it separately. That would keep the TeXLive updated, based on users' needs even in the middle of the TeXLive release cycle. Any thoughts? Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From nicu_fedora at nicubunu.ro Mon Dec 17 09:32:15 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 17 Dec 2007 11:32:15 +0200 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <476636F1.9030102@hhs.nl> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> Message-ID: <4766421F.8050500@nicubunu.ro> Hans de Goede wrote: > > Actually, in the case of games, the way too long menu when you install > lots of games (and who doesn't) has long been fixed, a simple "yum > install games-menus" will change your games applications menu (under all > fdo menuspec compliant environments) to have categorized submenu's using > the official fdo spec Game categories. There is one thing I personally would like to see about games and menu (and I expect it is not specs compliant): all unplayable the games because of no data available (needing the autodownloader to be run) in a separate menu, so I could ignore them easily in the Games Spin. Yeah, they cold move from that menu in the proper location once the data is available, but this is really a "pie in the sky" scenario. -- 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 kraxel at redhat.com Mon Dec 17 09:50:17 2007 From: kraxel at redhat.com (Gerd Hoffmann) Date: Mon, 17 Dec 2007 10:50:17 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197834610.32070.47.camel@Diffingo.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> Message-ID: <47664659.5060105@redhat.com> Stewart Adam wrote: > Hi, > > Just a note before I start, I'm talking mostly about Gnome but this may > apply to KDE or XFCE users. > > I know alacarte is there for a reason, but I was wondering if others > agree the system menus could use some restructuring. The generic names > like 'Movie Player' are great because you can search for programs by > function but what when 2+ desktop environments are installed? Which > 'File Brower' am I opening - XFCE, Gnome or KDE's? SuSE has a quite neat scheme for that. In KDE at least, dunno about gnome / others, I'm a KDE fanboy ;) Menu structure is like this: -> applications -> internet -> email <- GenericName -> kmail <- Name -> thunderburd <- Name The special trick now is that it doesn't show menus with only one entry. If you had only one email client installed, the "email" entry changed from a submenu to a button which started the one installed mailer directly. cheers, Gerd From kevin.kofler at chello.at Mon Dec 17 10:37:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 17 Dec 2007 10:37:03 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> Message-ID: Nicu Buculei nicubunu.ro> writes: > There is one thing I personally would like to see about games and menu > (and I expect it is not specs compliant): all unplayable the games > because of no data available (needing the autodownloader to be run) in a > separate menu, so I could ignore them easily in the Games Spin. > Yeah, they cold move from that menu in the proper location once the data > is available, but this is really a "pie in the sky" scenario. IMHO the right solution for this problem would be to ban autodownloader and everything using it (or worse, requiring original proprietary and charged-for game CDs) from the distribution. I see that tool as both an ugly kludge and a way to circumvent Fedora's licensing requirements. It also sends the entirely wrong message to upstream projects: before, it was "If you want to have your game in Fedora, you have to fix your licensing.", now it's "We'll just hack around it with autodownloader and ignore our Fedora Objectives entirely.". :-( In addition, for data files where the license allows non-commercial redistribution, it would IMHO be more user-friendly to have a fully-playable package in rpmfusion non-free than an autodownloader hack in Fedora. Kevin Kofler From buildsys at redhat.com Mon Dec 17 10:39:08 2007 From: buildsys at redhat.com (Build System) Date: Mon, 17 Dec 2007 05:39:08 -0500 Subject: rawhide report: 20071217 changes Message-ID: <200712171039.lBHAd8rC031976@porkchop.devel.redhat.com> New package pam_fprint Integrate libfprint with existing applications Updated Packages: KoboDeluxe-0.5.0-1.fc9 ---------------------- * Sun Dec 16 2007 Hans de Goede 0.5.0-1 - New upstream release 0.5.0 alexandria-0.6.2-0.6.b2.fc9 --------------------------- * Sun Dec 16 2007 Mamoru Tasaka - 0.6.2-0.6.b2 - Pass exception when user don't use evolution for mailer. - Fix crash when yelp is not installed. - Add INSTALL to %doc as this file contains some useful information. atlascpp-0.6.1-2.fc9 -------------------- * Sun Dec 16 2007 Wart 0.6.1-2 - Rebuild to fix multiarch-conflicts (BZ #340691) babel-0.9.1-1.fc9 ----------------- * Sun Dec 16 2007 Jeffrey C. Ollie - 0.9.1-1 - Update to 0.9.1 cyphesis-0.5.15-1.fc9 --------------------- * Sun Dec 16 2007 Wart 0.5.15-1 - Update to 0.5.15 dblatex-0.2.8-2.fc9.1 --------------------- * Sun Dec 16 2007 Patrice Dumas - 0.2.8-2.1 - don't install in docbook directory, it is a link to a versioned directory and may break upon docbook update (#425251,#389231) eris-1.3.13-1.fc9 ----------------- * Sun Dec 16 2007 Wart 1.3.13-1 - Update to 1.3.13 - Remove multiarch conflicts (BZ #341071) gmime-2.2.12-1.fc9 ------------------ * Sun Dec 16 2007 Matthias Clasen 2.2.12-1 - Update to 2.2.12 gnome-power-manager-2.21.1-1.fc9 -------------------------------- * Mon Dec 17 2007 Matthias Clasen - 2.21.1-1 - Update to 2.21.1 haproxy-1.3.14-1.fc9 -------------------- * Sun Dec 16 2007 Jeremy Hinegardner - 1.3.14-1 - update to 1.3.14 intltool-0.37.0-1.fc9 --------------------- * Mon Dec 17 2007 Matthias Clasen - 0.37.0-1 - Update to 0.37.0 isync-1.0.3-5.fc9 ----------------- * Sun Dec 16 2007 Lubomir Kundrak 1.0.3-5 - mbsync was ignoring option letters from last argument (#425838) * 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 jd-1.9.8-0.3.svn1640.fc9 ------------------------ * Sun Dec 16 2007 Mamoru Tasaka - 1.9.8-0.3.svn1640 - svn 1640 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls manedit-0.8.1-2.fc9 ------------------- * Mon Dec 17 2007 Mamoru Tasaka - 0.8.1-2 - Revert change from 0.7.1 to fix segv when pushed new button (bug 356171) mercator-0.2.5-3.fc9 -------------------- * Sun Dec 16 2007 Wart 0.2.5-3 - Modify docs for multiarch support (BZ #342591) metacity-2.21.3-1.fc9 --------------------- * Sun Dec 16 2007 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 mfiler2-4.0.0a-1.fc9 -------------------- * Sun Dec 16 2007 Mamoru Tasaka - 4.0.0a-1 - 4.0.0a mock-0.9.3-1.fc9 ---------------- * Fri Dec 14 2007 Clark Williams - 0.9.3-1 - added '--copyin' and '--copyout' modes - added makeChrootPath() method to Root - replaced most ad hock usages of .rootdir with makeChrootPath() - updated man page && added test cases - added 'help' target to Makefile.am * Thu Dec 13 2007 Michael Brown - 0.9.2-1 - add '--update' mode - fix '--shell' mode * Tue Dec 11 2007 Michael Brown - 0.9.1-1 - fix 'mock shell' command when passing more than one arg. - add --orphanskill mode which only does orphankill - make 'mock --shell' noninteractive and logged to root.log - fix for file-based BuildRequires - add sparcs to constant list for auto-setarch nginx-0.5.34-1.fc9 ------------------ * Sat Dec 15 2007 Jeremy Hinegardner - 0.5.34-1 - update to 0.5.34 nyquist-2.37-1.fc9 ------------------ * Sun Dec 16 2007 Gerard Milmeister - 2.37-1 - new release 2.37 perl-Moose-0.33-1.fc9 --------------------- * Sat Dec 15 2007 Chris Weyl 0.33-1 - update to 0.33 policycoreutils-2.0.33-3.fc9 ---------------------------- * Fri Dec 14 2007 Dan Walsh 2.0.33-3 - Add scroll bar to fcontext gui page python-pp-1.5-1.fc9 ------------------- * Sun Dec 16 2007 Steve 'Ashcrow' Milner - 1.5-1 - Updated to upstream latest stable. ruby-marc-0.1.8-1.fc9 --------------------- selinux-policy-3.2.4-2.fc9 -------------------------- * Thu Dec 13 2007 Dan Walsh 3.2.4-1 - Dontaudit dbus user client search of /root * Wed Dec 12 2007 Dan Walsh 3.2.4-1 - Update to upstream subcommander-1.2.2-9.fc9 ------------------------ * Sun Dec 16 2007 Jochen Schmitt 1.2.2-9 - Rebuild (#425779) telepathy-haze-0.1.4-2.fc9 -------------------------- * Sun Dec 16 2007 Peter Gordon - 0.1.4-2 - Add patch from upstream Darcs to fix bug 425870 (bad apostrophe escaping with Yahoo! messages). vdr-skins-20061119-5 -------------------- * Mon Dec 10 2007 Ville Skytt?? - 20061119-5 - Adjust font paths for dejavu-lgc-fonts 2.22+ (#388891). Deja vu, indeed. * Sun Nov 18 2007 Ville Skytt?? - 20061119-4 - Adjust font paths for dejavu-lgc-fonts 2.21+ (#388891). * Fri Aug 10 2007 Ville Skytt?? - 20061119-3 - Use DejaVu LGC fonts instead of Bitstream Vera. - License: GPL+ wfmath-0.3.7-1.fc9 ------------------ * Sat Dec 15 2007 Wart 0.3.7-1 - Update to 0.3.7 - Remove dates from doc files to avoid multiarch conflicts (BZ #343421) Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 lyx - 1.5.2-1.fc8.i386 requires tetex-preview mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.i386 requires libssl.so.6 proftpd - 1.3.1-1.fc8.i386 requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.i386 requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.i386 requires liblber-2.3.so.0 sear - 0.6.3-6.fc9.i386 requires liberis-1.3.so.13 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.i386 requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) lyx - 1.5.2-1.fc8.x86_64 requires tetex-preview mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.x86_64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.x86_64 requires liblber-2.3.so.0()(64bit) sear - 0.6.3-6.fc9.x86_64 requires liberis-1.3.so.13()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.x86_64 requires libartsmodulessynth.so.0()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 lyx - 1.5.2-1.fc8.ppc requires tetex-preview mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 proftpd - 1.3.1-1.fc8.ppc requires libssl.so.6 proftpd - 1.3.1-1.fc8.ppc requires libcrypto.so.6 proftpd-ldap - 1.3.1-1.fc8.ppc requires libldap-2.3.so.0 proftpd-ldap - 1.3.1-1.fc8.ppc requires liblber-2.3.so.0 sear - 0.6.3-6.fc9.ppc requires liberis-1.3.so.13 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulessynth.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_kde.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodules.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmoduleseffects.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmidi_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulesmixers.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsbuilder.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsgui_idl.so.0 taxipilot - 0.9.2-4.fc9.ppc requires libartsmodulescommon.so.0 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) lyx - 1.5.2-1.fc8.ppc64 requires tetex-preview mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 proftpd - 1.3.1-1.fc8.ppc64 requires libcrypto.so.6()(64bit) proftpd - 1.3.1-1.fc8.ppc64 requires libssl.so.6()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires libldap-2.3.so.0()(64bit) proftpd-ldap - 1.3.1-1.fc8.ppc64 requires liblber-2.3.so.0()(64bit) sear - 0.6.3-6.fc9.ppc64 requires liberis-1.3.so.13()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsbuilder.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmidi_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_idl.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulescommon.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodules.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulesmixers.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsgui_kde.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmoduleseffects.so.0()(64bit) taxipilot - 0.9.2-4.fc9.ppc64 requires libartsmodulessynth.so.0()(64bit) From j.w.r.degoede at hhs.nl Mon Dec 17 11:11:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Dec 2007 12:11:25 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> Message-ID: <4766595D.3040703@hhs.nl> Kevin Kofler wrote: > Nicu Buculei nicubunu.ro> writes: >> There is one thing I personally would like to see about games and menu >> (and I expect it is not specs compliant): all unplayable the games >> because of no data available (needing the autodownloader to be run) in a >> separate menu, so I could ignore them easily in the Games Spin. >> Yeah, they cold move from that menu in the proper location once the data >> is available, but this is really a "pie in the sky" scenario. > > IMHO the right solution for this problem would be to ban autodownloader and > everything using it (or worse, requiring original proprietary and charged-for > game CDs) from the distribution. I see that tool as both an ugly kludge and a > way to circumvent Fedora's licensing requirements. It also sends the entirely > wrong message to upstream projects: before, it was "If you want to have your > game in Fedora, you have to fix your licensing.", now it's "We'll just hack > around it with autodownloader and ignore our Fedora Objectives entirely.". :-( > In addition, for data files where the license allows non-commercial > redistribution, it would IMHO be more user-friendly to have a fully-playable > package in rpmfusion non-free than an autodownloader hack in Fedora. > Gee, thanks for the vote of confidence, autodownloader is for the cases where upstream can not or will not change the license. For example when I started packaging bolzplatz2006 (fun game) I contacted upstream and the upstream project lead said they would fix the license of the datafiles, at the end however one of upstreams major contributers wouldn't play ball. To be more precise, atleast the following list of packages in Fedora is in Fedora because I negotiated an acceptable license with upstream, or fixed license issues by replacing troublesome parts, and that is the list which I remember right now, the real list is (much) longer: glew worminator maniadrive-music crystal-stacker crystal-stacker-themes alphabet-soup crack-attack TnL And that is not counting all the packages where I transcoded sound from troublesome formats to free formats and patched the code to be able to handle those free formats. How many license changes have _you_ negotiated recently? Regards, Hans From panemade at gmail.com Mon Dec 17 11:59:42 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 17 Dec 2007 17:29:42 +0530 Subject: Packaging Starplot and related data files In-Reply-To: <3170f42f0711252250y58a3d1fdt93d856e7cf5f294c@mail.gmail.com> References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com> <1194879094.3198.9.camel@localhost.localdomain> <3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com> <1196016006.15604.5.camel@localhost.localdomain> <4749C2C7.3050000@hhs.nl> <1196016426.15604.8.camel@localhost.localdomain> <4749C8EA.9080601@hhs.nl> <3170f42f0711252250y58a3d1fdt93d856e7cf5f294c@mail.gmail.com> Message-ID: Hi, I got review problem into following packages starplot-yale5 => https://bugzilla.redhat.com/show_bug.cgi?id=425853 and starplot-gliese3 => https://bugzilla.redhat.com/show_bug.cgi?id=425839 . Looking at packaging which looked to me simple and correct, I approved reviews. But then I got comment on review from Mamoru Tasaka that both packaging needs fix. When installed both as rpm -ihv starplot-gliese3-0.95-1.fc8.noarch.rpm --excludedocs Preparing... ########################################### [100%] 1:starplot-gliese3 ########################################### [100%] *** Does not contain starconvert spec file. error: %post(starplot-gliese3-0.95-1.fc8.noarch) scriptlet failed, exit status 1 scriptlet is failing. I need help on how to solve this problem. Regards, Parag. From tcallawa at redhat.com Mon Dec 17 12:15:53 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 17 Dec 2007 07:15:53 -0500 Subject: license change for mcrypt Message-ID: <1197893753.13234.6.camel@localhost.localdomain> mcrypt 2.6.7 (headed to rawhide, and updates for F-7/F-8) is now GPLv3+ (it was GPLv2+). Nothing requires it, as far as I can see, and it has no libraries to link to. ~spot From debarshi.ray at gmail.com Mon Dec 17 13:02:22 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 17 Dec 2007 18:32:22 +0530 Subject: Packaging Starplot and related data files In-Reply-To: References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com> <1194879094.3198.9.camel@localhost.localdomain> <3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com> <1196016006.15604.5.camel@localhost.localdomain> <4749C2C7.3050000@hhs.nl> <1196016426.15604.8.camel@localhost.localdomain> <4749C8EA.9080601@hhs.nl> <3170f42f0711252250y58a3d1fdt93d856e7cf5f294c@mail.gmail.com> Message-ID: <3170f42f0712170502l783ab5fbm1f6bf96c88b054dd@mail.gmail.com> > scriptlet is failing. I need help on how to solve this problem. I will use %{_datadir}/%{name} instead of %{_docdir}/%{name}-%{version} to generate the *.stars file. Will that be acceptable? Cheerio, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From caillon at redhat.com Mon Dec 17 13:20:12 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 17 Dec 2007 14:20:12 +0100 Subject: gtksourceview-sharp packaging problem In-Reply-To: <1197851100.5868.20.camel@T7.Linux> References: <1197851100.5868.20.camel@T7.Linux> Message-ID: <4766778C.3060208@redhat.com> On 12/17/2007 01:25 AM, Paul wrote: > Hi, > > I've hit a snag when packaging a newer version of gtksourceview-sharp. > > The package name is currently incorrect and it should really be > gtksourceview-sharp-2.0-0.10-25 (or as it is now 2.0-0.11-1). The > problem is that you can't have a - sign as part of the version. > > Currently, the hack used is to define extra as 0.10 and then setup -q -n > to set up the directories. This is wrong, but I'm not sure how to get > the package name correct. > > Is there a way to glob the bits together to create the correct name? An "easy" fix might be to rename the package to gtksourceview-sharp2, like we do for gtk-sharp2 and gecko-sharp2 which have similar issues. It should be noted that the "2.0" is actually closer to part of the package name itself than part of the package version. It works with the 2.0 version of gtksourceview (or at least that's what it connotes to me, but looks like our gtksourceview-sharp package still builds against the 1.x version of it...hm...) From jkeating at redhat.com Mon Dec 17 13:50:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 08:50:33 -0500 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <200712141630.20467.dennis@ausil.us> References: <200712141630.20467.dennis@ausil.us> Message-ID: <20071217085033.55063dfd@redhat.com> On Fri, 14 Dec 2007 16:30:16 -0600 Dennis Gilmore wrote: > There will be an outage starting at 2007-12-16 16:00 UTC, which will > last approximately 10 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2007-12-16 16:00 UTC' > > Affected Services: > > ? ? Buildsystem > > Unaffected Services: > ? ? Websites > ? ? CVS / Source Control > ? ? Database > ? ? DNS > ? ? Mail > ? ? Torrent > > Ticket Link: ? > https://fedorahosted.org/fedora-infrastructure/ticket/264 > > Reason for Outage: > the current buildsystem is run on FC-6 we are doing an OS refresh on > all build related systems. At the same time koji and mock will be > updated to the latest stable codebase's Just an update on this. We have the main koji hub updated, as well as ppc2, and xenbuilder1,2,4. That leaves ppc3,4 and hammer2 to convert. Builds are processing though. We are finding a few issues here and there with the new code sets and will be fixing them as quickly as possible, as well as other issues such as static-repos not being reachable 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: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mtasaka at ioa.s.u-tokyo.ac.jp Mon Dec 17 14:04:35 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 17 Dec 2007 23:04:35 +0900 Subject: accessing package info from koji In-Reply-To: <1197872035.18618.6.camel@cutter> References: <1197872035.18618.6.camel@cutter> Message-ID: <476681F3.2090300@ioa.s.u-tokyo.ac.jp> seth vidal wrote, at 12/17/2007 03:13 PM +9:00: > I've been working on a new version of createrepo that uses the yum > modules to read in the package metadata. It's not really changing > createrepo fundamentally it just simplifies the code and reduces a lot > of duplication b/t createrepo and yum. However, one of the things that > comes out of this is the ability to create 'fake' yum package objects > comprised of data sucked directly out of koji. > > The idea is that instead of getting a list of pkgs, getting the metadata > from them, then putting that metadata into the repodata xml format you > could just connect to koji with a list of specific packages you wanted, > request where the packages exist on disk (or a url to retrieve them) and > all the package metadata directly. > Is it related to this that currently http://koji.fedoraproject.org/static-repos/dist-f9-build-current/ or so are not accessible? I used to download rpms from here soon after new rpms are rebuilt by yum. Regards, Mamoru From tcallawa at redhat.com Mon Dec 17 14:09:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 17 Dec 2007 09:09:23 -0500 Subject: accessing package info from koji In-Reply-To: <476681F3.2090300@ioa.s.u-tokyo.ac.jp> References: <1197872035.18618.6.camel@cutter> <476681F3.2090300@ioa.s.u-tokyo.ac.jp> Message-ID: <1197900563.13234.16.camel@localhost.localdomain> On Mon, 2007-12-17 at 23:04 +0900, Mamoru Tasaka wrote: > seth vidal wrote, at 12/17/2007 03:13 PM +9:00: > > I've been working on a new version of createrepo that uses the yum > > modules to read in the package metadata. It's not really changing > > createrepo fundamentally it just simplifies the code and reduces a lot > > of duplication b/t createrepo and yum. However, one of the things that > > comes out of this is the ability to create 'fake' yum package objects > > comprised of data sucked directly out of koji. > > > > The idea is that instead of getting a list of pkgs, getting the metadata > > from them, then putting that metadata into the repodata xml format you > > could just connect to koji with a list of specific packages you wanted, > > request where the packages exist on disk (or a url to retrieve them) and > > all the package metadata directly. > > > > Is it related to this that currently > http://koji.fedoraproject.org/static-repos/dist-f9-build-current/ or > so are not accessible? I used to download rpms from here soon after > new rpms are rebuilt by yum. No, the buildsystem changes that took place yesterday evening are why the static-repos are temporarily down. Fedora Release Engineering is working on restoring them now. ~spot From walters at redhat.com Mon Dec 17 14:44:48 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Dec 2007 09:44:48 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> Message-ID: <1197902688.2937.3.camel@space-ghost.verbum.private> On Sun, 2007-12-16 at 12:01 -0700, Kevin Fenzi wrote: > Yeah, I guess I should setup something to start pulseaudio in Xfce, > which I was really hoping to avoid. > > I was under the mistaken impression that if pulseaudio wasn't running, > then things would fall back to raw alsa and just work as before. ;( > Sadly, that doesn't seem to be the case. > > Hopefully bug 411151 will get fixed in the f9 cycle. Not sure if it's > worth pushing a f8 update with a pulseaudio starting script or not. ;( > > Ideally, I would like to see ConsoleKit and pulseaudio expand to handle > cases like: > > - user logging in on vty. > - user logging in on vty and running startx/xinit These will be going away - just run X with a fullscreen shell. > - startup processes that need to be able to make sounds. > - sound available in the gdm login screen The way we're moving is that GDM is a full session running as user gdm, so running a pulse instance as gdm makes sense. > - system processes that need to generate sounds on the console. Mmm...I'd say that rather than system processes hardcoding sounds, they should be emitting status messages on the system bus, and then any interested application can take action on that, such as playing a sound. From z.kota at gmx.net Mon Dec 17 13:22:29 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Mon, 17 Dec 2007 14:22:29 +0100 (CET) Subject: openoffice-pyuno and external python programs In-Reply-To: <1197478388.924.220.camel@Jehannum> References: <1197478388.924.220.camel@Jehannum> Message-ID: On Wed, 12 Dec 2007, Caolan McNamara wrote: > On Tue, 2007-10-16 at 13:06 +0200, Zoltan Kota wrote: > > The openoffice.org-pyuno package installs uno.py and other files > > under /usr/lib/openoffice.org/program/, so with the default installations > > and settings importing uno.py from external python programs gives an > > import error. > > And how about in rawhide now, does that work for you as you wanted... > > [caolan at Jehannum ~]$ python -c "import uno" > [caolan at Jehannum ~]$ I checked it in my rawhide box. "import uno" is ok now. I will play a bit with the devel version of pyblio to test the OOo connection through uno. Zoltan From mattdm at mattdm.org Mon Dec 17 15:17:55 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Dec 2007 10:17:55 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197902688.2937.3.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> Message-ID: <20071217151755.GA21523@jadzia.bu.edu> On Mon, Dec 17, 2007 at 09:44:48AM -0500, Colin Walters wrote: > > - user logging in on vty. > > - user logging in on vty and running startx/xinit > These will be going away - just run X with a fullscreen shell. Wait, what??? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From walters at redhat.com Mon Dec 17 15:24:04 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Dec 2007 10:24:04 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217151755.GA21523@jadzia.bu.edu> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> Message-ID: <1197905044.2937.21.camel@space-ghost.verbum.private> On Mon, 2007-12-17 at 10:17 -0500, Matthew Miller wrote: > On Mon, Dec 17, 2007 at 09:44:48AM -0500, Colin Walters wrote: > > > - user logging in on vty. > > > - user logging in on vty and running startx/xinit > > These will be going away - just run X with a fullscreen shell. > > Wait, what??? The virtual consoles will still be around, but really should only be an emergency fallback. The right way to do this is to log in via gdm, and select a session that gives you a fullscreen shell (with tabs, windows, virtual desktops) etc. This gives us one supported login path for local machines, and avoids all the brokenness that occurs with multiple concurrent logins to a shared home directory. From pertusus at free.fr Mon Dec 17 15:34:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 17 Dec 2007 16:34:06 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197905044.2937.21.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> Message-ID: <20071217153406.GJ18186@free.fr> On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > > The virtual consoles will still be around, but really should only be an > emergency fallback. The right way to do this is to log in via gdm, and > select a session that gives you a fullscreen shell (with tabs, windows, > virtual desktops) etc. A display manager should not need to be installed. On servers, for example http servers you want an http server to be installed and that's all. No X server, not even X libraries (if possible). -- Pat From walters at redhat.com Mon Dec 17 15:36:25 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Dec 2007 10:36:25 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217153406.GJ18186@free.fr> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> Message-ID: <1197905785.2937.27.camel@space-ghost.verbum.private> On Mon, 2007-12-17 at 16:34 +0100, Patrice Dumas wrote: > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > > > > The virtual consoles will still be around, but really should only be an > > emergency fallback. The right way to do this is to log in via gdm, and > > select a session that gives you a fullscreen shell (with tabs, windows, > > virtual desktops) etc. > > A display manager should not need to be installed. On servers, for > example http servers you want an http server to be installed and that's > all. No X server, not even X libraries (if possible). Yes, we're not talking about servers here. From pertusus at free.fr Mon Dec 17 15:57:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 17 Dec 2007 16:57:36 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197905785.2937.27.camel@space-ghost.verbum.private> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <1197905785.2937.27.camel@space-ghost.verbum.private> Message-ID: <20071217155734.GK18186@free.fr> On Mon, Dec 17, 2007 at 10:36:25AM -0500, Colin Walters wrote: > > Yes, we're not talking about servers here. We are. A server with sound, of course. For example with sox, and also PA (since if I understand well if there is only sox things will work). -- Pat From galibert at pobox.com Mon Dec 17 16:11:02 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 17 Dec 2007 17:11:02 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197829821.5869.3.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> Message-ID: <20071217161101.GA5056@dspnet.fr.eu.org> On Sun, Dec 16, 2007 at 12:30:21PM -0600, Callum Lerwick wrote: > No no no. The Pulseaudio library should take care of starting the damn > daemon. Like esd did. Am I the only one feeling a certain unease at the idea of simple sound playing requiring a library which does fork+exec, ipc, network sockets, etc? Of course I already have this unease with alsa, but it looks like I'm the only one who cares. OG. From mdehaan at redhat.com Mon Dec 17 16:09:25 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 17 Dec 2007 11:09:25 -0500 Subject: FUDCon -- considering switching Fri/Sat schedules In-Reply-To: References: Message-ID: <47669F35.8040004@redhat.com> Max Spevack wrote: > All, > > As we try to finalize the logistics for FUDCon, it looks like it will > be a lot easier from a space point of view if we make the actual > barcamp day Saturday (instead of Friday), and use Friday and Sunday > for the Hackfests. I also think we can get a better turnout at bar > camp if it is on Saturday. > > What we want to know is: does this totally mess up anyone's plans? > None of the dates actually change, just the agenda a little bit. > > Let me know off-list. If there's no major concerns, we'll turn this > from 'proposal' to 'official' on Monday and update the main barcamp page. > > Thanks, > Max > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > You might actually get more people on Friday, as they can take off work and still count it as work :) --Michael From limb at jcomserv.net Mon Dec 17 16:11:54 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 17 Dec 2007 10:11:54 -0600 (CST) Subject: Wiki Migration In-Reply-To: <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> Message-ID: <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> > Also I would like to note that there is a very nice Fedora theme for Enano > CMS that was made available since Fedora 8 came out. :) > > On Dec 15, 2007 9:23 AM, King InuYasha wrote: > >> If we do decide to move to a CMS, I would like to suggest that we go >> with >> Enano CMS. The conversion utilities could probably be adapted from the >> mediawiki version to Enano because Enano shares syntax with MediaWiki. >> Enano's own model of security is much more advanced from other systems, >> and >> is less likely to get hacked to bits. Enano provides fine-grained ACLS, >> and >> a better model for managing categories than Moin. It also recently >> started >> using a new search algorithm that is much faster than the original one. >> The >> searching also seems to be faster in Enano than in Moin. >> http://enanocms.org is the main website. >> >> >> On Dec 15, 2007 4:43 AM, Peter Robinson wrote: >> >> > On Dec 14, 2007 8:22 PM, Mike McGrath < mmcgrath at redhat.com> wrote: >> > > Ok, I'm just throwing this out there for discussion. >> > > >> > > We would like to migrate from Moin to another wiki. >> > > >> > > We have yet to find any valid migration scripts that convert users, >> > > histories, etc. >> > > >> > > What would YOU say if we made the current wiki read only, and made >> the >> > > teams and people migrate important relevant content over to a blank >> > wiki >> > > by hand (copy and paste)? >> > > >> > > I think this would also allow us to trim up the wiki a bit. So the >> > > question I'm asking is if we decided to go this route. How many of >> > you >> > > would hate the Infrastructure group? >> > >> > The X guys are looking at moving from Moin to MediaWiki. There's a >> > post about some conversion tools here => >> > http://lists.freedesktop.org/archives/xorg/2007-December/031007.html >> > >> > Looks like to tools need a bit of work but as they say many hands make >> > light work so maybe some coders could help out that tool and save a >> > whole lot of pain for a number of people. >> > >> > Pete I had been asked by Bart Couvreur to package some Drupal modules for review, and they are still waiting. Bart, was that for a possible MoinMoin replacement, or something else? >> > -- >> > 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 sundaram at fedoraproject.org Mon Dec 17 16:14:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 17 Dec 2007 21:44:05 +0530 Subject: Wiki Migration In-Reply-To: <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> Message-ID: <4766A04D.3030003@fedoraproject.org> Jon Ciesla wrote: > I had been asked by Bart Couvreur to package some Drupal modules for > review, and they are still waiting. Bart, was that for a possible > MoinMoin replacement, or something else? IIRC, that was for the planned Fedora News site. Rahul From ngompa13 at gmail.com Mon Dec 17 16:27:15 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 17 Dec 2007 10:27:15 -0600 Subject: Wiki Migration In-Reply-To: <364d303b0712151002w537cbdabh5cab91f40a75e4b7@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <364d303b0712151002w537cbdabh5cab91f40a75e4b7@mail.gmail.com> Message-ID: <8278b1b0712170827s409a2e80keb578816429c3c9f@mail.gmail.com> What RDBMS does the Fedora Project servers run? MySQL? PostgreSQL? On Dec 15, 2007 12:02 PM, Christopher Brown wrote: > On 14/12/2007, Mike McGrath wrote: > > Ok, I'm just throwing this out there for discussion. > > > > We would like to migrate from Moin to another wiki. > > Please dear god yes. Mediawiki would get my vote for scalability, one > less set of markup to remember and because newcomers may know it from > wikipedia. > > > We have yet to find any valid migration scripts that convert users, > > histories, etc. > > > > What would YOU say if we made the current wiki read only, and made the > > teams and people migrate important relevant content over to a blank wiki > > by hand (copy and paste)? > > I'm happy to help copying the stuff over that I use. > > > I think this would also allow us to trim up the wiki a bit. So the > > question I'm asking is if we decided to go this route. How many of you > > would hate the Infrastructure group? > > Not me. Trimming the wiki would reduce replication, particularly in > areas such as packaging where the duplication and sparseness is pretty > horrific at times. This needs to be done and sooner rather than later > I feel. As the responsiveness improves so will the overall quality. > > Cheers > > -- > Christopher Brown > > 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 snecklifter at gmail.com Mon Dec 17 16:42:09 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 17 Dec 2007 16:42:09 +0000 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <4766595D.3040703@hhs.nl> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> <4766595D.3040703@hhs.nl> Message-ID: <364d303b0712170842q7026e1bfgdfc422c12a6434d0@mail.gmail.com> On 17/12/2007, Hans de Goede wrote: > Kevin Kofler wrote: > > Nicu Buculei nicubunu.ro> writes: > >> There is one thing I personally would like to see about games and menu > >> (and I expect it is not specs compliant): all unplayable the games > >> because of no data available (needing the autodownloader to be run) in a > >> separate menu, so I could ignore them easily in the Games Spin. > >> Yeah, they cold move from that menu in the proper location once the data > >> is available, but this is really a "pie in the sky" scenario. > > > > IMHO the right solution for this problem would be to ban autodownloader and > > everything using it (or worse, requiring original proprietary and charged-for > > game CDs) from the distribution. I see that tool as both an ugly kludge and a > > way to circumvent Fedora's licensing requirements. It also sends the entirely > > wrong message to upstream projects: before, it was "If you want to have your > > game in Fedora, you have to fix your licensing.", now it's "We'll just hack > > around it with autodownloader and ignore our Fedora Objectives entirely.". :-( > > In addition, for data files where the license allows non-commercial > > redistribution, it would IMHO be more user-friendly to have a fully-playable > > package in rpmfusion non-free than an autodownloader hack in Fedora. > > > > Gee, thanks for the vote of confidence, autodownloader is for the cases where > upstream can not or will not change the license. For example when I started > packaging bolzplatz2006 (fun game) I contacted upstream and the upstream > project lead said they would fix the license of the datafiles, at the end > however one of upstreams major contributers wouldn't play ball. > > To be more precise, atleast the following list of packages in Fedora is in > Fedora because I negotiated an acceptable license with upstream, or fixed > license issues by replacing troublesome parts, and that is the list which I > remember right now, the real list is (much) longer: > > glew > worminator > maniadrive-music > crystal-stacker > crystal-stacker-themes > alphabet-soup > crack-attack > TnL > > And that is not counting all the packages where I transcoded sound from > troublesome formats to free formats and patched the code to be able to handle > those free formats. > > How many license changes have _you_ negotiated recently? Awesome work - I was about to d/l the games spin for my nephew to tinker with (qv. shut him up) at xmas. However I simply don't agree with "autodownloader is for the cases where upstream can not or will not change the license". Thats a bit of a dodgy road to be headed down. Is there any chance you will re-consider this for the next release? This is now completely OT so apologies - the only comment I would make about the original topic is that the mix of System Tools and Administration section is indeed bonkers I feel, as Jonathan pointed out. Cheers -- Christopher Brown http://www.chruz.com From kevin.kofler at chello.at Mon Dec 17 16:48:21 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 17 Dec 2007 16:48:21 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> <4766595D.3040703@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > Gee, thanks for the vote of confidence, autodownloader is for the cases where > upstream can not or will not change the license. For example when I started > packaging bolzplatz2006 (fun game) I contacted upstream and the upstream > project lead said they would fix the license of the datafiles, at the end > however one of upstreams major contributers wouldn't play ball. But what do you think puts more pressure on such people? "If you don't change your license, your game cannot and will not be included in Fedora. Ever." or "Oh, too bad then, we just used autodownloader." :-/ Projects like Debian and Fedora flat-out refusing to carry non-Free stuff play a big part in getting some upstream projects to fix their licensing. Erode this policy and you remove the incentive to relicense. The policies are already very lax for game content (non-modifiable content is allowed) without autodownloader. That said, thanks a lot for the packages where you did manage to convince upstream to relicense. Kevin Kofler From myfedora at richip.dhs.org Mon Dec 17 17:10:59 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 10:10:59 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217161101.GA5056@dspnet.fr.eu.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071217161101.GA5056@dspnet.fr.eu.org> Message-ID: <1197911459.19225.15.camel@localhost6.localdomain6> On Mon, 2007-12-17 at 17:11 +0100, Olivier Galibert wrote: > On Sun, Dec 16, 2007 at 12:30:21PM -0600, Callum Lerwick wrote: > > No no no. The Pulseaudio library should take care of starting the damn > > daemon. Like esd did. > > Am I the only one feeling a certain unease at the idea of simple sound > playing requiring a library which does fork+exec, ipc, network > sockets, etc? Of course I already have this unease with alsa, but it > looks like I'm the only one who cares. First of all, a library already exists and is being used. It's the pulseaudio libraries which applications using pulse are likely to use and link against. I think even the PA alsa emulation module uses it, so that any attempt by any app linking against it should be able to start the daemon when necessary. Just remember that a fork+exec is already done. Currently by a startup script. What makes one uneasy with moving it into the lib? And lest we forget, the important thing is having apps trigger the daemon startup, which doesn't necessarily mean incorporating it into the library. There are other means. I'm just wondering at the unease you feel for incorporating it into a lib. (It's not like adding device microcode-loading software into the kernel) -- Richi Plana From myfedora at richip.dhs.org Mon Dec 17 17:11:32 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 10:11:32 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197905044.2937.21.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> Message-ID: <1197911493.19225.17.camel@localhost6.localdomain6> On Mon, 2007-12-17 at 10:24 -0500, Colin Walters wrote: > On Mon, 2007-12-17 at 10:17 -0500, Matthew Miller wrote: > > On Mon, Dec 17, 2007 at 09:44:48AM -0500, Colin Walters wrote: > > > > - user logging in on vty. > > > > - user logging in on vty and running startx/xinit > > > These will be going away - just run X with a fullscreen shell. > > > > Wait, what??? > > The virtual consoles will still be around, but really should only be an > emergency fallback. The right way to do this is to log in via gdm, and > select a session that gives you a fullscreen shell (with tabs, windows, > virtual desktops) etc. I think someone is assuming the wrong thing about why people use virtual, text-based consoles. I don't know about others, but the only reason I use VCs these days is when X won't work or something is hogging the system resources and I have to use a minimalistic shell to fix it. I don't think supporting sound via PulseAudio is a big issue for occasional VC users. But again, if PulseAudio starts itself automatically either via its library or some other trigger (such as a socket open request), it wouldn't even be an issue. > This gives us one supported login path for local machines, and avoids > all the brokenness that occurs with multiple concurrent logins to a > shared home directory. As much as I laud the attempt to incorporate smooth usage of shared home directories, I wouldn't do it at the expense of other "features" that other uses might want such as a VC or a different login manager. Not that I'm asking everything to be supported. I'm just hoping no one starts lopping off other features for causing "breakage". -- Richi Plana From sundaram at fedoraproject.org Mon Dec 17 17:07:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 17 Dec 2007 22:37:09 +0530 Subject: sabayon looking for gnomesu In-Reply-To: References: Message-ID: <4766ACBD.5090005@fedoraproject.org> Xavier Toth wrote: > Is there a gnomesu in Fedora 8? If not then what, rebuild sabayon > --enable-consolehelper? Or move to using PolicyKit. File a bug report. Rahul From a.badger at gmail.com Mon Dec 17 17:23:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 17 Dec 2007 09:23:34 -0800 Subject: Wiki Migration In-Reply-To: <8278b1b0712170827s409a2e80keb578816429c3c9f@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <364d303b0712151002w537cbdabh5cab91f40a75e4b7@mail.gmail.com> <8278b1b0712170827s409a2e80keb578816429c3c9f@mail.gmail.com> Message-ID: <4766B096.9020004@gmail.com> King InuYasha wrote: > What RDBMS does the Fedora Project servers run? MySQL? PostgreSQL? > Both. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Mon Dec 17 17:37:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Dec 2007 12:37:47 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197911459.19225.15.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071217161101.GA5056@dspnet.fr.eu.org> <1197911459.19225.15.camel@localhost6.localdomain6> Message-ID: <1197913067.19318.11.camel@localhost.localdomain> On Mon, 2007-12-17 at 10:10 -0700, Richi Plana wrote: > > Just remember that a fork+exec is already done. Currently by a startup > script. What makes one uneasy with moving it into the lib? If you have files open which do not have the close-on-exec flag I feel a bit uneasy as well. It's like libraries calling exit() or playing with signals or starting threads, etc.., I hate when apps do things the main app developer does not know about, esp. if these libraries are being included into the app via very indirect means. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From nicolas.mailhot at laposte.net Mon Dec 17 17:39:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 17 Dec 2007 18:39:10 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197905785.2937.27.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <1197905785.2937.27.camel@space-ghost.verbum.private> Message-ID: <1197913150.3396.16.camel@rousalka.dyndns.org> Le lundi 17 d?cembre 2007 ? 10:36 -0500, Colin Walters a ?crit : > On Mon, 2007-12-17 at 16:34 +0100, Patrice Dumas wrote: > > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > > > > > > The virtual consoles will still be around, but really should only be an > > > emergency fallback. The right way to do this is to log in via gdm, and > > > select a session that gives you a fullscreen shell (with tabs, windows, > > > virtual desktops) etc. > > > > A display manager should not need to be installed. On servers, for > > example http servers you want an http server to be installed and that's > > all. No X server, not even X libraries (if possible). > > Yes, we're not talking about servers here. Please don't repeat the NetworkManager "everything is a laptop with no background services and we don't care about the rest" mess. I personally have no problem making X a server requirement. X is nothing compared to some of the bloated apps we have nowadays. The problem is not X but X userspace infrastructure that assumes it can do all sorts of wasteful things because it's in a user session. And it needs to be streamlined for OLPC-like uses anyway. Purging the crazy X/non-X stack duplication we managed to grow and drilling in desktop developers heads they need to be more careful would more than make up for the X cost (a bad CLI solution to avoid X and a bad X solution to avoid treating server cases makes two bad solutions installed concurrently on most Fedora systems). However I *do* have a problem with "everything is a complete gdm session" approach. Where does stuff like sound/video PVR streaming server fit? Is it supposed to grow a separate audio backend now? -- 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 loupgaroublond at gmail.com Mon Dec 17 17:44:15 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 17 Dec 2007 12:44:15 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197911493.19225.17.camel@localhost6.localdomain6> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <1197911493.19225.17.camel@localhost6.localdomain6> Message-ID: <7f692fec0712170944t4cc4561cl7eb7bf62beff9f5e@mail.gmail.com> On Dec 17, 2007 12:11 PM, Richi Plana wrote: > I think someone is assuming the wrong thing about why people use > virtual, text-based consoles. I don't know about others, but the only > reason I use VCs these days is when X won't work or something is hogging > the system resources and I have to use a minimalistic shell to fix it. In the world of today's ?ber computers using the text console may not be necessary, but I've had some pretty old computers, that took forever to start up X. Then running a terminal, even say urxvt with font-smoothing was slow. Sometimes we just want something simple, and to have a way of supporting it. Actually, i think doing the virtual consoles through X is a cool idea, because you can do alot of very interesting things that way, but it's always something to take into consideration, what use cases us edge people have had. -Yaakov From lesmikesell at gmail.com Mon Dec 17 18:11:39 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 17 Dec 2007 12:11:39 -0600 Subject: Wiki Migration In-Reply-To: <4766A04D.3030003@fedoraproject.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> Message-ID: <4766BBDB.4080900@gmail.com> Rahul Sundaram wrote: > >> I had been asked by Bart Couvreur to package some Drupal modules for >> review, and they are still waiting. Bart, was that for a possible >> MoinMoin replacement, or something else? > > IIRC, that was for the planned Fedora News site. Would it be possible to combine the fedora development specific wiki into some kind of framework that encompasses all of the available documentation for the included packages and perhaps links to the spec files used in packaging? That way you'd have one place to go to find information about any particular program and whatever distro-specific changes might have been applied. Links to bugzilla searches for outstanding bugs in each package and a place for running user commentary would be a plus. -- Les Mikesell lesmikesell at gmail.com From jonathan.underwood at gmail.com Mon Dec 17 18:10:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 17 Dec 2007 18:10:19 +0000 Subject: texlive + tex4ht In-Reply-To: <20071217085049.GB5029@dhcp-lab-186.brq.redhat.com> References: <476196DC.9040304@serpentine.com> <20071215085728.GA2937@dhcp-lab-186.brq.redhat.com> <47641F32.7080306@serpentine.com> <645d17210712151212k4ee8d70fp20c571c86314b846@mail.gmail.com> <20071217085049.GB5029@dhcp-lab-186.brq.redhat.com> Message-ID: <645d17210712171010u428057f3nf9103313adc1eb62@mail.gmail.com> On 17/12/2007, Jindrich Novy wrote: > I vote for 2) generally. Considering that TeXLive is mostly a set of > collections gathered from multiple upstreams at some time, it makes > perfectly sense to separate the most frequently used bits to their own > packages and let them updated/maintained separately by their own separate > maintainers. > The ideal situation IMO would be to have only core TeX/LaTeX bits in the > base TeXLive installation and most of the collections that need to be > updated more frequently than TeXLive release cycle (~once per 2 years) > out of it. > To keep consistency with TeXLive, the main texlive/texlive-texmf > packages could Requires: bits packaged separately as soon as someone > decides to maintain it separately. That would keep the TeXLive > updated, based on users' needs even in the middle of the TeXLive > release cycle. > > Any thoughts? Seems reasonable. From sundaram at fedoraproject.org Mon Dec 17 18:09:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 17 Dec 2007 23:39:10 +0530 Subject: Wiki Migration In-Reply-To: <4766BBDB.4080900@gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> Message-ID: <4766BB46.3060501@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >>> I had been asked by Bart Couvreur to package some Drupal modules for >>> review, and they are still waiting. Bart, was that for a possible >>> MoinMoin replacement, or something else? >> >> IIRC, that was for the planned Fedora News site. > > Would it be possible to combine the fedora development specific wiki > into some kind of framework that encompasses all of the available > documentation for the included packages and perhaps links to the spec > files used in packaging? That way you'd have one place to go to find > information about any particular program and whatever distro-specific > changes might have been applied. Links to bugzilla searches for > outstanding bugs in each package and a place for running user commentary > would be a plus. It would be possible. Are you willing to help in any way? Refer http://fedoraproject.org/wiki/MyFedora Rahul From snecklifter at gmail.com Mon Dec 17 18:42:06 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 17 Dec 2007 18:42:06 +0000 Subject: Wiki Migration In-Reply-To: <4766BB46.3060501@fedoraproject.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> Message-ID: <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> On 17/12/2007, Rahul Sundaram wrote: > Les Mikesell wrote: > > Rahul Sundaram wrote: > >> > >>> I had been asked by Bart Couvreur to package some Drupal modules for > >>> review, and they are still waiting. Bart, was that for a possible > >>> MoinMoin replacement, or something else? > >> > >> IIRC, that was for the planned Fedora News site. > > > > Would it be possible to combine the fedora development specific wiki > > into some kind of framework that encompasses all of the available > > documentation for the included packages and perhaps links to the spec > > files used in packaging? That way you'd have one place to go to find > > information about any particular program and whatever distro-specific > > changes might have been applied. Links to bugzilla searches for > > outstanding bugs in each package and a place for running user commentary > > would be a plus. > > It would be possible. Are you willing to help in any way? Refer > > http://fedoraproject.org/wiki/MyFedora Wow, that looks like package management nirvana. As a forerunner to this, would it be possible to include browser bookmarks to infrastructure stuff in the fedora-packager package? I'm afraid as part-time packager I lose track of where bodhi/koji/packagedb etc is... Cheers -- Christopher Brown http://www.chruz.com From s.adam at diffingo.com Mon Dec 17 18:40:02 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Mon, 17 Dec 2007 13:40:02 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <1197860994.5612.6.camel@Diffingo.localdomain> Message-ID: <1197916802.3920.2.camel@Diffingo.localdomain> On Mon, 2007-12-17 at 07:31 +0000, Kevin Kofler wrote: > I have to ask this so I know what to fix: What kdebase version and what locale > did you get the vague name in? kdebase-3.97.0-4.fc9 en_US.UTF-8 > > I cannot answer this one, this is a question for the Fedora Desktop Team (the > folks who handle GNOME in Fedora). > > Kevin Kofler Stewart From lesmikesell at gmail.com Mon Dec 17 18:44:47 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 17 Dec 2007 12:44:47 -0600 Subject: Wiki Migration In-Reply-To: <4766BB46.3060501@fedoraproject.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> Message-ID: <4766C39F.8050208@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> Rahul Sundaram wrote: >>> >>>> I had been asked by Bart Couvreur to package some Drupal modules for >>>> review, and they are still waiting. Bart, was that for a possible >>>> MoinMoin replacement, or something else? >>> >>> IIRC, that was for the planned Fedora News site. >> >> Would it be possible to combine the fedora development specific wiki >> into some kind of framework that encompasses all of the available >> documentation for the included packages and perhaps links to the spec >> files used in packaging? That way you'd have one place to go to find >> information about any particular program and whatever distro-specific >> changes might have been applied. Links to bugzilla searches for >> outstanding bugs in each package and a place for running user >> commentary would be a plus. > > It would be possible. Are you willing to help in any way? Refer > > http://fedoraproject.org/wiki/MyFedora > I was thinking of something more ordinary-user facing, but the same framework and components might work. My only experience with that sort of thing is with twiki and it's %INCLUDE% feature that can pull in other pages including remote http references so I'm not sure I'd be that much help. You'd almost certainly need some kind of caching front end for public access to pages with a lot of included components. -- Les Mikesell lesmikesell at gmail.com From galibert at pobox.com Mon Dec 17 18:43:19 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 17 Dec 2007 19:43:19 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197911493.19225.17.camel@localhost6.localdomain6> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <1197911493.19225.17.camel@localhost6.localdomain6> Message-ID: <20071217184319.GA22602@dspnet.fr.eu.org> On Mon, Dec 17, 2007 at 10:11:32AM -0700, Richi Plana wrote: > I don't think supporting sound via PulseAudio is a big issue for > occasional VC users. But again, if PulseAudio starts itself > automatically either via its library or some other trigger (such as a > socket open request), it wouldn't even be an issue. And in any case VC users is only a small part of the problem. Users that log in through ssh and not to be neglected. Very often I ssh from the laptop to the desktop to start some music because the desktop has the files and is connected to the 5.1 audio system. OG. From jkeating at redhat.com Mon Dec 17 19:01:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 14:01:14 -0500 Subject: Wiki Migration In-Reply-To: <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> Message-ID: <20071217140114.27c04877@redhat.com> On Mon, 17 Dec 2007 18:42:06 +0000 "Christopher Brown" wrote: > Wow, that looks like package management nirvana. As a forerunner to > this, would it be possible to include browser bookmarks to > infrastructure stuff in the fedora-packager package? I'm afraid as > part-time packager I lose track of where bodhi/koji/packagedb etc > is... I asked about this a while ago, and apparently there can only be one bookmark pack :/ -- 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 Mon Dec 17 18:55:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 18 Dec 2007 00:25:50 +0530 Subject: Wiki Migration In-Reply-To: <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> Message-ID: <4766C636.60607@fedoraproject.org> Christopher Brown wrote: > Wow, that looks like package management nirvana. As a forerunner to > this, would it be possible to include browser bookmarks to > infrastructure stuff in the fedora-packager package? I'm afraid as > part-time packager I lose track of where bodhi/koji/packagedb etc > is... You can login using the Fedora account system credentials and file a request at https://hosted.fedoraproject.org/fedora-packager/newticket Rahul From limb at jcomserv.net Mon Dec 17 19:28:40 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 17 Dec 2007 13:28:40 -0600 (CST) Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <20071217085033.55063dfd@redhat.com> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> Message-ID: <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> > On Fri, 14 Dec 2007 16:30:16 -0600 > Dennis Gilmore wrote: > >> There will be an outage starting at 2007-12-16 16:00 UTC, which will >> last approximately 10 hours. >> >> To convert UTC to your local time, take a look at >> http://fedoraproject.org/wiki/Infrastructure/UTCHowto >> or run: >> >> date -d '2007-12-16 16:00 UTC' >> >> Affected Services: >> >> ? ? Buildsystem >> >> Unaffected Services: >> ? ? Websites >> ? ? CVS / Source Control >> ? ? Database >> ? ? DNS >> ? ? Mail >> ? ? Torrent >> >> Ticket Link: ? >> https://fedorahosted.org/fedora-infrastructure/ticket/264 >> >> Reason for Outage: >> the current buildsystem is run on FC-6 we are doing an OS refresh on >> all build related systems. At the same time koji and mock will be >> updated to the latest stable codebase's > > Just an update on this. We have the main koji hub updated, as well as > ppc2, and xenbuilder1,2,4. That leaves ppc3,4 and hammer2 to convert. > Builds are processing though. We are finding a few issues here and > there with the new code sets and will be fixing them as quickly as > possible, as well as other issues such as static-repos not being > reachable right now. I assume that this explains the delivery of cvs mail, but not koji or bodhi mail. If not, then, well, now you know. Just want to make sure. > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > _______________________________________________ > 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 -- novus ordo absurdum From jkeating at redhat.com Mon Dec 17 19:41:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 14:41:29 -0500 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> Message-ID: <20071217144129.12ef299a@redhat.com> On Mon, 17 Dec 2007 13:28:40 -0600 (CST) "Jon Ciesla" wrote: > I assume that this explains the delivery of cvs mail, but not koji or > bodhi mail. If not, then, well, now you know. Just want to make sure. I'm seeing koji mail being delivered, what are you missing? -- 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 Mon Dec 17 19:45:02 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 18 Dec 2007 01:15:02 +0530 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <20071217144129.12ef299a@redhat.com> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> <20071217144129.12ef299a@redhat.com> Message-ID: <3170f42f0712171145l7bcd3357m4a5228e683f7c44f@mail.gmail.com> > > I assume that this explains the delivery of cvs mail, but not koji or > > bodhi mail. If not, then, well, now you know. Just want to make sure. > I'm seeing koji mail being delivered, what are you missing? In my case it took longer than it usually takes to arrive after a successful build. But given the ongoing work on the builders, it is understandable. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From limb at jcomserv.net Mon Dec 17 19:44:24 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 17 Dec 2007 13:44:24 -0600 (CST) Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <20071217144129.12ef299a@redhat.com> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> <20071217144129.12ef299a@redhat.com> Message-ID: <50014.63.85.68.164.1197920664.squirrel@mail.jcomserv.net> > On Mon, 17 Dec 2007 13:28:40 -0600 (CST) > "Jon Ciesla" wrote: > >> I assume that this explains the delivery of cvs mail, but not koji or >> bodhi mail. If not, then, well, now you know. Just want to make sure. > > I'm seeing koji mail being delivered, what are you missing? http://koji.fedoraproject.org/koji/buildinfo?buildID=28344 And this: https://admin.fedoraproject.org/updates/F8/pending/astromenace-1.2-6.fc8 > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From jkeating at redhat.com Mon Dec 17 19:55:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 14:55:14 -0500 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <50014.63.85.68.164.1197920664.squirrel@mail.jcomserv.net> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> <20071217144129.12ef299a@redhat.com> <50014.63.85.68.164.1197920664.squirrel@mail.jcomserv.net> Message-ID: <20071217145514.594c695a@redhat.com> On Mon, 17 Dec 2007 13:44:24 -0600 (CST) "Jon Ciesla" wrote: > http://koji.fedoraproject.org/koji/buildinfo?buildID=28344 http://koji.fedoraproject.org/koji/taskinfo?taskID=297297 > > And this: > > https://admin.fedoraproject.org/updates/F8/pending/astromenace-1.2-6.fc8 I'm not aware of any ongoing bodhi issues. -- 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 snecklifter at gmail.com Mon Dec 17 19:57:04 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 17 Dec 2007 19:57:04 +0000 Subject: Wiki Migration In-Reply-To: <4766C636.60607@fedoraproject.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> <364d303b0712171042y477a1276l8f411448cd223c0d@mail.gmail.com> <4766C636.60607@fedoraproject.org> Message-ID: <364d303b0712171157i7d712750g167a3636c7e8308b@mail.gmail.com> On 17/12/2007, Rahul Sundaram wrote: > Christopher Brown wrote: > > > Wow, that looks like package management nirvana. As a forerunner to > > this, would it be possible to include browser bookmarks to > > infrastructure stuff in the fedora-packager package? I'm afraid as > > part-time packager I lose track of where bodhi/koji/packagedb etc > > is... > > You can login using the Fedora account system credentials and file a > request at > > https://hosted.fedoraproject.org/fedora-packager/newticket Thanks Rahul. https://hosted.fedoraproject.org/fedora-packager/ticket/2 -- Christopher Brown http://www.chruz.com From snecklifter at gmail.com Mon Dec 17 20:00:19 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 17 Dec 2007 20:00:19 +0000 Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <20071217144129.12ef299a@redhat.com> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> <20071217144129.12ef299a@redhat.com> Message-ID: <364d303b0712171200h60376506rae04609fb3b897fb@mail.gmail.com> On 17/12/2007, Jesse Keating wrote: > On Mon, 17 Dec 2007 13:28:40 -0600 (CST) > "Jon Ciesla" wrote: > > > I assume that this explains the delivery of cvs mail, but not koji or > > bodhi mail. If not, then, well, now you know. Just want to make sure. > > I'm seeing koji mail being delivered, what are you missing? I'm getting mail no problems. Previous build hung though until I checked web interface which indicated it had completed. http://koji.fedoraproject.org/koji/taskinfo?taskID=297000 Cheers -- Christopher Brown http://www.chruz.com From walters at redhat.com Mon Dec 17 20:06:36 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Dec 2007 15:06:36 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197913150.3396.16.camel@rousalka.dyndns.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <1197905785.2937.27.camel@space-ghost.verbum.private> <1197913150.3396.16.camel@rousalka.dyndns.org> Message-ID: <1197921996.2937.65.camel@space-ghost.verbum.private> On Mon, 2007-12-17 at 18:39 +0100, Nicolas Mailhot wrote: > However I *do* have a problem with "everything is a complete gdm > session" approach. Where does stuff like sound/video PVR streaming > server fit? Is it supposed to grow a separate audio backend now? How does it work now? Is it just a background daemon with a web interface? In that kind case, for something that's specialized for audio in that way I'd say just have the app in control. If they want pulse, they should spawn it. From myfedora at richip.dhs.org Mon Dec 17 20:21:56 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 13:21:56 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197921996.2937.65.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <1197905785.2937.27.camel@space-ghost.verbum.private> <1197913150.3396.16.camel@rousalka.dyndns.org> <1197921996.2937.65.camel@space-ghost.verbum.private> Message-ID: <1197922916.19225.22.camel@localhost6.localdomain6> On Mon, 2007-12-17 at 15:06 -0500, Colin Walters wrote: > On Mon, 2007-12-17 at 18:39 +0100, Nicolas Mailhot wrote: > > > However I *do* have a problem with "everything is a complete gdm > > session" approach. Where does stuff like sound/video PVR streaming > > server fit? Is it supposed to grow a separate audio backend now? > > How does it work now? Is it just a background daemon with a web > interface? > In that kind case, for something that's specialized for audio in that > way I'd say just have the app in control. If they want pulse, they > should spawn it. Actually, I understand if gdm needs to play sounds and is therefore just another PA sound client (with user gdm), but please don't make gdm the app that starts the sound server for user desktop sessions. The better place to make sound server startup an all-in-one solution is the sound server itself. -- Richi Plana From myfedora at richip.dhs.org Mon Dec 17 20:24:53 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 13:24:53 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <7f692fec0712170944t4cc4561cl7eb7bf62beff9f5e@mail.gmail.com> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <1197911493.19225.17.camel@localhost6.localdomain6> <7f692fec0712170944t4cc4561cl7eb7bf62beff9f5e@mail.gmail.com> Message-ID: <1197923093.19225.25.camel@localhost6.localdomain6> On Mon, 2007-12-17 at 12:44 -0500, Yaakov Nemoy wrote: > On Dec 17, 2007 12:11 PM, Richi Plana wrote: > > I think someone is assuming the wrong thing about why people use > > virtual, text-based consoles. I don't know about others, but the only > > reason I use VCs these days is when X won't work or something is hogging > > the system resources and I have to use a minimalistic shell to fix it. > > In the world of today's ?ber computers using the text console may not > be necessary, but I've had some pretty old computers, that took > forever to start up X. Then running a terminal, even say urxvt with > font-smoothing was slow. Sometimes we just want something simple, and > to have a way of supporting it. > > Actually, i think doing the virtual consoles through X is a cool idea, > because you can do alot of very interesting things that way, but it's > always something to take into consideration, what use cases us edge > people have had. VC over X isn't a bad idea. In fact, it's an interesting idea ... specially if we want to wean console-only users like some emacs geeks I know to X. It doesn't do anything for the context of this thread, though, which is starting the PulseAudio daemon when it is required and when using non-dictated^Wstandard login paths. -- Richi Plana From limb at jcomserv.net Mon Dec 17 20:30:07 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 17 Dec 2007 14:30:07 -0600 (CST) Subject: Outage Notification (Buildsystem) - 2007-12-16 16:00 UTC In-Reply-To: <364d303b0712171200h60376506rae04609fb3b897fb@mail.gmail.com> References: <200712141630.20467.dennis@ausil.us> <20071217085033.55063dfd@redhat.com> <34330.63.85.68.164.1197919720.squirrel@mail.jcomserv.net> <20071217144129.12ef299a@redhat.com> <364d303b0712171200h60376506rae04609fb3b897fb@mail.gmail.com> Message-ID: <38639.63.85.68.164.1197923407.squirrel@mail.jcomserv.net> > On 17/12/2007, Jesse Keating wrote: >> On Mon, 17 Dec 2007 13:28:40 -0600 (CST) >> "Jon Ciesla" wrote: >> >> > I assume that this explains the delivery of cvs mail, but not koji or >> > bodhi mail. If not, then, well, now you know. Just want to make sure. >> >> I'm seeing koji mail being delivered, what are you missing? > > I'm getting mail no problems. Previous build hung though until I > checked web interface which indicated it had completed. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=297000 The koji message just got here, about 2 hours late, and still no bodhi. > Cheers > > -- > Christopher Brown > > http://www.chruz.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From oliver at linux-kernel.at Mon Dec 17 20:42:05 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 17 Dec 2007 21:42:05 +0100 Subject: Yet another sa_restorer bug Message-ID: <4766DF1D.3070509@linux-kernel.at> https://bugzilla.redhat.com/show_bug.cgi?id=426024 This is the second sa_restorer bug I filed. However. I can only ask all of you to check if your pkgs do use signal.h and if, check if they do use sa_restorer. Maybe someone volunteers to do a grep over all sources!? And list the pkgs here!? Someone already did a similar job after the introduction of FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I don't have the ressources at the moment... Well, I'd be happy to not see any build problems because of this again :-) cya, -of From mzerqung at 0pointer.de Mon Dec 17 22:31:32 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 17 Dec 2007 23:31:32 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197576314.28623.1.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> <1197576314.28623.1.camel@localhost6.localdomain6> Message-ID: <20071217223132.GC3559@tango.0pointer.de> On Thu, 13.12.07 13:05, Richi Plana (myfedora at richip.dhs.org) wrote: > Additionally, is there a way to get real-time (or even close to RT) > support either via PA API or over ALSA API? If you know what you do you can write RT clients for PA. However, I quite frankly see not much value in doing so, since RT audio software is pro audio software. And PA is not really useful for pro audio right now. Pro audio people should be running JACK and do that directly on the HW and no pass it through PA. Also note that the RT client support in PA is still WIP. The next release will (probably) ship with lock-free client-to-server communication which should make RT clients much more useful. Right now there are still a couple of locks that need to be taken on both sides and the data path is not the shortest thinkable, so stay tuned. 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 Dec 17 22:41:10 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 17 Dec 2007 23:41:10 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <47618D4E.3080107@poolshark.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <20071213202902.5698898e@lain.camperquake.de> <1197574456.28242.0.camel@localhost6.localdomain6> <47618D4E.3080107@poolshark.org> Message-ID: <20071217224110.GD3559@tango.0pointer.de> On Thu, 13.12.07 20:51, Denis Leroy (denis at poolshark.org) wrote: >>>> 4) Sound-using apps use ALSA/ESD as usual. >>>> - It's all actually going through pulseaudio, though. >>> Wait, wait. Since pulseaudio does not, actually, talk to the hardware, >>> applications using ALSA will be rerouted through pulseaudio, which in >>> turn >>> talks to ALSA to produce sound, is that right? >> Sounds like pretty standard wrapping technique, if it is. > > How much extra latency are we getting from this ? I've noticed the extra > lag in some of our games. The latency that is introduced through the wrapping of APIs is most likely not measurable. It's not that we do additional buffering or anything. And it is certainly not hearable with human ears. Of course, it would be better if we had native PA support in every audio library we ship. I am working on that, bear with me. If you can hear the lag in those games, than it is most likely caused because we currently route all SDL output through the ESD protocol. The ESD protocol doesn't offer any reasonable control of the buffer or the latency, so that's not easy to change. All ESD data is passed through a TCP socket, which needs to be fully filled up by the client, and which thus adds major buffer and thus major latency to the whole system. In F9 we'll hoepfully ship with SDL directly on top of PA. Stay tuned. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From seg at haxxed.com Mon Dec 17 22:41:57 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 17 Dec 2007 16:41:57 -0600 Subject: Game content autodownloader In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> Message-ID: <1197931317.18986.19.camel@localhost> On Mon, 2007-12-17 at 10:37 +0000, Kevin Kofler wrote: > IMHO the right solution for this problem would be to ban autodownloader and > everything using it (or worse, requiring original proprietary and charged-for > game CDs) from the distribution. I see that tool as both an ugly kludge and a > way to circumvent Fedora's licensing requirements. It also sends the entirely > wrong message to upstream projects: before, it was "If you want to have your > game in Fedora, you have to fix your licensing.", now it's "We'll just hack > around it with autodownloader and ignore our Fedora Objectives entirely.". :-( > In addition, for data files where the license allows non-commercial > redistribution, it would IMHO be more user-friendly to have a fully-playable > package in rpmfusion non-free than an autodownloader hack in Fedora. I am one of the few and the proud who went out and bought the Linux edition of Quake 3 when it came out. I rather like being able to play it again. Good luck getting the original binaries to work on a modern system... What are the licensing implications of this? Hell if I know. The game engine is GPL. The game content I bought legitimately. Dare I draw the parallel to web browsers, which are used to view all kinds of content that *isn't* licensed properly? I suddenly feel a strong sense of deja vu... -------------- 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 si at siancu.net Mon Dec 17 22:47:26 2007 From: si at siancu.net (Stelian Iancu) Date: Mon, 17 Dec 2007 23:47:26 +0100 Subject: Wiki Migration In-Reply-To: <4766BB46.3060501@fedoraproject.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> Message-ID: <4766FC7E.2090802@siancu.net> Rahul Sundaram wrote: > Les Mikesell wrote: >> Rahul Sundaram wrote: >>> >>>> I had been asked by Bart Couvreur to package some Drupal modules for >>>> review, and they are still waiting. Bart, was that for a possible >>>> MoinMoin replacement, or something else? >>> >>> IIRC, that was for the planned Fedora News site. >> >> Would it be possible to combine the fedora development specific wiki >> into some kind of framework that encompasses all of the available >> documentation for the included packages and perhaps links to the spec >> files used in packaging? That way you'd have one place to go to find >> information about any particular program and whatever distro-specific >> changes might have been applied. Links to bugzilla searches for >> outstanding bugs in each package and a place for running user >> commentary would be a plus. > > It would be possible. Are you willing to help in any way? Refer > > http://fedoraproject.org/wiki/MyFedora > > Rahul > Looking at the URL above, that resembles a lot with a portal. Which reminds me, has anybody thought about something Java based on the backend? Something like JBoss and JBoss Portal. Given the fact that RedHat owns now JBoss, I am sure that Fedora can find some expertise and support "in-house". Regards, Stelian Iancu From smooge at gmail.com Mon Dec 17 23:19:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 17 Dec 2007 16:19:44 -0700 Subject: Wiki Migration In-Reply-To: <4766FC7E.2090802@siancu.net> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> <4766FC7E.2090802@siancu.net> Message-ID: <80d7e4090712171519x63b83017g28721ccc31e68a8c@mail.gmail.com> On Dec 17, 2007 3:47 PM, Stelian Iancu wrote: > Rahul Sundaram wrote: > > Les Mikesell wrote: > >> Rahul Sundaram wrote: > >>> > >>>> I had been asked by Bart Couvreur to package some Drupal modules for > >>>> review, and they are still waiting. Bart, was that for a possible > >>>> MoinMoin replacement, or something else? > >>> > >>> IIRC, that was for the planned Fedora News site. > >> > >> Would it be possible to combine the fedora development specific wiki > >> into some kind of framework that encompasses all of the available > >> documentation for the included packages and perhaps links to the spec > >> files used in packaging? That way you'd have one place to go to find > >> information about any particular program and whatever distro-specific > >> changes might have been applied. Links to bugzilla searches for > >> outstanding bugs in each package and a place for running user > >> commentary would be a plus. > > > > It would be possible. Are you willing to help in any way? Refer > > > > http://fedoraproject.org/wiki/MyFedora > > > > Rahul > > > > Looking at the URL above, that resembles a lot with a portal. Which > reminds me, has anybody thought about something Java based on the > backend? Something like JBoss and JBoss Portal. Given the fact that > RedHat owns now JBoss, I am sure that Fedora can find some expertise and > support "in-house". > I would like to say that you probably assume to much.. Red Hat is a big company and it doesn't mean everyone who works there falls under the Fedora umbrella. Not that they might not be interested.. but they have day and night jobs with their own part of the company... The general rule for any project with Fedora is DO NOT EXPECT RED HAT TO DO IT. Unless there is enough outside people willing to do 60% of the work.. its not going to happen or if it does happen it won't be maintained. I would say that an opensource JBoss website would first be needing a community outside of RH to build/test and champion it. -- 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 si at siancu.net Mon Dec 17 23:32:32 2007 From: si at siancu.net (Stelian Iancu) Date: Tue, 18 Dec 2007 00:32:32 +0100 Subject: Wiki Migration In-Reply-To: <80d7e4090712171519x63b83017g28721ccc31e68a8c@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <8278b1b0712150725j67fce581t67d3ca4d0d11ac5f@mail.gmail.com> <4336.63.85.68.164.1197907914.squirrel@mail.jcomserv.net> <4766A04D.3030003@fedoraproject.org> <4766BBDB.4080900@gmail.com> <4766BB46.3060501@fedoraproject.org> <4766FC7E.2090802@siancu.net> <80d7e4090712171519x63b83017g28721ccc31e68a8c@mail.gmail.com> Message-ID: <47670710.4060105@siancu.net> Stephen John Smoogen wrote: > On Dec 17, 2007 3:47 PM, Stelian Iancu wrote: >> Rahul Sundaram wrote: >>> Les Mikesell wrote: >>>> Rahul Sundaram wrote: >>>>>> I had been asked by Bart Couvreur to package some Drupal modules for >>>>>> review, and they are still waiting. Bart, was that for a possible >>>>>> MoinMoin replacement, or something else? >>>>> IIRC, that was for the planned Fedora News site. >>>> Would it be possible to combine the fedora development specific wiki >>>> into some kind of framework that encompasses all of the available >>>> documentation for the included packages and perhaps links to the spec >>>> files used in packaging? That way you'd have one place to go to find >>>> information about any particular program and whatever distro-specific >>>> changes might have been applied. Links to bugzilla searches for >>>> outstanding bugs in each package and a place for running user >>>> commentary would be a plus. >>> It would be possible. Are you willing to help in any way? Refer >>> >>> http://fedoraproject.org/wiki/MyFedora >>> >>> Rahul >>> >> Looking at the URL above, that resembles a lot with a portal. Which >> reminds me, has anybody thought about something Java based on the >> backend? Something like JBoss and JBoss Portal. Given the fact that >> RedHat owns now JBoss, I am sure that Fedora can find some expertise and >> support "in-house". >> > > I would like to say that you probably assume to much.. Red Hat is a > big company and it doesn't mean everyone who works there falls under > the Fedora umbrella. Not that they might not be interested.. but they > have day and night jobs with their own part of the company... The > general rule for any project with Fedora is DO NOT EXPECT RED HAT TO > DO IT. Unless there is enough outside people willing to do 60% of the > work.. its not going to happen or if it does happen it won't be > maintained. > > I would say that an opensource JBoss website would first be needing a > community outside of RH to build/test and champion it. > > I didn't mean to say that Red Hat should do it. I only said that if some advice or expertise is needed, I _think_ the folks from Red Hat (JBoss) can help. My question is, has anybody from the Fedora project considered this as an alternative to the already existing system? If not, will they at least consider it (assuming that somebody comes with a concrete plan, but this will need, IMHO, intimate knowledge about the inner workings of the project). S. From davej at redhat.com Mon Dec 17 23:41:19 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 17 Dec 2007 18:41:19 -0500 Subject: FUDCon hotel information In-Reply-To: <1197757680.9916.34.camel@localhost.localdomain> References: <20071215044423.GA2468@redhat.com> <1197757680.9916.34.camel@localhost.localdomain> Message-ID: <20071217234119.GA12052@redhat.com> On Sat, Dec 15, 2007 at 05:28:00PM -0500, Paul W. Frields wrote: > > I get "Invalid Corporate ID" when I added that. > > I tried it in the 'Worldwide Corp. Account#' field and in the > > 'Group Booking Code:' field. > > Hm, it worked for me yesterday -- the return invoice showed "Red Hat" > for the group identification. Still no love. Am I the only person seeing problems with this ? Dave -- http://www.codemonkey.org.uk From mzerqung at 0pointer.de Mon Dec 17 23:48:05 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 00:48:05 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197823564.29354.25.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> Message-ID: <20071217234804.GE3559@tango.0pointer.de> On Sun, 16.12.07 09:46, Richi Plana (myfedora at richip.dhs.org) wrote: > Again, ideally, services (including system ones) should 1) only be > started and 2) actually be started when it is called for. Something > similar to the way kernel modules are autoloaded when there's a need for > the service. Or xinetd does for some services which use it (though with > an option to actually stay resident). Besides (very few) exceptions, kernel drivers are nowadays loaded when the hardware they driver becomes available -- and not only when they are used. You can configure PA so that it is autospawned when needed. However, I do not recommend this. I recommend to start it from the session manager like we do it right now for KDE and GNOME. Why? Because PA nowadays does much more than just proxying access to the hw. It reacts on hotplug events, network configuration changes, certain X11 events, it is a network server, and so on and so on. For all these reasons it is better to leave PA running all the time. If you don't use any kind of session manager, then I fear you have to start PA manually right now. Currently the situation with starting PA is not perfect. First, if have deactivated the "start ESD" gconf checkbox they don't get sound. That's especially a problem with uprgades from F7. Secondly, we don't really support console logins. Thirdly, we don't really support multiple logins by the same user. There have been some discussions how to fix that, but we've not really come to any conlusion on this yet. Anyway, in summary: I strongly believe that the SM is the place to start PA, and starting it by auto-spawning is a bad idea. 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 Dec 17 23:53:33 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 00:53:33 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197829821.5869.3.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> Message-ID: <20071217235333.GF3559@tango.0pointer.de> On Sun, 16.12.07 12:30, Callum Lerwick (seg at haxxed.com) wrote: > > I believe > > it's the session manager, which makes sense because the session manager > > is a part of a bigger app (the DE) that knows it will actually use the > > sound server. > > No no no. The Pulseaudio library should take care of starting the damn > daemon. Like esd did. No no no. See my previous post about that. Auto-spawning is a bad thing. 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 Dec 17 23:57:06 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 00:57:06 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217153406.GJ18186@free.fr> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> Message-ID: <20071217235706.GG3559@tango.0pointer.de> On Mon, 17.12.07 16:34, Patrice Dumas (pertusus at free.fr) wrote: > > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > > > > The virtual consoles will still be around, but really should only be an > > emergency fallback. The right way to do this is to log in via gdm, and > > select a session that gives you a fullscreen shell (with tabs, windows, > > virtual desktops) etc. > > A display manager should not need to be installed. On servers, for > example http servers you want an http server to be installed and that's > all. No X server, not even X libraries (if possible). Hmm? If you want no X, then you certainly also don't want any PA. I mean, last time I was in a server room I didn't see a single server with boxes attached... ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 00:00:14 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 01:00:14 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197922916.19225.22.camel@localhost6.localdomain6> References: <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <1197905785.2937.27.camel@space-ghost.verbum.private> <1197913150.3396.16.camel@rousalka.dyndns.org> <1197921996.2937.65.camel@space-ghost.verbum.private> <1197922916.19225.22.camel@localhost6.localdomain6> Message-ID: <20071218000013.GH3559@tango.0pointer.de> On Mon, 17.12.07 13:21, Richi Plana (myfedora at richip.dhs.org) wrote: > > How does it work now? Is it just a background daemon with a web > > interface? > > In that kind case, for something that's specialized for audio in that > > way I'd say just have the app in control. If they want pulse, they > > should spawn it. > > Actually, I understand if gdm needs to play sounds and is therefore just > another PA sound client (with user gdm), but please don't make gdm the > app that starts the sound server for user desktop sessions. The better > place to make sound server startup an all-in-one solution is the sound > server itself. gdm would start a PA daemon of its own that runs as "gdm" user. Then when the user logs in a second PA daemon is started from gnome-session that runs as the actual user. That's not implemented right now. But that's the idea we're heading to. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pertusus at free.fr Tue Dec 18 00:06:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Dec 2007 01:06:35 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217235706.GG3559@tango.0pointer.de> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> Message-ID: <20071218000635.GA13824@free.fr> On Tue, Dec 18, 2007 at 12:57:06AM +0100, Lennart Poettering wrote: > On Mon, 17.12.07 16:34, Patrice Dumas (pertusus at free.fr) wrote: > > > > Hmm? If you want no X, then you certainly also don't want any PA. I > mean, last time I was in a server room I didn't see a single server > with boxes attached... ;-) It really depends. There are serious server rooms and there are home servers that are more multipurpose. For example one could be a streaming server so one could want to use it to listen to music too, but no X. But in any case it is not the point. It is plain wrong to specialize for a use (for example when logged with a specific dm). It shows that the whole design has flaws. The sound server should be usable in all situation from the start. Otherwise said, being able to adapt to all sort of situation should be in its design. That being said I don't know anything about pulseaudio, but if it is the same than consolekit which was designed without pam interfacing in mind it is not something I like. But, well I don't have the financial power to launch the writting of a sound server, so... -- Pat From jkeating at redhat.com Tue Dec 18 00:17:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 19:17:40 -0500 Subject: FUDCon hotel information In-Reply-To: <20071217234119.GA12052@redhat.com> References: <20071215044423.GA2468@redhat.com> <1197757680.9916.34.camel@localhost.localdomain> <20071217234119.GA12052@redhat.com> Message-ID: <20071217191740.43d76784@redhat.com> On Mon, 17 Dec 2007 18:41:19 -0500 Dave Jones wrote: > Still no love. Am I the only person seeing problems with this ? Make sure you're only scheduling for days of Thu/Fri/Sat, those are the only days the code is good for I think. -- 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 Dec 18 00:17:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 19:17:53 -0500 Subject: FUDCon hotel information In-Reply-To: <20071217234119.GA12052@redhat.com> References: <20071215044423.GA2468@redhat.com> <1197757680.9916.34.camel@localhost.localdomain> <20071217234119.GA12052@redhat.com> Message-ID: <20071217191753.387630c3@redhat.com> On Mon, 17 Dec 2007 18:41:19 -0500 Dave Jones wrote: > Still no love. Am I the only person seeing problems with this ? and if all else fails, use that antiquated thing called a phone. -- 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 Dec 18 00:21:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 17 Dec 2007 15:21:31 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218000635.GA13824@free.fr> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> Message-ID: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> On Dec 17, 2007 3:06 PM, Patrice Dumas wrote: > It really depends. There are serious server rooms and there are home > servers that are more multipurpose. For example one could be a streaming > server so one could want to use it to listen to music too, but no X. > But in any case it is not the point. It is plain wrong to specialize > for a use (for example when logged with a specific dm). It shows that > the whole design has flaws. The sound server should be usable in all > situation from the start. Otherwise said, being able to adapt to all > sort of situation should be in its design. Is multimedia streaming server/client the predominate outstanding X-less real-world usage case that needs to be considered for pulse integration ? What's the software stack(s) we are talking about? Mythtv? mpd? elisa? Are there a configuration of a headless streamer that can be played with inside fedora project controlled repository? Or do they all use bits that live in 3rd party repos? I think if we gave the people who grok pulse at least one specific software configuration for them to spend a little time playing with, then we might be able to get a clearer picture on how to move forward in X-less multimedia server situations. I think people are sort of talking past each other, it would help if we all had a target configuration to duplicate and use as a reference. -jef From mzerqung at 0pointer.de Tue Dec 18 00:38:53 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 01:38:53 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> Message-ID: <20071218003853.GA12552@tango.0pointer.de> On Mon, 17.12.07 15:21, Jeff Spaleta (jspaleta at gmail.com) wrote: > Is multimedia streaming server/client the predominate outstanding > X-less real-world usage case that needs to be considered for pulse > integration ? What's the software stack(s) we are talking about? > Mythtv? mpd? elisa? Are there a configuration of a headless streamer > that can be played with inside fedora project controlled repository? > Or do they all use bits that live in 3rd party repos? > > I think if we gave the people who grok pulse at least one specific > software configuration for them to spend a little time playing with, > then we might be able to get a clearer picture on how to move forward > in X-less multimedia server situations. I think people are sort of > talking past each other, it would help if we all had a target > configuration to duplicate and use as a reference. It's not that PA doesn't work at all on those special no-X-involved setups. The only limitation is that you need to run PA manually in such setups. -- No big deal! I mean, those who are capable to configure their system in such a non-standard way should also be able to start PA with a simple "pulseaudio -D" at the appropriate place. Thus I don't really see the point of the whole discussion. My aim is to make the default setup work out of the box. And for all other setups it should be possible to make it work at all. And quite frankly, I think I mostly managed to achieve that already. 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 Tue Dec 18 00:39:07 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 17:39:07 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217234804.GE3559@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> Message-ID: <1197938347.26469.16.camel@localhost6.localdomain6> On Tue, 2007-12-18 at 00:48 +0100, Lennart Poettering wrote: > On Sun, 16.12.07 09:46, Richi Plana (myfedora at richip.dhs.org) wrote: > > > Again, ideally, services (including system ones) should 1) only be > > started and 2) actually be started when it is called for. Something > > similar to the way kernel modules are autoloaded when there's a need for > > the service. Or xinetd does for some services which use it (though with > > an option to actually stay resident). > > Besides (very few) exceptions, kernel drivers are nowadays loaded when > the hardware they driver becomes available -- and not only when they > are used. > > You can configure PA so that it is autospawned when needed. However, I > do not recommend this. I recommend to start it from the session > manager like we do it right now for KDE and GNOME. Why? Because PA > nowadays does much more than just proxying access to the hw. It reacts > on hotplug events, network configuration changes, certain X11 events, > it is a network server, and so on and so on. For all these reasons it > is better to leave PA running all the time. But how are those hotplug events communicated? That's what I meant when I said the pulseaudio sound server should be started on an as-needed triggering event. If there are too many entry paths to using PA, then I understand the complexity. What's the underlying communication mechanism for event passing? D-Bus? TCP communication? For TCP sessions, we have xinetd. Would there be an interest in having a similar service for spawning object / services as a result of D-Bus service requests? Or is there already an existing infrastructure? Now I'm just curious. -- Richi Plana From myfedora at richip.dhs.org Tue Dec 18 00:41:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 17:41:29 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217235706.GG3559@tango.0pointer.de> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> Message-ID: <1197938489.26469.19.camel@localhost6.localdomain6> On Tue, 2007-12-18 at 00:57 +0100, Lennart Poettering wrote: > On Mon, 17.12.07 16:34, Patrice Dumas (pertusus at free.fr) wrote: > > > > > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > > > > > > The virtual consoles will still be around, but really should only be an > > > emergency fallback. The right way to do this is to log in via gdm, and > > > select a session that gives you a fullscreen shell (with tabs, windows, > > > virtual desktops) etc. > > > > A display manager should not need to be installed. On servers, for > > example http servers you want an http server to be installed and that's > > all. No X server, not even X libraries (if possible). > > Hmm? If you want no X, then you certainly also don't want any PA. I > mean, last time I was in a server room I didn't see a single server > with boxes attached... ;-) Would you believe I still know people who only use linux via consoles? Most of the stuff she does is using emacs. The rest are from bash. Even I remember the time when that's all I'd needed and "mpg123 file.mp3" was all I needed to play music. ;) -- Richi From pertusus at free.fr Tue Dec 18 00:45:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Dec 2007 01:45:03 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> Message-ID: <20071218004502.GC13824@free.fr> On Mon, Dec 17, 2007 at 03:21:31PM -0900, Jeff Spaleta wrote: > > Is multimedia streaming server/client the predominate outstanding > X-less real-world usage case that needs to be considered for pulse > integration ? What's the software stack(s) we are talking about? > Mythtv? mpd? elisa? Are there a configuration of a headless streamer > that can be played with inside fedora project controlled repository? > Or do they all use bits that live in 3rd party repos? I hope that there is a streaming server in fedora! In fact there seems to be icecast. As for a client there are many, and I guess that some have no X interfaces. But once again, a thought experiment is the only thing needed, not a real case. And it is not very hard, somebody in the thread clearly presented the situations where PA should work, without the artificial need to resort to a specific use. > I think if we gave the people who grok pulse at least one specific > software configuration for them to spend a little time playing with, > then we might be able to get a clearer picture on how to move forward > in X-less multimedia server situations. I think people are sort of > talking past each other, it would help if we all had a target > configuration to duplicate and use as a reference. I don't think it is of any use. Such situation has to be taken into account during planning, there is no need for a 'real' case. Of course it may be useful in later steps, but if not taken into account at the beginning it is too late later. -- Pat From alan at clueserver.org Tue Dec 18 00:48:56 2007 From: alan at clueserver.org (Alan) Date: Mon, 17 Dec 2007 16:48:56 -0800 (PST) Subject: how is pulseaudio supposed to work? In-Reply-To: <1197938489.26469.19.camel@localhost6.localdomain6> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <1197938489.26469.19.camel@localhost6.localdomain6> Message-ID: <24157.198.182.194.170.1197938936.squirrel@clueserver.org> > On Tue, 2007-12-18 at 00:57 +0100, Lennart Poettering wrote: >> On Mon, 17.12.07 16:34, Patrice Dumas (pertusus at free.fr) wrote: >> >> > >> > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: >> > > >> > > The virtual consoles will still be around, but really should only be >> an >> > > emergency fallback. The right way to do this is to log in via gdm, >> and >> > > select a session that gives you a fullscreen shell (with tabs, >> windows, >> > > virtual desktops) etc. >> > >> > A display manager should not need to be installed. On servers, for >> > example http servers you want an http server to be installed and >> that's >> > all. No X server, not even X libraries (if possible). >> >> Hmm? If you want no X, then you certainly also don't want any PA. I >> mean, last time I was in a server room I didn't see a single server >> with boxes attached... ;-) > > Would you believe I still know people who only use linux via consoles? > Most of the stuff she does is using emacs. The rest are from bash. Even > I remember the time when that's all I'd needed and "mpg123 file.mp3" was > all I needed to play music. ;) Its more fun if you use mpg123 to play music on someone elses machine. (Selections from Marx Brothers movies is always fun.) ssh remote command execution on boxes you administer is your friend. ]:> From jspaleta at gmail.com Tue Dec 18 00:51:14 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 17 Dec 2007 15:51:14 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218003853.GA12552@tango.0pointer.de> References: <1197823564.29354.25.camel@localhost6.localdomain6> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> Message-ID: <604aa7910712171651x6a881cdcoedea455cc72f1ce5@mail.gmail.com> On Dec 17, 2007 3:38 PM, Lennart Poettering wrote: > Thus I don't really see the point of the whole discussion. My aim is > to make the default setup work out of the box. Out of the box, could easily mean a a dedicated spin to act to act as a multimedia streaming client/server that is talking across a local network assuming we have the software in the repository to make that possible. -jef From myfedora at richip.dhs.org Tue Dec 18 00:52:43 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Dec 2007 17:52:43 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <24157.198.182.194.170.1197938936.squirrel@clueserver.org> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <1197938489.26469.19.camel@localhost6.localdomain6> <24157.198.182.194.170.1197938936.squirrel@clueserver.org> Message-ID: <1197939163.26469.22.camel@localhost6.localdomain6> On Mon, 2007-12-17 at 16:48 -0800, Alan wrote: > > On Tue, 2007-12-18 at 00:57 +0100, Lennart Poettering wrote: > >> On Mon, 17.12.07 16:34, Patrice Dumas (pertusus at free.fr) wrote: > >> > >> > > >> > On Mon, Dec 17, 2007 at 10:24:04AM -0500, Colin Walters wrote: > >> > > > >> > > The virtual consoles will still be around, but really should only be > >> an > >> > > emergency fallback. The right way to do this is to log in via gdm, > >> and > >> > > select a session that gives you a fullscreen shell (with tabs, > >> windows, > >> > > virtual desktops) etc. > >> > > >> > A display manager should not need to be installed. On servers, for > >> > example http servers you want an http server to be installed and > >> that's > >> > all. No X server, not even X libraries (if possible). > >> > >> Hmm? If you want no X, then you certainly also don't want any PA. I > >> mean, last time I was in a server room I didn't see a single server > >> with boxes attached... ;-) > > > > Would you believe I still know people who only use linux via consoles? > > Most of the stuff she does is using emacs. The rest are from bash. Even > > I remember the time when that's all I'd needed and "mpg123 file.mp3" was > > all I needed to play music. ;) > > Its more fun if you use mpg123 to play music on someone elses machine. > (Selections from Marx Brothers movies is always fun.) > > ssh remote command execution on boxes you administer is your friend. ]:> That's the old-school way (which I admit to doing and surprising the heck out of linux newbies in the late 90's). New school is to get permission on the PulseAudio sound server running on that machine ;) -- Richi Plana From bpepple at fedoraproject.org Tue Dec 18 01:00:22 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 17 Dec 2007 20:00:22 -0500 Subject: FESCo Meeting Summary for 2007-12-13 Message-ID: <1197939622.10055.6.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Jeremy Katz (jeremy) * Christian Iseli (c4chris) * Kevin Fenzi (nirik) * Christopher Aillon (caillon) * David Woodhouse (dwmw2) * Tom Callaway (spot) = Absent = * Josh Boyer (jwb) == Summary == === FESCo Proposal Template === * f13 created a template for proposals to FESCo. It can be found at: http://fedoraproject.org/wiki/Development/FescoProposalTemplate === s/AWOL/non-responsive/ === * FESCo agreed to change references in the wiki from AWOL maintainers to Non-responsive maintainers, since the former can be viewed as a bit hostile towards maintainers. === Automated MIA Proposal === * FESCo approved an initial proposal for an automated MIA process, which will give people something to work from, and a goal to get to. http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal * For: bpepple, tibbs, warren, nirik, c4chris, dgilmore, dwmw2, notting, f13 * Against: * Abstain: spot, jeremy, caillon === Merge Reviews === * FESCo approved the list of Merge Reviews that tibbs compiled, which we would like to see completed before F9. tibbs will be sending out an announcement with the list of merger reviews to the -devel mailing list. http://fedoraproject.org/wiki/JasonTibbitts/MergeReviews * For: f13, bpepple, dgilmore, dwmw2, c4chris, warren, caillon, jeremy, notting, spot, tibbs, nirik * Against: * Abstain: === FESCo meetings during holidays === * FESCo decided to cancel the December 27th, 2007 meeting due to the holidays, and will keep the meeting planned for Jan. 3rd, 2008. === F9 Feature Process === * FESCo approved the following features for F9: * http://fedoraproject.org/wiki/Features/VirtAuthentication * http://fedoraproject.org/wiki/Features/VirtPolicyKit * http://fedoraproject.org/wiki/Releases/FeatureMoreNetworkManager * http://fedoraproject.org/wiki/Features/K12Linux IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2007-12-13.html BTW, if you want to see the IRC logs (since I'm getting slower and slower writing up the summaries), I tend to upload them 10 minutes or so after the meetings here: http://bpepple.fedorapeople.org/fesco/ 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 jspaleta at gmail.com Tue Dec 18 01:10:49 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 17 Dec 2007 16:10:49 -0900 Subject: Game content autodownloader In-Reply-To: <1197931317.18986.19.camel@localhost> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> <1197931317.18986.19.camel@localhost> Message-ID: <604aa7910712171710s436cafbar194c0d73d5ccb6a@mail.gmail.com> On Dec 17, 2007 1:41 PM, Callum Lerwick wrote: > What are the licensing implications of this? Hell if I know. The game > engine is GPL. The game content I bought legitimately. Dare I draw the > parallel to web browsers, which are used to view all kinds of content > that *isn't* licensed properly? I suddenly feel a strong sense of deja > vu... The content versus code debate isn't going to go away any time soon and sadly game data isn't going to be the greyest area in the futre. Once we start deeply integrating web services into our desktop experience and as a project start trying to make peace with the implications of relying on software as a service from non-open webservice providers.. we won't have enough time to worry about the ethics of needing to download copyright protected game data. -jef"wonders if the underlying market principles which keep the baen free library open for electronic books could also apply for eposodic game data?"spaleta From cjdahlin at ncsu.edu Tue Dec 18 01:21:28 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 17 Dec 2007 20:21:28 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1197866012.2962.18.camel@localhost.localdomain> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <1197862385.5612.30.camel@Diffingo.localdomain> <4765F6A0.3000206@gmail.com> <1197866012.2962.18.camel@localhost.localdomain> Message-ID: <47672098.40502@ncsu.edu> Matthias Clasen wrote: > On Sun, 2007-12-16 at 20:10 -0800, Andrew Farris wrote: > > >> I don't think its that bad to have each entry in one menu as long as they are >> different, just adding the actual application name to the front or back of the >> menu text would be fine: >> Text Editor - GEdit >> Text Editor - Mousepad >> >> Mousepad - Text Editor >> Gedit - Text Editor >> >> We've already got that type of setup going on many menus, like gThumb Image >> Viewer and Xpdf PDF Viewer, and both Firefox Web Browser and Epiphany Web Browser. >> >> Either way works fine really and avoids submenus, I just agree with you Stewart >> that the general naming is a bit out of hand when you end up with exact >> duplicates and can't tell what is what until you try it. >> > > We may indeed have to give up the generic naming that was very nice > while we had the luxury to define the menu layout for a single default > install. In the new multi-spin world order, we may have to accept the > "name - generic name" style, even if it break localization to a certain > degree. > > For the general problem of menu overcrowding in everything or k+g > installations, I believe that only moving to a dynamic menu system like > bigboard will significantly improve the situation. > > > Matthias > > > Why not have a this configurable? The .desktop file format supports specification of name and generic name independently, why not let the user decide what permutation of these is displayed? Then we can just fight over the default :) --CJD From cmadams at hiwaay.net Tue Dec 18 01:26:00 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 17 Dec 2007 19:26:00 -0600 Subject: Disable a USB device? Message-ID: <20071218012600.GB909413@hiwaay.net> While poking at powertop and reading online, I saw a good bit of wakeups from USB. I read a recommendation to remove all USB devices to lower wakeups, but I have a Thinkpad with a fingerprint reader built-in. Is there a way to disable an unused USB device so that it acts like it has been unplugged? Otherwise, USB wakes up 4 times per second for no particular reason (no other USB devices are attached). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mattdm at mattdm.org Tue Dec 18 02:11:31 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Dec 2007 21:11:31 -0500 Subject: FUDCon -- considering switching Fri/Sat schedules In-Reply-To: References: Message-ID: <20071218021131.GA11609@jadzia.bu.edu> On Fri, Dec 14, 2007 at 02:29:06PM -0500, Max Spevack wrote: > As we try to finalize the logistics for FUDCon, it looks like it will be > a lot easier from a space point of view if we make the actual barcamp > day Saturday (instead of Friday), and use Friday and Sunday for the > Hackfests. I also think we can get a better turnout at bar camp if it > is on Saturday. Ouch! Please don't do this. My req for plane tickets is already in and I'm not sure I can change things. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at fedoraproject.org Tue Dec 18 03:06:05 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Dec 2007 22:06:05 -0500 Subject: FUDCon -- considering switching Fri/Sat schedules In-Reply-To: <20071218021131.GA11609@jadzia.bu.edu> References: <20071218021131.GA11609@jadzia.bu.edu> Message-ID: <1197947165.18618.39.camel@cutter> On Mon, 2007-12-17 at 21:11 -0500, Matthew Miller wrote: > On Fri, Dec 14, 2007 at 02:29:06PM -0500, Max Spevack wrote: > > As we try to finalize the logistics for FUDCon, it looks like it will be > > a lot easier from a space point of view if we make the actual barcamp > > day Saturday (instead of Friday), and use Friday and Sunday for the > > Hackfests. I also think we can get a better turnout at bar camp if it > > is on Saturday. > > Ouch! Please don't do this. My req for plane tickets is already in and I'm > not sure I can change things. > Were you planning on coming up and back on the same day? -sv From mattdm at mattdm.org Tue Dec 18 03:20:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Dec 2007 22:20:40 -0500 Subject: FUDCon -- considering switching Fri/Sat schedules In-Reply-To: <1197947165.18618.39.camel@cutter> References: <20071218021131.GA11609@jadzia.bu.edu> <1197947165.18618.39.camel@cutter> Message-ID: <20071218032040.GA18268@jadzia.bu.edu> On Mon, Dec 17, 2007 at 10:06:05PM -0500, seth vidal wrote: > > > As we try to finalize the logistics for FUDCon, it looks like it will be > > > a lot easier from a space point of view if we make the actual barcamp > > > day Saturday (instead of Friday), and use Friday and Sunday for the > > > Hackfests. I also think we can get a better turnout at bar camp if it > > > is on Saturday. > > Ouch! Please don't do this. My req for plane tickets is already in and I'm > > not sure I can change things. > Were you planning on coming up and back on the same day? In Thursday evening, out Saturday morning. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kevin.kofler at chello.at Tue Dec 18 03:41:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Dec 2007 03:41:07 +0000 (UTC) Subject: Opinions welcome: Restructuring the system menus References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <1197862385.5612.30.camel@Diffingo.localdomain> <4765F6A0.3000206@gmail.com> <1197866012.2962.18.camel@localhost.localdomain> <47672098.40502@ncsu.edu> Message-ID: Casey Dahlin ncsu.edu> writes: > Why not have a this configurable? The .desktop file format supports > specification of name and generic name independently, why not let the > user decide what permutation of these is displayed? Then we can just > fight over the default :) In fact, that's what KDE already does. Of course, that only works if there's actually useful entries for both Name and GenericName... Kevin Kofler From kevin.kofler at chello.at Tue Dec 18 03:55:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Dec 2007 03:55:37 +0000 (UTC) Subject: Proprietary web apps (was: Re: Game content autodownloader) References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> <1197931317.18986.19.camel@localhost> <604aa7910712171710s436cafbar194c0d73d5ccb6a@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > The content versus code debate isn't going to go away any time soon > and sadly game data isn't going to be the greyest area in the futre. > Once we start deeply integrating web services into our desktop > experience and as a project start trying to make peace with the > implications of relying on software as a service from non-open > webservice providers.. we won't have enough time to worry about the > ethics of needing to download copyright protected game data. Indeed, I'm also worried about these developments, like GNOME's Online Desktop and KDE 4's plasmoids for various proprietary web apps. I think these are really bad ideas, they're slowly eroding what the Free desktop was supposed to be about. If the only Free Software you ever use is a web browser and all the apps you use are proprietary web apps, then are you really using Free Software? Of course, it's hard to tell where to draw the line. But when something originally developed as a communication medium starts getting used to host your e-mail client, your picture gallery etc., IMHO that's really going too far. One criterion that you're a web service user and not just a web user is when you use the web to manage YOUR personal data, not just to communicate with others. (That also has privacy implications, by the way, not just licensing.) Another is when the browser starts becoming your client to everything. But there's of course a gray area everywhere, for example I'm writing this through the GMane web interface, is that a "web service" or "communication"? Even things like GMail could be argued to be communication, as can picture galleries as soon as picture sharing is involved. Kevin Kofler From jdieter at gmail.com Tue Dec 18 05:20:12 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 18 Dec 2007 07:20:12 +0200 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> Message-ID: <1197955212.3290.77.camel@jndwidescreen.lesbg.loc> On Mon, 2007-12-17 at 15:21 -0900, Jeff Spaleta wrote: > Is multimedia streaming server/client the predominate outstanding > X-less real-world usage case that needs to be considered for pulse > integration ? What's the software stack(s) we are talking about? > Mythtv? mpd? elisa? Are there a configuration of a headless streamer > that can be played with inside fedora project controlled repository? > Or do they all use bits that live in 3rd party repos? > > I think if we gave the people who grok pulse at least one specific > software configuration for them to spend a little time playing with, > then we might be able to get a clearer picture on how to move forward > in X-less multimedia server situations. I think people are sort of > talking past each other, it would help if we all had a target > configuration to duplicate and use as a reference. FWIW, I run a headless home music server named musicbox that uses PA and runs mpd. When my wife or I want to watch a movie, we just redirect the sound output from our respective laptops to musicbox. Mpd has a PA plugin, so it was quite easy to configure. The only problem I ran into was in trying to get PA to run as a system-wide daemon. I had to track down why it couldn't open /dev/snd/*, and finally worked out that it was a permissions problem, easily fixed using ConsoleKit. All that to say that except for the permissions problems, it just worked. 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 tmz at pobox.com Tue Dec 18 06:49:07 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 18 Dec 2007 01:49:07 -0500 Subject: libgpod update for F-7 and F-8 (attn: amarok, elisa, exaile, gpodder, kipi-plugins, quodlibet, and rhythmbox maintainers) Message-ID: <20071218064907.GB20084@inocybe.teonanacatl.org> So, libgpod-0.6.0 has stewed in rawhide for several weeks without any bug reports. Either no one with a rawhide install has tested any apps using it, or it's proved reasonably stable. :) (I do have a report that updates I'd made for F-7 were working for one user of a new iPod, FWIW.) I'd like to push libgpod to updates-testing for F-7 and F-8 so that all those folks picking up new iPods can be supported. If there are no objections, I'll prepare the update and rebuild deps as needed, say on Wednesday. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stress is when you wake up screaming and you realize you weren't sleeping. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From nicu_fedora at nicubunu.ro Tue Dec 18 07:13:09 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 18 Dec 2007 09:13:09 +0200 Subject: Game content autodownloader In-Reply-To: <1197931317.18986.19.camel@localhost> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <4765CEF7.70002@gmail.com> <476636F1.9030102@hhs.nl> <4766421F.8050500@nicubunu.ro> <1197931317.18986.19.camel@localhost> Message-ID: <47677305.2010602@nicubunu.ro> Callum Lerwick wrote: > I am one of the few and the proud who went out and bought the Linux > edition of Quake 3 when it came out. I rather like being able to play it > again. Good luck getting the original binaries to work on a modern > system... Quake 3 is an excellent example, one that I wanted to use myself but for a completely opposite conclusion: we have OpenArena in the distro. I am not a huge Quake player, but I enjoy a occasional deathmatch. From this position, I don't notice any advantage on playing with the Q3 demo datafiles (what's offered by the autodownloader) over OpenArena, so I see the use of autodownloader *for this particular case* as redundant and useless. Having the Q3 application to use with OpenArena and UrbanTerror is, of course, wonderful. > What are the licensing implications of this? Hell if I know. The game > engine is GPL. The game content I bought legitimately. Dare I draw the > parallel to web browsers, which are used to view all kinds of content > that *isn't* licensed properly? I suddenly feel a strong sense of deja > vu... This is not the point: you surely are free to use your own datafiles in any way you want. It is about us pushing (with autodownloader and somehow circumventing our general policy) the proprietary bits in Q3 demo data files, when we have a good and free replacement. -- 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 Tue Dec 18 07:15:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 08:15:53 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> Message-ID: <1197962153.5515.5.camel@rousalka.dyndns.org> Le lundi 17 d?cembre 2007 ? 15:21 -0900, Jeff Spaleta a ?crit : > I think people are sort of > talking past each other, it would help if we all had a target > configuration to duplicate and use as a reference. As other people already explained the target is the home desktop/small server where you have a fixed box directly wired to hardware (ADSL entry point, printer, projector, amp & sound setup, cable, whatever) and roaming light desktops like laptops that use/control the services (mail, sound, video, pvr...) provided by this box. The box may also serve as desktop but its other services are headless in the sense they don't run a full GNOME session but at most output a specialised UI to specific video outputs. The box may be built-your-own or shipped by the cable/adsl provider. Either way it runs Linux and can often be fedora-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 nicolas.mailhot at laposte.net Tue Dec 18 07:22:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 08:22:49 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218003853.GA12552@tango.0pointer.de> References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> Message-ID: <1197962569.5515.12.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 01:38 +0100, Lennart Poettering a ?crit : > It's not that PA doesn't work at all on those special no-X-involved > setups. The only limitation is that you need to run PA manually in > such setups. -- No big deal! Says the PA author. Why are we seeing the same lame arguments again and again? Are we going to have to retrofit support for "special" uses (special meaning the author didn't think of them so they "must" be marginal) in PA after several releases of complains like with the other "future" solutions? Will we have to remove PA by default from the Fedora DVD spin to drive the point home and get you to care about every Fedora user? -- 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 triad at df.lth.se Tue Dec 18 08:18:33 2007 From: triad at df.lth.se (Linus Walleij) Date: Tue, 18 Dec 2007 09:18:33 +0100 (CET) Subject: libgpod update for F-7 and F-8 (attn: amarok, elisa, exaile, gpodder, kipi-plugins, quodlibet, and rhythmbox maintainers) In-Reply-To: <20071218064907.GB20084@inocybe.teonanacatl.org> References: <20071218064907.GB20084@inocybe.teonanacatl.org> Message-ID: On Tue, 18 Dec 2007, Todd Zullinger wrote: > I'd like to push libgpod to updates-testing for F-7 and F-8 so that > all those folks picking up new iPods can be supported. Go for it Todd, as mentioned in bug 359401 this will be combined with Todd rebuilding libmtp (0.2.4) for F-7 and F-8 and pushing that alongside libgpod so we support all the latest music players (eg the Creative ZEN) as well. Linus From pertusus at free.fr Tue Dec 18 08:24:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Dec 2007 09:24:02 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218003853.GA12552@tango.0pointer.de> References: <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> Message-ID: <20071218082402.GB2530@free.fr> On Tue, Dec 18, 2007 at 01:38:53AM +0100, Lennart Poettering wrote: > > It's not that PA doesn't work at all on those special no-X-involved > setups. The only limitation is that you need to run PA manually in > such setups. -- No big deal! Is there something like a session pam module planned to start PA to achieve independence from the the login entry point? -- Pat From triad at df.lth.se Tue Dec 18 08:46:50 2007 From: triad at df.lth.se (Linus Walleij) Date: Tue, 18 Dec 2007 09:46:50 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <1197962569.5515.12.camel@rousalka.dyndns.org> References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> Message-ID: On Tue, 18 Dec 2007, Nicolas Mailhot wrote: > Why are we seeing the same lame arguments again and again? Now that's a bit rude. Lennart is pushing the limits for an advanced Linux desktop/workstation with his work, and frankly I think it's worth it, even if it messes with some server use cases a bit. Even if it means Fedora userbase becomes a testbed for experiments that can be a bit painful at times. Someone has to do it, it'd better be us, because I like test-driving the future. And I also think that is the reason RedHat desired to hire Lennart and Bastien especially: these guys are really world leaders in some key desktop technologies. RH officals could perhaps state their intentions with backing desktop developers out loud so I don't have to guess.. Making sure everything works on server is IMHO one of the big reasons why Debian cannot hold a release schedule and introduce new features quickly enough, so these glitches are a side-effect of what makes Fedora great. I for one can live with it. Linus From andy at smile.org.ua Tue Dec 18 09:09:03 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Tue, 18 Dec 2007 11:09:03 +0200 Subject: Disable a USB device? In-Reply-To: <20071218012600.GB909413@hiwaay.net> References: <20071218012600.GB909413@hiwaay.net> Message-ID: <20071218090902.GD29292@serv.smile.org.ua> Hi Chris Adams! On Mon, Dec 17, 2007 at 07:26:00PM -0600, Chris Adams wrote next: > Otherwise, USB wakes up 4 times per second for no particular reason (no > other USB devices are attached). I don't know exactly, but may be some like next helps? [root at toaster special-english]# cat /sys/bus/usb/devices/usb1/power/wakeup enabled [root at toaster special-english]# echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup [root at toaster special-english]# cat /sys/bus/usb/devices/usb1/power/wakeup disabled P.S. I think the sysfs may provide some interface for it. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From tomek at crocom.com.pl Tue Dec 18 09:20:43 2007 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Tue, 18 Dec 2007 10:20:43 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071217234804.GE3559@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> Message-ID: <1197969643.3361.0.camel@s1.crocom.com.pl> Dnia 18-12-2007, wto o godzinie 00:48 +0100, Lennart Poettering pisze: > You can configure PA so that it is autospawned when needed. However, I > do not recommend this. I recommend to start it from the session > manager like we do it right now for KDE and GNOME. Why? Because PA > nowadays does much more than just proxying access to the hw. It reacts > on hotplug events, network configuration changes, certain X11 events, > it is a network server, and so on and so on. For all these reasons it > is better to leave PA running all the time. If PA is so important, why not start it system-wide by default? -- Tomasz Torcz From pertusus at free.fr Tue Dec 18 09:42:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Dec 2007 10:42:00 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> Message-ID: <20071218094200.GD2530@free.fr> On Tue, Dec 18, 2007 at 09:46:50AM +0100, Linus Walleij wrote: > On Tue, 18 Dec 2007, Nicolas Mailhot wrote: > > Now that's a bit rude. Lennart is pushing the limits for an advanced Linux > desktop/workstation with his work, and frankly I think it's worth it, even > if it messes with some server use cases a bit. Even if it means Fedora > userbase becomes a testbed for experiments that can be a bit painful at > times. Someone has to do it, it'd better be us, because I like test-driving > the future. We all like to be test-driving the future or else we wouldn't be using fedora. But the issue is more on the planning of the future. In the planning phase the issues that will be faced should be taken into account such as not to leave aside some category of use cases/users and the overall design should take that into account. Aftere that, sure testing will be needed to make sure everything is right. But things that have been ruled out by design won't appear later magically. > And I also think that is the reason RedHat desired to hire Lennart and > Bastien especially: these guys are really world leaders in some key desktop > technologies. RH officals could perhaps state their intentions with backing > desktop developers out loud so I don't have to guess.. Where they put money is more eloquent that any word. -- Pat From mzerqung at 0pointer.de Tue Dec 18 10:42:50 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 11:42:50 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197962569.5515.12.camel@rousalka.dyndns.org> References: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> Message-ID: <20071218104250.GB1518@tango.0pointer.de> On Tue, 18.12.07 08:22, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > Le mardi 18 d?cembre 2007 ? 01:38 +0100, Lennart Poettering a ?crit : > > > It's not that PA doesn't work at all on those special no-X-involved > > setups. The only limitation is that you need to run PA manually in > > such setups. -- No big deal! > > Says the PA author. > > Why are we seeing the same lame arguments again and again? Are we going > to have to retrofit support for "special" uses (special meaning the > author didn't think of them so they "must" be marginal) in PA after > several releases of complains like with the other "future" > solutions? Hmm? I am not sure what you want? If people write their own .xinitrc, then they do that because they want better control of what is started in their X session and what is not. Now, I am not sure what you are are asking for? Shall I find some magic way that PA is started even when people use their own handcrafted xinitrc? You know, I am pretty sure that people would hate me even more for that than with the current solution. If people want the extra bit of control, than they should have it -- and that includes the control if, when and where to start PA. > Will we have to remove PA by default from the Fedora DVD spin to drive > the point home and get you to care about every Fedora user? Again, my focus is to get things working out-of-the-box for the default cases. If you feel you need to write your own session scripts, then you're welcome to do so -- to get PA working on such setups all you need to do is add a "pulseaudio -D" to that script. That seems to be a very reasonable solution for me. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From caillon at redhat.com Tue Dec 18 10:45:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 18 Dec 2007 11:45:56 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197962569.5515.12.camel@rousalka.dyndns.org> References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> Message-ID: <4767A4E4.4020902@redhat.com> On 12/18/2007 08:22 AM, Nicolas Mailhot wrote: > Will we have to remove PA by default from the Fedora DVD spin to drive > the point home and get you to care about every Fedora user? Then we need to remove both KDE and GNOME from the DVD spins because they don't cater to every Fedora user. From mzerqung at 0pointer.de Tue Dec 18 10:54:09 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 11:54:09 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218094200.GD2530@free.fr> References: <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> <20071218094200.GD2530@free.fr> Message-ID: <20071218105409.GC1518@tango.0pointer.de> On Tue, 18.12.07 10:42, Patrice Dumas (pertusus at free.fr) wrote: > > On Tue, Dec 18, 2007 at 09:46:50AM +0100, Linus Walleij wrote: > > On Tue, 18 Dec 2007, Nicolas Mailhot wrote: > > > > Now that's a bit rude. Lennart is pushing the limits for an advanced Linux > > desktop/workstation with his work, and frankly I think it's worth it, even > > if it messes with some server use cases a bit. Even if it means Fedora > > userbase becomes a testbed for experiments that can be a bit painful at > > times. Someone has to do it, it'd better be us, because I like test-driving > > the future. > > We all like to be test-driving the future or else we wouldn't be using > fedora. But the issue is more on the planning of the future. In the > planning phase the issues that will be faced should be taken into > account such as not to leave aside some category of use cases/users > and the overall design should take that into account. Aftere that, sure > testing will be needed to make sure everything is right. But things that > have been ruled out by design won't appear later magically. As I wrote in a mail yesterday: I am fully aware of the issues with console logins an PA. And as I wrote yesterday as well: to come up with a solution for this has been on my TODO list for quite a while. However, my TODO list is long. Actually it's not just long, it is huge. I am trying my best to close all the issues on the list one-by-one. For different people different things on the TODO list have priority. That means, that whatever order I choose to fix all these issues, I'll always make some people unhappy because I didn't provide their specific feature already yesterday. All I ask for, is bear with me -- and let's not forget: this is all Free Software. Instead of waiting for some other guy to fix the bug for you (and insulting him on the way), people are always welcome to scratch their itches themselves -- and provide a patch. You have one guarantee: if a patch is well done, I will happily commit it. Now, since getting PA working manually on console logins is not particularly hard (just run pulseaudio -D), I don't see any need to make this the top priority on my list. The amount of work to get this working smoothly is way larger than the short-time benefit of it. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 11:00:45 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 12:00:45 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218082402.GB2530@free.fr> References: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> Message-ID: <20071218110045.GD1518@tango.0pointer.de> On Tue, 18.12.07 09:24, Patrice Dumas (pertusus at free.fr) wrote: > > It's not that PA doesn't work at all on those special no-X-involved > > setups. The only limitation is that you need to run PA manually in > > such setups. -- No big deal! > > Is there something like a session pam module planned to start PA to > achieve independence from the the login entry point? I am not convinced that PAM is the right place to start any daemons. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nicolas.mailhot at laposte.net Tue Dec 18 11:05:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 12:05:00 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: References: <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> Message-ID: <60932.192.54.193.52.1197975900.squirrel@rousalka.dyndns.org> Le Mar 18 d?cembre 2007 09:46, Linus Walleij a ?crit : > On Tue, 18 Dec 2007, Nicolas Mailhot wrote: > >> Why are we seeing the same lame arguments again and again? > > Now that's a bit rude. Lennart is pushing the limits for an advanced > Linux desktop/workstation with his work, and frankly I think it's > worth it, even if it messes with some server use cases a bit. I don't question Lennart qualifications or qualities, I question the trend we've been seeing lately where every new Fedora tech is designed for very narrowly defined use cases that do not build on Fedora's general-purpose inheritance and needlessly ignores some classes of users (which have to be put back in after a few releases). I question the artificial separation between "desktop" and "server" and the way some teams purposefully ignore problems of other teams and think that's a good deal for Fedora, when in fact there is a lot of grey area between and our strength WRT proprietary marketing-driven competition was we were able to manage this grey area. Which is not to say Fedora should transform in RHEL or something like Debian that takes years to get out, but there is a huge difference between not trying to be a perfect big iron solution and declaring anything which has a small dhcp/bind/apache or any other sort of service running is NOT-A-DESKTOP and thus WE-DON'T-CARE and should DO-SOMETHING-ELSE. There are lots of use cases even for home users (let alone SOHO users) that involve partly serverized desktops which should IMHO be handled well by Fedora. I think like Linus that building something that scales from embedded to huge server creates value for everyone involved, and going many small specialized incompatible spins that do not play well together and reinvent square wheels is a waste of resources. It's a shame with our heritage when one of our teams declares stuff which is routinely handled by non-server windows systems in the wild have no place in Fedora's "desktop" roadmap. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Dec 18 11:23:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 12:23:04 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218104250.GB1518@tango.0pointer.de> References: <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> <20071218104250.GB1518@tango.0pointer.de> Message-ID: <11021.192.54.193.52.1197976984.squirrel@rousalka.dyndns.org> Le Mar 18 d?cembre 2007 11:42, Lennart Poettering a ?crit : > I am not sure what you want? I want an official way to get sound working for non-human-user sessions that does not involves writing manually .xinitrcs, can be integrated by the packagers of software needing this in their packages, and is cared about by the stack authors. I don't want every use that does not fit nicely fit in the gnome human session scenarii to be relegated in RTFM and google land. -- Nicolas Mailhot From pertusus at free.fr Tue Dec 18 11:37:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Dec 2007 12:37:35 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218110045.GD1518@tango.0pointer.de> References: <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> Message-ID: <20071218113735.GA20976@free.fr> On Tue, Dec 18, 2007 at 12:00:45PM +0100, Lennart Poettering wrote: > On Tue, 18.12.07 09:24, Patrice Dumas (pertusus at free.fr) wrote: > > > > It's not that PA doesn't work at all on those special no-X-involved > > > setups. The only limitation is that you need to run PA manually in > > > such setups. -- No big deal! > > > > Is there something like a session pam module planned to start PA to > > achieve independence from the the login entry point? > > I am not convinced that PAM is the right place to start any daemons. But gdm is? -- Pat From lkundrak at redhat.com Tue Dec 18 12:09:23 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Tue, 18 Dec 2007 13:09:23 +0100 Subject: Yet another sa_restorer bug In-Reply-To: <4766DF1D.3070509@linux-kernel.at> References: <4766DF1D.3070509@linux-kernel.at> Message-ID: <1197979763.14028.2.camel@localhost.localdomain> Oliver, On Mon, 2007-12-17 at 21:42 +0100, Oliver Falk wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=426024 > > This is the second sa_restorer bug I filed. However. > > I can only ask all of you to check if your pkgs do use signal.h and if, > check if they do use sa_restorer. > > Maybe someone volunteers to do a grep over all sources!? And list the > pkgs here!? Someone already did a similar job after the introduction of > FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I > don't have the ressources at the moment... I have complete rawhide source tree from 2007-11-14 exploded lying around. I'll assume it's recent enough and will post the results of the grep, but it takes some time as it's on a compressed filesystem. -- Lubomir Kundrak (Red Hat Security Response Team) From oliver at linux-kernel.at Tue Dec 18 12:14:35 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 18 Dec 2007 13:14:35 +0100 Subject: Yet another sa_restorer bug In-Reply-To: <1197979763.14028.2.camel@localhost.localdomain> References: <4766DF1D.3070509@linux-kernel.at> <1197979763.14028.2.camel@localhost.localdomain> Message-ID: <4767B9AB.5010200@linux-kernel.at> On 12/18/2007 01:09 PM, Lubomir Kundrak wrote: > Oliver, > > On Mon, 2007-12-17 at 21:42 +0100, Oliver Falk wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=426024 >> >> This is the second sa_restorer bug I filed. However. >> >> I can only ask all of you to check if your pkgs do use signal.h and if, >> check if they do use sa_restorer. >> >> Maybe someone volunteers to do a grep over all sources!? And list the >> pkgs here!? Someone already did a similar job after the introduction of >> FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I >> don't have the ressources at the moment... > > I have complete rawhide source tree from 2007-11-14 exploded lying > around. I'll assume it's recent enough and will post the results of the > grep, but it takes some time as it's on a compressed filesystem. Great Lubomir! Thx. I'm looking forward to see the results. Best, Oliver From denis at poolshark.org Tue Dec 18 12:46:52 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 18 Dec 2007 13:46:52 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218113735.GA20976@free.fr> References: <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> Message-ID: <4767C13C.4060601@poolshark.org> Patrice Dumas wrote: > On Tue, Dec 18, 2007 at 12:00:45PM +0100, Lennart Poettering wrote: >> On Tue, 18.12.07 09:24, Patrice Dumas (pertusus at free.fr) wrote: >> >>>> It's not that PA doesn't work at all on those special no-X-involved >>>> setups. The only limitation is that you need to run PA manually in >>>> such setups. -- No big deal! >>> Is there something like a session pam module planned to start PA to >>> achieve independence from the the login entry point? >> I am not convinced that PAM is the right place to start any daemons. > > But gdm is? why not start PA from an init script ? From jwboyer at gmail.com Tue Dec 18 13:27:09 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 18 Dec 2007 07:27:09 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a Message-ID: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> That's right... it's time to start naming the Fedora 9 release. We're starting early this release to give the Fedora Art team time to come up with some great art for F9, and really because there is no reason to wait so long anyway. Fill in your suggestion for the blanks. Remember the rules: 1) must have some link to Werewolf More specifically, the link should be Werewolf is a and is a Where is the same for both. 2) The link between and Werewolf cannot be the same as between Moonshine and Werewolf. I will be collecting suggestions for 1 week so the cutoff for names is: December 25, 2007 Suggestions will be run through the legal queue and an election will happen for Fedora contributors to pick the next Fedora name. Let the naming begin! josh From lkundrak at redhat.com Tue Dec 18 13:32:49 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Tue, 18 Dec 2007 14:32:49 +0100 Subject: Yet another sa_restorer bug In-Reply-To: <4767B9AB.5010200@linux-kernel.at> References: <4766DF1D.3070509@linux-kernel.at> <1197979763.14028.2.camel@localhost.localdomain> <4767B9AB.5010200@linux-kernel.at> Message-ID: <1197984769.14028.5.camel@localhost.localdomain> On Tue, 2007-12-18 at 13:14 +0100, Oliver Falk wrote: > On 12/18/2007 01:09 PM, Lubomir Kundrak wrote: > > Oliver, > > > > On Mon, 2007-12-17 at 21:42 +0100, Oliver Falk wrote: > >> https://bugzilla.redhat.com/show_bug.cgi?id=426024 > >> > >> This is the second sa_restorer bug I filed. However. > >> > >> I can only ask all of you to check if your pkgs do use signal.h and if, > >> check if they do use sa_restorer. > >> > >> Maybe someone volunteers to do a grep over all sources!? And list the > >> pkgs here!? Someone already did a similar job after the introduction of > >> FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I > >> don't have the ressources at the moment... > > > > I have complete rawhide source tree from 2007-11-14 exploded lying > > around. I'll assume it's recent enough and will post the results of the > > grep, but it takes some time as it's on a compressed filesystem. > > Great Lubomir! Thx. I'm looking forward to see the results. Here you are [1]. Just raw grep results, I hope it will help you find out where to look for sa_restorer occurences. [1] http://skosi.org/~lkundrak/misc/sa_restorer Regards, -- Lubomir Kundrak (Red Hat Security Response Team) From limb at jcomserv.net Tue Dec 18 13:32:31 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 18 Dec 2007 07:32:31 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. > > Fill in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Werewolf > > More specifically, the link should be > Werewolf is a and > is a > Where is the same for both. > > 2) The link between and Werewolf cannot be the same as between > Moonshine and Werewolf. Unicorn. Link = fictional creatures. > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Tue Dec 18 13:37:14 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 18 Dec 2007 07:37:14 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> Message-ID: <5042.63.85.68.164.1197985034.squirrel@mail.jcomserv.net> > >> That's right... it's time to start naming the Fedora 9 release. We're >> starting early this release to give the Fedora Art team time to come up >> with some great art for F9, and really because there is no reason to >> wait so long anyway. >> >> Fill in your suggestion for the blanks. Remember the rules: >> >> 1) must have some link to Werewolf >> >> More specifically, the link should be >> Werewolf is a and >> is a >> Where is the same for both. >> >> 2) The link between and Werewolf cannot be the same as between >> Moonshine and Werewolf. > > Unicorn. Link = fictional creatures. Ooh, then F10 could be Narwhal, link = one-horn. Then F11 could be Lancaster, link = UK military aircraft. Maybe Nimrod. >> I will be collecting suggestions for 1 week so the cutoff for names is: >> >> December 25, 2007 >> >> Suggestions will be run through the legal queue and an election will >> happen for Fedora contributors to pick the next Fedora name. >> >> Let the naming begin! >> >> josh >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From oliver at linux-kernel.at Tue Dec 18 13:43:42 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 18 Dec 2007 14:43:42 +0100 Subject: Yet another sa_restorer bug In-Reply-To: <1197984769.14028.5.camel@localhost.localdomain> References: <4766DF1D.3070509@linux-kernel.at> <1197979763.14028.2.camel@localhost.localdomain> <4767B9AB.5010200@linux-kernel.at> <1197984769.14028.5.camel@localhost.localdomain> Message-ID: <4767CE8E.7000301@linux-kernel.at> On 12/18/2007 02:32 PM, Lubomir Kundrak wrote: > On Tue, 2007-12-18 at 13:14 +0100, Oliver Falk wrote: >> On 12/18/2007 01:09 PM, Lubomir Kundrak wrote: >>> Oliver, >>> >>> On Mon, 2007-12-17 at 21:42 +0100, Oliver Falk wrote: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=426024 >>>> >>>> This is the second sa_restorer bug I filed. However. >>>> >>>> I can only ask all of you to check if your pkgs do use signal.h and if, >>>> check if they do use sa_restorer. >>>> >>>> Maybe someone volunteers to do a grep over all sources!? And list the >>>> pkgs here!? Someone already did a similar job after the introduction of >>>> FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I >>>> don't have the ressources at the moment... >>> I have complete rawhide source tree from 2007-11-14 exploded lying >>> around. I'll assume it's recent enough and will post the results of the >>> grep, but it takes some time as it's on a compressed filesystem. >> Great Lubomir! Thx. I'm looking forward to see the results. > > Here you are [1]. Just raw grep results, I hope it will help you find > out where to look for sa_restorer occurences. > > [1] http://skosi.org/~lkundrak/misc/sa_restorer Well. There are some in kernel - I don't want to touch that :-) However, there are some that are already commented out - but some are still serious. I'll take a closer look on that in the next days and see how we can do an easy join of the pkg names + maintainer mail :-) -of From oliver at linux-kernel.at Tue Dec 18 13:43:42 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 18 Dec 2007 14:43:42 +0100 Subject: Yet another sa_restorer bug In-Reply-To: <1197984769.14028.5.camel@localhost.localdomain> References: <4766DF1D.3070509@linux-kernel.at> <1197979763.14028.2.camel@localhost.localdomain> <4767B9AB.5010200@linux-kernel.at> <1197984769.14028.5.camel@localhost.localdomain> Message-ID: <4767CE8E.7000301@linux-kernel.at> On 12/18/2007 02:32 PM, Lubomir Kundrak wrote: > On Tue, 2007-12-18 at 13:14 +0100, Oliver Falk wrote: >> On 12/18/2007 01:09 PM, Lubomir Kundrak wrote: >>> Oliver, >>> >>> On Mon, 2007-12-17 at 21:42 +0100, Oliver Falk wrote: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=426024 >>>> >>>> This is the second sa_restorer bug I filed. However. >>>> >>>> I can only ask all of you to check if your pkgs do use signal.h and if, >>>> check if they do use sa_restorer. >>>> >>>> Maybe someone volunteers to do a grep over all sources!? And list the >>>> pkgs here!? Someone already did a similar job after the introduction of >>>> FORITIFY_SOURCE=2 with glibc's open check... I would do so myself, but I >>>> don't have the ressources at the moment... >>> I have complete rawhide source tree from 2007-11-14 exploded lying >>> around. I'll assume it's recent enough and will post the results of the >>> grep, but it takes some time as it's on a compressed filesystem. >> Great Lubomir! Thx. I'm looking forward to see the results. > > Here you are [1]. Just raw grep results, I hope it will help you find > out where to look for sa_restorer occurences. > > [1] http://skosi.org/~lkundrak/misc/sa_restorer Well. There are some in kernel - I don't want to touch that :-) However, there are some that are already commented out - but some are still serious. I'll take a closer look on that in the next days and see how we can do an easy join of the pkg names + maintainer mail :-) -of From myfedora at richip.dhs.org Tue Dec 18 13:51:49 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Dec 2007 06:51:49 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197969643.3361.0.camel@s1.crocom.com.pl> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> Message-ID: <1197985910.30757.3.camel@localhost6.localdomain6> On Tue, 2007-12-18 at 10:20 +0100, Tomasz Torcz wrote: > Dnia 18-12-2007, wto o godzinie 00:48 +0100, Lennart Poettering pisze: > > You can configure PA so that it is autospawned when needed. However, I > > do not recommend this. I recommend to start it from the session > > manager like we do it right now for KDE and GNOME. Why? Because PA > > nowadays does much more than just proxying access to the hw. It reacts > > on hotplug events, network configuration changes, certain X11 events, > > it is a network server, and so on and so on. For all these reasons it > > is better to leave PA running all the time. > > If PA is so important, why not start it system-wide by default? The access model it is using is running the daemon as the UID of the user that is running the "session" (as opposed to a specific PA UID that authenticates and authorizes each access request). Not to mention going against the desires of a group of users who don't believe it is that necessary. -- Richi Plana From jnovy at redhat.com Tue Dec 18 14:08:07 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 18 Dec 2007 15:08:07 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> Message-ID: <20071218140807.GA2287@localhost.localdomain> On Tue, Dec 18, 2007 at 07:32:31AM -0600, Jon Ciesla wrote: > > > That's right... it's time to start naming the Fedora 9 release. We're > > starting early this release to give the Fedora Art team time to come up > > with some great art for F9, and really because there is no reason to > > wait so long anyway. > > > > Fill in your suggestion for the blanks. Remember the rules: > > > > 1) must have some link to Werewolf > > > > More specifically, the link should be > > Werewolf is a and > > is a > > Where is the same for both. > > > > 2) The link between and Werewolf cannot be the same as between > > Moonshine and Werewolf. > > Unicorn. Link = fictional creatures. How about Vampire? The same link as above. > > > I will be collecting suggestions for 1 week so the cutoff for names is: > > > > December 25, 2007 > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > Let the naming begin! > > > > josh > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy http://people.redhat.com/jnovy/ From galibert at pobox.com Tue Dec 18 14:22:18 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 18 Dec 2007 15:22:18 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <4767C13C.4060601@poolshark.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> Message-ID: <20071218142218.GA48638@dspnet.fr.eu.org> On Tue, Dec 18, 2007 at 01:46:52PM +0100, Denis Leroy wrote: > Patrice Dumas wrote: > >On Tue, Dec 18, 2007 at 12:00:45PM +0100, Lennart Poettering wrote: > >>I am not convinced that PAM is the right place to start any daemons. > > > >But gdm is? > > why not start PA from an init script ? Something is still unclear to be. Are the PA deamons per-system, per-user or per-login session? OG. From limb at jcomserv.net Tue Dec 18 14:32:24 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 18 Dec 2007 08:32:24 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218140807.GA2287@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> Message-ID: <55266.63.85.68.164.1197988344.squirrel@mail.jcomserv.net> > On Tue, Dec 18, 2007 at 07:32:31AM -0600, Jon Ciesla wrote: >> >> > That's right... it's time to start naming the Fedora 9 release. We're >> > starting early this release to give the Fedora Art team time to come >> up >> > with some great art for F9, and really because there is no reason to >> > wait so long anyway. >> > >> > Fill in your suggestion for the blanks. Remember the rules: >> > >> > 1) must have some link to Werewolf >> > >> > More specifically, the link should be >> > Werewolf is a and >> > is a >> > Where is the same for both. >> > >> > 2) The link between and Werewolf cannot be the same as >> between >> > Moonshine and Werewolf. >> >> Unicorn. Link = fictional creatures. > > How about Vampire? The same link as above. Unicorns are cuter. :) Who doesn't love unicorns? Besides, Vampire would DEFINATELY kill your kittens. :) >> >> > I will be collecting suggestions for 1 week so the cutoff for names >> is: >> > >> > December 25, 2007 >> > >> > Suggestions will be run through the legal queue and an election will >> > happen for Fedora contributors to pick the next Fedora name. >> > >> > Let the naming begin! >> > >> > josh >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> -- >> novus ordo absurdum >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > Jindrich Novy http://people.redhat.com/jnovy/ > -- novus ordo absurdum From cmadams at hiwaay.net Tue Dec 18 14:38:57 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 18 Dec 2007 08:38:57 -0600 Subject: Disable a USB device? In-Reply-To: <20071218090902.GD29292@serv.smile.org.ua> References: <20071218012600.GB909413@hiwaay.net> <20071218090902.GD29292@serv.smile.org.ua> Message-ID: <20071218143857.GA1079654@hiwaay.net> Once upon a time, Andy Shevchenko said: > On Mon, Dec 17, 2007 at 07:26:00PM -0600, Chris Adams wrote next: > > Otherwise, USB wakes up 4 times per second for no particular reason (no > > other USB devices are attached). > I don't know exactly, but may be some like next helps? > > [root at toaster special-english]# echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup That didn't seem to help. Not only does "rmmod usb-uhci" cut out 4 wakeups per second, it allows the CPU to go into state C3 (otherwise I never see anything but C2). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sandeen at redhat.com Tue Dec 18 14:47:25 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 18 Dec 2007 08:47:25 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <55266.63.85.68.164.1197988344.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> <55266.63.85.68.164.1197988344.squirrel@mail.jcomserv.net> Message-ID: <4767DD7D.3000904@redhat.com> Jon Ciesla wrote: >> On Tue, Dec 18, 2007 at 07:32:31AM -0600, Jon Ciesla wrote: >>>> 2) The link between and Werewolf cannot be the same as >>> between >>>> Moonshine and Werewolf. >>> Unicorn. Link = fictional creatures. >> How about Vampire? The same link as above. > > Unicorns are cuter. :) Who doesn't love unicorns? Besides, Vampire would > DEFINATELY kill your kittens. :) Plus, then the next release could be "Rainbow Pony", link == things my first grader might like on her sparkly lunchbox... ;-) -Eric From cjdahlin at ncsu.edu Tue Dec 18 14:49:29 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 18 Dec 2007 09:49:29 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <4767DDF9.9030608@ncsu.edu> Josh Boyer wrote: > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. > > Fill in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Werewolf > > More specifically, the link should be > Werewolf is a and > is a > Where is the same for both. > > 2) The link between and Werewolf cannot be the same as between > Moonshine and Werewolf. > > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! > > josh > > Homedog. Link = canine/human hybrid. From galibert at pobox.com Tue Dec 18 15:12:21 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 18 Dec 2007 16:12:21 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197985910.30757.3.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> Message-ID: <20071218151221.GA53607@dspnet.fr.eu.org> On Tue, Dec 18, 2007 at 06:51:49AM -0700, Richi Plana wrote: > The access model it is using is running the daemon as the UID of the > user that is running the "session" (as opposed to a specific PA UID that > authenticates and authorizes each access request). Hmmm, if it is "one daemon per user", can multiple deamons for different users run simultaneously? OG. From mclasen at redhat.com Tue Dec 18 15:15:58 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 18 Dec 2007 10:15:58 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218151221.GA53607@dspnet.fr.eu.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> Message-ID: <1197990958.2944.10.camel@localhost.localdomain> On Tue, 2007-12-18 at 16:12 +0100, Olivier Galibert wrote: > On Tue, Dec 18, 2007 at 06:51:49AM -0700, Richi Plana wrote: > > The access model it is using is running the daemon as the UID of the > > user that is running the "session" (as opposed to a specific PA UID that > > authenticates and authorizes each access request). > > Hmmm, if it is "one daemon per user", can multiple deamons for > different users run simultaneously? Why don't you try it yourself, instead of blowing up this thread even further ? From bnocera at redhat.com Tue Dec 18 15:22:03 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 18 Dec 2007 15:22:03 +0000 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197829821.5869.3.camel@localhost> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <1197829821.5869.3.camel@localhost> Message-ID: <1197991323.26210.383.camel@cookie.hadess.net> On Sun, 2007-12-16 at 12:30 -0600, Callum Lerwick wrote: > On Sun, 2007-12-16 at 09:46 -0700, Richi Plana wrote: > > No, no, no. > > > > First of all, ideally, any service should be started by the app that > > actually needs it, either implicitly or automatically. You're right that > > it's not the duty of the window manager to start a sound server like PA, > > but I don't think the wm is what's starting it in this case. > > Yes yes yes. > > > I believe > > it's the session manager, which makes sense because the session manager > > is a part of a bigger app (the DE) that knows it will actually use the > > sound server. > > No no no. The Pulseaudio library should take care of starting the damn > daemon. Like esd did. And it was completely broken, because you had no idea what would be starting it, or which environment it would end up with. It's disabled by default, because it's broken. From mark.bidewell at alumni.clemson.edu Tue Dec 18 16:08:52 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Tue, 18 Dec 2007 11:08:52 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: How about "Mad Hatter" Fictional beast + bonus to the Fedora logo or Optimus (Werewolf can change its form) Optimus Prime could change his form Mark Bidewell On 12/18/07, Josh Boyer wrote: > > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. > > Fill in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Werewolf > > More specifically, the link should be > Werewolf is a and > is a > Where is the same for both. > > 2) The link between and Werewolf cannot be the same as between > Moonshine and Werewolf. > > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! > > 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 ericsbinaryworld at gmail.com Tue Dec 18 16:14:37 2007 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Tue, 18 Dec 2007 11:14:37 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767DDF9.9030608@ncsu.edu> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <4767DDF9.9030608@ncsu.edu> Message-ID: <582715960712180814r3c89950j7a895197f775f60f@mail.gmail.com> Helsing connection -> hunts creatures similar to werewolves On Dec 18, 2007 9:49 AM, Casey Dahlin wrote: > Josh Boyer wrote: > > That's right... it's time to start naming the Fedora 9 release. We're > > starting early this release to give the Fedora Art team time to come up > > with some great art for F9, and really because there is no reason to > > wait so long anyway. > > > > Fill in your suggestion for the blanks. Remember the rules: > > > > 1) must have some link to Werewolf > > > > More specifically, the link should be > > Werewolf is a and > > is a > > Where is the same for both. > > > > 2) The link between and Werewolf cannot be the same as between > > Moonshine and Werewolf. > > > > I will be collecting suggestions for 1 week so the cutoff for names is: > > > > December 25, 2007 > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > Let the naming begin! > > > > josh > > > > > Homedog. Link = canine/human hybrid. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Eric Mesa http://www.ericsbinaryworld.com http://server.ericsbinaryworld.com "Do not worry about those things that are outside of your circle of influence. For since they are outside of your power to control them it is simply a waste of time and energy to dwell on them. Instead, turn your attention to those things that you can control and grow your influence in those areas and you will see the effects begin to trickle out to those items that were previously out of your power to influence." ? Eric Mesa inspired by Covey's 7 Habits of Highly Effective People -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu_fedora at nicubunu.ro Tue Dec 18 16:22:42 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 18 Dec 2007 18:22:42 +0200 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <5042.63.85.68.164.1197985034.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <5042.63.85.68.164.1197985034.squirrel@mail.jcomserv.net> Message-ID: <4767F3D2.3040402@nicubunu.ro> Jon Ciesla wrote: >> Unicorn. Link = fictional creatures. > > Ooh, then F10 could be Narwhal, link = one-horn. Then F11 could be > Lancaster, link = UK military aircraft. Maybe Nimrod. Well, then F9 could be Narwhal or Lancaster as Werewolf is a USSR attack helicopter (Kamov Ka-50, Hokum) -- 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 mdehaan at redhat.com Tue Dec 18 16:20:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 18 Dec 2007 11:20:29 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> Message-ID: <4767F34D.2090905@redhat.com> Jon Ciesla wrote: >> That's right... it's time to start naming the Fedora 9 release. >> > > Unicorn. Link = fictional creatures. I bring bad suggestions for everyone: * Dragicorn. Link = fictional creatures. * Moonshine. Link = werewolf was a Fedora release codename, Moonshine was also a Fedora release codename. * Apache. Link = werewolf is a apparently a codename for a Russian Helicopter. An Apache is also a helicopter. * Fred. Werewolves are killed by silver bullets. Fred Brooks said there is no Silver Bullet. * Dentist. Werewolves scare kids. Dentists scare kids. (substitute something else that scares kids). No, seriously, I'm totally going with Dragicorn. They are better than Hippie Hamsters or Indifferent Iguanas any way you look at it. Even better it makes the next naming choice very hard :) --Michael From lowen at pari.edu Tue Dec 18 16:25:21 2007 From: lowen at pari.edu (Lamar Owen) Date: Tue, 18 Dec 2007 11:25:21 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <200712181125.21403.lowen@pari.edu> On Tuesday 18 December 2007, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. Tennin Six Months. (Tennin is a shapeshifting entity in Japanese Buddhism; Werewolf is a shapeshifting entitity). -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From ericsbinaryworld at gmail.com Tue Dec 18 16:27:47 2007 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Tue, 18 Dec 2007 11:27:47 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767F34D.2090905@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <4767F34D.2090905@redhat.com> Message-ID: <582715960712180827k7b2d0185w692fcde7c5abb0c9@mail.gmail.com> "No, seriously, I'm totally going with Dragicorn. They are better than Hippie Hamsters or Indifferent Iguanas any way you look at it. Even better it makes the next naming choice very hard :)" Hilarious jab at our friends over at canonical On Dec 18, 2007 11:20 AM, Michael DeHaan wrote: > Jon Ciesla wrote: > >> That's right... it's time to start naming the Fedora 9 release. > >> > > > > Unicorn. Link = fictional creatures. > > I bring bad suggestions for everyone: > > * Dragicorn. Link = fictional creatures. > * Moonshine. Link = werewolf was a Fedora release codename, Moonshine > was also a Fedora release codename. > * Apache. Link = werewolf is a apparently a codename for a Russian > Helicopter. An Apache is also a helicopter. > * Fred. Werewolves are killed by silver bullets. Fred Brooks said > there is no Silver Bullet. > * Dentist. Werewolves scare kids. Dentists scare kids. (substitute > something else that scares kids). > > No, seriously, I'm totally going with Dragicorn. They are better than > Hippie Hamsters or Indifferent Iguanas any way > you look at it. Even better it makes the next naming choice very hard :) > > --Michael > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Eric Mesa http://www.ericsbinaryworld.com http://server.ericsbinaryworld.com "Do not worry about those things that are outside of your circle of influence. For since they are outside of your power to control them it is simply a waste of time and energy to dwell on them. Instead, turn your attention to those things that you can control and grow your influence in those areas and you will see the effects begin to trickle out to those items that were previously out of your power to influence." ? Eric Mesa inspired by Covey's 7 Habits of Highly Effective People -------------- next part -------------- An HTML attachment was scrubbed... URL: From loupgaroublond at gmail.com Tue Dec 18 16:28:09 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 18 Dec 2007 11:28:09 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767F34D.2090905@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <4767F34D.2090905@redhat.com> Message-ID: <7f692fec0712180828k201ed6f6vbd93300caf1a12d0@mail.gmail.com> On Dec 18, 2007 11:20 AM, Michael DeHaan wrote: > I bring bad suggestions for everyone: > > * Dragicorn. Link = fictional creatures. > * Moonshine. Link = werewolf was a Fedora release codename, Moonshine > was also a Fedora release codename. > * Apache. Link = werewolf is a apparently a codename for a Russian > Helicopter. An Apache is also a helicopter. > * Fred. Werewolves are killed by silver bullets. Fred Brooks said > there is no Silver Bullet. > * Dentist. Werewolves scare kids. Dentists scare kids. (substitute > something else that scares kids). > > No, seriously, I'm totally going with Dragicorn. They are better than > Hippie Hamsters or Indifferent Iguanas any way > you look at it. Even better it makes the next naming choice very hard :) How about a Liger, almost as ferocious as a Werewolf? -le loupgarou blond From nicu_fedora at nicubunu.ro Tue Dec 18 16:31:07 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 18 Dec 2007 18:31:07 +0200 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <4767F5CB.7010605@nicubunu.ro> Josh Boyer wrote: > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! Here is a name I am sure will not pass legal, but I like the complex connection: Iron Maiden. Link? Werewolves and vampires are somewhat alike and in an continual war, kicking each other's asses, with Dracula the most "popular" vampire. Dracula takes his name from Vlad the Impaler but is inspired from the history of Countess Bathory, which allegedly used to bath in virgin's blood, believing this will keep her young. And the best torture device to deplete a human body of blood is the Iron Maiden. -- 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 limb at jcomserv.net Tue Dec 18 16:31:35 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 18 Dec 2007 10:31:35 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767F5CB.7010605@nicubunu.ro> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <4767F5CB.7010605@nicubunu.ro> Message-ID: <47199.63.85.68.164.1197995495.squirrel@mail.jcomserv.net> > Josh Boyer wrote: >> I will be collecting suggestions for 1 week so the cutoff for names is: >> >> December 25, 2007 >> >> Suggestions will be run through the legal queue and an election will >> happen for Fedora contributors to pick the next Fedora name. >> >> Let the naming begin! > > Here is a name I am sure will not pass legal, but I like the complex > connection: Iron Maiden. > Link? Werewolves and vampires are somewhat alike and in an continual > war, kicking each other's asses, with Dracula the most "popular" > vampire. Dracula takes his name from Vlad the Impaler but is inspired > from the history of Countess Bathory, which allegedly used to bath in > virgin's blood, believing this will keep her young. And the best torture > device to deplete a human body of blood is the Iron Maiden. Ok, man, exhale, exhale. :) > -- > 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 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mike at miketc.com Tue Dec 18 16:35:12 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 18 Dec 2007 10:35:12 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181125.21403.lowen@pari.edu> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <200712181125.21403.lowen@pari.edu> Message-ID: <1197995712.2522.1.camel@scrappy.miketc.com> On Tue, 2007-12-18 at 11:25 -0500, Lamar Owen wrote: > On Tuesday 18 December 2007, Josh Boyer wrote: > > That's right... it's time to start naming the Fedora 9 release. We're > > starting early this release to give the Fedora Art team time to come up > > with some great art for F9, and really because there is no reason to > > wait so long anyway. > > Tennin Six Months. > > (Tennin is a shapeshifting entity in Japanese Buddhism; Werewolf is a > shapeshifting entitity). Sasquatch --> Both are VERY hairy! -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From ssorce at redhat.com Tue Dec 18 16:38:09 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 11:38:09 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <1197995889.19318.47.camel@localhost.localdomain> Anubis [1]: Anubis is a mythological creature of human/canine form Werewolf is a mythological creature of human/canine form [1]: http://en.wikipedia.org/wiki/Anubis Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From akahl at iconmobile.com Tue Dec 18 16:37:57 2007 From: akahl at iconmobile.com (Alexander Kahl) Date: Tue, 18 Dec 2007 17:37:57 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <1197995877.27690.27.camel@dev31.iconmobile.de> Octopus, as they are one of the few non-fictional shapeshifters. "Some animals, particularly octopi, are able to change their body shape and color to mimic other creatures and objects, for camouflage or to hide in narrow spaces. The Mimic Octopus is noted for its ability to impersonate sea snakes, widely different fish species, and rock formations." (source: http://en.wikipedia.org/wiki/Shapeshifting) Or perhaps, to stay within fictional realms, Doppelganger (German loanword "Doppelg?nger"). "While Doppelg?ngers in folklore were a kind of portent that resembled a person, with no shapeshifting required, in modern fiction and roleplaying games, they are usually depicted as shape-shifters out to usurp someone's place." (source: http://en.wikipedia.org/wiki/Shapeshifting) Alex On Tue, 2007-12-18 at 07:27 -0600, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. > > Fill in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Werewolf > > More specifically, the link should be > Werewolf is a and > is a > Where is the same for both. > > 2) The link between and Werewolf cannot be the same as between > Moonshine and Werewolf. > > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! > > josh > -- alexander kahl _ developer iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256 akahl at iconmobile.com _ www.iconmobile.com local court charlottenburg _ hrb 88308 managing directors _ thomas fellger | stefan kirschke -------------- 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 gmail.com Tue Dec 18 16:45:49 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 18 Dec 2007 10:45:49 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <582715960712180814r3c89950j7a895197f775f60f@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <4767DDF9.9030608@ncsu.edu> <582715960712180814r3c89950j7a895197f775f60f@mail.gmail.com> Message-ID: <20071218104549.4a29b761@hansolo.jdub.homelinux.org> On Tue, 18 Dec 2007 11:14:37 -0500 "Eric Mesa" wrote: > Helsing > > connection -> hunts creatures similar to werewolves I think you mean Van Helsing. And I believe that the connection is too closely related to that of Moonshine -> Werewolf, which is movies. josh From nicu_fedora at nicubunu.ro Tue Dec 18 16:50:06 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 18 Dec 2007 18:50:06 +0200 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <4767FA3E.9080809@nicubunu.ro> Mark Bidewell wrote: > How about "Mad Hatter" Fictional beast + bonus to the Fedora logo You know "Mad Hatter" was a codename for Sun Java Desktop System? -- 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 dennis at ausil.us Tue Dec 18 16:55:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 18 Dec 2007 10:55:00 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1197995889.19318.47.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> Message-ID: <200712181055.00912.dennis@ausil.us> On Tuesday 18 December 2007, Simo Sorce wrote: > Anubis [1]: > > Anubis is a mythological creature of human/canine form > Werewolf is a mythological creature of human/canine form > > [1]: http://en.wikipedia.org/wiki/Anubis I like this suggestion :) Dennis From silfreed at silfreed.net Tue Dec 18 17:05:15 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 18 Dec 2007 12:05:15 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1197995889.19318.47.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> Message-ID: <200712181205.15928.silfreed@silfreed.net> On Tuesday 18 December 2007, Simo Sorce wrote: > Anubis [1]: > > Anubis is a mythological creature of human/canine form > Werewolf is a mythological creature of human/canine form > > [1]: http://en.wikipedia.org/wiki/Anubis +1; it opens up the Stargate references for the next batch. -Doug -------------- 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 smooge at gmail.com Tue Dec 18 17:32:52 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 18 Dec 2007 10:32:52 -0700 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <80d7e4090712180932x18293cbxdaf904181bc01fe4@mail.gmail.com> On Dec 18, 2007 6:27 AM, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. > Cool. Gives me time to finish up the page and articles before 9 occurs. Ok 3 and 6 were both RHEL bases.. I wonder if 9 will be? Things that will not get past Legal, but might be fun: GURPS -- Linked that Werewolf and GURPS are roleplaying games Airwolf - Werewolf and Airwolf are helicopters Talbot - The character name in the Wolf Man Chaney - The last name of the Werewolf Trader Vic - The place werewolves drink their Pina Coladas Semi legal names Pina Colada - The drink werewolves like Selkie - Shapeshifter seal Penguicorn - A Penguin with a Horn -- 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 cjdahlin at ncsu.edu Tue Dec 18 17:31:20 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 18 Dec 2007 12:31:20 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767F5CB.7010605@nicubunu.ro> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <4767F5CB.7010605@nicubunu.ro> Message-ID: <476803E8.2040400@ncsu.edu> Nicu Buculei wrote: > Josh Boyer wrote: >> I will be collecting suggestions for 1 week so the cutoff for names is: >> >> December 25, 2007 >> >> Suggestions will be run through the legal queue and an election will >> happen for Fedora contributors to pick the next Fedora name. >> >> Let the naming begin! > > Here is a name I am sure will not pass legal, but I like the complex > connection: Iron Maiden. > Link? Werewolves and vampires are somewhat alike and in an continual > war, kicking each other's asses, with Dracula the most "popular" > vampire. Dracula takes his name from Vlad the Impaler but is inspired > from the history of Countess Bathory, which allegedly used to bath in > virgin's blood, believing this will keep her young. And the best > torture device to deplete a human body of blood is the Iron Maiden. > ...who was in Friday the 13th, with Kevin Bacon. From mark.bidewell at alumni.clemson.edu Tue Dec 18 17:35:41 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Tue, 18 Dec 2007 12:35:41 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181205.15928.silfreed@silfreed.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> Message-ID: Absolutely awesome great idea! On 12/18/07, Douglas E. Warner wrote: > > On Tuesday 18 December 2007, Simo Sorce wrote: > > Anubis [1]: > > > > Anubis is a mythological creature of human/canine form > > Werewolf is a mythological creature of human/canine form > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > +1; it opens up the Stargate references for the next batch. > > -Doug > > -- > 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 cjdahlin at ncsu.edu Tue Dec 18 17:34:43 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 18 Dec 2007 12:34:43 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <7f692fec0712180828k201ed6f6vbd93300caf1a12d0@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <4767F34D.2090905@redhat.com> <7f692fec0712180828k201ed6f6vbd93300caf1a12d0@mail.gmail.com> Message-ID: <476804B3.8060903@ncsu.edu> Yaakov Nemoy wrote: > On Dec 18, 2007 11:20 AM, Michael DeHaan wrote: > >> I bring bad suggestions for everyone: >> >> * Dragicorn. Link = fictional creatures. >> * Moonshine. Link = werewolf was a Fedora release codename, Moonshine >> was also a Fedora release codename. >> * Apache. Link = werewolf is a apparently a codename for a Russian >> Helicopter. An Apache is also a helicopter. >> * Fred. Werewolves are killed by silver bullets. Fred Brooks said >> there is no Silver Bullet. >> * Dentist. Werewolves scare kids. Dentists scare kids. (substitute >> something else that scares kids). >> >> No, seriously, I'm totally going with Dragicorn. They are better than >> Hippie Hamsters or Indifferent Iguanas any way >> you look at it. Even better it makes the next naming choice very hard :) >> > > How about a Liger, almost as ferocious as a Werewolf? > > Bred for its skills in magic? Its probably my favorite animal. > -le loupgarou blond > > From mdehaan at redhat.com Tue Dec 18 18:08:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 18 Dec 2007 13:08:09 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> Message-ID: <47680C89.7060607@redhat.com> Mark Bidewell wrote: > Absolutely awesome great idea! > > On 12/18/07, *Douglas E. Warner* > wrote: > > On Tuesday 18 December 2007, Simo Sorce wrote: > > Anubis [1]: > > > > Anubis is a mythological creature of human/canine form > > Werewolf is a mythological creature of human/canine form > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > +1; it opens up the Stargate references for the next batch. > > -Doug > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > Undomesticated equines can not remove me from voting for this one. +1 million just for the pending Stargate release naming opportunity. --Michael From mzerqung at 0pointer.de Tue Dec 18 18:14:20 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:14:20 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197938347.26469.16.camel@localhost6.localdomain6> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197938347.26469.16.camel@localhost6.localdomain6> Message-ID: <20071218181420.GB28630@tango.0pointer.de> On Mon, 17.12.07 17:39, Richi Plana (myfedora at richip.dhs.org) wrote: > > You can configure PA so that it is autospawned when needed. However, I > > do not recommend this. I recommend to start it from the session > > manager like we do it right now for KDE and GNOME. Why? Because PA > > nowadays does much more than just proxying access to the hw. It reacts > > on hotplug events, network configuration changes, certain X11 events, > > it is a network server, and so on and so on. For all these reasons it > > is better to leave PA running all the time. > > But how are those hotplug events communicated? That's what I meant when > I said the pulseaudio sound server should be started on an as-needed > triggering event. If there are too many entry paths to using PA, then I > understand the complexity. The hotplug events come from HAL, so effectivel they are passed via D-Bus. There are a lot of external event sources PA acts on. If you really want to have them all trigger "on-demand" launching of PA, then you'd need a lot of "starter" programs everywhere. And PA would be started, and stopped and started and stopped all the time. Certainly nothing that helps user experience and performance of your system. Handling audio is a long-running process and not just something that is a short reaction on some other action. Also, those actions can come very frequently. Thus, PA should be running all the time, and not only when some action happens. > What's the underlying communication mechanism for event passing? D-Bus? > TCP communication? For TCP sessions, we have xinetd. Would there be an > interest in having a similar service for spawning object / services as a > result of D-Bus service requests? Or is there already an existing > infrastructure? Now I'm just curious. inetd is dead. And I am dancing on its grave. Virtually no modern network server software these days comes with inetd support enabled by default anymore. Also, things like inetd run as system daemon, not as user daemon. So, if you want to start PA via such a system than you'd have to duplicate inetd for the user. And not just inetd. Also HAL, Avahi, cron, X11... Again. I really don't think that auto-spawning is what you want. There are too many paths that might need to get PA started. Just think about one trivial thing: X11 integration. PA connects to X11 to hook into a couple of events (bell, ...). In your model X11 would be starting PA everytime one of these events happen, across user boundaries. Eerks! The X11 people would certainly love that! ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From ssorce at redhat.com Tue Dec 18 18:15:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 13:15:05 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181205.15928.silfreed@silfreed.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> Message-ID: <1198001705.19318.62.camel@localhost.localdomain> On Tue, 2007-12-18 at 12:05 -0500, Douglas E. Warner wrote: > On Tuesday 18 December 2007, Simo Sorce wrote: > > Anubis [1]: > > > > Anubis is a mythological creature of human/canine form > > Werewolf is a mythological creature of human/canine form > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > +1; it opens up the Stargate references for the next batch. Eh eh I knew this was going to be appreciated :) Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From skvidal at fedoraproject.org Tue Dec 18 18:21:42 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 18 Dec 2007 13:21:42 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <47680C89.7060607@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> Message-ID: <1198002102.13693.12.camel@cutter> On Tue, 2007-12-18 at 13:08 -0500, Michael DeHaan wrote: > Mark Bidewell wrote: > > Absolutely awesome great idea! > > > > On 12/18/07, *Douglas E. Warner* > > wrote: > > > > On Tuesday 18 December 2007, Simo Sorce wrote: > > > Anubis [1]: > > > > > > Anubis is a mythological creature of human/canine form > > > Werewolf is a mythological creature of human/canine form > > > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > > > +1; it opens up the Stargate references for the next batch. > > > > -Doug > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > Undomesticated equines can not remove me from voting for this one. > > +1 million just for the pending Stargate release naming opportunity. Okay, but I want everyone to know about an important strategic decision we have to make. Fedora 11 MUST be named "ours goes to" Fedora "ours goes to" 11 Optionally it could be named: Lumbar Puncture. So we have to get from here to there. :) -sv From mzerqung at 0pointer.de Tue Dec 18 18:26:29 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:26:29 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197969643.3361.0.camel@s1.crocom.com.pl> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> Message-ID: <20071218182629.GC28630@tango.0pointer.de> On Tue, 18.12.07 10:20, Tomasz Torcz (tomek at crocom.com.pl) wrote: > > You can configure PA so that it is autospawned when needed. However, I > > do not recommend this. I recommend to start it from the session > > manager like we do it right now for KDE and GNOME. Why? Because PA > > nowadays does much more than just proxying access to the hw. It reacts > > on hotplug events, network configuration changes, certain X11 events, > > it is a network server, and so on and so on. For all these reasons it > > is better to leave PA running all the time. > > If PA is so important, why not start it system-wide by default? "Importance" is not really a good reason for making a daemon system-wide instead of per-session. PA is intended to be run as a session daemon. There's some support to run it as a system daemon, too. However, unless you really know what you do I discourage everyone to use it. There are many reasons why I chose to make PA a session daemon: one being desktop integration: if you want PA to hook into all kinds of events of the various parts of the desktop than you want to run PA as the same user as the rest of the desktop. Then, there is security: PA exposes a lot of internal data via SHM segments. That data might be security relevant. Opening it up for all users is thus problematic, it is much safer to run PA and the clients as the same user. Then, synchronisation with clients becomes a lot more difficult if you want to do it with low overhead but without allowing clients to hang or freeze the sound server. Then, there is the whole policy issue. If PA decides based on some policy how sound is routed/processed (i.e. volume, which device to choose) then the policy should be a per-user thing. Then, there is simplicty: it's a lot easier if you have everything in one process, instead of having a farm of cooperating processes distributed among different user ids, and not trusting each other. And the list goes on and on... Admittedly there are a couple of drawbacks of PA being a session daemon. One being that it is very difficult to play an event sound while switching VTs on FUS. And sharing sound cards between multiple active sessions is difficult too. But I think these disadvantages do not outweigh the advantages of the per-session design, far from that. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 18:28:36 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:28:36 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218113735.GA20976@free.fr> References: <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> Message-ID: <20071218182836.GD28630@tango.0pointer.de> On Tue, 18.12.07 12:37, Patrice Dumas (pertusus at free.fr) wrote: > > On Tue, Dec 18, 2007 at 12:00:45PM +0100, Lennart Poettering wrote: > > On Tue, 18.12.07 09:24, Patrice Dumas (pertusus at free.fr) wrote: > > > > > > It's not that PA doesn't work at all on those special no-X-involved > > > > setups. The only limitation is that you need to run PA manually in > > > > such setups. -- No big deal! > > > > > > Is there something like a session pam module planned to start PA to > > > achieve independence from the the login entry point? > > > > I am not convinced that PAM is the right place to start any daemons. > > But gdm is? Hm? gdm will not start PA for the real user that logs in. Just for its own greeter desktop, so that hotplug works and the whole mess. BTW, the plan is to make gdm start nm in the greeter, too, to allow networking while noone is logged in. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 18:29:16 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:29:16 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <4767C13C.4060601@poolshark.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> Message-ID: <20071218182916.GE28630@tango.0pointer.de> On Tue, 18.12.07 13:46, Denis Leroy (denis at poolshark.org) wrote: >>>>> It's not that PA doesn't work at all on those special no-X-involved >>>>> setups. The only limitation is that you need to run PA manually in >>>>> such setups. -- No big deal! >>>> Is there something like a session pam module planned to start PA to >>>> achieve independence from the the login entry point? >>> I am not convinced that PAM is the right place to start any daemons. >> But gdm is? > > why not start PA from an init script ? Because it is a per-user/per-session daemon. Not a system daemon. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From kevin at scrye.com Tue Dec 18 18:58:45 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 18 Dec 2007 11:58:45 -0700 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218182629.GC28630@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <20071218182629.GC28630@tango.0pointer.de> Message-ID: <20071218115845.569346ac@ghistelwchlohm.scrye.com> On Tue, 18 Dec 2007 19:26:29 +0100 mzerqung at 0pointer.de (Lennart Poettering) wrote: > On Tue, 18.12.07 10:20, Tomasz Torcz (tomek at crocom.com.pl) wrote: > > > > You can configure PA so that it is autospawned when needed. > > > However, I do not recommend this. I recommend to start it from > > > the session manager like we do it right now for KDE and GNOME. > > > Why? Because PA nowadays does much more than just proxying access > > > to the hw. It reacts on hotplug events, network configuration > > > changes, certain X11 events, it is a network server, and so on > > > and so on. For all these reasons it is better to leave PA running > > > all the time. > > > > If PA is so important, why not start it system-wide by default? > > "Importance" is not really a good reason for making a daemon > system-wide instead of per-session. > > PA is intended to be run as a session daemon. There's some support to > run it as a system daemon, too. However, unless you really know what > you do I discourage everyone to use it. > > There are many reasons why I chose to make PA a session daemon: ...snipp... This brings me to the following question: Why not have a /etc/xdg/autostart/pulseaudio.desktop to start pulseaudio for user sessions? Then there would be one place where at least KDE/Gnome/Xfce/any XDG compliant DE would know to start it. User could go in and disable/enable it for their session, etc. I'm sure I am probibly missing something, but this seems like a much cleaner way to do things. kevin -------------- 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 Dec 18 19:00:14 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 18 Dec 2007 13:00:14 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218182916.GE28630@tango.0pointer.de> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> Message-ID: <476818BE.2080308@gmail.com> Lennart Poettering wrote: >>>>>> It's not that PA doesn't work at all on those special no-X-involved >>>>>> setups. The only limitation is that you need to run PA manually in >>>>>> such setups. -- No big deal! >>>>> Is there something like a session pam module planned to start PA to >>>>> achieve independence from the the login entry point? >>>> I am not convinced that PAM is the right place to start any daemons. >>> But gdm is? >> why not start PA from an init script ? > > Because it is a per-user/per-session daemon. Not a system daemon. What is supposed to happen when you have multiple users/sessions on one box, as the rest of the system is designed to support? -- Les Mikesell lesmikesell at gmail.com From denis at poolshark.org Tue Dec 18 18:57:34 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 18 Dec 2007 19:57:34 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218182916.GE28630@tango.0pointer.de> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> Message-ID: <4768181E.9000503@poolshark.org> Lennart Poettering wrote: > On Tue, 18.12.07 13:46, Denis Leroy (denis at poolshark.org) wrote: > >>>>>> It's not that PA doesn't work at all on those special no-X-involved >>>>>> setups. The only limitation is that you need to run PA manually in >>>>>> such setups. -- No big deal! >>>>> Is there something like a session pam module planned to start PA to >>>>> achieve independence from the the login entry point? >>>> I am not convinced that PAM is the right place to start any daemons. >>> But gdm is? >> why not start PA from an init script ? > > Because it is a per-user/per-session daemon. Not a system daemon. but there's only one set of speakers per system, so I don't understand the logic here. Multiple instances of PA can coexist ? Does PA handle user switching correctly for example ? What if i want somebody to connect through ssh on my system and run an mp3 for me, can i allow them to do so ? From loupgaroublond at gmail.com Tue Dec 18 19:12:12 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 18 Dec 2007 14:12:12 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> On Dec 18, 2007 1:21 PM, seth vidal wrote: > Okay, but I want everyone to know about an important strategic decision > we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 Fedora X, then Fedora "ours goes to" XI I'm sure Apple Legal would have a field day. -Yaakov From kyle at mcmartin.ca Tue Dec 18 18:51:23 2007 From: kyle at mcmartin.ca (Kyle McMartin) Date: Tue, 18 Dec 2007 13:51:23 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <20071218185123.GB7847@fattire.cabal.ca> On Tue, Dec 18, 2007 at 01:21:42PM -0500, seth vidal wrote: > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > > So we have to get from here to there. :) > Werewolves of London song by Warren Zevon's amp goes to 11? From smooge at gmail.com Tue Dec 18 18:52:55 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 18 Dec 2007 11:52:55 -0700 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <80d7e4090712181052v538ca14fq7e33709d559f97a1@mail.gmail.com> On Dec 18, 2007 11:21 AM, seth vidal wrote: > > On Tue, 2007-12-18 at 13:08 -0500, Michael DeHaan wrote: > > Mark Bidewell wrote: > > > Absolutely awesome great idea! > > > > > > On 12/18/07, *Douglas E. Warner* > > > wrote: > > > > > > On Tuesday 18 December 2007, Simo Sorce wrote: > > > > Anubis [1]: > > > > > > > > Anubis is a mythological creature of human/canine form > > > > Werewolf is a mythological creature of human/canine form > > > > > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > > > > > +1; it opens up the Stargate references for the next batch. > > > > > > -Doug > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > > Undomesticated equines can not remove me from voting for this one. > > > > +1 million just for the pending Stargate release naming opportunity. > > Okay, but I want everyone to know about an important strategic decision > we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > Optionally it could be named: Lumbar Puncture. > > Transylvania Legendary home of dracula/werewolves/etc Transylvania 6-5000 has Ed Begley Jr. in it who was John 'Stumpy' Pepys in Lumbar Puncture. > So we have to get from here to there. :) > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jeff at ocjtech.us Tue Dec 18 18:41:26 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 18 Dec 2007 12:41:26 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <935ead450712181041p1cfc2e73h85f6537168c2e236@mail.gmail.com> On 12/18/07, seth vidal wrote: > > Okay, but I want everyone to know about an important strategic decision > we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > Optionally it could be named: Lumbar Puncture. > > So we have to get from here to there. :) +11 Jeff From silfreed at silfreed.net Tue Dec 18 18:30:28 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 18 Dec 2007 13:30:28 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <200712181330.28613.silfreed@silfreed.net> On Tuesday 18 December 2007, seth vidal wrote: > Okay, but I want everyone to know about an important strategic decision > we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > Optionally it could be named: Lumbar Puncture. > > > So we have to get from here to there. :) Given how much emphasis Stargate SG-1 gave to puns, it really shouldn't be that hard to branch out from Stargate to anything :) -Doug -------------- 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 mzerqung at 0pointer.de Tue Dec 18 18:36:09 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:36:09 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <11021.192.54.193.52.1197976984.squirrel@rousalka.dyndns.org> References: <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> <20071218104250.GB1518@tango.0pointer.de> <11021.192.54.193.52.1197976984.squirrel@rousalka.dyndns.org> Message-ID: <20071218183609.GG28630@tango.0pointer.de> On Tue, 18.12.07 12:23, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > I am not sure what you want? > > I want an official way to get sound working for non-human-user > sessions that does not involves writing manually .xinitrcs, can be What is a "non-human-user session"? > integrated by the packagers of software needing this in their > packages, and is cared about by the stack authors. The official way to get sound working in cases that do not involve KDE or GNOME is to start "pulseaudio -D". Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 18:39:18 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:39:18 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218151221.GA53607@dspnet.fr.eu.org> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> Message-ID: <20071218183918.GH28630@tango.0pointer.de> On Tue, 18.12.07 16:12, Olivier Galibert (galibert at pobox.com) wrote: > > On Tue, Dec 18, 2007 at 06:51:49AM -0700, Richi Plana wrote: > > The access model it is using is running the daemon as the UID of the > > user that is running the "session" (as opposed to a specific PA UID that > > authenticates and authorizes each access request). > > Hmmm, if it is "one daemon per user", can multiple deamons for > different users run simultaneously? Yes. But only one daemon instance can access the audio HW at a time. But since to awesome projects like HAL and CK PA will automatically be notified when the active VT/session is switched. And the PA daemon that becomes inactive closes the audio device and the one the becomes active opens it. Fast user switching is totally awesome hot stuff, if you ask me. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 18:33:20 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 19:33:20 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218142218.GA48638@dspnet.fr.eu.org> References: <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218142218.GA48638@dspnet.fr.eu.org> Message-ID: <20071218183320.GF28630@tango.0pointer.de> On Tue, 18.12.07 15:22, Olivier Galibert (galibert at pobox.com) wrote: > > On Tue, Dec 18, 2007 at 01:46:52PM +0100, Denis Leroy wrote: > > Patrice Dumas wrote: > > >On Tue, Dec 18, 2007 at 12:00:45PM +0100, Lennart Poettering wrote: > > >>I am not convinced that PAM is the right place to start any daemons. > > > > > >But gdm is? > > > > why not start PA from an init script ? > > Something is still unclear to be. Are the PA deamons per-system, > per-user or per-login session? As mentioned earlier, PA may be run as system daemon. However, I do not recommend that. What I recommend is running it as a session/user daemon. Generally the daemon is designed to run per-user. However, some modules currently assume to be run per-session. Since currently multiple simultaneous logins per user are not really supported by GNOME anyway, I don't see it as a problem that PA in some areas acts as a per-user and in others as a per-session daemon. Except for the console login case we can safely assume that per-session and per-user is the same thing. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From notting at redhat.com Tue Dec 18 19:13:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Dec 2007 14:13:54 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <20071218191354.GA3359@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > Let the naming begin! So, Werewolf is a: - Fictional creature - Ancient: Griffin, Sphinx, Cerberus (yeah, that's not going to stick), Scylla, Chimaera, etc. - SciFi Movie/TV: Tauntaun, Tribble, Ewok, Faun, Dalek, etc. - Cryptozoology: Bigfoot, Loch Ness Monster, etc. - Horror: Mummy, Vampire - Games: Grue, Flood - Game Shows: Whammy Personally, I like 'Sphinx' or 'Grue'. - A baseball team (the London Werewolves, natch) - Paints, Otters, Wild Things, Biscuits, etc. - Something found at Trader Vic's - Mai Tai, Tiki - Things found in London in song titles - Bells, Foggy Days, Bridge, Streets Bill From jspaleta at gmail.com Tue Dec 18 18:39:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Dec 2007 09:39:01 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <1197955212.3290.77.camel@jndwidescreen.lesbg.loc> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <1197955212.3290.77.camel@jndwidescreen.lesbg.loc> Message-ID: <604aa7910712181039l102b184dxbe4f4fda6136b730@mail.gmail.com> On Dec 17, 2007 8:20 PM, Jonathan Dieter wrote: > FWIW, I run a headless home music server named musicbox that uses PA and > runs mpd. When my wife or I want to watch a movie, we just redirect the > sound output from our respective laptops to musicbox. Mpd has a PA > plugin, so it was quite easy to configure. Thanks, no matter what other people think.. i think it helps to have a specific implementation example to use as a baseline reference. Is mpd even in the mainline Fedora repository? Or am I blind? > > The only problem I ran into was in trying to get PA to run as a > system-wide daemon. I had to track down why it couldn't > open /dev/snd/*, and finally worked out that it was a permissions > problem, easily fixed using ConsoleKit. > > All that to say that except for the permissions problems, it just > worked. Is this fixable via some change in default policy that can be done via packaging payload or via mpd scriptlet? Or does this have to be done via local admin action? I will admit that ConsoleKit still confuses me because it runs counter to muscle memory. -jef From skvidal at fedoraproject.org Tue Dec 18 19:12:33 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 18 Dec 2007 14:12:33 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218185123.GB7847@fattire.cabal.ca> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <20071218185123.GB7847@fattire.cabal.ca> Message-ID: <1198005153.13693.14.camel@cutter> On Tue, 2007-12-18 at 13:51 -0500, Kyle McMartin wrote: > On Tue, Dec 18, 2007 at 01:21:42PM -0500, seth vidal wrote: > > Fedora 11 MUST be named "ours goes to" > > Fedora "ours goes to" 11 > > > > So we have to get from here to there. :) > > > > Werewolves of London song by Warren Zevon's amp goes to 11? Warren Zevon's Amp wrote Werewolves of London? Wow, that's a talented amp. It goes waaaaaaaaaaay past 11. -sv From walters at redhat.com Tue Dec 18 19:15:55 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 18 Dec 2007 14:15:55 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218115845.569346ac@ghistelwchlohm.scrye.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <20071218182629.GC28630@tango.0pointer.de> <20071218115845.569346ac@ghistelwchlohm.scrye.com> Message-ID: <1198005355.3085.4.camel@space-ghost.verbum.private> On Tue, 2007-12-18 at 11:58 -0700, Kevin Fenzi wrote: > Why not have a /etc/xdg/autostart/pulseaudio.desktop > to start pulseaudio for user sessions? If that works, I agree that would be a better way to do it. We should also delete the esd launching (and associated "preference") from GNOME. Historically that was around as a "I want my system broken in a different way" knob to let apps that didn't route through ESD get access to the sound card (but break mixing). Pulse releases the sound device if it's not being used, so it is safe to always start, as far as I can tell. From notting at redhat.com Tue Dec 18 19:23:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Dec 2007 14:23:22 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218191354.GA3359@nostromo.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> Message-ID: <20071218192322.GB3359@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Josh Boyer (jwboyer at gmail.com) said: > > Let the naming begin! > > So, Werewolf is a: > > - Fictional creature > - Ancient: Griffin, Sphinx, Cerberus (yeah, that's not going to stick), Scylla, > Chimaera, etc. > - SciFi Movie/TV: Tauntaun, Tribble, Ewok, Faun, Dalek, etc. > - Cryptozoology: Bigfoot, Loch Ness Monster, etc. > - Horror: Mummy, Vampire > - Games: Grue, Flood > - Game Shows: Whammy > > Personally, I like 'Sphinx' or 'Grue'. > > - A baseball team (the London Werewolves, natch) > - Paints, Otters, Wild Things, Biscuits, etc. > > - Something found at Trader Vic's > - Mai Tai, Tiki > > - Things found in London in song titles > - Bells, Foggy Days, Bridge, Streets Also: - Characters played by Lon Chaney, Jr. - Chingachgook, Dracula, Mummy, Sinbad, Pedro Martines (heh) - A syndrome - Stockholm, Asperger, Usher, Marfan, Tourette Bill From fedora at leemhuis.info Tue Dec 18 19:41:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 18 Dec 2007 20:41:17 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <80d7e4090712181052v538ca14fq7e33709d559f97a1@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <80d7e4090712181052v538ca14fq7e33709d559f97a1@mail.gmail.com> Message-ID: <4768225D.4080004@leemhuis.info> On 18.12.2007 19:52, Stephen John Smoogen wrote: > On Dec 18, 2007 11:21 AM, seth vidal wrote: >> On Tue, 2007-12-18 at 13:08 -0500, Michael DeHaan wrote: >>> Mark Bidewell wrote: >>>> Absolutely awesome great idea! >>>> > Anubis [1]: >>>> +1; it opens up the Stargate references for the next batch. >>> Undomesticated equines can not remove me from voting for this one. >>> +1 million just for the pending Stargate release naming opportunity. >> Fedora 11 MUST be named "ours goes to" >> Fedora "ours goes to" 11 >> Optionally it could be named: Lumbar Puncture. > Transylvania > Legendary home of dracula/werewolves/etc > Transylvania 6-5000 has Ed Begley Jr. in it who was John 'Stumpy' > Pepys in Lumbar Puncture. ?berwald http://en.wikipedia.org/wiki/%C3%9Cberwald [...]Although ?berwald has a large human population, they play a secondary role in the region's history. It is ruled by dwarfs, vampires, and werewolves http://wiki.lspace.org/wiki/%C3%9Cberwald Cu knurd From jspaleta at gmail.com Tue Dec 18 19:45:53 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Dec 2007 10:45:53 -0900 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <5042.63.85.68.164.1197985034.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <5042.63.85.68.164.1197985034.squirrel@mail.jcomserv.net> Message-ID: <604aa7910712181145j699d195ct90b58030aa506524@mail.gmail.com> On Dec 18, 2007 4:37 AM, Jon Ciesla wrote: > Ooh, then F10 could be Narwhal, link = one-horn. One very friendly horn http://www.threadless.com/product/979/The_Friendly_Narwhal#zoom - Martin Sourada from a previous thread in the Art list in Nov suggested Ouroboros as a codename, to quote the original post: Uroboros (though the word itself does not sound to me much nice) has some good connection to Fedora itself, as it symbolises infinity and unity, in words from wikipedia[1]: "It has been used to represent many things over the ages, but it most generally symbolizes ideas of cyclicality, unity, or infinity." References: [1] http://en.wikipedia.org/wiki/Ouroboros - Also from the Art list discussions, there is a desire to thematically emphasize "Freedom is a Feature." There was some discussion to bring the codename inline with that theme. Can we get to a codename using the establish naming rules which alludes/implies/symbolizes Freedom? -jef From nicolas.mailhot at laposte.net Tue Dec 18 19:58:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 20:58:30 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <4768181E.9000503@poolshark.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> Message-ID: <1198007910.11811.10.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 19:57 +0100, Denis Leroy a ?crit : > Lennart Poettering wrote: > > On Tue, 18.12.07 13:46, Denis Leroy (denis at poolshark.org) wrote: > > > >>>>>> It's not that PA doesn't work at all on those special no-X-involved > >>>>>> setups. The only limitation is that you need to run PA manually in > >>>>>> such setups. -- No big deal! > >>>>> Is there something like a session pam module planned to start PA to > >>>>> achieve independence from the the login entry point? > >>>> I am not convinced that PAM is the right place to start any daemons. > >>> But gdm is? > >> why not start PA from an init script ? > > > > Because it is a per-user/per-session daemon. Not a system daemon. > > but there's only one set of speakers per system, It's even worse even dirt-cheap systems have multiple audio outputs that can trivially be routed to different rooms just by running some audio cable (that was common way before any multi-head GFX card arrived on market). So in addition to having several users contending on the same outputs you can have several sets of input/outputs used at once by different classes of users (think you want desktop you've got mail routed to the system PVR app currently recording late show for some other user?) It's very unclear to me how this kind if setup is supposed to be handled in a PA world. -- 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 Tue Dec 18 20:04:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 21:04:41 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218183609.GG28630@tango.0pointer.de> References: <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> <20071218104250.GB1518@tango.0pointer.de> <11021.192.54.193.52.1197976984.squirrel@rousalka.dyndns.org> <20071218183609.GG28630@tango.0pointer.de> Message-ID: <1198008281.11811.16.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 19:36 +0100, Lennart Poettering a ?crit : > On Tue, 18.12.07 12:23, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > > I am not sure what you want? > > > > I want an official way to get sound working for non-human-user > > sessions that does not involves writing manually .xinitrcs, can be > > What is a "non-human-user session"? Anything which is not a human logging in to read his mail. Can be a streaming server, a background PVR app with a kiosk-like interface statically routed to a video output, an audio app sitting on the home music store directly remote-controlled, 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 silfreed at silfreed.net Tue Dec 18 20:11:49 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 18 Dec 2007 15:11:49 -0500 Subject: Build error: warning: Could not canonicalize hostname: xenbuilder4.fedora.phx.redhat.com Message-ID: <200712181511.50058.silfreed@silfreed.net> I'm trying to build a new qgis package, but am having a wierd build error; I'll include it below (the entire build log is not large) Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=299272 Build Log: http://koji.fedoraproject.org/koji/getfile?taskID=299288&name=build.log -Doug == start build.log == ENTER doChroot(, 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/qgis.spec', '', uidManager=logger=gid=421uid=421timeout=0) ENTER do('rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/qgis.spec', '/var/lib/mock/dist-f9-build-95445-12142/root/', 0, True, 0, , 421, 421, 'x86_64', logger=) run cmd timeout(0): rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/qgis.spec warning: Could not canonicalize hostname: xenbuilder4.fedora.phx.redhat.com Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/qgis-0.9.1-1.fc9.src.rpm LEAVE do --> LEAVE doChroot --> == stop build.log == -------------- 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 Dec 18 20:12:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 15:12:10 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198007910.11811.10.camel@rousalka.dyndns.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> Message-ID: <20071218151210.2542f875@redhat.com> On Tue, 18 Dec 2007 20:58:30 +0100 Nicolas Mailhot wrote: > It's very unclear to me how this kind if setup is supposed to be > handled in a PA world. How is it supposed to be handled in a non PA world? -- 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 lowen at pari.edu Tue Dec 18 20:13:41 2007 From: lowen at pari.edu (Lamar Owen) Date: Tue, 18 Dec 2007 15:13:41 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <80d7e4090712181052v538ca14fq7e33709d559f97a1@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <200712181513.41160.lowen@pari.edu> On Tuesday 18 December 2007, Stephen John Smoogen wrote: > Transylvania > Legendary home of dracula/werewolves/etc > Transylvania 6-5000 has Ed Begley Jr. in it who was John 'Stumpy' > Pepys in Lumbar Puncture. Given where I am located, I would have to like that one. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From nicolas.mailhot at laposte.net Tue Dec 18 20:15:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 21:15:43 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218183918.GH28630@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> Message-ID: <1198008943.11811.25.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 19:39 +0100, Lennart Poettering a ?crit : > But only one daemon instance can access the audio HW at a time. But > since to awesome projects like HAL and CK PA will automatically be > notified when the active VT/session is switched. And the PA daemon > that becomes inactive closes the audio device and the one the becomes > active opens it. Then I guess any form of time shifting and delayed audio/video recording is out? Have we progressed so much recording anything including audio now involves post-its forbidding anyone from logging at the wrong hour to avoid stealing audio from recording apps? -- 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 lowen at pari.edu Tue Dec 18 20:15:48 2007 From: lowen at pari.edu (Lamar Owen) Date: Tue, 18 Dec 2007 15:15:48 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <200712181515.48651.lowen@pari.edu> On Tuesday 18 December 2007, seth vidal wrote: > Okay, but I want everyone to know about an important strategic decision > we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > Optionally it could be named: Lumbar Puncture. Ten needs to be 'Marshall' then, right? Ok, Werewolf was played by Chaney; call 9 'Chaney' Marshall (as in Penny) is an actress; Chaney is an actor. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From silfreed at silfreed.net Tue Dec 18 20:23:08 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 18 Dec 2007 15:23:08 -0500 Subject: Build error: /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character Message-ID: <200712181523.08926.silfreed@silfreed.net> Here's another one for syslog-ng. Strangely, both this one and for qgis are on the x86_64 arch. Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=299278 Build Log: http://koji.fedoraproject.org/koji/getfile?taskID=299314&name=build.log Any ideas on what might be going on with this one? -Doug -------------- 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 Tue Dec 18 20:38:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 21:38:15 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218151210.2542f875@redhat.com> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> Message-ID: <1198010295.11811.27.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 15:12 -0500, Jesse Keating a ?crit : > On Tue, 18 Dec 2007 20:58:30 +0100 > Nicolas Mailhot wrote: > > > It's very unclear to me how this kind if setup is supposed to be > > handled in a PA world. > > How is it supposed to be handled in a non PA world? You assign specific alsa devices to specific apps -- 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 smooge at gmail.com Tue Dec 18 20:38:58 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 18 Dec 2007 13:38:58 -0700 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181513.41160.lowen@pari.edu> References: <80d7e4090712181052v538ca14fq7e33709d559f97a1@mail.gmail.com> <200712181513.41160.lowen@pari.edu> Message-ID: <80d7e4090712181238y54a24adat6b98532d2895ae6f@mail.gmail.com> On Dec 18, 2007 1:13 PM, Lamar Owen wrote: > On Tuesday 18 December 2007, Stephen John Smoogen wrote: > > > Transylvania > > Legendary home of dracula/werewolves/etc > > Transylvania 6-5000 has Ed Begley Jr. in it who was John 'Stumpy' > > Pepys in Lumbar Puncture. > > Given where I am located, I would have to like that one. > Werewolf -> Transylvania -> Begley -> THis is Spinal Tap -> Win. -- 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 mzerqung at 0pointer.de Tue Dec 18 20:41:41 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 21:41:41 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <4768181E.9000503@poolshark.org> References: <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> Message-ID: <20071218204141.GA3360@tango.0pointer.de> On Tue, 18.12.07 19:57, Denis Leroy (denis at poolshark.org) wrote: >>>>>> Is there something like a session pam module planned to start PA to >>>>>> achieve independence from the the login entry point? >>>>> I am not convinced that PAM is the right place to start any daemons. >>>> But gdm is? >>> why not start PA from an init script ? >> Because it is a per-user/per-session daemon. Not a system daemon. > > but there's only one set of speakers per system, so I don't understand the > logic here. Multiple instances of PA can coexist ? Does PA handle user > switching correctly for example ? What if i want somebody to connect > through ssh on my system and run an mp3 for me, can i allow them to do so ? I already explained that on this thread. But here we go again: A single instance of the daemon may access the audio hw at a time. Using HAL and CK we make sure the active session gets access and all others don't. You can always choose to disable authentication for your sound server, or hand other people the auth cookie you're using (~/.pulse-cookie). Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nicolas.mailhot at laposte.net Tue Dec 18 20:51:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 21:51:32 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198010295.11811.27.camel@rousalka.dyndns.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> Message-ID: <1198011092.12620.10.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 21:38 +0100, Nicolas Mailhot a ?crit : > Le mardi 18 d?cembre 2007 ? 15:12 -0500, Jesse Keating a ?crit : > > On Tue, 18 Dec 2007 20:58:30 +0100 > > Nicolas Mailhot wrote: > > > > > It's very unclear to me how this kind if setup is supposed to be > > > handled in a PA world. > > > > How is it supposed to be handled in a non PA world? > > You assign specific alsa devices to specific apps And the apps arbiter resource access just like cups arbiters simultaneous access to a localy attached printer from local, remote and background users. Because audio cabling is static and audio devices are at the same stage today as non-networked printers were two decade ago. There are systems connected to audio devices by virtue of being near the audio devices, and there is no 1:1 relashionship between the user sitting on the local system in the current dekstop session and the user making use of audio devices. It's perfectly legitimate to have a desktop system sitting in the living room that simultaneously plays a DVD for one user on the TV/projector output, records analog video for another through PVR card, while a third is connected in dekstop session and checks his mails or does some quick browsing. -- 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 mzerqung at 0pointer.de Tue Dec 18 20:55:55 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 21:55:55 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218115845.569346ac@ghistelwchlohm.scrye.com> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <20071218182629.GC28630@tango.0pointer.de> <20071218115845.569346ac@ghistelwchlohm.scrye.com> Message-ID: <20071218205554.GB3360@tango.0pointer.de> On Tue, 18.12.07 11:58, Kevin Fenzi (kevin at scrye.com) wrote: > > There are many reasons why I chose to make PA a session daemon: > ...snipp... > > This brings me to the following question: > > Why not have a /etc/xdg/autostart/pulseaudio.desktop > to start pulseaudio for user sessions? Actually, if you look closely you'll see that we do ship an XDG autostart file. However, not really because of the reasons you are suggesting here and it's a different story. Basically, the problem is that XDG autostart doesn't define any order in which those files are executed. However, PA needs to be started before any login sound is played, or any event sound is cached in the server. KDE extended the XDG spec a bit, and thus on KDE PA is started that way. However, on GNOME gnome-session starts PA sychronously and waits for it and then uploads event samples to it. And thus we cannot really move the point where we start PA out of there. What I am planning to do is make PA a normal XSM client like any other app, and rip out the esd-specific code in gsm. But that's not done yet. So for now the PA as esd-dropin works great and is good enough. It's not a top priority on my list to change this. But it's right next to the top of my list. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jkeating at redhat.com Tue Dec 18 20:55:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 15:55:50 -0500 Subject: Build error: warning: Could not canonicalize hostname: xenbuilder4.fedora.phx.redhat.com In-Reply-To: <200712181511.50058.silfreed@silfreed.net> References: <200712181511.50058.silfreed@silfreed.net> Message-ID: <20071218155550.27291202@redhat.com> On Tue, 18 Dec 2007 15:11:49 -0500 "Douglas E. Warner" wrote: > I'm trying to build a new qgis package, but am having a wierd build > error; I'll include it below (the entire build log is not large) > > Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=299272 > Build Log: > http://koji.fedoraproject.org/koji/getfile?taskID=299288&name=build.log The error is in the root.log, not the build.log in this case: DEBUG util.py:260: Error: Missing Dependency: libcrypto.so.6()(64bit) is needed by package grass DEBUG util.py:260: Error: Missing Dependency: libssl.so.6()(64bit) is needed by package grass DEBUG util.py:260: Error: Missing Dependency: libssl.so.6()(64bit) is needed by package gdal DEBUG util.py:260: Error: Missing Dependency: libcrypto.so.6()(64bit) is needed by package gdal gdal needs a rebuild, but is blocked by grass. -- 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 Tue Dec 18 20:57:48 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 21:57:48 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <476818BE.2080308@gmail.com> References: <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> Message-ID: <20071218205748.GC3360@tango.0pointer.de> On Tue, 18.12.07 13:00, Les Mikesell (lesmikesell at gmail.com) wrote: >>>>> I am not convinced that PAM is the right place to start any daemons. >>>> But gdm is? >>> why not start PA from an init script ? >> Because it is a per-user/per-session daemon. Not a system daemon. > > What is supposed to happen when you have multiple users/sessions on one > box, as the rest of the system is designed to support? I explained that already twice: with the help of HAL/CK we are notified whenever the active session changes and thus can give up access to the audio hw and open it again when needed. That works fine, and is part of F8. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 21:00:24 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 22:00:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198008281.11811.16.camel@rousalka.dyndns.org> References: <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <1197962569.5515.12.camel@rousalka.dyndns.org> <20071218104250.GB1518@tango.0pointer.de> <11021.192.54.193.52.1197976984.squirrel@rousalka.dyndns.org> <20071218183609.GG28630@tango.0pointer.de> <1198008281.11811.16.camel@rousalka.dyndns.org> Message-ID: <20071218210024.GD3360@tango.0pointer.de> On Tue, 18.12.07 21:04, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > Le mardi 18 d?cembre 2007 ? 19:36 +0100, Lennart Poettering a ?crit : > > On Tue, 18.12.07 12:23, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > > > > I am not sure what you want? > > > > > > I want an official way to get sound working for non-human-user > > > sessions that does not involves writing manually .xinitrcs, can be > > > > What is a "non-human-user session"? > > Anything which is not a human logging in to read his mail. Can be a > streaming server, a background PVR app with a kiosk-like interface > statically routed to a video output, an audio app sitting on the home > music store directly remote-controlled, etc If you call this a "session", then you can just run "pulseaudio -D" from that session too. Or you can just bypass PA and directly access the HW, since there's not much point in using PA if you don't have an UI for it anyway. Just use "hw:0" as ALSA audio device instead of "default" or "pulse". Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Dec 18 21:02:38 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 22:02:38 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198008943.11811.25.camel@rousalka.dyndns.org> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> <1198008943.11811.25.camel@rousalka.dyndns.org> Message-ID: <20071218210238.GE3360@tango.0pointer.de> On Tue, 18.12.07 21:15, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > But only one daemon instance can access the audio HW at a time. But > > since to awesome projects like HAL and CK PA will automatically be > > notified when the active VT/session is switched. And the PA daemon > > that becomes inactive closes the audio device and the one the becomes > > active opens it. > > Then I guess any form of time shifting and delayed audio/video recording > is out? Have we progressed so much recording anything including audio > now involves post-its forbidding anyone from logging at the wrong hour > to avoid stealing audio from recording apps? I really don't see what "time shifting" has to do with PA? Didn't you know? PA eats children for breakfast. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jspaleta at gmail.com Tue Dec 18 21:03:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Dec 2007 12:03:19 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218205748.GC3360@tango.0pointer.de> References: <20071217235706.GG3559@tango.0pointer.de> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> Message-ID: <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> On Dec 18, 2007 11:57 AM, Lennart Poettering wrote: > I explained that already twice: with the help of HAL/CK we are > notified whenever the active session changes and thus can give up > access to the audio hw and open it again when needed. That works fine, > and is part of F8. I think one of the problems here is CK runs against a body of shared administration experience in the community. There isn't a shared understanding of how to use CK effectively to get common hardware related admin crap done, so as a result any explanation on how to do something semi-involved as an administrator which boils down to "it uses CK to do it" just doesn't connect. -jef From Michael_E_Brown at dell.com Tue Dec 18 21:08:13 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 18 Dec 2007 15:08:13 -0600 Subject: Build error: /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character In-Reply-To: <200712181523.08926.silfreed@silfreed.net> References: <200712181523.08926.silfreed@silfreed.net> Message-ID: <20071218210813.GA26557@humbolt.us.dell.com> On Tue, Dec 18, 2007 at 03:23:08PM -0500, Douglas E. Warner wrote: > Here's another one for syslog-ng. > > Strangely, both this one and for qgis are on the x86_64 arch. > > Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=299278 > Build Log: > http://koji.fedoraproject.org/koji/getfile?taskID=299314&name=build.log > > Any ideas on what might be going on with this one? Maybe this? https://bugzilla.redhat.com/show_bug.cgi?id=304121 Usually caused by "//" in one of the paths. -- Michael From mzerqung at 0pointer.de Tue Dec 18 21:13:12 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Dec 2007 22:13:12 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198010295.11811.27.camel@rousalka.dyndns.org> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> Message-ID: <20071218211312.GG3360@tango.0pointer.de> On Tue, 18.12.07 21:38, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > It's very unclear to me how this kind if setup is supposed to be > > > handled in a PA world. > > > > How is it supposed to be handled in a non PA world? > > You assign specific alsa devices to specific apps You're welcome to do that even if login sessions use PA. PA releases the audio devices when idle. And thus your kind of setup works as good or as bad as it did before. Just use "front:0" or "front:1" as ALSA audio device, instead of "default" or "pulse". Oh, and since you seem to hate PA really that much: just disable it! Just remove alsa-plugins-pulseaudio and you have it back, your naked ALSA. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rvinyard at cs.nmsu.edu Tue Dec 18 21:18:37 2007 From: rvinyard at cs.nmsu.edu (rvinyard at cs.nmsu.edu) Date: Tue, 18 Dec 2007 14:18:37 -0700 (MST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218191354.GA3359@nostromo.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> Message-ID: <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> > Josh Boyer (jwboyer at gmail.com) said: >> Let the naming begin! > > So, Werewolf is a: > > - Fictional creature > - Ancient: Griffin, Sphinx, Cerberus (yeah, that's not going to stick), > Scylla, > Chimaera, etc. > - SciFi Movie/TV: Tauntaun, Tribble, Ewok, Faun, Dalek, etc. > - Cryptozoology: Bigfoot, Loch Ness Monster, etc. Chupacabra > - Horror: Mummy, Vampire > - Games: Grue, Flood > - Game Shows: Whammy > > Personally, I like 'Sphinx' or 'Grue'. > > - A baseball team (the London Werewolves, natch) > - Paints, Otters, Wild Things, Biscuits, etc. > > - Something found at Trader Vic's > - Mai Tai, Tiki > > - Things found in London in song titles > - Bells, Foggy Days, Bridge, Streets > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicolas.mailhot at laposte.net Tue Dec 18 21:20:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 22:20:27 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218210238.GE3360@tango.0pointer.de> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> <1198008943.11811.25.camel@rousalka.dyndns.org> <20071218210238.GE3360@tango.0pointer.de> Message-ID: <1198012827.12620.19.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 22:02 +0100, Lennart Poettering a ?crit : > On Tue, 18.12.07 21:15, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > > But only one daemon instance can access the audio HW at a time. But > > > since to awesome projects like HAL and CK PA will automatically be > > > notified when the active VT/session is switched. And the PA daemon > > > that becomes inactive closes the audio device and the one the becomes > > > active opens it. > > > > Then I guess any form of time shifting and delayed audio/video recording > > is out? Have we progressed so much recording anything including audio > > now involves post-its forbidding anyone from logging at the wrong hour > > to avoid stealing audio from recording apps? > > I really don't see what "time shifting" has to do with PA? You have background processes eating analog audio and video and producing recordings for some users. While another one may be logged in GNOME or KDE doing something else. In the bright new world you described as soon as the human logs in device access is stolen from everything/one else. Of course I may have misunderstood the explanation but it seemed to be there is one exclusive user of audio devices at any time, the active desktop session (whatever that is going to be, since people are working to make multi-head X a reality) -- 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 Michael_E_Brown at dell.com Tue Dec 18 21:21:11 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 18 Dec 2007 15:21:11 -0600 Subject: Build error: /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character In-Reply-To: <20071218210813.GA26557@humbolt.us.dell.com> References: <200712181523.08926.silfreed@silfreed.net> <20071218210813.GA26557@humbolt.us.dell.com> Message-ID: <20071218212111.GB26557@humbolt.us.dell.com> On Tue, Dec 18, 2007 at 03:08:13PM -0600, Michael E Brown wrote: > On Tue, Dec 18, 2007 at 03:23:08PM -0500, Douglas E. Warner wrote: > > Here's another one for syslog-ng. > > > > Strangely, both this one and for qgis are on the x86_64 arch. > > > > Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=299278 > > Build Log: > > http://koji.fedoraproject.org/koji/getfile?taskID=299314&name=build.log > > > > Any ideas on what might be going on with this one? > > Maybe this? > > https://bugzilla.redhat.com/show_bug.cgi?id=304121 > > Usually caused by "//" in one of the paths. Maybe this, from your posted log, note the //: cfg.c: In function 'persist_config_save': cfg.c:549: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result cfg-lex.c: In function 'yylex': /home/bazsi/zwa/git//syslog-ng/syslog-ng--mainline--2.0/src/cfg-lex.l:247: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/eventlog -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -MT logmsg.o -MD -MP -MF ".deps/logmsg.Tpo" \ -c -o logmsg.o `test -f 'logmsg.c' || echo './'`logmsg.c; \ then mv -f ".deps/logmsg.Tpo" ".deps/logmsg.Po"; \ else rm -f ".deps/logmsg.Tpo"; exit 1; \ fi -- Michael From jkeating at redhat.com Tue Dec 18 21:21:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 16:21:09 -0500 Subject: Rolling Koji builder outage Message-ID: <20071218162109.055439c8@redhat.com> Over the next few hours we're going to have a rolling outage of the Koji builders. This is necessary to install a new kernel on them to resolve some build issues discovered after the refresh. First we will disable the host to be rebooted and allow it to complete any active jobs without taking on new ones. Then the host will be rebooted to the new kernel and re-enabled for taking new jobs. Users should expect some delay in build tasks, but no loss of jobs. -- 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 nicolas.mailhot at laposte.net Tue Dec 18 21:40:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Dec 2007 22:40:26 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218211312.GG3360@tango.0pointer.de> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> Message-ID: <1198014026.12620.35.camel@rousalka.dyndns.org> Le mardi 18 d?cembre 2007 ? 22:13 +0100, Lennart Poettering a ?crit : > Oh, and since you seem to hate PA really that much: I don't hate PA anymore than you hate users that do not fit in your assumptions > just disable it! Ok, if that's the official answer I'll ask application authors to un-pulsify their apps so sound still works for the Fedora users you don't want to care about. I had accepted it would not work short term but if even asking how some use-cases are supposed to work mid-term is too much, there's little hope left. -- 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 ssorce at redhat.com Tue Dec 18 21:41:25 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 16:41:25 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218211312.GG3360@tango.0pointer.de> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> Message-ID: <1198014085.19318.68.camel@localhost.localdomain> On Tue, 2007-12-18 at 22:13 +0100, Lennart Poettering wrote: > On Tue, 18.12.07 21:38, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > > > It's very unclear to me how this kind if setup is supposed to be > > > > handled in a PA world. > > > > > > How is it supposed to be handled in a non PA world? > > > > You assign specific alsa devices to specific apps > > You're welcome to do that even if login sessions use PA. PA releases > the audio devices when idle. And thus your kind of setup works as good > or as bad as it did before. Just use "front:0" or "front:1" as ALSA > audio device, instead of "default" or "pulse". > > Oh, and since you seem to hate PA really that much: just disable it! > Just remove alsa-plugins-pulseaudio and you have it back, your naked > ALSA. Lennart, just one question, can I tell PA which device to use if I have more than one? Let's say I have regular boxes and an USB audio device (headset), will PA grab them both? Just one, switch automatically from one to the other when I plug in the headset ? None of the above? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From williams at redhat.com Tue Dec 18 21:47:50 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 18 Dec 2007 15:47:50 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <80d7e4090712180932x18293cbxdaf904181bc01fe4@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <80d7e4090712180932x18293cbxdaf904181bc01fe4@mail.gmail.com> Message-ID: <47684006.9090808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen John Smoogen wrote: > Semi legal names > Pina Colada - The drink werewolves like yeah, but that's only UK Werewolves, right? How about: Trader Vics (which evidently is where Werewolves hang out in London) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHaEAFHyuj/+TTEp0RApUWAKDkl6RmKrrg3IFUxG97uiB3amn4sQCfW0OS DdZ7frbn6Hoesov1VmhdLr0= =b4w4 -----END PGP SIGNATURE----- From galibert at pobox.com Tue Dec 18 21:54:43 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 18 Dec 2007 22:54:43 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218211312.GG3360@tango.0pointer.de> References: <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> Message-ID: <20071218215443.GA97953@dspnet.fr.eu.org> On Tue, Dec 18, 2007 at 10:13:12PM +0100, Lennart Poettering wrote: > Oh, and since you seem to hate PA really that much: just disable it! > Just remove alsa-plugins-pulseaudio and you have it back, your naked > ALSA. No, we'd just like it to be usable in other contexts than laptops. We don't need another NM-like story. Especially since Fedora would like to make it mandatory (for very good reasons too). An example of real use I have at home: - Main desktop machine is connected to speakers through normal wires and to the living room ac3/dts through toslink - Both the GF & I are usually logged on that machine, her with KDE on Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in my startup wouldn't be a problem. - User switching, as it is, is just C-A-F7/C-A-F8 - Additionally, we often ssh to the machine from our laptops to start music using xmms/audacious/mplayer sending on spdif to hear it in the living room. Files are on the desktop machine, so we'd rather do X than nfs+pcm over the wifi. Can PA do that? Can PA be modified to support that? OG. From Michael_E_Brown at dell.com Tue Dec 18 21:56:56 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 18 Dec 2007 15:56:56 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198014026.12620.35.camel@rousalka.dyndns.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> Message-ID: <20071218215656.GC26557@humbolt.us.dell.com> On Tue, Dec 18, 2007 at 10:40:26PM +0100, Nicolas Mailhot wrote: > > Le mardi 18 d?cembre 2007 ? 22:13 +0100, Lennart Poettering a ?crit : > > > Oh, and since you seem to hate PA really that much: > > I don't hate PA anymore than you hate users that do not fit in your > assumptions Sounds like you two need a time-out. Neither of those comments were necessary. > Ok, if that's the official answer I'll ask application authors to > un-pulsify their apps so sound still works for the Fedora users you > don't want to care about. I had accepted it would not work short term > but if even asking how some use-cases are supposed to work mid-term is > too much, there's little hope left. Oh dear. Nicolas, I've been watching this thread and still dont see what you are going on and on and on about. Your use case is slightly outside of the "out-of-the-box" experience for fedora... There aren't PVR apps or any of the other things you are talking about in the box with fedora as it stands now. SOOOOO... if it is going to take you a bit of work to install these apps from third-party repositories, then you should also expect that it is going to take you a little bit of integration work to get it all going. Wiki anybody? Aside from that, Lennart has done what I would consider a good job giving you all the tools and options you would need to set up such a system, either using PA as it was intended, or by disabling it. Aside from that, It sounds like your main problem is with CK, not with pulse, that is, if your main problem is with users logging in "stealing" sound. It seems like there would be a way to configure this outside of CK such that the DVR apps PA daemon has constant access to the sound devices (group permissions?) -- Michael From Michael_E_Brown at dell.com Tue Dec 18 22:01:14 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 18 Dec 2007 16:01:14 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218215443.GA97953@dspnet.fr.eu.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> Message-ID: <20071218220114.GD26557@humbolt.us.dell.com> On Tue, Dec 18, 2007 at 10:54:43PM +0100, Olivier Galibert wrote: > On Tue, Dec 18, 2007 at 10:13:12PM +0100, Lennart Poettering wrote: > > Oh, and since you seem to hate PA really that much: just disable it! > > Just remove alsa-plugins-pulseaudio and you have it back, your naked > > ALSA. > > No, we'd just like it to be usable in other contexts than laptops. We > don't need another NM-like story. Especially since Fedora would like > to make it mandatory (for very good reasons too). > > An example of real use I have at home: > > - Main desktop machine is connected to speakers through normal wires > and to the living room ac3/dts through toslink > > - Both the GF & I are usually logged on that machine, her with KDE on > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in > my startup wouldn't be a problem. > > - User switching, as it is, is just C-A-F7/C-A-F8 > > - Additionally, we often ssh to the machine from our laptops to start > music using xmms/audacious/mplayer sending on spdif to hear it in > the living room. Files are on the desktop machine, so we'd rather > do X than nfs+pcm over the wifi. > > Can PA do that? Can PA be modified to support that? No answer from me on this one, but I would like to make a comment. This was an excellent example of a well-worded question with specific and actionable detail, rather than the lot of handwaving I've seen in several other parts of the thread. People on IRC have been asking for a way to setup a test environment to see these scenarios that everybody has been complaining about, but so far, nobody has given enough detail to actually do anything. Thank you, Olivier. -- Michael From jkeating at redhat.com Tue Dec 18 22:02:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 17:02:49 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218215443.GA97953@dspnet.fr.eu.org> References: <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> Message-ID: <20071218170249.0150ee3b@redhat.com> On Tue, 18 Dec 2007 22:54:43 +0100 Olivier Galibert wrote: > - Both the GF & I are usually logged on that machine, her with KDE on > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D > in my startup wouldn't be a problem. > > - User switching, as it is, is just C-A-F7/C-A-F8 Why aren't you using fast-user-switch 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 lesmikesell at gmail.com Tue Dec 18 22:33:08 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 18 Dec 2007 16:33:08 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> References: <20071217235706.GG3559@tango.0pointer.de> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> Message-ID: <47684AA4.5090606@gmail.com> Jeff Spaleta wrote: > On Dec 18, 2007 11:57 AM, Lennart Poettering wrote: >> I explained that already twice: with the help of HAL/CK we are >> notified whenever the active session changes and thus can give up >> access to the audio hw and open it again when needed. That works fine, >> and is part of F8. > > I think one of the problems here is CK runs against a body of shared > administration experience > in the community. There isn't a shared understanding of how to use CK > effectively to get common hardware related admin crap done, so as a > result any explanation on how to do something semi-involved as an > administrator which boils down to "it uses CK to do it" just doesn't > connect. Yes, that doesn't make any sense to me - even the concept of 'active session'. If your X display is on a nearby machine (or several) but you want local audio, is that 'active' or not in PA speak? What if you have mythtv running but not related to a logged in session and also want to log in? -- Les Mikesell lesmikesell at gmail.com From galibert at pobox.com Tue Dec 18 22:36:24 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 18 Dec 2007 23:36:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218170249.0150ee3b@redhat.com> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071218170249.0150ee3b@redhat.com> Message-ID: <20071218223624.GB97953@dspnet.fr.eu.org> On Tue, Dec 18, 2007 at 05:02:49PM -0500, Jesse Keating wrote: > On Tue, 18 Dec 2007 22:54:43 +0100 > Olivier Galibert wrote: > > > - Both the GF & I are usually logged on that machine, her with KDE on > > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D > > in my startup wouldn't be a problem. > > > > - User switching, as it is, is just C-A-F7/C-A-F8 > > Why aren't you using fast-user-switch here? kdm + kde on one side, panel-less fvwm2 on the other, and sometimes startx in single-screen instead of dualhead on some of the sessions. OG. From jkeating at redhat.com Tue Dec 18 22:36:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 17:36:05 -0500 Subject: Rolling Koji builder outage In-Reply-To: <20071218162109.055439c8@redhat.com> References: <20071218162109.055439c8@redhat.com> Message-ID: <20071218173605.4eca1fc3@redhat.com> On Tue, 18 Dec 2007 16:21:09 -0500 Jesse Keating wrote: > Over the next few hours we're going to have a rolling outage of the > Koji builders. This is necessary to install a new kernel on them to > resolve some build issues discovered after the refresh. First we will > disable the host to be rebooted and allow it to complete any active > jobs without taking on new ones. Then the host will be rebooted to > the new kernel and re-enabled for taking new jobs. > > Users should expect some delay in build tasks, but no loss of jobs. Outage is over. New kernels are on all the active builds. You should no longer see mysterious build failures due to missing files (that were actually there on the file 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: -------------- next part -------------- _______________________________________________ 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 Tue Dec 18 22:40:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 17:40:33 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218223624.GB97953@dspnet.fr.eu.org> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071218170249.0150ee3b@redhat.com> <20071218223624.GB97953@dspnet.fr.eu.org> Message-ID: <20071218174033.2bae1e0c@redhat.com> On Tue, 18 Dec 2007 23:36:24 +0100 Olivier Galibert wrote: > kdm + kde on one side, panel-less fvwm2 on the other, So? > and sometimes > startx in single-screen instead of dualhead on some of the sessions. Why though? xrandr can shut off a display if you need to. fast user switching allows you to pick what session to launch from gdm. -- 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 denis at poolshark.org Tue Dec 18 22:36:40 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 18 Dec 2007 23:36:40 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218215656.GC26557@humbolt.us.dell.com> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> Message-ID: <47684B78.4090202@poolshark.org> Michael E Brown wrote: > Your use case is slightly outside of the "out-of-the-box" experience for > fedora... There aren't PVR apps or any of the other things you are > talking about in the box with fedora as it stands now. SOOOOO... I'm bothered by that comment. Since when is Fedora a "box" ? i thought it was more of a platform to build on (ok, more like: a luxury house around which you can build yourself a nice garden :-) ). Here's my use scenario. I have a Zonbu here at home that I use as a "courtesy" system in my living room. That is, when I have visiting friends or relatives, they can use the system to check their email and such. Because the zonbu is so low-power and quiet, it's almost always on and the user logged in. Gdm is configured to autologin a guest user here. The zonbu is also connected to my stereo system, which i can hear from my office. So i will often ssh into the zonbu and play an mp3 from the wireless-mounted NFS directory. Now PA means i have to log in as the same guest user, which is not necessarily ideal because of the nfs mount permissions, but certainly workable. Now of course i can just disable PA in this case and be happy. But you were asking for a specific scenario. From jspaleta at gmail.com Tue Dec 18 22:47:23 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Dec 2007 13:47:23 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <47684B78.4090202@poolshark.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> Message-ID: <604aa7910712181447l30c88e1cvc4caaade620e11d7@mail.gmail.com> On Dec 18, 2007 1:36 PM, Denis Leroy wrote: > The zonbu is also connected to my stereo system, which i can hear from > my office. So i will often ssh into the zonbu and play an mp3 from the > wireless-mounted NFS directory. Now PA means i have to log in as the > same guest user, which is not necessarily ideal because of the nfs mount > permissions, but certainly workable. Now of course i can just disable PA > in this case and be happy. But you were asking for a specific scenario. What do you use to play the mp3 from the remote ssh session? Is this a case of device permissions not being set like you need via ConsoleKit... or is it really a problem concerning PA's operation? -jef From ml at deadbabylon.de Tue Dec 18 22:49:44 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 18 Dec 2007 23:49:44 +0100 Subject: KDE-SIG weekly report (48/2007) Message-ID: <200712182349.49371.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 51/2007 Time: 2007-12-18 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-18 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-18?action=AttachFile&do=get&target=fedora-kde-sig-2007-12-18.txt ---------------------------------------------------------------------------------- = Participants = - KevinKofler - LukasTinkl - SebastianVahl - ThanNgo ---------------------------------------------------------------------------------- = Agenda = * Trolltech's Phonon GStreamer backend * kdemultimedia3 compat package? * API documentation * Live images for KDE4 * development progress: the road to kde4 = Summary = o Trolltech's Phonon GStreamer backend: - Trolltech has committed a GStreamer backend for phonon which will likely become the upstream default for kde 4.1 - We'll have to wait until it gets usuable and use xine-lib for now o kdemultimedia3 compat package? - at least taxipilot is relying on aRts-related libraries provided by kdemultimedia 3 which has now broken dependencies - Also it's possible that some apps will fail at runtime due to trying to load some aRts modules which were in kdemultimedia3 and not finding them - If we create a kdemultimedia3 we should make sure phonon, arts and pulseaudio work together - taxipilot itself isn't ported to kde 4 yet - there was no consensus if we drop taxipilot because of it's unmaintained kde4 state, patch it to don't use arts or create a kdemultimedia3 package - If we create a kdemultimedia3 package we have to get it reviewed because it's not existing in cvs o API documentation: - API documentation for kde 4 is currently not packaged but should be included in the future as -apidocs subpackages - A suggestion by RexDieter was to package them seperately to get them noarch - But this would mean to duplicate many spec files - the current decision was to package them as a part of the current specs o Live images for KDE4: - SebastianVahl created a tracker bug for monitoring the current MUST/SHOULD solve issues for the live images: #421891 [1] - #422061 is working with selinux in permissive mode since yesterdays rawhide push [2] - in comparison to the kde3 live images the following applications were dropped: krusader, koffice-krita, twinkle and ktorrent - the current package list: CurrentPackageList [3] - One of the biggest remaining issues is the non-working installer (#424811). [4] JeremyKatz said he has a hack to workaround this o development progress: the road to kde4: - kdeadmin, kaider and extragear-plasma are in rawhide now, kde-l10n is still being reviewed (#421231). [5] - the kde4 port of bluecurve is also awaiting review (#425872) [6] - /usr/share/doc/HTML/en/common was splitted into a kdelibs-common subpackage (# 417251) [7] o recent bugs: - flash plugin seems to be still not working on x86_64 (#410651) [8] - but this seems to be an issue of nspluginwrapper and a separate bug report against nspluginwrapper is needed ---------------------------------------------------------------------------------- = Next Meeting = Next tuesday is christmas holidays and the following tuesday is New Year. We should find at least one date in this two weeks for a meeting. A proposal would be 2007-12-03 at 1600 UTC: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel ---------------------------------------------------------------------------------- = Links = [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=421891 [2] https://bugzilla.redhat.com/showdependencytree.cgi?id=422061 [3] http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList [4] https://bugzilla.redhat.com/showdependencytree.cgi?id=424811 [5] https://bugzilla.redhat.com/showdependencytree.cgi?id=421231 [6] https://bugzilla.redhat.com/showdependencytree.cgi?id=425872 [7] https://bugzilla.redhat.com/showdependencytree.cgi?id=4217251 [8] https://bugzilla.redhat.com/showdependencytree.cgi?id=410651 -------------- 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 ml at deadbabylon.de Tue Dec 18 22:53:11 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 18 Dec 2007 23:53:11 +0100 Subject: KDE-SIG weekly report (51/2007) In-Reply-To: <200712182349.49371.ml@deadbabylon.de> References: <200712182349.49371.ml@deadbabylon.de> Message-ID: <200712182353.11448.ml@deadbabylon.de> I love copy&paste: the correct week would be 51/2007 Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From Michael_E_Brown at dell.com Tue Dec 18 23:00:29 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 18 Dec 2007 17:00:29 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <47684B78.4090202@poolshark.org> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> Message-ID: <20071218230029.GE26557@humbolt.us.dell.com> On Tue, Dec 18, 2007 at 11:36:40PM +0100, Denis Leroy wrote: > Michael E Brown wrote: > > >Your use case is slightly outside of the "out-of-the-box" experience for > >fedora... There aren't PVR apps or any of the other things you are > >talking about in the box with fedora as it stands now. SOOOOO... > > I'm bothered by that comment. Since when is Fedora a "box" ? i thought > it was more of a platform to build on (ok, more like: a luxury house > around which you can build yourself a nice garden :-) ). > > Here's my use scenario. I have a Zonbu here at home that I use as a > "courtesy" system in my living room. That is, when I have visiting > friends or relatives, they can use the system to check their email and > such. Because the zonbu is so low-power and quiet, it's almost always on > and the user logged in. Gdm is configured to autologin a guest user here. > > The zonbu is also connected to my stereo system, which i can hear from > my office. So i will often ssh into the zonbu and play an mp3 from the > wireless-mounted NFS directory. Now PA means i have to log in as the > same guest user, which is not necessarily ideal because of the nfs mount > permissions, but certainly workable. Now of course i can just disable PA > in this case and be happy. But you were asking for a specific scenario. Well, to me this certainly is a lot better way to frame the question, as I can clearly understand your problem. I can see several potential answers for you, based on the rest of this thread: 1) copy the zonbu's ~guest/.pulse-cookie file to your home dir. (from Lennart's previous email, I havent tested this.) This looks to me like the best option. 2) ask your music player to directly use the alsa hw:0 device, and probably twiddle permissions on the /dev/snd/ files. 3) other... somebody else probably has something I havent thought of. -- Michael From walters at redhat.com Tue Dec 18 23:00:41 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 18 Dec 2007 18:00:41 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <47684B78.4090202@poolshark.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> Message-ID: <1198018841.3085.9.camel@space-ghost.verbum.private> On Tue, 2007-12-18 at 23:36 +0100, Denis Leroy wrote: > Now PA means i have to log in as the > same guest user, Not necessarily - if the guest user isn't playing sound, then guest's pulseaudiod should have released the device, so you can open the device in your ssh session. From mattdm at mattdm.org Tue Dec 18 23:08:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 18 Dec 2007 18:08:34 -0500 Subject: user switching [was Re: how is pulseaudio supposed to work?] In-Reply-To: <20071218215443.GA97953@dspnet.fr.eu.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> Message-ID: <20071218230834.GA20140@jadzia.bu.edu> On Tue, Dec 18, 2007 at 10:54:43PM +0100, Olivier Galibert wrote: > - Both the GF & I are usually logged on that machine, her with KDE on > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in > my startup wouldn't be a problem. > - User switching, as it is, is just C-A-F7/C-A-F8 I'm glad to hear of someone else doing this. Is gdm in rawhide all broken for you too? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From denis at poolshark.org Tue Dec 18 23:05:07 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Dec 2007 00:05:07 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712181447l30c88e1cvc4caaade620e11d7@mail.gmail.com> References: <20071218110045.GD1518@tango.0pointer.de> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> <604aa7910712181447l30c88e1cvc4caaade620e11d7@mail.gmail.com> Message-ID: <47685223.4080705@poolshark.org> Jeff Spaleta wrote: > On Dec 18, 2007 1:36 PM, Denis Leroy wrote: >> The zonbu is also connected to my stereo system, which i can hear from >> my office. So i will often ssh into the zonbu and play an mp3 from the >> wireless-mounted NFS directory. Now PA means i have to log in as the >> same guest user, which is not necessarily ideal because of the nfs mount >> permissions, but certainly workable. Now of course i can just disable PA >> in this case and be happy. But you were asking for a specific scenario. > > What do you use to play the mp3 from the remote ssh session? Is this > a case of device permissions not being set like you need via > ConsoleKit... or is it > really a problem concerning PA's operation? good point, it seems to be a permission with /dev/dsp indeed. Colin is right, if PA's user is not actually playing any sound, then it works if I chmod /dev/dsp the right way. From denis at poolshark.org Tue Dec 18 23:07:13 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Dec 2007 00:07:13 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218230029.GE26557@humbolt.us.dell.com> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> <20071218230029.GE26557@humbolt.us.dell.com> Message-ID: <476852A1.50100@poolshark.org> Michael E Brown wrote: > 1) copy the zonbu's ~guest/.pulse-cookie file to your home dir. (from > Lennart's previous email, I havent tested this.) This looks to me like > the best option. The file isn't readable to other of course, but even then, this doesn't seem to work. > > 2) ask your music player to directly use the alsa hw:0 device, and > probably twiddle permissions on the /dev/snd/ files. That indeed works. From mzerqung at 0pointer.de Tue Dec 18 23:14:11 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 00:14:11 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198007910.11811.10.camel@rousalka.dyndns.org> References: <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> Message-ID: <20071218231411.GH3360@tango.0pointer.de> On Tue, 18.12.07 20:58, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > Because it is a per-user/per-session daemon. Not a system daemon. > > > > but there's only one set of speakers per system, > > It's even worse even dirt-cheap systems have multiple audio outputs that > can trivially be routed to different rooms just by running some audio > cable (that was common way before any multi-head GFX card arrived on > market). > > So in addition to having several users contending on the same outputs > you can have several sets of input/outputs used at once by different > classes of users (think you want desktop you've got mail routed to the > system PVR app currently recording late show for some other user?) > > It's very unclear to me how this kind if setup is supposed to be handled > in a PA world. It's not so much a PA world, but more a CK world. The basic idea is that CK knows which speakers belong to which seat, and PA will honour that. Or actually, as soon as we get revoke() in the kernel CK will enforce that, by forcibly kicking processes from their devices if they don't comply. However, multi-seat support is not really available in CK yet. davidz and William Jon McCann can tell you more about this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From galibert at pobox.com Tue Dec 18 23:14:14 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 19 Dec 2007 00:14:14 +0100 Subject: user switching [was Re: how is pulseaudio supposed to work?] In-Reply-To: <20071218230834.GA20140@jadzia.bu.edu> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071218230834.GA20140@jadzia.bu.edu> Message-ID: <20071218231414.GA10026@dspnet.fr.eu.org> On Tue, Dec 18, 2007 at 06:08:34PM -0500, Matthew Miller wrote: > On Tue, Dec 18, 2007 at 10:54:43PM +0100, Olivier Galibert wrote: > > - Both the GF & I are usually logged on that machine, her with KDE on > > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in > > my startup wouldn't be a problem. > > - User switching, as it is, is just C-A-F7/C-A-F8 > > I'm glad to hear of someone else doing this. Is gdm in rawhide all broken > for you too? No idea. I'm not actually using fedora on that box, and we've been doing that for more than 3 years. OG. From jspaleta at gmail.com Tue Dec 18 23:16:39 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Dec 2007 14:16:39 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <47685223.4080705@poolshark.org> References: <20071218110045.GD1518@tango.0pointer.de> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> <604aa7910712181447l30c88e1cvc4caaade620e11d7@mail.gmail.com> <47685223.4080705@poolshark.org> Message-ID: <604aa7910712181516m68f0ebbbj3b46d6045bd5c6c5@mail.gmail.com> On Dec 18, 2007 2:05 PM, Denis Leroy wrote: > good point, it seems to be a permission with /dev/dsp indeed. Colin is > right, if PA's user is not actually playing any sound, then it works if > I chmod /dev/dsp the right way. does PA's user steal the device back if your mp3 playing is active? I think one of the missing pieces here is some grassroot training materials concerning how to handle this sort of re-permissioning for remote shell logins through ConsoleKit authorization granting. To me ConsoleKit seems to be the piece of the puzzle we all need to understand a little more. Session Daemons are learning how to programmatically work with CK through hal, but we are gonna need to learn how to deal with CK for remote shell and cmdline activity. -jef From ml at deadbabylon.de Tue Dec 18 23:22:08 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 19 Dec 2007 00:22:08 +0100 Subject: KDE-SIG weekly report (48/2007) In-Reply-To: <200712182349.49371.ml@deadbabylon.de> References: <200712182349.49371.ml@deadbabylon.de> Message-ID: <200712190022.08231.ml@deadbabylon.de> Am Di 18.Dezember 2007 schrieb Sebastian Vahl: > = Next Meeting = > > Next tuesday is christmas holidays and the following tuesday is New Year. > We should find at least one date in this two weeks for a meeting. A > proposal would be 2007-12-03 at 1600 UTC: > http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel Of course this should be 2008-01-03 :) Sebastian -------------- 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 silfreed at silfreed.net Wed Dec 19 00:15:37 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 18 Dec 2007 19:15:37 -0500 Subject: Build error: /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character In-Reply-To: <20071218210813.GA26557@humbolt.us.dell.com> References: <200712181523.08926.silfreed@silfreed.net> <20071218210813.GA26557@humbolt.us.dell.com> Message-ID: <200712181915.37337.silfreed@silfreed.net> On Tuesday 18 December 2007, Michael E Brown wrote: > Maybe this? > > https://bugzilla.redhat.com/show_bug.cgi?id=304121 > > Usually caused by "//" in one of the paths. Thanks for that. -Doug -------------- 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 Dec 19 00:23:49 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 19:23:49 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218231411.GH3360@tango.0pointer.de> References: <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> Message-ID: <1198023829.19318.80.camel@localhost.localdomain> On Wed, 2007-12-19 at 00:14 +0100, Lennart Poettering wrote: > On Tue, 18.12.07 20:58, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > > > Because it is a per-user/per-session daemon. Not a system daemon. > > > > > > but there's only one set of speakers per system, > > > > It's even worse even dirt-cheap systems have multiple audio outputs that > > can trivially be routed to different rooms just by running some audio > > cable (that was common way before any multi-head GFX card arrived on > > market). > > > > So in addition to having several users contending on the same outputs > > you can have several sets of input/outputs used at once by different > > classes of users (think you want desktop you've got mail routed to the > > system PVR app currently recording late show for some other user?) > > > > It's very unclear to me how this kind if setup is supposed to be handled > > in a PA world. > > It's not so much a PA world, but more a CK world. > > The basic idea is that CK knows which speakers belong to which seat, > and PA will honour that. Or actually, as soon as we get revoke() in > the kernel CK will enforce that, by forcibly kicking processes from > their devices if they don't comply. > > However, multi-seat support is not really available in CK yet. > > davidz and William Jon McCann can tell you more about this. Trying again, maybe you will answer my other question too. My normal use case is that I have rhythmbox running in my account which I tend to screenlock, when my wife wants to browse the web briefly she fast-switches to her account. What will PA do? Will it stop rhythmbox in the other session? If so why? What is the logic? I usually want to keep the music running. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From alexl at users.sourceforge.net Wed Dec 19 00:25:44 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 18 Dec 2007 17:25:44 -0700 Subject: KDE-SIG weekly report (48/2007) In-Reply-To: <200712182349.49371.ml@deadbabylon.de> (Sebastian Vahl's message of "Tue\, 18 Dec 2007 23\:49\:44 +0100") References: <200712182349.49371.ml@deadbabylon.de> Message-ID: >>>>> "SV" == Sebastian Vahl writes: [...] SV> o kdemultimedia3 compat package? - at least taxipilot is relying SV> on aRts-related libraries provided by kdemultimedia 3 which has SV> now broken dependencies - Also it's possible that some apps will SV> fail at runtime due to trying to load some aRts modules which were SV> in kdemultimedia3 and not finding them - If we create a SV> kdemultimedia3 we should make sure phonon, arts and pulseaudio SV> work together - taxipilot itself isn't ported to kde 4 yet - there SV> was no consensus if we drop taxipilot because of it's unmaintained SV> kde4 state, patch it to don't use arts or create a kdemultimedia3 SV> package - If we create a kdemultimedia3 package we have to get it SV> reviewed because it's not existing in cvs As another datapoint: tellico uses the CDDB support from kdemultimedia3, although if it is not present, tellico simply doesn't use it at compile-time. We currently dropped the BuildRequires for kdemultimedia for the tellico package in rawhide, which works, but isn't ideal. Alex From ndbecker2 at gmail.com Wed Dec 19 00:49:07 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 18 Dec 2007 19:49:07 -0500 Subject: This seems to be getting worse Message-ID: Warning: don't show this to children http://fedora.org/ From seg at haxxed.com Wed Dec 19 00:53:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 18 Dec 2007 18:53:32 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218183918.GH28630@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> Message-ID: <1198025613.18986.131.camel@localhost> On Tue, 2007-12-18 at 19:39 +0100, Lennart Poettering wrote: > But only one daemon instance can access the audio HW at a time. But > since to awesome projects like HAL and CK PA will automatically be > notified when the active VT/session is switched. And the PA daemon > that becomes inactive closes the audio device and the one the becomes > active opens it. What if your hardware supports multiple streams? Obviously that should allow more than one daemon to use the card. But then what about single user use? Is PA just going to let my multi-stream capable hardware go to waste? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Wed Dec 19 01:04:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 18 Dec 2007 19:04:12 -0600 Subject: KDE-SIG weekly report (48/2007) References: <200712182349.49371.ml@deadbabylon.de> Message-ID: Alex Lancaster wrote: > As another datapoint: tellico uses the CDDB support from > kdemultimedia3, although if it is not present, tellico simply doesn't > use it at compile-time. We currently dropped the BuildRequires for > kdemultimedia for the tellico package in rawhide, which works, but > isn't ideal. I think we can all agree the a kdemultimedia3 (compat) pkg would be nice (primarily for arts plugins). Any volunteers to help create/maintain it would be welcome(*). -- Rex (*) Otherwise, I (or others in the KDE-SIG) may get to it eventually, but our current focus is on kde4. From cebbert at redhat.com Wed Dec 19 01:25:12 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 18 Dec 2007 20:25:12 -0500 Subject: Can't release a package because it's been untagged Message-ID: <476872F8.2050302@redhat.com> Trying to add kernel-2.6.23.9-47.fc7 in bodhi, I get "kernel-2.6.23.9-47.fc7 not tagged with dist-fc7-updates-candidate". Sure enough, the history says: Sun Dec 16 05:22:24 2007: Untagged kernel-2.6.23.9-47.fc7 from dist-fc7-updates-candidate Yet I never made any kind of request. What would cause my package to get untagged like that? From seg at haxxed.com Wed Dec 19 01:29:15 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 18 Dec 2007 19:29:15 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218140807.GA2287@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> Message-ID: <1198027755.18986.140.camel@localhost> On Tue, 2007-12-18 at 15:08 +0100, Jindrich Novy wrote: > > Unicorn. Link = fictional creatures. > > How about Vampire? The same link as above. World of Darkness anyone? Mage Hunter Orpheus Prometheus I guess that's treading kind of close to a trademark minefield. (The Link Is Not WoD Really Its Not!) I think we should keep to things easily mascot-able. People like cute mascots. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Dec 19 01:36:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 18 Dec 2007 19:36:56 -0600 Subject: This seems to be getting worse In-Reply-To: References: Message-ID: <1198028216.18986.143.camel@localhost> On Tue, 2007-12-18 at 19:49 -0500, Neal Becker wrote: > Warning: don't show this to children > http://fedora.org/ Licking cats? At least its not goatse.cx guy or tubgirl. ... Yet. -------------- 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 jon at fedoraunity.org Wed Dec 19 01:46:03 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Tue, 18 Dec 2007 18:46:03 -0700 Subject: This seems to be getting worse In-Reply-To: References: Message-ID: <20071218184603.7015dbd1@damaestrojr> On Tue, 18 Dec 2007 19:49:07 -0500 Neal Becker wrote: > Warning: don't show this to children > http://fedora.org/ > ... or the kitten gets it ... From notting at redhat.com Wed Dec 19 01:55:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Dec 2007 20:55:29 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198023829.19318.80.camel@localhost.localdomain> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> Message-ID: <20071219015529.GA24979@nostromo.devel.redhat.com> Simo Sorce (ssorce at redhat.com) said: > My normal use case is that I have rhythmbox running in my account which > I tend to screenlock, when my wife wants to browse the web briefly she > fast-switches to her account. > > What will PA do? Will it stop rhythmbox in the other session? Yes. > If so why? Because the session for that desktop is no longer active. Bill From ssorce at redhat.com Wed Dec 19 02:11:00 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 21:11:00 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219015529.GA24979@nostromo.devel.redhat.com> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> Message-ID: <1198030261.19318.83.camel@localhost.localdomain> On Tue, 2007-12-18 at 20:55 -0500, Bill Nottingham wrote: > Simo Sorce (ssorce at redhat.com) said: > > My normal use case is that I have rhythmbox running in my account which > > I tend to screenlock, when my wife wants to browse the web briefly she > > fast-switches to her account. > > > > What will PA do? Will it stop rhythmbox in the other session? > > Yes. > > > If so why? > > Because the session for that desktop is no longer active. I guess disabling PA is the only option for anybody willing to play music not from the current active session? Or will there be a way to easily configure access from anybody on the same machine? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jkeating at redhat.com Wed Dec 19 03:21:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 22:21:28 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198030261.19318.83.camel@localhost.localdomain> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> Message-ID: <20071218222128.779d1d88@redhat.com> On Tue, 18 Dec 2007 21:11:00 -0500 Simo Sorce wrote: > I guess disabling PA is the only option for anybody willing to play > music not from the current active session? > Or will there be a way to easily configure access from anybody on the > same machine? Again, this isn't PA necessarily, it's ConsoleKit / PolicyKit. If you define policy that lets everybody write to the devices then... -- 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 Dec 19 03:23:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 22:23:31 -0500 Subject: Can't release a package because it's been untagged In-Reply-To: <476872F8.2050302@redhat.com> References: <476872F8.2050302@redhat.com> Message-ID: <20071218222331.1d8919b3@redhat.com> On Tue, 18 Dec 2007 20:25:12 -0500 Chuck Ebbert wrote: > Yet I never made any kind of request. What would cause my package > to get untagged like that? An attempted bodhi push without a rollback. You should be able to tag it yourself for -candidate. -- 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 kamisamanou at kamisamanou.net Wed Dec 19 03:38:29 2007 From: kamisamanou at kamisamanou.net (Kamisamanou Burgess) Date: Tue, 18 Dec 2007 21:38:29 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181055.00912.dennis@ausil.us> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181055.00912.dennis@ausil.us> Message-ID: <5dbb83710712181938m27f8a530n17a26cab8c719c79@mail.gmail.com> On Dec 18, 2007 10:55 AM, Dennis Gilmore wrote: > On Tuesday 18 December 2007, Simo Sorce wrote: > > Anubis [1]: > > > > Anubis is a mythological creature of human/canine form > > Werewolf is a mythological creature of human/canine form > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > I like this suggestion :) > > Dennis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Likewise -- Sayonara, Kamisamanou Burgess http://www.kamisamanou.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at thecodergeek.com Wed Dec 19 03:48:33 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 18 Dec 2007 19:48:33 -0800 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712181039l102b184dxbe4f4fda6136b730@mail.gmail.com> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216120141.1f0b79ae@ghistelwchlohm.scrye.com> <1197902688.2937.3.camel@space-ghost.verbum.private> <20071217151755.GA21523@jadzia.bu.edu> <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <1197955212.3290.77.camel@jndwidescreen.lesbg.loc> <604aa7910712181039l102b184dxbe4f4fda6136b730@mail.gmail.com> Message-ID: <1198036113.4453.1.camel@tuxhugs> On Tue, 2007-12-18 at 09:39 -0900, Jeff Spaleta wrote: > Thanks, no matter what other people think.. i think it helps to have a > specific implementation > example to use as a baseline reference. Is mpd even in the mainline > Fedora repository? Or am I blind? No, it's not; and you're not. :) IIRC it includes various MP3 decoding stuff in its source tarball which is troublesome at best to remove or patch away. -- 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 ssorce at redhat.com Wed Dec 19 04:14:42 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Dec 2007 23:14:42 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218222128.779d1d88@redhat.com> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> Message-ID: <1198037682.19318.89.camel@localhost.localdomain> On Tue, 2007-12-18 at 22:21 -0500, Jesse Keating wrote: > On Tue, 18 Dec 2007 21:11:00 -0500 > Simo Sorce wrote: > > > I guess disabling PA is the only option for anybody willing to play > > music not from the current active session? > > Or will there be a way to easily configure access from anybody on the > > same machine? > > Again, this isn't PA necessarily, it's ConsoleKit / PolicyKit. If you > define policy that lets everybody write to the devices then... Sure I can do that for myself but that's not the point. I was specifically asking if there will be a configuration option somewhere to handle this (I think common enough) case so that you can decide whether fast switching users means killing audio or not. It seem to me that this PA thing has the noble goal of making audio easier to work with on a Desktop, and then you expect people to fiddle manually with ConsoleKit/PolicyKit to make a trivial configuration change for a common case? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From walters at redhat.com Wed Dec 19 04:37:52 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 18 Dec 2007 23:37:52 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198037682.19318.89.camel@localhost.localdomain> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> Message-ID: <1198039072.3085.18.camel@space-ghost.verbum.private> On Tue, 2007-12-18 at 23:14 -0500, Simo Sorce wrote: > I was specifically asking if there will be a configuration option > somewhere to handle this (I think common enough) case so that you can > decide whether fast switching users means killing audio or not. A configuration option would only work for people who happen to read fedora-devel-list or care enough to search deeply for it (this is a tiny fraction of the user base, or I hope so anyways). Probably the ideal way things could work here is that on a user switch, instead of automatically stopping playback at that point, we instead have an unobtrusive window appear in the new user's session, say at the bottom right (or as a notification area display) that says: "Other User is playing music [Pause Playback] [X]". This all said though, I don't see how it's really a big deal if playback automatically stopped on user switch. There are a lot more important bugs... From cra at WPI.EDU Wed Dec 19 04:55:28 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 18 Dec 2007 23:55:28 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <47685223.4080705@poolshark.org> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> <604aa7910712181447l30c88e1cvc4caaade620e11d7@mail.gmail.com> <47685223.4080705@poolshark.org> Message-ID: <20071219045528.GA11069@angus.ind.WPI.EDU> On Wed, Dec 19, 2007 at 12:05:07AM +0100, Denis Leroy wrote: > Jeff Spaleta wrote: >> On Dec 18, 2007 1:36 PM, Denis Leroy wrote: >>> The zonbu is also connected to my stereo system, which i can hear from >>> my office. So i will often ssh into the zonbu and play an mp3 from the >>> wireless-mounted NFS directory. Now PA means i have to log in as the >>> same guest user, which is not necessarily ideal because of the nfs mount >>> permissions, but certainly workable. Now of course i can just disable PA >>> in this case and be happy. But you were asking for a specific scenario. >> >> What do you use to play the mp3 from the remote ssh session? Is this >> a case of device permissions not being set like you need via >> ConsoleKit... or is it >> really a problem concerning PA's operation? > > good point, it seems to be a permission with /dev/dsp indeed. Colin is > right, if PA's user is not actually playing any sound, then it works if I > chmod /dev/dsp the right way. You could always add an ACL to the device node--that is what ConsoleKit does. getfacl /dev/dsp getfacl /dev/snd/* setfacl -m user::rw- /dev/dsp setfacl -m user::rw- /dev/snd/* BTW, why are you using /dev/dsp which is an OSS device? From abraxis at telkomsa.net Wed Dec 19 06:12:39 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Wed, 19 Dec 2007 08:12:39 +0200 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198039072.3085.18.camel@space-ghost.verbum.private> References: <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> Message-ID: <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> On Tue, Dec 18, 2007 at 11:37:52PM -0500, Colin Walters wrote: > > This all said though, I don't see how it's really a big deal if playback > automatically stopped on user switch. There are a lot more important > bugs... > Completely apart from the current issue, this is an attitude that seems to be prevalent amongst the Fedora desktop team, and it worries me - "So what if it used to work? We have this brand new bling that is better and you WILL use it!" You do understand the concept that regressions are bad, don't you? -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From kevin.kofler at chello.at Wed Dec 19 06:23:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 19 Dec 2007 06:23:08 +0000 (UTC) Subject: KDE-SIG weekly report (48/2007) References: <200712182349.49371.ml@deadbabylon.de> <200712190022.08231.ml@deadbabylon.de> Message-ID: Sebastian Vahl deadbabylon.de> writes: > Of course this should be 2008-01-03 :) Actually I suggested 2008-01-02 (Wednesday), but 2008-01-03 (Thursday) would also be possible. Kevin Kofler From seg at haxxed.com Wed Dec 19 06:40:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 19 Dec 2007 00:40:40 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <5dbb83710712181938m27f8a530n17a26cab8c719c79@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181055.00912.dennis@ausil.us> <5dbb83710712181938m27f8a530n17a26cab8c719c79@mail.gmail.com> Message-ID: <1198046440.18986.149.camel@localhost> On Tue, 2007-12-18 at 21:38 -0600, Kamisamanou Burgess wrote: > On Dec 18, 2007 10:55 AM, Dennis Gilmore wrote: > On Tuesday 18 December 2007, Simo Sorce wrote: > > Anubis [1]: > > Anubis is a mythological creature of human/canine form > > Werewolf is a mythological creature of human/canine form > > > > [1]: http://en.wikipedia.org/wiki/Anubis > > > I like this suggestion :) > > Likewise Okay we have our mascot. Now we just need our obligatory booze reference... -------------- 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 Wed Dec 19 07:19:33 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 19 Dec 2007 07:19:33 +0000 (UTC) Subject: Mock and consolehelper Message-ID: I have noticed that mock in Rawhide has been changed to drop the SUID helper, instead consolehelper is used to run the entire mock as root. IMHO, this is a regression: * It now means you have to know the root password to run mock. Before, it was possible to give out mock access and only that simply by making the user a member of the mockbuild group. Now the only way to do that is to allow running all of mock as root, which probably opens up several ways to get full root access from there. * It means mock has to be run interactively. What are the implications of this on the builders? Will they have to install all of mock SUID root, or set up consolehelper in a way which effectively does the same? * It reduces security, as instead of a small helper doing only a few controlled operations, you now run all of mock as root. Sure, it's Python, so buffer overflows probably can't happen, but still, trigger any bug in mock with a trojaned SRPM and you have root. Kevin Kofler From wart at kobold.org Wed Dec 19 07:42:56 2007 From: wart at kobold.org (Wart) Date: Tue, 18 Dec 2007 23:42:56 -0800 Subject: add eris-1.3.13 to the build root Message-ID: <4768CB80.5090003@kobold.org> I need to rebuild sear with the latest eris package, but eris can't be pushed to the updates repo yet because the current sear package depends on the old package. Can someone from releng put eris-1.3.13 temporarily in the build root so that I can rebuild sear and push both the updated eris and sear at the same time? Thanks, --Wart From tmraz at redhat.com Wed Dec 19 08:25:20 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 19 Dec 2007 09:25:20 +0100 Subject: Mock and consolehelper In-Reply-To: References: Message-ID: <1198052720.12586.27.camel@vespa.frost.loc> On Wed, 2007-12-19 at 07:19 +0000, Kevin Kofler wrote: > I have noticed that mock in Rawhide has been changed to drop the SUID helper, > instead consolehelper is used to run the entire mock as root. IMHO, this is a > regression: > * It now means you have to know the root password to run mock. Before, it was > possible to give out mock access and only that simply by making the user a > member of the mockbuild group. Now the only way to do that is to allow running > all of mock as root, which probably opens up several ways to get full root > access from there. You can configure access to mock through the /etc/pam.d/mock file and it currently already should allow to non-interactive use by users in group mock. There is: auth sufficient pam_rootok.so auth sufficient pam_succeed_if.so user ingroup mock use_uid quiet > * It means mock has to be run interactively. What are the implications of this > on the builders? Will they have to install all of mock SUID root, or set up > consolehelper in a way which effectively does the same? > * It reduces security, as instead of a small helper doing only a few controlled > operations, you now run all of mock as root. Sure, it's Python, so buffer > overflows probably can't happen, but still, trigger any bug in mock with a > trojaned SRPM and you have root. mock could still drop priviledges - change to mock user or whatever as soon as it doesn't need to be root anymore. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mzerqung at 0pointer.de Wed Dec 19 09:13:17 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:13:17 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198023829.19318.80.camel@localhost.localdomain> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> Message-ID: <20071219091317.GB9741@tango.0pointer.de> On Tue, 18.12.07 19:23, Simo Sorce (ssorce at redhat.com) wrote: > > However, multi-seat support is not really available in CK yet. > > > > davidz and William Jon McCann can tell you more about this. > > Trying again, maybe you will answer my other question too. > > My normal use case is that I have rhythmbox running in my account which > I tend to screenlock, when my wife wants to browse the web briefly she > fast-switches to her account. > > What will PA do? Will it stop rhythmbox in the other session? If so why? > What is the logic? I usually want to keep the music running. It will pause playback. When you switch back it will resume. Much like MacOS does it. The idea is that speakers are IO devices much like the screen, keyboard, and mice. I do believe that the normal case is that when you switch sessions, you don't want to allow the inactive session to record data from you microphone anymore or interfere with your audio in otherwise. I know that some people want to continue playback when they switch to a different session. However, I do not believe that this should be the default. Maybe we will add support for this in a later version somehow, but I do believe the right approach is to make sure that inactive sessions cannot spy on the user who's active on the seat. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:15:29 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:15:29 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198030261.19318.83.camel@localhost.localdomain> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> Message-ID: <20071219091529.GC9741@tango.0pointer.de> On Tue, 18.12.07 21:11, Simo Sorce (ssorce at redhat.com) wrote: > > > If so why? > > > > Because the session for that desktop is no longer active. > > I guess disabling PA is the only option for anybody willing to play > music not from the current active session? > Or will there be a way to easily configure access from anybody on the > same machine? if you do want stuff like that you can just open the audio device directly via raw ALSA devices. Much the same way as it is handled without PA. Of course the audio device will then be blocked, but yeah, that's the way it always used to be. As soon as CK works properly this won't work anymore howewver (in the default configuration at least). Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:20:24 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:20:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198037682.19318.89.camel@localhost.localdomain> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> Message-ID: <20071219092024.GD9741@tango.0pointer.de> On Tue, 18.12.07 23:14, Simo Sorce (ssorce at redhat.com) wrote: > > Again, this isn't PA necessarily, it's ConsoleKit / PolicyKit. If you > > define policy that lets everybody write to the devices then... > > Sure I can do that for myself but that's not the point. > > I was specifically asking if there will be a configuration option > somewhere to handle this (I think common enough) case so that you can > decide whether fast switching users means killing audio or not. > > It seem to me that this PA thing has the noble goal of making audio > easier to work with on a Desktop, and then you expect people to fiddle > manually with ConsoleKit/PolicyKit to make a trivial configuration > change for a common case? The scenario you came up here with is totally artificial. Why? Because right now whith dmix you cannot share audio devices like this either. Because dmix is not open for other user ids. (And it would not make sense to open it by default, because it comes with security implications). So, in fact, not much has changed by the introduction of PA: sharing an audio device between multiple users didn't work before PA without major reconfiguration of ALSA, and it doesn work after the introduction of PA without some manual configuration. As mentioned already: I do plan to add some support for sharing audio devices like this, but it's not a top priority on my list. Far from that. The right behaviour is to make sure inactive sessions cannot interfere with your IO devices while they are inactive. And IO devices are keyboards, mice, screens *and* sound cards. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:22:49 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:22:49 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198039072.3085.18.camel@space-ghost.verbum.private> References: <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> Message-ID: <20071219092249.GE9741@tango.0pointer.de> On Tue, 18.12.07 23:37, Colin Walters (walters at redhat.com) wrote: > > I was specifically asking if there will be a configuration option > > somewhere to handle this (I think common enough) case so that you can > > decide whether fast switching users means killing audio or not. > > A configuration option would only work for people who happen to read > fedora-devel-list or care enough to search deeply for it (this is a tiny > fraction of the user base, or I hope so anyways). My plan is to add a small checkbox to paprefs: "Allow other inactive sessions to access the soundcard" or something like that. But again, to implement this is a very low-priority item on my TODO list. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:26:10 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:26:10 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> Message-ID: <20071219092610.GF9741@tango.0pointer.de> On Wed, 19.12.07 08:12, Neil Thompson (abraxis at telkomsa.net) wrote: > > This all said though, I don't see how it's really a big deal if playback > > automatically stopped on user switch. There are a lot more important > > bugs... > > > > Completely apart from the current issue, this is an attitude that seems to > be prevalent amongst the Fedora desktop team, and it worries me - "So what > if it used to work? We have this brand new bling that is better and you WILL > use it!" Sharing audio devices between multiple concurrent sessions of different users without major reconfiguration of ALSA never worked. This is no regression. Also, I'd argue even if it worked before (which it didn't) the behaviour exposed by PA+CK is the more correct one, from a security perspective. And hence speaking of a "regression" in this area is very adventurous. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:35:47 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:35:47 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> References: <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> Message-ID: <20071219093547.GG9741@tango.0pointer.de> On Tue, 18.12.07 12:03, Jeff Spaleta (jspaleta at gmail.com) wrote: > > On Dec 18, 2007 11:57 AM, Lennart Poettering wrote: > > I explained that already twice: with the help of HAL/CK we are > > notified whenever the active session changes and thus can give up > > access to the audio hw and open it again when needed. That works fine, > > and is part of F8. > > I think one of the problems here is CK runs against a body of shared > administration experience > in the community. There isn't a shared understanding of how to use CK > effectively to get common hardware related admin crap done, so as a > result any explanation on how to do something semi-involved as an > administrator which boils down to "it uses CK to do it" just doesn't > connect. The basic idea of the CK/HAL integration is very simple: only the active session on a seat gets access to your IO devices like mice, keyboard, screen, sound card. To make that a reality ACLs on the device nodes are modified to match user on the current active VT. And as soon as we have revoke() in the kernel applications accessing those device files are kicked from doing so as soon as their session becomes inactive. That's basically it. Sure, there could be better documentation. I guess for 99% of all Free Software there could be better documentation. In spirit of real Free Software you're always welcome to contribute better documentation! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:38:27 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:38:27 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198012827.12620.19.camel@rousalka.dyndns.org> References: <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> <1198008943.11811.25.camel@rousalka.dyndns.org> <20071218210238.GE3360@tango.0pointer.de> <1198012827.12620.19.camel@rousalka.dyndns.org> Message-ID: <20071219093827.GH9741@tango.0pointer.de> On Tue, 18.12.07 22:20, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > Then I guess any form of time shifting and delayed audio/video recording > > > is out? Have we progressed so much recording anything including audio > > > now involves post-its forbidding anyone from logging at the wrong hour > > > to avoid stealing audio from recording apps? > > > > I really don't see what "time shifting" has to do with PA? > > You have background processes eating analog audio and video and > producing recordings for some users. While another one may be logged in > GNOME or KDE doing something else. > > In the bright new world you described as soon as the human logs in > device access is stolen from everything/one else. Of course I may have > misunderstood the explanation but it seemed to be there is one exclusive > user of audio devices at any time, the active desktop session (whatever > that is going to be, since people are working to make multi-head X a > reality) Multi-head X *is* a reality. Yes, in the current version of the CK the default behaviour is to disallow access to the IO devices like sound cards for all but the current active session. But you are always welcome to change the configuration or maybe manually add an ACL entry to the device node fo your user. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:41:27 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:41:27 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198025613.18986.131.camel@localhost> References: <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <1197985910.30757.3.camel@localhost6.localdomain6> <20071218151221.GA53607@dspnet.fr.eu.org> <20071218183918.GH28630@tango.0pointer.de> <1198025613.18986.131.camel@localhost> Message-ID: <20071219094127.GI9741@tango.0pointer.de> On Tue, 18.12.07 18:53, Callum Lerwick (seg at haxxed.com) wrote: > > On Tue, 2007-12-18 at 19:39 +0100, Lennart Poettering wrote: > > But only one daemon instance can access the audio HW at a time. But > > since to awesome projects like HAL and CK PA will automatically be > > notified when the active VT/session is switched. And the PA daemon > > that becomes inactive closes the audio device and the one the becomes > > active opens it. > > What if your hardware supports multiple streams? Obviously that should > allow more than one daemon to use the card. But then what about single > user use? Is PA just going to let my multi-stream capable hardware go to > waste? This has been discussed before. Hardware mixing is obsolete technology. Mixing audio on the CPU is cheap and usually done with better and more reliable quality. Unless someone contributes a patch PA will not support hw mixing. I am certainly not working on a feture like that. As soon as we have revoke() in the kernel the processes of inactive sessions will kicked from the devices as soon as they become inactive. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:46:04 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:46:04 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <47684AA4.5090606@gmail.com> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> Message-ID: <20071219094603.GJ9741@tango.0pointer.de> On Tue, 18.12.07 16:33, Les Mikesell (lesmikesell at gmail.com) wrote: >> I think one of the problems here is CK runs against a body of shared >> administration experience >> in the community. There isn't a shared understanding of how to use CK >> effectively to get common hardware related admin crap done, so as a >> result any explanation on how to do something semi-involved as an >> administrator which boils down to "it uses CK to do it" just doesn't >> connect. > > Yes, that doesn't make any sense to me - even the concept of 'active > session'. If your X display is on a nearby machine (or several) but you > want local audio, is that 'active' or not in PA speak? What if you have > mythtv running but not related to a logged in session and also want to log > in? You're always welcome to change he default configuration of CK. The point of CK is that we try to fix a gaping security hole: think of a university system: a workstation where different people logon/logoff all the time. Right now, a user may keep open the sound card forever, and use it to spy people who access the same machine later on. I.e. use the mike to listen to what they are saying and stuff like that. If you don't care about that kind of security than you are always welcome to change the configuration. But I believe that the default installation of Fedora should be reasonably secure, and that this should be a priority. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:49:37 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:49:37 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198014085.19318.68.camel@localhost.localdomain> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014085.19318.68.camel@localhost.localdomain> Message-ID: <20071219094937.GK9741@tango.0pointer.de> On Tue, 18.12.07 16:41, Simo Sorce (ssorce at redhat.com) wrote: > > > > How is it supposed to be handled in a non PA world? > > > > > > You assign specific alsa devices to specific apps > > > > You're welcome to do that even if login sessions use PA. PA releases > > the audio devices when idle. And thus your kind of setup works as good > > or as bad as it did before. Just use "front:0" or "front:1" as ALSA > > audio device, instead of "default" or "pulse". > > > > Oh, and since you seem to hate PA really that much: just disable it! > > Just remove alsa-plugins-pulseaudio and you have it back, your naked > > ALSA. > > Lennart, > just one question, can I tell PA which device to use if I have more than > one? Yes, of course. Right now, support for multiple audio devices is one of the hottest features of PA. You might want to have a look on the screencast linked in this blog story of mine: http://0pointer.de/blog/projects/pa-097.html > Let's say I have regular boxes and an USB audio device (headset), will > PA grab them both? Just one, switch automatically from one to the other > when I plug in the headset ? None of the above? As mentioned a million times already, PA hooks into HAL to be notified about USB hotplugs. I does so to make use of the devices as soon as they become available. You really should have a look on the screencast linked above. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:54:32 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:54:32 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218215443.GA97953@dspnet.fr.eu.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> Message-ID: <20071219095432.GL9741@tango.0pointer.de> On Tue, 18.12.07 22:54, Olivier Galibert (galibert at pobox.com) wrote: > No, we'd just like it to be usable in other contexts than laptops. We > don't need another NM-like story. Especially since Fedora would like > to make it mandatory (for very good reasons too). Hmm? PA is already activated by default in F8. The plans are already a reality. > An example of real use I have at home: > > - Main desktop machine is connected to speakers through normal wires > and to the living room ac3/dts through toslink PA doesn't really support AC3 out. AC3 is not a free codec, so we will always have trouble to support something like this. Also ALSA doesn't really allow us to detect if SP/DIF is available or not. spdif support is WIP and needs more support from ALSA right now. That means, for now, you have to use the raw ALSA "spdif" device if you want to playback audio on spdif. That hasn't changed from pre-PA times. > - Both the GF & I are usually logged on that machine, her with KDE on > Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in > my startup wouldn't be a problem. You should be using the normal fast-user-switching for that. > - User switching, as it is, is just C-A-F7/C-A-F8 > > - Additionally, we often ssh to the machine from our laptops to start > music using xmms/audacious/mplayer sending on spdif to hear it in > the living room. Files are on the desktop machine, so we'd rather > do X than nfs+pcm over the wifi. > > Can PA do that? Can PA be modified to support that? PA supports f-u-s just fine, as I think I already wrote about 555 times on this thread. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 09:57:12 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 10:57:12 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198014026.12620.35.camel@rousalka.dyndns.org> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> Message-ID: <20071219095711.GM9741@tango.0pointer.de> On Tue, 18.12.07 22:40, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > Oh, and since you seem to hate PA really that much: > > I don't hate PA anymore than you hate users that do not fit in your > assumptions I don't hate anyone. What's so wrong with "make the common things easy and the uncommon things possible"? > > just disable it! > > Ok, if that's the official answer I'll ask application authors to > un-pulsify their apps so sound still works for the Fedora users you > don't want to care about. I had accepted it would not work short term > but if even asking how some use-cases are supposed to work mid-term is > too much, there's little hope left. I love you too. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 10:00:37 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 11:00:37 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <476852A1.50100@poolshark.org> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <1198014026.12620.35.camel@rousalka.dyndns.org> <20071218215656.GC26557@humbolt.us.dell.com> <47684B78.4090202@poolshark.org> <20071218230029.GE26557@humbolt.us.dell.com> <476852A1.50100@poolshark.org> Message-ID: <20071219100037.GN9741@tango.0pointer.de> On Wed, 19.12.07 00:07, Denis Leroy (denis at poolshark.org) wrote: > > Michael E Brown wrote: >> 1) copy the zonbu's ~guest/.pulse-cookie file to your home dir. (from >> Lennart's previous email, I havent tested this.) This looks to me like >> the best option. > > The file isn't readable to other of course, but even then, this doesn't > seem to work. It doesn't? Please be more elaborate than "it doesn't seem to work"! >> 2) ask your music player to directly use the alsa hw:0 device, and >> probably twiddle permissions on the /dev/snd/ files. > > That indeed works. BTW: Better user "front:0" or suchlike. hw:0 is not intended to be used by normal user applications. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From abraxis at telkomsa.net Wed Dec 19 10:12:32 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Wed, 19 Dec 2007 12:12:32 +0200 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219092610.GF9741@tango.0pointer.de> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> Message-ID: <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> On Wed, Dec 19, 2007 at 10:26:10AM +0100, Lennart Poettering wrote: > On Wed, 19.12.07 08:12, Neil Thompson (abraxis at telkomsa.net) wrote: > > > > This all said though, I don't see how it's really a big deal if playback > > > automatically stopped on user switch. There are a lot more important > > > bugs... > > > > > > > Completely apart from the current issue, this is an attitude that seems to > > be prevalent amongst the Fedora desktop team, and it worries me - "So what > > if it used to work? We have this brand new bling that is better and you WILL > > use it!" > > Sharing audio devices between multiple concurrent sessions of > different users without major reconfiguration of ALSA never worked. > > This is no regression. Ah yes, the "brand new bling" argument. Not buying it. > > Also, I'd argue even if it worked before (which it didn't) the > behaviour exposed by PA+CK is the more correct one, from a security > perspective. And hence speaking of a "regression" in this area is very > adventurous. > Something that used to work without issues, doesn't any more...looks like a duck, walks like a duck... And then the use case just gets dismissed. Paraphrasing..."the clueless newbie who doesn't really use her machine will be OK, and the other folks will just have to change the way they work". Like I said, it's the attitude that seems to be coming across from the desktop folks that worries me - you either fit into their (limited) set of use cases or you're SOL. It happened with NM, and if you read through this thread you'll see it happening again. And the "well, just disable it" comments aren't helping either. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From jroth at linux.vnet.ibm.com Wed Dec 19 10:21:11 2007 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Wed, 19 Dec 2007 11:21:11 +0100 Subject: NFS root path support in mkinitrd Message-ID: <4768F097.3000506@linux.vnet.ibm.com> Peter, thanks for adding the nfs root-path by dhcp support to mkinitrd. Unfortunately there are some limitations and problems which may occur. I'd like to discuss them with you and the devel list. My original patch evaluated the kernel command line like the kernel does. (Documentation/nfsroot.txt) Setting root=/dev/nfs caused the initrd to read the root-path option from the dhcp lease. The way you did it was looking at the mount-options of the root-filesystem in /etc/fstab. If the "dhcp" mount option is there it will read the dhcp lease file in the initrd. I like this way, but the problem we're having is the following. Setting the mount option "dhcp" in /etc/fstab causes the network script to fail as "dhcp" isn't a supported mount option. Remounting root filesystem in read-write mode: Unsupported nfs mount option: dhcp [FAILED] And as a consequence /etc/mtab doesn't contain the mounted root filesystem. The reboot will then fail as it tries to shutdown the network interface on an NFS root filesystem! One workaround is to create a separate fstab with "dhcp" mount option. Then we pass this fstab as an argument to mkinitrd like: mkinitrd --fstab=fstab ... Another workaround would have been to pass the option by using --rootopts . This isn't possible because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=356371 Does anyone on this list have a suggestion about how we can improve / solve this issue? Luckily there is a workaround available. Thanks for your comments. -- Jochen From mzerqung at 0pointer.de Wed Dec 19 10:31:15 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 11:31:15 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> References: <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> Message-ID: <20071219103114.GA14958@tango.0pointer.de> On Wed, 19.12.07 12:12, Neil Thompson (abraxis at telkomsa.net) wrote: > > Also, I'd argue even if it worked before (which it didn't) the > > behaviour exposed by PA+CK is the more correct one, from a security > > perspective. And hence speaking of a "regression" in this area is very > > adventurous. > > > > Something that used to work without issues, doesn't any more...looks like > a duck, walks like a duck... Sorry, but it *didn't* work before. By default the access mode of the dmix SHM is 0600. i.e. only a single user ID may access the sound card at a time. If you want to open up dmix to multiple users at the same time you need to change it to 0666 or so, which is a security hole and needs some non-trivial reconfiguration. The reconfiguration necessary to open up PA to other users is a lot simpler to do. Just copy a cookie file around. > And then the use case just gets dismissed. Paraphrasing..."the clueless newbie > who doesn't really use her machine will be OK, and the other folks will just have > to change the way they work". I didn't dismiss your use case at all. All I told you is that the kind of setup you envision required non-trivial reconfiguration before, and it requires reconfiguration now. So, calling this is a regression is bogus. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nicolas.mailhot at laposte.net Wed Dec 19 10:32:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Dec 2007 11:32:19 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219092024.GD9741@tango.0pointer.de> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <20071219092024.GD9741@tango.0pointer.de> Message-ID: <12390.192.54.193.53.1198060339.squirrel@rousalka.dyndns.org> Le Mer 19 d?cembre 2007 10:20, Lennart Poettering a ?crit : > The right behaviour is to make sure inactive sessions cannot interfere > with your IO devices while they are inactive. And IO devices are > keyboards, mice, screens *and* sound cards. Sound cards are *not* like keyboards, mice and screens. A keyboard is only providing a service to the person typing on it A mice is only providing a service to the person which has it in its hand Any semi-decent speaker can provide music services to everyone in a room, (even a different room of the one where the computer is) not just the person in front of the computer. Time shifting means a user can access sound devices even after his desktop session went inactive or closed. Printing is outputting info too. Will we limit printer access to the active session too to get the "right" behaviour? -- Nicolas Mailhot From mzerqung at 0pointer.de Wed Dec 19 10:34:47 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 11:34:47 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <12390.192.54.193.53.1198060339.squirrel@rousalka.dyndns.org> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <20071219092024.GD9741@tango.0pointer.de> <12390.192.54.193.53.1198060339.squirrel@rousalka.dyndns.org> Message-ID: <20071219103447.GA15305@tango.0pointer.de> On Wed, 19.12.07 11:32, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > The right behaviour is to make sure inactive sessions cannot interfere > > with your IO devices while they are inactive. And IO devices are > > keyboards, mice, screens *and* sound cards. > > Sound cards are *not* like keyboards, mice and screens. > A keyboard is only providing a service to the person typing on it > A mice is only providing a service to the person which has it in its hand > > Any semi-decent speaker can provide music services to everyone in a > room, (even a different room of the one where the computer is) not > just the person in front of the computer. Time shifting means a user > can access sound devices even after his desktop session went inactive > or closed. > > Printing is outputting info too. Will we limit printer access to the > active session too to get the "right" behaviour? With a printer you cannot really spy on people. With access to the sound card you can. Very easily. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From galibert at pobox.com Wed Dec 19 10:44:48 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 19 Dec 2007 11:44:48 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219095432.GL9741@tango.0pointer.de> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> Message-ID: <20071219104448.GA80218@dspnet.fr.eu.org> On Wed, Dec 19, 2007 at 10:54:32AM +0100, Lennart Poettering wrote: > On Tue, 18.12.07 22:54, Olivier Galibert (galibert at pobox.com) wrote: > > - Main desktop machine is connected to speakers through normal wires > > and to the living room ac3/dts through toslink > > PA doesn't really support AC3 out. AC3 is not a free codec, so we will > always have trouble to support something like this. toslink/spdif also supports 48KHz 16bits stereo pcm as I'm sure you perfectly know. It also very easily could be, as it was at a time, one of the 3 stereo line outputs of the ac97 onboard support. > That means, for now, you have to use the raw ALSA "spdif" device if > you want to playback audio on spdif. That hasn't changed from pre-PA times. I can use alsa for everything, I know that already. That was not the point of the email. If your answer to "how can PA be used to support my configuration" is systematically "don't use PA", why are you working on PA in the first place? > You should be using the normal fast-user-switching for that. So now gdm and using a panel is a fedora requirement for multiuser support? > PA supports f-u-s just fine, as I think I already wrote about 555 > times on this thread. Where fine means "only the currently selected user can do sound", from what you wrote too. Which, if you had bothered to read my use case with your brain on, you'd have noticed is not fine at all. OG. From mzerqung at 0pointer.de Wed Dec 19 11:07:44 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 12:07:44 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219104448.GA80218@dspnet.fr.eu.org> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> Message-ID: <20071219110744.GA16151@tango.0pointer.de> On Wed, 19.12.07 11:44, Olivier Galibert (galibert at pobox.com) wrote: > > That means, for now, you have to use the raw ALSA "spdif" device if > > you want to playback audio on spdif. That hasn't changed from pre-PA times. > > I can use alsa for everything, I know that already. That was not the > point of the email. > > If your answer to "how can PA be used to support my configuration" is > systematically "don't use PA", why are you working on PA in the first > place? Come on. The are a lot of thing PA doesn't do right now. Not just this one. However, there happen to be a couple of things PA can do very well. What kind of stupid game is this, anyway? You find cases where PA doesn't work without manual reconfigration. And then you ask me, and I say, "yes, it doesn't work", and then you tell me "yes, i thought so, PA is total crap." I you want we can play this game with swapped roles: I find a feature that software you wrote doesn't do and then I tell you "Your software sucks big time." It certainly would be a lot more fun for me that way! Also, in this case the bad support of SPDIF in PA is not really PA's fault. It's more ALSA's since it doesn't really have any (working) API for discovering if spdif is available and if it is exclusive to analog out. Also note, that PA supports spdif quite fine if you do manual reconfiguration in style of adding a single line to /etc/pulse/default.pa: load-module module-alsa-sink device=spdif:0 Oh, and it is also not the case that I wouldn't be aware of the messy SPDIF support right now, and that I wouldn't be working with the ALSA people to find a resolution. > > You should be using the normal fast-user-switching for that. > > So now gdm and using a panel is a fedora requirement for multiuser > support? We try our best to supply you with easy-to-use software for doing f-u-s. And all you do is telling us is that you refuse to use our software, but go on complaining that f-u-s doesn't work for you? How do you think we should be fixing this? I mean, it's hard to get this fixed for you if you don't want to use our code. Don't you think? The f-u-s code is open. You're welcome to hack up your one UI for it. That's what Free Software is all about: scracthing your own itches. We already supply you with a couple of UIs, if they are not good enough for you, then I guess you need to get your hands dirty yourself and teach us fools how a really good UI should look like. > > PA supports f-u-s just fine, as I think I already wrote about 555 > > times on this thread. > > Where fine means "only the currently selected user can do sound", from > what you wrote too. Which, if you had bothered to read my use case > with your brain on, you'd have noticed is not fine at all. Let's stop this stupid discussion now. I already wrote countless times on this thread: with some minimal reconfiguration you can get PA working for you, or can bypass it, whatever suits you best. And I already explained in detail why we chose to do multi-session support the way we are doing it. We tend to do our stuff for good reasons the way we do. And we explain them to anyone who asks. And we take suggestions. But in the end, the one who produces the code is ... the one who produces the code. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From caillon at redhat.com Wed Dec 19 11:51:40 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 19 Dec 2007 12:51:40 +0100 Subject: add eris-1.3.13 to the build root In-Reply-To: <4768CB80.5090003@kobold.org> References: <4768CB80.5090003@kobold.org> Message-ID: <476905CC.0@redhat.com> On 12/19/2007 08:42 AM, Wart wrote: > I need to rebuild sear with the latest eris package, but eris can't be > pushed to the updates repo yet because the current sear package depends > on the old package. > > Can someone from releng put eris-1.3.13 temporarily in the build root so > that I can rebuild sear and push both the updated eris and sear at the > same time? This sort of request should go to fedora-release-engineering at redhat.com Also, you didn't specify which buildroot it needs to be in (which is not obvious since you didn't provide a dist tag) From ibmalone at gmail.com Wed Dec 19 12:06:29 2007 From: ibmalone at gmail.com (Ian Malone) Date: Wed, 19 Dec 2007 12:06:29 +0000 Subject: This seems to be getting worse In-Reply-To: <1198028216.18986.143.camel@localhost> References: <1198028216.18986.143.camel@localhost> Message-ID: <47690945.6050303@gmail.com> Callum Lerwick wrote: > On Tue, 2007-12-18 at 19:49 -0500, Neal Becker wrote: >> Warning: don't show this to children >> http://fedora.org/ > > Licking cats? At least its not goatse.cx guy or tubgirl. > Although probably a bad idea, -- imalone From opensource at till.name Wed Dec 19 12:10:33 2007 From: opensource at till.name (Till Maas) Date: Wed, 19 Dec 2007 13:10:33 +0100 Subject: Mock and consolehelper In-Reply-To: References: Message-ID: <200712191310.44342.opensource@till.name> On Wednesday 19 December 2007 08:19:33 Kevin Kofler wrote: > I have noticed that mock in Rawhide has been changed to drop the SUID > helper, instead consolehelper is used to run the entire mock as root. IMHO, > this is a regression: > * It now means you have to know the root password to run mock. Before, it > was possible to give out mock access and only that simply by making the > user a member of the mockbuild group. Now the only way to do that is to > allow running all of mock as root, which probably opens up several ways to > get full root access from there. Older versions of mock already allow every user that is allowed to run it, i.e. is in the mockbuild group, to get root access: $ mock shell init mock-chroot> chmod u+s /bin/bash mock-chroot> exit exit ending done $ /var/lib/mock/fedora-7-i386/root/bin/bash -p 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 jwboyer at gmail.com Wed Dec 19 12:43:20 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 19 Dec 2007 06:43:20 -0600 Subject: add eris-1.3.13 to the build root In-Reply-To: <476905CC.0@redhat.com> References: <4768CB80.5090003@kobold.org> <476905CC.0@redhat.com> Message-ID: <20071219064320.2f7b4dd6@hansolo.jdub.homelinux.org> On Wed, 19 Dec 2007 12:51:40 +0100 Christopher Aillon wrote: > On 12/19/2007 08:42 AM, Wart wrote: > > I need to rebuild sear with the latest eris package, but eris can't be > > pushed to the updates repo yet because the current sear package depends > > on the old package. > > > > Can someone from releng put eris-1.3.13 temporarily in the build root so > > that I can rebuild sear and push both the updated eris and sear at the > > same time? > > This sort of request should go to fedora-release-engineering at redhat.com Er, rel-eng at fedoraproject.org josh From bnocera at redhat.com Wed Dec 19 13:42:27 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 19 Dec 2007 13:42:27 +0000 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198005355.3085.4.camel@space-ghost.verbum.private> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <20071218182629.GC28630@tango.0pointer.de> <20071218115845.569346ac@ghistelwchlohm.scrye.com> <1198005355.3085.4.camel@space-ghost.verbum.private> Message-ID: <1198071747.8815.82.camel@cookie.hadess.net> On Tue, 2007-12-18 at 14:15 -0500, Colin Walters wrote: > On Tue, 2007-12-18 at 11:58 -0700, Kevin Fenzi wrote: > > > Why not have a /etc/xdg/autostart/pulseaudio.desktop > > to start pulseaudio for user sessions? > > If that works, I agree that would be a better way to do it. We should > also delete the esd launching (and associated "preference") from GNOME. It was removed from the first build of F9 rawhide. From ssorce at redhat.com Wed Dec 19 14:18:46 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Dec 2007 09:18:46 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219103114.GA14958@tango.0pointer.de> References: <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> Message-ID: <1198073926.19318.96.camel@localhost.localdomain> On Wed, 2007-12-19 at 11:31 +0100, Lennart Poettering wrote: > On Wed, 19.12.07 12:12, Neil Thompson (abraxis at telkomsa.net) wrote: > > > > Also, I'd argue even if it worked before (which it didn't) the > > > behaviour exposed by PA+CK is the more correct one, from a security > > > perspective. And hence speaking of a "regression" in this area is very > > > adventurous. > > > > > > > Something that used to work without issues, doesn't any more...looks like > > a duck, walks like a duck... > > Sorry, but it *didn't* work before. > > By default the access mode of the dmix SHM is 0600. i.e. only a single > user ID may access the sound card at a time. Lennart, I am ok with the answers you gave, but here I can't agree with you. Previous behavior: user A play music, F-U-S, music keep playing. PA scenario: user A play music, F-U-S, music stop playing. I understand it make sense that the new scenario is the default for security reasons, I agree, but don't say there is no difference. > If you want to open up dmix to multiple users at the same time you > need to change it to 0666 or so, which is a security hole and needs > some non-trivial reconfiguration. Only if you have a mic, common on laptops, uncommon on desktops (just my 2c) > The reconfiguration necessary to open up PA to other users is a lot > simpler to do. Just copy a cookie file around. This require knowledge that is beyond normal users, if this is something users are expected to do, then a simple configuration dialog should be provided. > > And then the use case just gets dismissed. Paraphrasing..."the clueless newbie > > who doesn't really use her machine will be OK, and the other folks will just have > > to change the way they work". > > I didn't dismiss your use case at all. All I told you is that the kind > of setup you envision required non-trivial reconfiguration before, and > it requires reconfiguration now. So, calling this is a regression is > bogus. And yet it would be nice to make it possible to have the 2 major use cases working easily: A) Only the active session have access to sound B) Everybody have access to sound A big switch in the sound configuration window is all is needed (including scary warnings about the insecurity of option B). Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From david at lovesunix.net Wed Dec 19 14:21:35 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 19 Dec 2007 15:21:35 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> Message-ID: <1198074095.21251.2.camel@localhost.localdomain> Em Ter, 2007-12-18 ?s 14:18 -0700, rvinyard at cs.nmsu.edu escreveu: > > Josh Boyer (jwboyer at gmail.com) said: > >> Let the naming begin! > > > > So, Werewolf is a: > > > > - Fictional creature > > - Ancient: Griffin, Sphinx, Cerberus (yeah, that's not going to stick), > > Scylla, > > Chimaera, etc. > > - SciFi Movie/TV: Tauntaun, Tribble, Ewok, Faun, Dalek, etc. > > - Cryptozoology: Bigfoot, Loch Ness Monster, etc. > > > Chupacabra Are you absolutely sure that naming our pride and joy after something commonly known as "The mexican goatsucker" isn't... involving some undesirable images not to mention snide review comments. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From pertusus at free.fr Wed Dec 19 14:22:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 15:22:45 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219110744.GA16151@tango.0pointer.de> References: <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> Message-ID: <20071219142245.GB2526@free.fr> On Wed, Dec 19, 2007 at 12:07:44PM +0100, Lennart Poettering wrote: > > The f-u-s code is open. You're welcome to hack up your one UI for > it. That's what Free Software is all about: scracthing your own > itches. We already supply you with a couple of UIs, if they are not > good enough for you, then I guess you need to get your hands dirty > yourself and teach us fools how a really good UI should look > like. We don't have necessarily time to do such things. Many people in fedora are benevolent. Anyway why not do a pam module such that all the login systems (be it wdm, xdm, console login...) can benefit from it? We have a wondefully modular system for everything that can take place on login, this would ease life for a lot of people, and allow for choice of UI instead of tying those who don't have the money to pay programmers to UI they don't like. -- Pat From jkeating at redhat.com Wed Dec 19 14:25:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Dec 2007 09:25:25 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198073926.19318.96.camel@localhost.localdomain> References: <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> Message-ID: <20071219092525.6bbde9f8@redhat.com> On Wed, 19 Dec 2007 09:18:46 -0500 Simo Sorce wrote: > Lennart, > I am ok with the answers you gave, but here I can't agree with you. > > Previous behavior: > user A play music, F-U-S, music keep playing. > > PA scenario: > user A play music, F-U-S, music stop playing Previously was the user you fast switched to able to play anything? I think that's what Lennart was saying was broken. -- 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 jima at beer.tclug.org Wed Dec 19 14:26:57 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 19 Dec 2007 08:26:57 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <200712181055.00912.dennis@ausil.us> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181055.00912.dennis@ausil.us> Message-ID: On Tue, 18 Dec 2007, Dennis Gilmore wrote: > On Tuesday 18 December 2007, Simo Sorce wrote: >> Anubis [1]: >> >> Anubis is a mythological creature of human/canine form >> Werewolf is a mythological creature of human/canine form >> >> [1]: http://en.wikipedia.org/wiki/Anubis > > I like this suggestion :) One may have to look at Dennis's email headers to fully get this joke. Jima From mclasen at redhat.com Wed Dec 19 14:28:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Dec 2007 09:28:22 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219142245.GB2526@free.fr> References: <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> Message-ID: <1198074502.2809.4.camel@localhost.localdomain> On Wed, 2007-12-19 at 15:22 +0100, Patrice Dumas wrote: > On Wed, Dec 19, 2007 at 12:07:44PM +0100, Lennart Poettering wrote: > > > > The f-u-s code is open. You're welcome to hack up your one UI for > > it. That's what Free Software is all about: scracthing your own > > itches. We already supply you with a couple of UIs, if they are not > > good enough for you, then I guess you need to get your hands dirty > > yourself and teach us fools how a really good UI should look > > like. > > We don't have necessarily time to do such things. Many people in fedora > are benevolent. > > Anyway why not do a pam module such that all the login systems (be it > wdm, xdm, console login...) can benefit from it? We have a wondefully > modular system for everything that can take place on login, this would > ease life for a lot of people, and allow for choice of UI instead of > tying those who don't have the money to pay programmers to UI they don't > like. Don't let Nalin hear that... From pertusus at free.fr Wed Dec 19 14:48:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 15:48:49 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198074502.2809.4.camel@localhost.localdomain> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> Message-ID: <20071219144849.GC2526@free.fr> On Wed, Dec 19, 2007 at 09:28:22AM -0500, Matthias Clasen wrote: > > > > > We don't have necessarily time to do such things. Many people in fedora > > are benevolent. > > > > Anyway why not do a pam module such that all the login systems (be it > > wdm, xdm, console login...) can benefit from it? We have a wondefully > > modular system for everything that can take place on login, this would > > ease life for a lot of people, and allow for choice of UI instead of > > tying those who don't have the money to pay programmers to UI they don't > > like. > > > Don't let Nalin hear that... I don't really understand your comment. I still haven't got any answer on how to use adequately the pam_consolekit module, and a PA pam module is systematically taken down and we are asked to use gdm only. And the desktop people don't seem to care about those who would like to use pam to incorporate things on other login entry points than gdm. I am not saying that there is an issue with pam, but with the desktop people not wanting to use it. See for example https://bugzilla.redhat.com/show_bug.cgi?id=228110 and also https://bugzilla.redhat.com/show_bug.cgi?id=228079#c16 Now this is not necessarily a problem, one display manager to rule them all and avoiding using pam may also be a good choice (less duplication of work, less support). This is an important choice, however. -- Pat From jima at beer.tclug.org Wed Dec 19 14:50:46 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 19 Dec 2007 08:50:46 -0600 (CST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198074095.21251.2.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> Message-ID: On Wed, 19 Dec 2007, David Nielsen wrote: > Em Ter, 2007-12-18 ?s 14:18 -0700, rvinyard at cs.nmsu.edu escreveu: >> Chupacabra > > Are you absolutely sure that naming our pride and joy after something > commonly known as "The mexican goatsucker" isn't... involving some > undesirable images not to mention snide review comments. I can see it now. "Parents sometimes conjure the name Chupacabra to scare their children into obeying them. We can now do the same with Linux users, with the Fedora Project's latest release by the same name..." No thanks. Jima AAAA! El chupacabra got me! No, wait, that's the kitten. Oops. From mzerqung at 0pointer.de Wed Dec 19 15:02:24 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 16:02:24 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198073926.19318.96.camel@localhost.localdomain> References: <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> Message-ID: <20071219150224.GB28769@tango.0pointer.de> On Wed, 19.12.07 09:18, Simo Sorce (ssorce at redhat.com) wrote: > > If you want to open up dmix to multiple users at the same time you > > need to change it to 0666 or so, which is a security hole and needs > > some non-trivial reconfiguration. > > Only if you have a mic, common on laptops, uncommon on desktops (just my > 2c) Hmm? What does dmix have to do with microphones? > > The reconfiguration necessary to open up PA to other users is a lot > > simpler to do. Just copy a cookie file around. > > This require knowledge that is beyond normal users, if this is something > users are expected to do, then a simple configuration dialog should be > provided. Hmm? reconfiguring alsa is a big step more difficult than reconfiguring PA. > And yet it would be nice to make it possible to have the 2 major use > cases working easily: > A) Only the active session have access to sound > B) Everybody have access to sound > > A big switch in the sound configuration window is all is needed > (including scary warnings about the insecurity of option B). As mentioned before, adding this has been requested before and has been on my TODO list for while. However it is not a top priority for me. Why? Because with a little bit of manual configuration you can do this already. And the major work that is necessary to make this more streamlined isn't really justified by what little we gain by this in the short term. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 15:11:04 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 16:11:04 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219092525.6bbde9f8@redhat.com> References: <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219092525.6bbde9f8@redhat.com> Message-ID: <20071219151104.GC28769@tango.0pointer.de> On Wed, 19.12.07 09:25, Jesse Keating (jkeating at redhat.com) wrote: > On Wed, 19 Dec 2007 09:18:46 -0500 > Simo Sorce wrote: > > > Lennart, > > I am ok with the answers you gave, but here I can't agree with you. > > > > Previous behavior: > > user A play music, F-U-S, music keep playing. > > > > PA scenario: > > user A play music, F-U-S, music stop playing > > Previously was the user you fast switched to able to play anything? I > think that's what Lennart was saying was broken. Yes, exactly. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rdieter at math.unl.edu Wed Dec 19 15:12:33 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Dec 2007 09:12:33 -0600 Subject: nm-0.7 (final) release, schedule? Message-ID: Per http://mail.gnome.org/archives/networkmanager-list/2007-December/msg00294.html anyone have a notion of a nm-0.7 release schedule? If nm-0.7 is good enough to be included in fedora(8), it ought to be close to good enough for a formal release, no? Not having a release or a visible schedule has some bad side-effects, primarily (from my pov) that downstream-apps and distros don't use it yet. Of course, I'm asking out of selfishness, since a lack of release/schedule is the primary reason that kde4 (and knetworkmanager) doesn't yet support nm-0.7. -- Rex From Michael_E_Brown at dell.com Wed Dec 19 15:24:49 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 09:24:49 -0600 Subject: Mock and consolehelper In-Reply-To: References: Message-ID: <20071219152448.GA5428@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 07:19:33AM +0000, Kevin Kofler wrote: > I have noticed that mock in Rawhide has been changed to drop the SUID helper, > instead consolehelper is used to run the entire mock as root. IMHO, this is a > regression: > * It now means you have to know the root password to run mock. Before, it was > possible to give out mock access and only that simply by making the user a > member of the mockbuild group. Now the only way to do that is to allow running > all of mock as root, which probably opens up several ways to get full root > access from there. Mock in rawhide is configured by default to run exactly like mock 0.8 in F7/F8, ie. if you are in the 'mock' group you can run it by default. Using consolehelper we now have the additional enhancement that people not in the 'mock' group can run mock if they know the root password, just like all of the other utilities that use consolehelper. > * It means mock has to be run interactively. What are the implications of this > on the builders? Will they have to install all of mock SUID root, or set up > consolehelper in a way which effectively does the same? Untrue. > * It reduces security, as instead of a small helper doing only a few controlled > operations, you now run all of mock as root. Sure, it's Python, so buffer > overflows probably can't happen, but still, trigger any bug in mock with a > trojaned SRPM and you have root. A small amount of research before we go off the deep end, please? Mock has two main security concerns: 1) is it safe to let untrusted users run mock, and 2) is it safe for a trusted user to compile untrusted code using mock. As a project, the mock development team has stated that (1) is not a current goal for the project, and that we would strive to achieve (2), but there are several known holes that make 2 difficult to acheive. Mock is already KNOWN TO BE UNSAFE TO RUN BY UNTRUSTED USERS, and this has been stated time and time again. If you run a shell server for a college, dont give those users access to mock. There are *many* paths by which an untrusted user could easily elevate their privileges. It is not a goal of mock to be runnable by untrusted users. This is why access to mock is protected by the 'mock' group or knowledge of the root password (in rawhide). Even considering the above, we have taken steps inside the source to minimize the privileges as much as possible. We drop privs before copying the srpm and before setting up output logs. We drop privs for the actual rpm build. This should provide a high (but not impregnable) degree of protection for trusted users compiling untrusted code. The new design (present in mock 0.8 and higher). Actually allows us much finer access control, more auditable, easier to program, and numerous other benefits as compared to the old mock <= 0.7 codebase. -- Michael From mclasen at redhat.com Wed Dec 19 15:26:14 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Dec 2007 10:26:14 -0500 Subject: nm-0.7 (final) release, schedule? In-Reply-To: References: Message-ID: <1198077974.2809.15.camel@localhost.localdomain> On Wed, 2007-12-19 at 09:12 -0600, Rex Dieter wrote: > Per > http://mail.gnome.org/archives/networkmanager-list/2007-December/msg00294.html > anyone have a notion of a nm-0.7 release schedule? > > If nm-0.7 is good enough to be included in fedora(8), it ought to be close > to good enough for a formal release, no? > > Not having a release or a visible schedule has some bad side-effects, > primarily (from my pov) that downstream-apps and distros don't use it yet. > > Of course, I'm asking out of selfishness, since a lack of release/schedule > is the primary reason that kde4 (and knetworkmanager) doesn't yet support > nm-0.7. em Why do you think asking here will give better results than asking upstream ? Anyway, the plan going into F9 was to get NM 0.7 out before the end of the year. This may not quite work out that way, since a few things (dialup support, multiple active devices, system settings) are not quite done yet, but we are making progress, as far as I know. Dan may be able to provide more details. Matthias From mzerqung at 0pointer.de Wed Dec 19 15:37:27 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 16:37:27 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219142245.GB2526@free.fr> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> Message-ID: <20071219153727.GD28769@tango.0pointer.de> On Wed, 19.12.07 15:22, Patrice Dumas (pertusus at free.fr) wrote: > On Wed, Dec 19, 2007 at 12:07:44PM +0100, Lennart Poettering wrote: > > > > The f-u-s code is open. You're welcome to hack up your one UI for > > it. That's what Free Software is all about: scracthing your own > > itches. We already supply you with a couple of UIs, if they are not > > good enough for you, then I guess you need to get your hands dirty > > yourself and teach us fools how a really good UI should look > > like. > > We don't have necessarily time to do such things. Many people in fedora > are benevolent. I am very benevolent, too. ;-) > Anyway why not do a pam module such that all the login systems (be it > wdm, xdm, console login...) can benefit from it? We have a wondefully > modular system for everything that can take place on login, this would > ease life for a lot of people, and allow for choice of UI instead of > tying those who don't have the money to pay programmers to UI they don't > like. PAM is about authentication. It's just not the place to start daemons. I mean, why should we start it there? We don't start dbus from there either, or X11, or nm-applet, or gnome-volume-manager or seahorse-agent or gnome-screensaver or vino-server or anything else that runs in the usual login session. And why don't we start those things from PAM? Because we already start them from the session manager, in the appropriate order. Because starting and monitoring processes is just what a session manager is good in. A session manager is not good for authenticating users, and PAM is not great for starting/monitoring/stopping processes. So we leave PAM the authentication and session preparation stuff, and leave session management to the session manager. Also, PAM is system configuration. If we'd start PA from there, then the user would have no way to disable PA unless he's root. And, as it seems, some people are very eager to do just that. ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nicolas.mailhot at laposte.net Wed Dec 19 15:44:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Dec 2007 16:44:41 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219150224.GB28769@tango.0pointer.de> References: <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> Message-ID: <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> Le Mer 19 d?cembre 2007 16:02, Lennart Poettering a ?crit : > On Wed, 19.12.07 09:18, Simo Sorce (ssorce at redhat.com) wrote: > >> > If you want to open up dmix to multiple users at the same time you >> > need to change it to 0666 or so, which is a security hole and >> needs >> > some non-trivial reconfiguration. >> >> Only if you have a mic, common on laptops, uncommon on desktops >> (just my >> 2c) > > Hmm? What does dmix have to do with microphones? You raised the security argument. Mere mortals like Simo only see actual potential security problems with microphones. (running a wide open dmix is a small security problem but no one here is asking to mix the active desktop session beeps with the background music started out of this session) Note that: - being able to cut audio resources from other applications just by logging in is a DoS in security-speak. - if you can log in a system there are many more attack vectors than audio devices (let alone that most of the time people will have also physical access so they can leave a small recorder next to the computer) - pushing many users to hack manually around rigid security rules that forbid common use-cases has not been known to improve security overall. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Dec 19 15:51:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Dec 2007 16:51:44 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219153727.GD28769@tango.0pointer.de> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> Message-ID: <57376.192.54.193.53.1198079504.squirrel@rousalka.dyndns.org> Le Mer 19 d?cembre 2007 16:37, Lennart Poettering a ?crit : > Also, PAM is system configuration. If we'd start PA from there, then > the user would have no way to disable PA unless he's root. And, as it > seems, some people are very eager to do just that. ;-) Circular argument I don't want to do A in B that would allow C C users should just disable B B can not do A because then C users can't disable B as is their wish -- Nicolas Mailhot From caillon at redhat.com Wed Dec 19 15:55:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 19 Dec 2007 16:55:05 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219144849.GC2526@free.fr> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219144849.GC2526@free.fr> Message-ID: <47693ED9.2020203@redhat.com> On 12/19/2007 03:48 PM, Patrice Dumas wrote: > On Wed, Dec 19, 2007 at 09:28:22AM -0500, Matthias Clasen wrote: >>> We don't have necessarily time to do such things. Many people in fedora >>> are benevolent. >>> >>> Anyway why not do a pam module such that all the login systems (be it >>> wdm, xdm, console login...) can benefit from it? We have a wondefully >>> modular system for everything that can take place on login, this would >>> ease life for a lot of people, and allow for choice of UI instead of >>> tying those who don't have the money to pay programmers to UI they don't >>> like. >> >> Don't let Nalin hear that... > > I don't really understand your comment. Nalin (the pam maintainer in Fedora), is very much against using pam modules in non-authentication ways. Yes, we know that other things do it. That doesn't mean we should keep doing it. From pertusus at free.fr Wed Dec 19 16:06:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 17:06:34 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219153727.GD28769@tango.0pointer.de> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> Message-ID: <20071219160634.GE2526@free.fr> On Wed, Dec 19, 2007 at 04:37:27PM +0100, Lennart Poettering wrote: > > PAM is about authentication. It's just not the place to start > daemons. I mean, why should we start it there? We don't start dbus from > there either, or X11, or nm-applet, or gnome-volume-manager or > seahorse-agent or gnome-screensaver or vino-server or anything else > that runs in the usual login session. Except for dbus, all the examples you cite are display specific stuff that should not be started from pam anyway (they could but there is no much point). A relevant case you could have done is starting ssh-agent. It is indeed not display specific and it is done in the session script. But there is also a pam module pam_ssh that can launch ssh-agent in the pam session phase. > And why don't we start those things from PAM? Because we already start > them from the session manager, in the appropriate order. Because All the login paths don't have a session manager. PAM start things in the appropriate order, that is in the order they appear on the session stack. > starting and monitoring processes is just what a session manager is > good in. A session manager is not good for authenticating users, and > PAM is not great for starting/monitoring/stopping processes. So we PAM is great for starting (and maybe stopping) session-wide processes. > leave PAM the authentication and session preparation stuff, and leave > session management to the session manager. PAM can also be used for session stuff. > Also, PAM is system configuration. If we'd start PA from there, then > the user would have no way to disable PA unless he's root. And, as it > seems, some people are very eager to do just that. ;-) Being able to have a policy to start PA set up by the administrator is something that is interesting. Now it is optional, of course, not all administrator would want to impose that, still something nice to have. It would really simplify the PA support in anything else than gdm, and allow for local administrator customization. Of course, the priority of such stuff could be low, but, in my opinion, not considering it is not nice to those who like to administer login and session stuff through pam. -- Pat From mzerqung at 0pointer.de Wed Dec 19 16:07:50 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 17:07:50 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> References: <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> Message-ID: <20071219160750.GE28769@tango.0pointer.de> On Wed, 19.12.07 16:44, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > Hmm? What does dmix have to do with microphones? > > You raised the security argument. Mere mortals like Simo only see > actual potential security problems with microphones. (running a wide > open dmix is a small security problem but no one here is asking to mix > the active desktop session beeps with the background music started out > of this session) Uh? dmix is not involved with recording audio. However, dmix has two problems if you open it up for other users: you can use it to capture whatever the other users play [1], and you get more access to the other processe's internals than is safe. I.e. you can make the other process freeze, burn CPU and so on. > Note that: > - being able to cut audio resources from other applications just by > logging in is a DoS in security-speak. Ah! that's good. The last time I tried to run "rm /etc/fstab" as a normal user all I got back was "Access denied". I never came to the conclusion that this should be considered a "Denial of service". But indeed, we should consider all "Access denied" errors to be "Denial of service" exploits. Let me prepare those mails to bugtraq... > - if you can log in a system there are many more attack vectors than > audio devices (let alone that most of the time people will have also > physical access so they can leave a small recorder next to the > computer) This. Is. Just. Great. > - pushing many users to hack manually around rigid security rules that > forbid common use-cases has not been known to improve security > overall. It. Gets. Even. Better. Lennart Footnotes: [1] And I certainly don't want other people using my machine to spy on my VoIP calls or listen into the audio track of my very private porn videos! ;-) -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pertusus at free.fr Wed Dec 19 16:07:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 17:07:45 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <47693ED9.2020203@redhat.com> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219144849.GC2526@free.fr> <47693ED9.2020203@redhat.com> Message-ID: <20071219160745.GF2526@free.fr> On Wed, Dec 19, 2007 at 04:55:05PM +0100, Christopher Aillon wrote: > > Nalin (the pam maintainer in Fedora), is very much against using pam > modules in non-authentication ways. What is the rationale? -- Pat From mzerqung at 0pointer.de Wed Dec 19 16:12:10 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 17:12:10 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <57376.192.54.193.53.1198079504.squirrel@rousalka.dyndns.org> References: <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> <57376.192.54.193.53.1198079504.squirrel@rousalka.dyndns.org> Message-ID: <20071219161210.GF28769@tango.0pointer.de> On Wed, 19.12.07 16:51, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote: > > > Le Mer 19 d?cembre 2007 16:37, Lennart Poettering a ?crit : > > > Also, PAM is system configuration. If we'd start PA from there, then > > the user would have no way to disable PA unless he's root. And, as it > > seems, some people are very eager to do just that. ;-) > > Circular argument > > I don't want to do A in B that would allow C > C users should just disable B > B can not do A because then C users can't disable B as is their wish Confusing argument A equals "Starting daemon"? B equals "PAM"? C equlas "Your setup"? Hmm, no, probably not, because I don't think you want to disable PAM, do you? I see no circles. Either you're confused, or I am. I prefer to believe it's not me... ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nalin at redhat.com Wed Dec 19 16:16:41 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 19 Dec 2007 11:16:41 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198074502.2809.4.camel@localhost.localdomain> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> Message-ID: <20071219161641.GB17216@redhat.com> On Wed, Dec 19, 2007 at 09:28:22AM -0500, Matthias Clasen wrote: > On Wed, 2007-12-19 at 15:22 +0100, Patrice Dumas wrote: > > Anyway why not do a pam module such that all the login systems (be it > > wdm, xdm, console login...) can benefit from it? We have a wondefully > > modular system for everything that can take place on login, this would > > ease life for a lot of people, and allow for choice of UI instead of > > tying those who don't have the money to pay programmers to UI they don't > > like. > > Don't let Nalin hear that... I recommend against using PAM as a place to be launching arbitrary processes. The environment in which a module runs is just way too underspecified to be dependable for doing that. Environment, privilege level, signal handling, none of it's guaranteed by the specification [1]. If you fork a process (from a module, which is loaded by a shared library, with the calling application having no idea of what to expect), you have to be _very_ careful about how you do it, and how you handle its termination, and how all of that interacts with what the calling appliction's already doing. Even for the modules which are careful about this, we still run into bugs. And many modules aren't careful. Sure, maybe we need something that'll serve the function of launching random stuff for you when you log in, but I don't think that PAM is it. HTH, Nalin [1] http://www.opengroup.org/tech/rfc/mirror-rfc/rfc86.0.txt From paul at all-the-johnsons.co.uk Wed Dec 19 16:17:14 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 19 Dec 2007 16:17:14 +0000 Subject: Monodevelop 0.18 Message-ID: <1198081034.4722.11.camel@T7.Linux> Hi, Monodevelop 1.0 beta 3 is now out, however it relies on mono-addins. I've built mono-addins locally and packaged it, however I am unable to log into my ftp server at all-the-johnsons.co.uk for some reason. Can anyone host it for a while so I can get it approved and entered into rawhide? I just need ftp access. 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 nalin at redhat.com Wed Dec 19 16:18:58 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 19 Dec 2007 11:18:58 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <47693ED9.2020203@redhat.com> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219144849.GC2526@free.fr> <47693ED9.2020203@redhat.com> Message-ID: <20071219161858.GC17216@redhat.com> On Wed, Dec 19, 2007 at 04:55:05PM +0100, Christopher Aillon wrote: > Nalin (the pam maintainer in Fedora), is very much against using pam > modules in non-authentication ways. Tomas Mraz has been handling PAM maintenance for a few years now, I think rather well. Nalin From skvidal at fedoraproject.org Wed Dec 19 16:22:05 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 11:22:05 -0500 Subject: Hackfests at Fudcon Message-ID: <1198081325.13693.29.camel@cutter> Hey folks, So, I drew the short straw and I get to help organize the hackfests. It looks like we?ll have 5 rooms and probably lots of miscellaneous hallway/lobby space. We?ll call the rooms: ABCDE. If you have a hackfest you?d like to start up, let me know, I?ll update the wiki and see about organizing the rooms/times. What do folks think about 2 hackfest sessions per day one before lunch (caffeinated) and one after lunch (fed and maybe more caffeinated). So sessions in rooms can be: 1A, 1B, 1C, 1D, 1E 2A, 2B, 2C, 2D, 2E on friday and sunday. and then everything else that can?t get a room. I?m sure some hackfests will take longer than one session and I?m sure sunday afternoon a lot of people will be leaving to go home, but I?d like to fill things up as much as possible. So email your ideas and plans. Thanks, -sv From tmraz at redhat.com Wed Dec 19 16:25:55 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 19 Dec 2007 17:25:55 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <47693ED9.2020203@redhat.com> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219144849.GC2526@free.fr> <47693ED9.2020203@redhat.com> Message-ID: <1198081555.12586.55.camel@vespa.frost.loc> On Wed, 2007-12-19 at 16:55 +0100, Christopher Aillon wrote: > On 12/19/2007 03:48 PM, Patrice Dumas wrote: > > On Wed, Dec 19, 2007 at 09:28:22AM -0500, Matthias Clasen wrote: > >>> We don't have necessarily time to do such things. Many people in fedora > >>> are benevolent. > >>> > >>> Anyway why not do a pam module such that all the login systems (be it > >>> wdm, xdm, console login...) can benefit from it? We have a wondefully > >>> modular system for everything that can take place on login, this would > >>> ease life for a lot of people, and allow for choice of UI instead of > >>> tying those who don't have the money to pay programmers to UI they don't > >>> like. > >> > >> Don't let Nalin hear that... > > > > I don't really understand your comment. > > Nalin (the pam maintainer in Fedora), is very much against using pam > modules in non-authentication ways. Yes, we know that other things do > it. That doesn't mean we should keep doing it. Hmm, I have been the pam maintainer in Fedora (and RHEL) already for 3 years. Nalin was the previous maintainer. I'm not really sure what Nalin means by using pam modules in non-authentication ways and which problems are brought by such modules. Pulseaudio could be probably started by pam_exec module. But if it should run under the uid/gid of the user it would be more appropriate to run it from the user's login session directly. Running things from PAM modules should be reserved for things which require root priviledges. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jkeating at redhat.com Wed Dec 19 16:28:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Dec 2007 11:28:01 -0500 Subject: Monodevelop 0.18 In-Reply-To: <1198081034.4722.11.camel@T7.Linux> References: <1198081034.4722.11.camel@T7.Linux> Message-ID: <20071219112801.4bfee8bf@redhat.com> On Wed, 19 Dec 2007 16:17:14 +0000 Paul wrote: > Monodevelop 1.0 beta 3 is now out, however it relies on mono-addins. > I've built mono-addins locally and packaged it, however I am unable to > log into my ftp server at all-the-johnsons.co.uk for some reason. > > Can anyone host it for a while so I can get it approved and entered > into rawhide? I just need ftp access. You can use fedorapeople.org for this. Every maintainer gets webspace there. You use ssh to get to it (sftp if you prefer). Place contents in your public_html/ directory and it'll show up at http://.fedorapeople.org/ -- 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 tmraz at redhat.com Wed Dec 19 16:30:31 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 19 Dec 2007 17:30:31 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219161641.GB17216@redhat.com> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219161641.GB17216@redhat.com> Message-ID: <1198081831.12586.60.camel@vespa.frost.loc> On Wed, 2007-12-19 at 11:16 -0500, Nalin Dahyabhai wrote: > I recommend against using PAM as a place to be launching arbitrary > processes. The environment in which a module runs is just way too > underspecified to be dependable for doing that. > > Environment, privilege level, signal handling, none of it's guaranteed > by the specification [1]. If you fork a process (from a module, which > is loaded by a shared library, with the calling application having no > idea of what to expect), you have to be _very_ careful about how you do > it, and how you handle its termination, and how all of that interacts > with what the calling appliction's already doing. Exactly. > Even for the modules which are careful about this, we still run into > bugs. And many modules aren't careful. True. Although it doesn't mean that a module cannot be written safely and carefully. > Sure, maybe we need something that'll serve the function of launching > random stuff for you when you log in, but I don't think that PAM is it. As I said in the other mail PAM might be it if you really need a root access but otherwise I agree. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mzerqung at 0pointer.de Wed Dec 19 16:38:04 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 17:38:04 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219160634.GE2526@free.fr> References: <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> <20071219160634.GE2526@free.fr> Message-ID: <20071219163804.GG28769@tango.0pointer.de> On Wed, 19.12.07 17:06, Patrice Dumas (pertusus at free.fr) wrote: > > starting and monitoring processes is just what a session manager is > > good in. A session manager is not good for authenticating users, and > > PAM is not great for starting/monitoring/stopping processes. So we > > PAM is great for starting (and maybe stopping) session-wide > processes. Not really. What we really want is some kind of init-like babysitter as the session manager. Something that looks after processes, starts them, stops them, restarts them when they die, handles login/logout, maintains their startup order, supervises RT cpu load, kills misbehaving processes, sets resource limits, nice levels, handles core files, allows control via D-Bus, and so on and so on. Basically what a good system init process would do for system daemons, but for user/session daemons and other processes. I try to push Scott Remnant with his InitKit into that direction. Right now, every single user/session daemon behaves differently. Some daemonize properly (which is a bad thing), some don't. Some do their own logging, some don't. Some are started via XSM, some via XDG autostart, some are run directly by gs. So, what we really want is a central daemon which treats all those daemons the same, and makes sure they are started in the right order, and that it is waited that they fully started up before we get to the next process. While the dependency trees are certainly much simpler for GNOME sessions than for system bootup it is basically the same problem, so it would be great to handle both the same way by the same code. Now, we don't have such a cool session daemon right now. However, moving things into PAM is definitely the wrong direction. Because in PAM you can only hook code when the session starts and when the session ends. A session daemon like that however needs to constantly monitor all its processes, and thus needs to be running all the time. Now, of course you can fork this monitoring daemon away from the PAM session login code and kill it on logout. But if you do that you are mixing the code that makes up the session with the code that sets up the session. More correct than running PA and any number of other auxiliary daemons from the PAM hooks would be to call the session manager with special settings for the console from the login process, instead of /bin/bash directly. i.e. replace the shell in /etc/passwd by /usr/bin/initkit or suchlike. However, that's definitely a controversial issue. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From alan at redhat.com Wed Dec 19 16:43:18 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Dec 2007 11:43:18 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198027755.18986.140.camel@localhost> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> <1198027755.18986.140.camel@localhost> Message-ID: <20071219164318.GA2662@devserv.devel.redhat.com> On Tue, Dec 18, 2007 at 07:29:15PM -0600, Callum Lerwick wrote: > > How about Vampire? The same link as above. > > World of Darkness anyone? Oh please no > I guess that's treading kind of close to a trademark minefield. (The > Link Is Not WoD Really Its Not!) Not that they ever respected IPR too much since they happily lifted AberMUD without credit From pertusus at free.fr Wed Dec 19 16:42:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 17:42:40 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219161641.GB17216@redhat.com> References: <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219161641.GB17216@redhat.com> Message-ID: <20071219164240.GH2526@free.fr> On Wed, Dec 19, 2007 at 11:16:41AM -0500, Nalin Dahyabhai wrote: > > I recommend against using PAM as a place to be launching arbitrary > processes. The environment in which a module runs is just way too > underspecified to be dependable for doing that. It is not arbitrary processes, and it is not relevant for all pam modules, only for those that corresponds with login (like login, gdm, wdm, ssh...). > Environment, privilege level, signal handling, none of it's guaranteed > by the specification [1]. If you fork a process (from a module, which Is it an issue for PA? Also pam_ssh just does that and I don't know about any issue with pam_ssh (well, any issue related with strating ssh-agent and setting the environement variables). > is loaded by a shared library, with the calling application having no > idea of what to expect), you have to be _very_ careful about how you do > it, and how you handle its termination, and how all of that interacts > with what the calling appliction's already doing. In this case it is only for logins, not a module to be used from a random application (or at the own administrator risk). > Even for the modules which are careful about this, we still run into > bugs. And many modules aren't careful. We can assume that we are careful, can't we? > Sure, maybe we need something that'll serve the function of launching > random stuff for you when you log in, but I don't think that PAM is it. Nobody thinks that. But PAM allows to run some login wide stuff, with modularity and under administrator control, and hook in any login program. This may not be the perfect place to start PA, but it is still better than starting it only in gdm. Maybe the X session script is better, but the issue with session script (in /etc/X11/xinit/xinitrc-common) is that it is only for X, and it is not modular. The interest of pam is that the administrator may decide which login path uses it. -- Pat From tibbs at math.uh.edu Wed Dec 19 16:47:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2007 10:47:16 -0600 Subject: Hackfests at Fudcon In-Reply-To: <1198081325.13693.29.camel@cutter> References: <1198081325.13693.29.camel@cutter> Message-ID: >>>>> "sv" == seth vidal writes: sv> We?ll call the rooms: ABCDE. If you have a hackfest you?d like to sv> start up, let me know, I?ll update the wiki and see about sv> organizing the rooms/times. It would be good to do a review process brainstorm at some point; I added this to the barcamp page a while back. Probably no real hacking, of course. - J< From nicolas.mailhot at laposte.net Wed Dec 19 16:49:05 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Dec 2007 17:49:05 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219160750.GE28769@tango.0pointer.de> References: <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> <20071219160750.GE28769@tango.0pointer.de> Message-ID: <56627.192.54.193.53.1198082945.squirrel@rousalka.dyndns.org> Le Mer 19 d?cembre 2007 17:07, Lennart Poettering a ?crit : > This. Is. Just. Great. I understand Simo. You don't. That means Simo made the effort to be understood by me, and I made the effort to understand him. Are we all fools because our questions do not correspond to the answers you've got ready? It takes two to get a useful discussion started. Can we get something else than your answerphone? or should we end this turing test parody? -- Nicolas Mailhot From jprindiv at redhat.com Wed Dec 19 16:52:02 2007 From: jprindiv at redhat.com (Jon Prindiville) Date: Wed, 19 Dec 2007 11:52:02 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> Message-ID: <47694C32.5040000@redhat.com> Yaakov Nemoy wrote: > Fedora X, then Fedora "ours goes to" XI I prefer Fedora "OS" X From mackay_d at bellsouth.net Wed Dec 19 16:51:48 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Wed, 19 Dec 2007 10:51:48 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198011092.12620.10.camel@rousalka.dyndns.org> References: <1197905044.2937.21.camel@space-ghost.verbum.private> <20071217153406.GJ18186@free.fr> <20071217235706.GG3559@tango.0pointer.de> <20071218000635.GA13824@free.fr> <604aa7910712171621k1c8924dbi67cfa3297a33593b@mail.gmail.com> <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <1198011092.12620.10.camel@rousalka.dyndns.org> Message-ID: <1198083109.13167.6.camel@vorpal.macdev.com> On Tue, 2007-12-18 at 21:51 +0100, Nicolas Mailhot wrote: > Because audio cabling is static and audio devices are at the same stage > today as non-networked printers were two decade ago. There are systems > connected to audio devices by virtue of being near the audio devices, > and there is no 1:1 relashionship between the user sitting on the local > system in the current dekstop session and the user making use of audio > devices. > > It's perfectly legitimate to have a desktop system sitting in the living > room that simultaneously plays a DVD for one user on the TV/projector > output, records analog video for another through PVR card, while a third > is connected in dekstop session and checks his mails or does some quick > browsing. The problem that you're discussing centers more around poorly designed video capture cards than audio capability. The Hauppage PVR-150 and PVR-350 cards (and probably others) don't require the use of the sound card to record audio. Dave From caillon at redhat.com Wed Dec 19 16:54:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 19 Dec 2007 17:54:56 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198081555.12586.55.camel@vespa.frost.loc> References: <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219144849.GC2526@free.fr> <47693ED9.2020203@redhat.com> <1198081555.12586.55.camel@vespa.frost.loc> Message-ID: <47694CE0.8090307@redhat.com> On 12/19/2007 05:25 PM, Tomas Mraz wrote: > Hmm, I have been the pam maintainer in Fedora (and RHEL) already for 3 > years. Nalin was the previous maintainer. I'm not really sure what Nalin > means by using pam modules in non-authentication ways and which problems > are brought by such modules. Oops, my bad. I've heard Nalin complain so many times about this issue that it's all melting together as to who does what. Sorry about that. :-) From alan at redhat.com Wed Dec 19 16:58:43 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Dec 2007 11:58:43 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> Message-ID: <20071219165843.GB2662@devserv.devel.redhat.com> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: > into obeying them. We can now do the same with Linux users, with the > Fedora Project's latest release by the same name..." Some more suggestions "sulphur" "mayonaisse" (like werewolves they react badly with silver) From pertusus at free.fr Wed Dec 19 17:03:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 18:03:57 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219163804.GG28769@tango.0pointer.de> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> <20071219160634.GE2526@free.fr> <20071219163804.GG28769@tango.0pointer.de> Message-ID: <20071219170357.GI2526@free.fr> On Wed, Dec 19, 2007 at 05:38:04PM +0100, Lennart Poettering wrote: > On Wed, 19.12.07 17:06, Patrice Dumas (pertusus at free.fr) wrote: > > > > starting and monitoring processes is just what a session manager is > > > good in. A session manager is not good for authenticating users, and > > > PAM is not great for starting/monitoring/stopping processes. So we > > > > PAM is great for starting (and maybe stopping) session-wide > > processes. > > Not really. > > What we really want is some kind of init-like babysitter as the > session manager. Something that looks after processes, starts them, > stops them, restarts them when they die, handles login/logout, > maintains their startup order, supervises RT cpu load, kills > misbehaving processes, sets resource limits, nice levels, handles core > files, allows control via D-Bus, and so on and so on. Basically what a > good system init process would do for system daemons, but for > user/session daemons and other processes. I try to push Scott > Remnant with his InitKit into that direction. Urg... This seems a bit too much, that time ;-). something that launches scripts in a given order at start and stop would be enough in my opinion. But with a possibility of modularity and per-login possible configuration. > Right now, every single user/session daemon behaves differently. Some > daemonize properly (which is a bad thing), some don't. Some do their > own logging, some don't. Some are started via XSM, some via XDG > autostart, some are run directly by gs. So, what we really want is a > central daemon which treats all those daemons the same, and makes sure > they are started in the right order, and that it is waited that they > fully started up before we get to the next process. While the > dependency trees are certainly much simpler for GNOME sessions than > for system bootup it is basically the same problem, so it would be > great to handle both the same way by the same code. System bootup seems more complex to me, but why not have some manager that can be used for both, indeed (as long as it is not mandatory). > Now, we don't have such a cool session daemon right now. However, > moving things into PAM is definitely the wrong direction. Because in > PAM you can only hook code when the session starts and when the > session ends. A session daemon like that however needs to constantly > monitor all its processes, and thus needs to be running all the time. You mean must be restarted when it died? > Now, of course you can fork this monitoring daemon away from the PAM > session login code and kill it on logout. But if you do that you are > mixing the code that makes up the session with the code that sets up > the session. I can't see why this couln't be possible. > More correct than running PA and any number of other auxiliary daemons > from the PAM hooks would be to call the session manager with special > settings for the console from the login process, instead of /bin/bash > directly. i.e. replace the shell in /etc/passwd by /usr/bin/initkit or > suchlike. However, that's definitely a controversial issue. It would be nice to have many way of doing it. Including as a shell, from X init scripts, from pam, from window manager, and so on and so forth. Still, currently, the only modular place where per login stuff can be launched at the administrator will is PAM. -- Pat From snecklifter at gmail.com Wed Dec 19 17:06:00 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 19 Dec 2007 17:06:00 +0000 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071219165843.GB2662@devserv.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> Message-ID: <47694F78.3000707@gmail.com> Alan Cox wrote: > On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >> into obeying them. We can now do the same with Linux users, with the >> Fedora Project's latest release by the same name..." > > > Some more suggestions > > "sulphur" > "mayonaisse" > > (like werewolves they react badly with silver) > > Didn't the Lone Ranger use silver bullets? His horse was called Silver. Nice Rawhide connection there... Fedora 9 "The Lone Ranger" - leading the fight for freedom etc. etc. Ugh. From nalin at redhat.com Wed Dec 19 17:10:26 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 19 Dec 2007 12:10:26 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219164240.GH2526@free.fr> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219161641.GB17216@redhat.com> <20071219164240.GH2526@free.fr> Message-ID: <20071219171026.GD17216@redhat.com> On Wed, Dec 19, 2007 at 05:42:40PM +0100, Patrice Dumas wrote: > On Wed, Dec 19, 2007 at 11:16:41AM -0500, Nalin Dahyabhai wrote: > > I recommend against using PAM as a place to be launching arbitrary > > processes. The environment in which a module runs is just way too > > underspecified to be dependable for doing that. > > It is not arbitrary processes, and it is not relevant for all pam > modules, only for those that corresponds with login (like login, gdm, > wdm, ssh...). That means you can probably assume you're running as root, but I don't see that it simplifies the problem beyond that. > > Environment, privilege level, signal handling, none of it's guaranteed > > by the specification [1]. If you fork a process (from a module, which > > Is it an issue for PA? I couldn't say. Maybe. Lennart's going to know more about that than I do, I think. > Also pam_ssh just does that and I don't know about any issue with > pam_ssh (well, any issue related with strating ssh-agent and setting the > environement variables). > > > is loaded by a shared library, with the calling application having no > > idea of what to expect), you have to be _very_ careful about how you do > > it, and how you handle its termination, and how all of that interacts > > with what the calling appliction's already doing. > > In this case it is only for logins, not a module to be used from a > random application (or at the own administrator risk). I'm not sure I understand what you're saying here. I think you're suggesting that for the subset of PAM-aware applications which log a user in, that we can assume some specifics about the execution environment, and I'd disagree with that. > > Even for the modules which are careful about this, we still run into > > bugs. And many modules aren't careful. > > We can assume that we are careful, can't we? In this case? I don't know -- if something breaks now, I'm not the person who gets asked to fix it. I used to be, and to put it bluntly, it sucked. And I'll freely admit that it's colored my perception. > > Sure, maybe we need something that'll serve the function of launching > > random stuff for you when you log in, but I don't think that PAM is it. > > Nobody thinks that. But PAM allows to run some login wide stuff, with > modularity and under administrator control, and hook in any login > program. This may not be the perfect place to start PA, but it is still > better than starting it only in gdm. Maybe the X session script is > better, but the issue with session script (in > /etc/X11/xinit/xinitrc-common) is that it is only for X, and it is not > modular. The interest of pam is that the administrator may decide which > login path uses it. It may be better in terms of configurability, but I don't think it's the right place to do it. I'm not against some other means of doing exactly that (and I think we both agree that we'd like *something* like that), but I think that PAM is an unsafe place to do it. Cheers, Nalin From alan at clueserver.org Wed Dec 19 17:12:11 2007 From: alan at clueserver.org (Alan) Date: Wed, 19 Dec 2007 09:12:11 -0800 (PST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071219165843.GB2662@devserv.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> Message-ID: <54914.198.182.194.170.1198084331.squirrel@clueserver.org> > On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >> into obeying them. We can now do the same with Linux users, with the >> Fedora Project's latest release by the same name..." > > > Some more suggestions > > "sulphur" > "mayonaisse" > > (like werewolves they react badly with silver) Lutefisk From loupgaroublond at gmail.com Wed Dec 19 17:13:53 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 19 Dec 2007 12:13:53 -0500 Subject: Hackfests at Fudcon In-Reply-To: <1198081325.13693.29.camel@cutter> References: <1198081325.13693.29.camel@cutter> Message-ID: <7f692fec0712190913o88c3e80x3693607dd8965f88@mail.gmail.com> On Dec 19, 2007 11:22 AM, seth vidal wrote: > Hey folks, > > So, I drew the short straw and I get to help organize the hackfests. It > looks like we'll have 5 rooms and probably lots of miscellaneous > hallway/lobby space. > > We'll call the rooms: ABCDE. If you have a hackfest you'd like to start > up, let me know, I'll update the wiki and see about organizing the > rooms/times. > > What do folks think about 2 hackfest sessions per day one before lunch > (caffeinated) and one after lunch (fed and maybe more caffeinated). > > So sessions in rooms can be: > > 1A, 1B, 1C, 1D, 1E > > 2A, 2B, 2C, 2D, 2E > > on friday and sunday. > > and then everything else that can't get a room. I'm sure some hackfests > will take longer than one session and I'm sure sunday afternoon a lot of > people will be leaving to go home, but I'd like to fill things up as > much as possible. So email your ideas and plans. I know it draws away some of the attention from hacking in meatspace, but depending on what the project is, I can imagine there are alot of contributers who can't make it to FUDCon. Is there going to be alot of cyberspace interaction as well? Ekiga? -Yaakov From mrtom at fedoraproject.org Wed Dec 19 17:14:20 2007 From: mrtom at fedoraproject.org (Thomas Canniot) Date: Wed, 19 Dec 2007 18:14:20 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071219165843.GB2662@devserv.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> Message-ID: <20071219181420.593b35bb@annifrid.mrtomlinux> Le Wed, 19 Dec 2007 11:58:43 -0500, Alan Cox a ?crit : > On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: > Some more suggestions > > "mayonaisse" Oh please no... no French food as a distro name, people would make fun of us here. How credible could we be with such a fatty name ? Thomas Canniot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Wed Dec 19 17:39:52 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 19 Dec 2007 12:39:52 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <1198085992.30771.190.camel@localhost.localdomain> On Tue, 2007-12-18 at 07:27 -0600, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 9 release. We're > starting early this release to give the Fedora Art team time to come up > with some great art for F9, and really because there is no reason to > wait so long anyway. "Werewolf" is a Michael Hurley song title. Some other song titles by the same artist that sound like code names: Penguins, Trinidad, Revenant, Victoria, Wildegeeses, Mona Lisa, El Dorado. The song "Werewolf" was covered by Cat Power. Other Cat Power covers: Satisfaction, Bathysphere, Kingsport Town, Salty Dog, Blue. - ajax From jspaleta at gmail.com Wed Dec 19 17:14:49 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 08:14:49 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219160750.GE28769@tango.0pointer.de> References: <20071218222128.779d1d88@redhat.com> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> <20071219160750.GE28769@tango.0pointer.de> Message-ID: <604aa7910712190914o4fbd818fy5d675b174c4f905@mail.gmail.com> On Dec 19, 2007 7:07 AM, Lennart Poettering wrote: > [1] And I certainly don't want other people using my machine to spy on > my VoIP calls or listen into the audio track of my very private > porn videos! ;-) You only think its private... I found it using gnutella... you should wear those red leather chaps to work. -jef From alan at clueserver.org Wed Dec 19 17:16:06 2007 From: alan at clueserver.org (Alan) Date: Wed, 19 Dec 2007 09:16:06 -0800 (PST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <54914.198.182.194.170.1198084331.squirrel@clueserver.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <54914.198.182.194.170.1198084331.squirrel@clueserver.org> Message-ID: <60232.198.182.194.170.1198084566.squirrel@clueserver.org> >> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >>> into obeying them. We can now do the same with Linux users, with the >>> Fedora Project's latest release by the same name..." >> >> >> Some more suggestions >> >> "sulphur" >> "mayonaisse" >> >> (like werewolves they react badly with silver) > > Lutefisk "I will not buy this lutefisk, it is scratched. My hovercraft is full of fedoras." From jspaleta at gmail.com Wed Dec 19 17:16:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 08:16:38 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219171026.GD17216@redhat.com> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219161641.GB17216@redhat.com> <20071219164240.GH2526@free.fr> <20071219171026.GD17216@redhat.com> Message-ID: <604aa7910712190916s39454109w2d6ca8d9b027e122@mail.gmail.com> On Dec 19, 2007 8:10 AM, Nalin Dahyabhai wrote: > It may be better in terms of configurability, but I don't think it's the > right place to do it. I'm not against some other means of doing exactly > that (and I think we both agree that we'd like *something* like that), > but I think that PAM is an unsafe place to do it. Thoughts as to where that "something" should be? -jef From skvidal at fedoraproject.org Wed Dec 19 17:13:40 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 12:13:40 -0500 Subject: Hackfests at Fudcon In-Reply-To: <7f692fec0712190913o88c3e80x3693607dd8965f88@mail.gmail.com> References: <1198081325.13693.29.camel@cutter> <7f692fec0712190913o88c3e80x3693607dd8965f88@mail.gmail.com> Message-ID: <1198084420.13693.31.camel@cutter> On Wed, 2007-12-19 at 12:13 -0500, Yaakov Nemoy wrote: > I know it draws away some of the attention from hacking in meatspace, > but depending on what the project is, I can imagine there are alot of > contributers who can't make it to FUDCon. Is there going to be alot > of cyberspace interaction as well? Ekiga? > As much as the folks working on the various projects desire. There will be working network access so interacting with folks online should be completely possible. -sv From skvidal at fedoraproject.org Wed Dec 19 17:15:45 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 12:15:45 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071219181420.593b35bb@annifrid.mrtomlinux> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <20071219181420.593b35bb@annifrid.mrtomlinux> Message-ID: <1198084545.13693.33.camel@cutter> On Wed, 2007-12-19 at 18:14 +0100, Thomas Canniot wrote: > Le Wed, 19 Dec 2007 11:58:43 -0500, > Alan Cox a ?crit : > > > On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: > > > Some more suggestions > > > > > "mayonaisse" > > Oh please no... no French food as a distro name, people would make fun > of us here. How credible could we be with such a fatty name ? > mayonaisse is a french food? I never knew that. I just assumed it was the stuff people ask to not have on burgers and do add to tomato sandwiches. -sv From skvidal at fedoraproject.org Wed Dec 19 17:16:42 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 12:16:42 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <60232.198.182.194.170.1198084566.squirrel@clueserver.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <54914.198.182.194.170.1198084331.squirrel@clueserver.org> <60232.198.182.194.170.1198084566.squirrel@clueserver.org> Message-ID: <1198084602.13693.35.camel@cutter> On Wed, 2007-12-19 at 09:16 -0800, Alan wrote: > >> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: > >>> into obeying them. We can now do the same with Linux users, with the > >>> Fedora Project's latest release by the same name..." > >> > >> > >> Some more suggestions > >> > >> "sulphur" > >> "mayonaisse" > >> > >> (like werewolves they react badly with silver) > > > > Lutefisk > > "I will not buy this lutefisk, it is scratched. My hovercraft is full of > fedoras." Are you trying to throw off my spam scanner with sentences that make no sense? :) -sv From mzerqung at 0pointer.de Wed Dec 19 17:21:27 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 18:21:27 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712190914o4fbd818fy5d675b174c4f905@mail.gmail.com> References: <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> <20071219160750.GE28769@tango.0pointer.de> <604aa7910712190914o4fbd818fy5d675b174c4f905@mail.gmail.com> Message-ID: <20071219172127.GA3319@tango.0pointer.de> On Wed, 19.12.07 08:14, Jeff Spaleta (jspaleta at gmail.com) wrote: > > On Dec 19, 2007 7:07 AM, Lennart Poettering wrote: > > [1] And I certainly don't want other people using my machine to spy on > > my VoIP calls or listen into the audio track of my very private > > porn videos! ;-) > > You only think its private... I found it using gnutella... you should > wear those red leather chaps to work. I work from home. How do you know I am not wearing them right now? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pingoufc4 at yahoo.fr Wed Dec 19 17:21:25 2007 From: pingoufc4 at yahoo.fr (pingou) Date: Wed, 19 Dec 2007 18:21:25 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <47694F78.3000707@gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <47694F78.3000707@gmail.com> Message-ID: <47695315.2040905@yahoo.fr> Christopher Brown wrote: > Alan Cox wrote: >> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >>> into obeying them. We can now do the same with Linux users, with the >>> Fedora Project's latest release by the same name..." >> >> >> Some more suggestions >> >> "sulphur" >> "mayonaisse" >> >> (like werewolves they react badly with silver) >> >> > > Didn't the Lone Ranger use silver bullets? His horse was called Silver. > Nice Rawhide connection there... > > Fedora 9 "The Lone Ranger" - leading the fight for freedom etc. etc. > It actually make me think about that comic strip http://wildwester.wi.ohost.de/artikel/lucky.gif Cheers, P.Yves ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From jspaleta at gmail.com Wed Dec 19 17:24:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 08:24:00 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219172127.GA3319@tango.0pointer.de> References: <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> <20071219160750.GE28769@tango.0pointer.de> <604aa7910712190914o4fbd818fy5d675b174c4f905@mail.gmail.com> <20071219172127.GA3319@tango.0pointer.de> Message-ID: <604aa7910712190924i64bb9e3cx8030c3604ec9d39@mail.gmail.com> On Dec 19, 2007 8:21 AM, Lennart Poettering wrote: > I work from home. How do you know I am not wearing them right now? because I've hacked your microphone and I don't hear the leather creaking! -jef"-35 F"spaleta From pemboa at gmail.com Wed Dec 19 17:24:10 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 19 Dec 2007 11:24:10 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1197995889.19318.47.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> Message-ID: <16de708d0712190924y133099c8k19ed46c81a922f97@mail.gmail.com> On Dec 18, 2007 10:38 AM, Simo Sorce wrote: > > Anubis [1]: > > Anubis is a mythological creature of human/canine form > Werewolf is a mythological creature of human/canine form > > [1]: http://en.wikipedia.org/wiki/Anubis +1 for Anubis and +1 for future stargate references -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From snecklifter at gmail.com Wed Dec 19 17:29:23 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 19 Dec 2007 17:29:23 +0000 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <47695315.2040905@yahoo.fr> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <47694F78.3000707@gmail.com> <47695315.2040905@yahoo.fr> Message-ID: <476954F3.8040400@gmail.com> pingou wrote: > Christopher Brown wrote: >> Alan Cox wrote: >>> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >>>> into obeying them. We can now do the same with Linux users, with the >>>> Fedora Project's latest release by the same name..." >>> >>> Some more suggestions >>> >>> "sulphur" >>> "mayonaisse" >>> >>> (like werewolves they react badly with silver) >>> >>> >> Didn't the Lone Ranger use silver bullets? His horse was called Silver. >> Nice Rawhide connection there... >> >> Fedora 9 "The Lone Ranger" - leading the fight for freedom etc. etc. >> > It actually make me think about that comic strip > http://wildwester.wi.ohost.de/artikel/lucky.gif It'd just never get past legal. Although the original stuff is over 50 years old.... who owns the copyright on it I wonder. Anyone? Anyway, I prefer Lutefisk! Apparently: http://www.lutefiskmike.com/lutefisk.cfm Olsen Fish Company has positioned itself as the world?s largest Lutefisk producer using only genuine Norwegian stockfish. With many years of experience producing Lutefisk, it is obvious why more customers prefer Olsen?s Flakee White Lutefisk. From alan at clueserver.org Wed Dec 19 17:31:45 2007 From: alan at clueserver.org (Alan) Date: Wed, 19 Dec 2007 09:31:45 -0800 (PST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198084602.13693.35.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <54914.198.182.194.170.1198084331.squirrel@clueserver.org> <60232.198.182.194.170.1198084566.squirrel@clueserver.org> <1198084602.13693.35.camel@cutter> Message-ID: <16296.198.182.194.170.1198085505.squirrel@clueserver.org> > > On Wed, 2007-12-19 at 09:16 -0800, Alan wrote: >> >> On Wed, Dec 19, 2007 at 08:50:46AM -0600, Jima wrote: >> >>> into obeying them. We can now do the same with Linux users, with >> the >> >>> Fedora Project's latest release by the same name..." >> >> >> >> >> >> Some more suggestions >> >> >> >> "sulphur" >> >> "mayonaisse" >> >> >> >> (like werewolves they react badly with silver) >> > >> > Lutefisk >> >> "I will not buy this lutefisk, it is scratched. My hovercraft is full >> of >> fedoras." > > Are you trying to throw off my spam scanner with sentences that make no > sense? :) It is a Monty Python reference. ("Hungarian phrasebook" sketch.) From jspaleta at gmail.com Wed Dec 19 17:32:15 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 08:32:15 -0900 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198084545.13693.33.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <20071219181420.593b35bb@annifrid.mrtomlinux> <1198084545.13693.33.camel@cutter> Message-ID: <604aa7910712190932k706da7c6g65a8bc7f49765d5a@mail.gmail.com> On Dec 19, 2007 8:15 AM, seth vidal wrote: > mayonaisse is a french food? > I never knew that. I just assumed it was the stuff people ask to not > have on burgers and do add to tomato sandwiches. mayonaisse on a hamburger bun is essential to keeping lightly toasted buns from absorbing too much meat grease and going on soggy! So sayth the holy script(ure)s of the Good Eats television show. Who dares question the wisdom of the prophet Alton Brown. Heresy! I'd say burn such people at the stake, but since Good Eats hasn't done a show on how to correctly cook human flesh, it would be sort of a waste. -jef"the moose tenderloin in the freezer is beckoning me"spaleta From ssorce at redhat.com Wed Dec 19 17:37:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Dec 2007 12:37:22 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <476954F3.8040400@gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <47694F78.3000707@gmail.com> <47695315.2040905@yahoo.fr> <476954F3.8040400@gmail.com> Message-ID: <1198085842.10601.1.camel@localhost.localdomain> On Wed, 2007-12-19 at 17:29 +0000, Christopher Brown wrote: > > It'd just never get past legal. Although the original stuff is over > 50 > years old.... who owns the copyright on it I wonder. Anyone? Copyright != Trademark You can't copyright a word or a name. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jonathan.roberts.uk at googlemail.com Wed Dec 19 17:32:45 2007 From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts) Date: Wed, 19 Dec 2007 17:32:45 +0000 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <604aa7910712190932k706da7c6g65a8bc7f49765d5a@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <20071219181420.593b35bb@annifrid.mrtomlinux> <1198084545.13693.33.camel@cutter> <604aa7910712190932k706da7c6g65a8bc7f49765d5a@mail.gmail.com> Message-ID: <1198085565.2684.1.camel@localhost.localdomain> How about Marduk? Werewolves' being mythical, and Marduk, as the most powerful Babylonian God, also being mythical... Jon From lesmikesell at gmail.com Wed Dec 19 17:39:42 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 19 Dec 2007 11:39:42 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219160750.GE28769@tango.0pointer.de> References: <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> <1198039072.3085.18.camel@space-ghost.verbum.private> <20071219061239.GP6485@eeyore.32.boerneef.vornavalley> <20071219092610.GF9741@tango.0pointer.de> <20071219101232.GB12085@eeyore.32.boerneef.vornavalley> <20071219103114.GA14958@tango.0pointer.de> <1198073926.19318.96.camel@localhost.localdomain> <20071219150224.GB28769@tango.0pointer.de> <20519.192.54.193.53.1198079081.squirrel@rousalka.dyndns.org> <20071219160750.GE28769@tango.0pointer.de> Message-ID: <4769575E.5050001@gmail.com> Lennart Poettering wrote: > Footnotes: > > [1] And I certainly don't want other people using my machine to spy on > my VoIP calls or listen into the audio track of my very private > porn videos! ;-) But sometimes you do want simultaneous multiplexed access or random use among a set of users/processes not separated by any particular event. It should be the administrator/users decision about who can do what, not hard coded in a program. Controlling access among multiple users on a multi user operating system isn't exactly a new concept except for the recent notion that logging in at the console (if you happen to have such a thing) should magically give you ownship of more than /dev/tty. Why can't you provide an init.d script to be used (optionally) to start a daemon associated with a local sound device if you need it to handle processes not associated with a login (perhaps mythtv or any of the jukebox server process), add a group that will always be permitted access so certain users/processes can be given permanent access regardless of any events, and use kernel locking if you want to guarantee exclusive access? That makes it the usual 'service service_name start/stop' and 'chkconfig service_name on' operations that fedora/RH users expect to use to control optional daemons. If sessions that proxy to remote devices run separate daemons, those could still be started on demand, and if you don't need the init.d daemon, you wouldn't have to use it. -- Les Mikesell lesmikesell at gmail.com From snecklifter at gmail.com Wed Dec 19 17:43:14 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 19 Dec 2007 17:43:14 +0000 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198085842.10601.1.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <47694F78.3000707@gmail.com> <47695315.2040905@yahoo.fr> <476954F3.8040400@gmail.com> <1198085842.10601.1.camel@localhost.localdomain> Message-ID: <47695832.5080708@gmail.com> Simo Sorce wrote: > On Wed, 2007-12-19 at 17:29 +0000, Christopher Brown wrote: >> It'd just never get past legal. Although the original stuff is over >> 50 >> years old.... who owns the copyright on it I wonder. Anyone? > > Copyright != Trademark > > You can't copyright a word or a name. I was talking about the comics, films and cartoon linked to previously, not the name... Regards Chris From jkeating at redhat.com Wed Dec 19 17:49:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Dec 2007 12:49:01 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198085992.30771.190.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1198085992.30771.190.camel@localhost.localdomain> Message-ID: <20071219124901.3cb895a0@redhat.com> On Wed, 19 Dec 2007 12:39:52 -0500 Adam Jackson wrote: > Bathysphere I like this one. -- 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 Wed Dec 19 18:01:43 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 19:01:43 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219164240.GH2526@free.fr> References: <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <1198074502.2809.4.camel@localhost.localdomain> <20071219161641.GB17216@redhat.com> <20071219164240.GH2526@free.fr> Message-ID: <20071219180143.GD3319@tango.0pointer.de> On Wed, 19.12.07 17:42, Patrice Dumas (pertusus at free.fr) wrote: > Nobody thinks that. But PAM allows to run some login wide stuff, with > modularity and under administrator control, and hook in any login > program. This may not be the perfect place to start PA, but it is still > better than starting it only in gdm. Maybe the X session script is > better, but the issue with session script (in > /etc/X11/xinit/xinitrc-common) is that it is only for X, and it is not > modular. The interest of pam is that the administrator may decide which > login path uses it. You are aware that there still is /etc/profile and similar scripts? Those are usually not interpreted when doing a login on X11 (at least AFAIK). So, for shell-only logins it is not that difficult to hook additional stuff in. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed Dec 19 18:09:40 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 19 Dec 2007 19:09:40 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219170357.GI2526@free.fr> References: <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> <20071219160634.GE2526@free.fr> <20071219163804.GG28769@tango.0pointer.de> <20071219170357.GI2526@free.fr> Message-ID: <20071219180940.GE3319@tango.0pointer.de> On Wed, 19.12.07 18:03, Patrice Dumas (pertusus at free.fr) wrote: > > Now, we don't have such a cool session daemon right now. However, > > moving things into PAM is definitely the wrong direction. Because in > > PAM you can only hook code when the session starts and when the > > session ends. A session daemon like that however needs to constantly > > monitor all its processes, and thus needs to be running all the time. > > You mean must be restarted when it died? Monitoring process is more than just restarting. You might want to kill PA when it eats to much CPU, or process its log output. Or handle core dumps or whatever. Many things I listed require constantly running supervisers. > > Now, of course you can fork this monitoring daemon away from the PAM > > session login code and kill it on logout. But if you do that you are > > mixing the code that makes up the session with the code that sets up > > the session. > > I can't see why this couln't be possible. Just because something is "possible" it's not necessarily the right thing to do. > It would be nice to have many way of doing it. Including as a shell, > from X init scripts, from pam, from window manager, and so on and so > forth. > > Still, currently, the only modular place where per login stuff can be > launched at the administrator will is PAM. it would be trivial to add code to /etc/profile and /etc/X11/xinit/xinitrc to allow executing certain hook scripts that are stored in a special directory on login for the console and login on X11. Oh wait! We already have that. ;-) It's called /etc/X11/xinit/xinitrc.d/ and /etc/profile.d/. However, this is not really useful for the GNOME cases (and neither for other cases) because gnome-session wants to start PA and upload the samples itself. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From galibert at pobox.com Wed Dec 19 18:29:53 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 19 Dec 2007 19:29:53 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219110744.GA16151@tango.0pointer.de> References: <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> Message-ID: <20071219182952.GA48316@dspnet.fr.eu.org> On Wed, Dec 19, 2007 at 12:07:44PM +0100, Lennart Poettering wrote: > Come on. The are a lot of thing PA doesn't do right now. Not just this > one. However, there happen to be a couple of things PA can do very > well. > > What kind of stupid game is this, anyway? You find cases where PA > doesn't work without manual reconfigration. And then you ask me, and I > say, "yes, it doesn't work", and then you tell me "yes, i thought so, > PA is total crap." I you want we can play this game with swapped roles: > I find a feature that software you wrote doesn't do and then I > tell you "Your software sucks big time." It certainly would be a lot > more fun for me that way! Where did I? Please, tell me, where did _I_ say your software sucked? I gave you a real world (as in, my home) use case. I asked you if PA supported it as is (with or without specific configuration of course), and if not if it could be modified to support it. Your answer at that point seems to be varying between "just disable PA", "you don't want to reconfigure so fuck off" and "why do you hate me", which is kinda... surprising. Please have a beer or any other beverage of choice and a long shower/sleep and try again. > > So now gdm and using a panel is a fedora requirement for multiuser > > support? > > We try our best to supply you with easy-to-use software for doing > f-u-s. And all you do is telling us is that you refuse to use our > software, but go on complaining that f-u-s doesn't work for you? > > How do you think we should be fixing this? I mean, it's hard to get > this fixed for you if you don't want to use our code. Don't you think? The '?' at the end of a sentence usually means the sentence is a question. I don't know f-u-s, I barely heard its name before this thread, and given I don't use a panel there is close to no chance I'd find it just by looking around. I'd incidentally be curious to know where I said it wasn't working for me, since I never tried it in the first place. Is wanting to know whether multiuser is only supposed to happen through f-u-s nowadays (vs. multiple X servers on different VCs which is a method that has worked for more years than Fedora has existed) that out-of-line a request? My next question would have been how users coming in through ssh were integrated in that scheme. > > Where fine means "only the currently selected user can do sound", from > > what you wrote too. Which, if you had bothered to read my use case > > with your brain on, you'd have noticed is not fine at all. > > Let's stop this stupid discussion now. I already wrote countless times > on this thread: with some minimal reconfiguration you can get PA > working for you, or can bypass it, whatever suits you best. I've seen a lot of contradictory handwaving with usually keywords like "ConsoleKit" in the middle, I've yet to see a clear example of such "minimal reconfiguration". I was expecting answers that looked like "you have to configure CK to do X and each user/entry login has to start its own daemon and ..." or "PA can't support it at that point, it needs X added first", that kind of thing. Not what I got. > And I already explained in detail why we chose to do multi-session > support the way we are doing it. We tend to do our stuff for good reasons > the way we do. And we explain them to anyone who asks. And we take > suggestions. But in the end, the one who produces the code is ... the > one who produces the code. The only reason I've seen yet is security in non-trusted multiuser environments. Which is only one kind of environment, no more and no less important than the others like "trusted multiuser", "multihomed", "mediabox" and others. OG. From rdieter at math.unl.edu Wed Dec 19 15:35:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Dec 2007 09:35:42 -0600 Subject: nm-0.7 (final) release, schedule? References: <1198077974.2809.15.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > Why do you think asking here will give better results than asking > upstream ? It *has* been asked, several times now on the upstream list (and I included the latest reference), with no answers, sadly. > Dan may be able to provide more details. That was my hope. :) -- Rex From cjdahlin at ncsu.edu Wed Dec 19 18:48:31 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 19 Dec 2007 13:48:31 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218192322.GB3359@nostromo.devel.redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <20071218192322.GB3359@nostromo.devel.redhat.com> Message-ID: <4769677F.3040209@ncsu.edu> Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > >> Josh Boyer (jwboyer at gmail.com) said: >> >>> Let the naming begin! >>> >> So, Werewolf is a: >> >> - Fictional creature >> - Ancient: Griffin, Sphinx, Cerberus (yeah, that's not going to stick), Scylla, >> Chimaera, etc. >> - SciFi Movie/TV: Tauntaun, Tribble, Ewok, Faun, Dalek, etc. >> - Cryptozoology: Bigfoot, Loch Ness Monster, etc. >> - Horror: Mummy, Vampire >> - Games: Grue, Flood >> - Game Shows: Whammy >> >> Personally, I like 'Sphinx' or 'Grue'. >> >> - A baseball team (the London Werewolves, natch) >> - Paints, Otters, Wild Things, Biscuits, etc. >> >> - Something found at Trader Vic's >> - Mai Tai, Tiki >> >> - Things found in London in song titles >> - Bells, Foggy Days, Bridge, Streets >> > > Also: > > - Characters played by Lon Chaney, Jr. > - Chingachgook, Dracula, Mummy, Sinbad, Pedro Martines (heh) > > - A syndrome > - Stockholm, Asperger, Usher, Marfan, Tourette > > I have Aspergers. That would be interesting. Though you left out Beatlenemia > Bill > > From bpepple at fedoraproject.org Wed Dec 19 18:49:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 19 Dec 2007 13:49:24 -0500 Subject: Plan for tomorrows (20071220) FESCO meeting Message-ID: <1198090164.4860.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 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 /topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13 /topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy /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, since we have a pretty full schedule). 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... 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 Michael_E_Brown at Dell.com Wed Dec 19 19:03:46 2007 From: Michael_E_Brown at Dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 13:03:46 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198083109.13167.6.camel@vorpal.macdev.com> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <1198011092.12620.10.camel@rousalka.dyndns.org> <1198083109.13167.6.camel@vorpal.macdev.com> Message-ID: <20071219190346.GA12682@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 10:51:48AM -0600, David G. Mackay wrote: > On Tue, 2007-12-18 at 21:51 +0100, Nicolas Mailhot wrote: > > > Because audio cabling is static and audio devices are at the same stage > > today as non-networked printers were two decade ago. There are systems > > connected to audio devices by virtue of being near the audio devices, > > and there is no 1:1 relashionship between the user sitting on the local > > system in the current dekstop session and the user making use of audio > > devices. > > > > It's perfectly legitimate to have a desktop system sitting in the living > > room that simultaneously plays a DVD for one user on the TV/projector > > output, records analog video for another through PVR card, while a third > > is connected in dekstop session and checks his mails or does some quick > > browsing. > > The problem that you're discussing centers more around poorly designed > video capture cards than audio capability. The Hauppage PVR-150 and > PVR-350 cards (and probably others) don't require the use of the sound > card to record audio. Good point. HD cards can also capture audio/video without the use of a sound card. -- Michael From pertusus at free.fr Wed Dec 19 19:30:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Dec 2007 20:30:16 +0100 Subject: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198090164.4860.3.camel@kennedy> References: <1198090164.4860.3.camel@kennedy> Message-ID: <20071219193016.GA2642@free.fr> On Wed, Dec 19, 2007 at 01:49:24PM -0500, 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 18:00 UTC > in #fedora-meeting on irc.freenode.org: The automatic mailing of multiarch conflicts... -- Pat From mschwendt.tmp0701.nospam at arcor.de Wed Dec 19 19:35:43 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Dec 2007 20:35:43 +0100 Subject: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198090164.4860.3.camel@kennedy> References: <1198090164.4860.3.camel@kennedy> Message-ID: <20071219203543.8349c4a5.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Dec 2007 13:49:24 -0500, 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 18:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 > > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - > f13 > > /topic Status Update: Compat Policy > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > /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, since we have a pretty full schedule). 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... > > Later, > /B From seg at haxxed.com Wed Dec 19 19:38:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 19 Dec 2007 13:38:11 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198085565.2684.1.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> <20071219181420.593b35bb@annifrid.mrtomlinux> <1198084545.13693.33.camel@cutter> <604aa7910712190932k706da7c6g65a8bc7f49765d5a@mail.gmail.com> <1198085565.2684.1.camel@localhost.localdomain> Message-ID: <1198093091.18986.154.camel@localhost> On Wed, 2007-12-19 at 17:32 +0000, Jonathan Roberts wrote: > How about Marduk? > > Werewolves' being mythical, and Marduk, as the most powerful Babylonian > God, also being mythical... "If I eat food, there won't be any room for Marduk, slayer of Tiamat!" (Okay, for those who don't watch American late night cable TV... Warning, contains animated drug use. The message is anti-drug, really...) http://vids.myspace.com/index.cfm?fuseaction=vids.individual&VideoID=3163397 -------------- 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 bos at serpentine.com Wed Dec 19 19:52:15 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 19 Dec 2007 11:52:15 -0800 Subject: Delays in package processing Message-ID: <4769766F.3010306@serpentine.com> I'm finding the manual package signing step that has to happen before a package can go into testing to be a considerable drag. There's a long lag between submitting a request and the event actually occurring, and there's no real visibility into why a request is languishing. For example, there are some packages in the F-8 pending queue that have been there for six weeks. I usually end up going into #fedora-devel and bugging people after four or five days, but I don't actually like having to prod people who I assume are already busy doing other worthy work. The combination of delay and opacity makes my volunteer job as a packager a lot less rewarding. I'd like to package more software, rather than less, but as long as the delays and overhead of maintaining just one or two packages are this high, that's a big barrier to me working up any further enthusiasm. I have a few meta-questions about this situation which might help to defuse my discontent with the process. I can't imagine that I'm the only one in this position, so maybe it will help others too. Is the package signing step done by hand? That's been my understanding, but maybe I'm missing something. It reminds me of Sigourney Weaver's role in "Galaxy Quest": a seemingly needless insertion of people into the process. If so, why? Can we switch to an automated process? If a long delay between submitting a request to bodhi and getting a human to turn the crank is going to the norm, could we add some functionality that lets us see why? Some graphs showing the rates of request submission and clearance, and the amounts of time that packages are spending in queues, might help people who aren't glued into the faily process to understand what's going on. Thanks! References: <4769766F.3010306@serpentine.com> Message-ID: <1198094151.3400.13.camel@localhost.localdomain> On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: > Is the package signing step done by hand? That's been my understanding, > but maybe I'm missing something. It reminds me of Sigourney Weaver's > role in "Galaxy Quest": a seemingly needless insertion of people into > the process. > > If so, why? Can we switch to an automated process? It is currently a manual process, and Jesse Keating has been working for some time to make an open source signing server that will work for Fedora's infrastructure needs but also be useful for anyone. This is his cue to give us a status report. ;) ~spot From jeff at ocjtech.us Wed Dec 19 19:59:56 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 19 Dec 2007 13:59:56 -0600 Subject: Delays in package processing In-Reply-To: <1198094151.3400.13.camel@localhost.localdomain> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> Message-ID: <935ead450712191159p6e18398ei832b181c3d9aa287@mail.gmail.com> On 12/19/07, Tom spot Callaway wrote: > > On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: > > > Is the package signing step done by hand? That's been my understanding, > > but maybe I'm missing something. It reminds me of Sigourney Weaver's > > role in "Galaxy Quest": a seemingly needless insertion of people into > > the process. > > > > If so, why? Can we switch to an automated process? > > It is currently a manual process, and Jesse Keating has been working for > some time to make an open source signing server that will work for > Fedora's infrastructure needs but also be useful for anyone. > > This is his cue to give us a status report. ;) Some Fedora Hosted project space was set up today for the signing server code: https://fedorahosted.org/sigul/ The code isn't there yet but I'm sure it will soon be. Jeff From tcallawa at redhat.com Wed Dec 19 20:01:33 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Dec 2007 15:01:33 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <47694C32.5040000@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> Message-ID: <1198094493.3400.15.camel@localhost.localdomain> On Wed, 2007-12-19 at 11:52 -0500, Jon Prindiville wrote: > Yaakov Nemoy wrote: > > Fedora X, then Fedora "ours goes to" XI > > I prefer Fedora "OS" X No, no, no. There is no Fedora 10. There can never be a 10. We have to either skip to 11, or rename again. ~spot From lesmikesell at gmail.com Wed Dec 19 20:05:08 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 19 Dec 2007 14:05:08 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219094603.GJ9741@tango.0pointer.de> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> <20071219094603.GJ9741@tango.0pointer.de> Message-ID: <47697974.4060401@gmail.com> Lennart Poettering wrote: >>> I think one of the problems here is CK runs against a body of shared >>> administration experience >>> in the community. There isn't a shared understanding of how to use CK >>> effectively to get common hardware related admin crap done, so as a >>> result any explanation on how to do something semi-involved as an >>> administrator which boils down to "it uses CK to do it" just doesn't >>> connect. >> Yes, that doesn't make any sense to me - even the concept of 'active >> session'. If your X display is on a nearby machine (or several) but you >> want local audio, is that 'active' or not in PA speak? What if you have >> mythtv running but not related to a logged in session and also want to log >> in? > > You're always welcome to change he default configuration of CK. > > The point of CK is that we try to fix a gaping security hole: think of > a university system: a workstation where different people logon/logoff > all the time. Right now, a user may keep open the sound card forever, > and use it to spy people who access the same machine later > on. I.e. use the mike to listen to what they are saying and stuff like > that. I thought kernel locks were the appropriate mechanism to ensure exclusive access and files/devices should all be abstracted to look the same. > If you don't care about that kind of security than you are always > welcome to change the configuration. But I believe that the default > installation of Fedora should be reasonably secure, and that this > should be a priority. I just don't see the conceptual difference between this device and (say) a tape device. It seems as silly to give exclusive access to a sound device based on an assumed proximity as it would with a tape device that is likely to also be needed for scheduled jobs - and will need exclusive access. And even stranger to tie access to some particular window manager startup when many different ones may be running along with processes not running under X and ones tunneled via ssh instead of having a local session. -- Les Mikesell lesmikesell at gmail.com From jwboyer at gmail.com Wed Dec 19 20:09:35 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 19 Dec 2007 14:09:35 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198094493.3400.15.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> <1198094493.3400.15.camel@localhost.localdomain> Message-ID: <20071219140935.6cf0550f@hansolo.jdub.homelinux.org> On Wed, 19 Dec 2007 15:01:33 -0500 "Tom \"spot\" Callaway" wrote: > > On Wed, 2007-12-19 at 11:52 -0500, Jon Prindiville wrote: > > Yaakov Nemoy wrote: > > > Fedora X, then Fedora "ours goes to" XI > > > > I prefer Fedora "OS" X > > > No, no, no. > > There is no Fedora 10. There can never be a 10. > > We have to either skip to 11, or rename again. Horsepoo. My suggestion for Fedora 9 is ten then. Fedora 9 (Ten) josh From skvidal at fedoraproject.org Wed Dec 19 20:07:24 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 15:07:24 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198094493.3400.15.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> <1198094493.3400.15.camel@localhost.localdomain> Message-ID: <1198094844.13693.37.camel@cutter> On Wed, 2007-12-19 at 15:01 -0500, Tom "spot" Callaway wrote: > On Wed, 2007-12-19 at 11:52 -0500, Jon Prindiville wrote: > > Yaakov Nemoy wrote: > > > Fedora X, then Fedora "ours goes to" XI > > > > I prefer Fedora "OS" X > > > No, no, no. > > There is no Fedora 10. There can never be a 10. > > We have to either skip to 11, or rename again. no, we have to have a 10. Then ours can go to 11! -sv From sconklin at redhat.com Wed Dec 19 20:14:05 2007 From: sconklin at redhat.com (Steve Conklin) Date: Wed, 19 Dec 2007 14:14:05 -0600 Subject: Mock: loss of login shell Message-ID: <47697B8D.1020107@redhat.com> This was covered briefly in a couple of emails on this list a couple of weeks ago but I see this as a bug, further discussion please . . . Mock no longer uses a login shell for builds. The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config. krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh No user shell, therefore no path, and configure fails to find krb5-config. The simple solution for this is to add the following to the %build section of the spec file for ipsec-tools: source /etc/profile.d/krb5-devel.sh Having put that into the spec file, there's potential for what would otherwise be a perfectly acceptable change to the krb5 package to break builds of other packages that have a BuildRequire for it. I'm afraid that this might lead to a proliferation of small changes to spec files that create unneeded dependencies. I'm interested in what other people think about this. Steve From mcepl at redhat.com Wed Dec 19 20:00:30 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 19 Dec 2007 21:00:30 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071218191354.GA3359@nostromo.devel.redhat.com> <60215.155.148.81.122.1198012717.squirrel@intranet.cs.nmsu.edu> <1198074095.21251.2.camel@localhost.localdomain> <20071219165843.GB2662@devserv.devel.redhat.com> Message-ID: On 2007-12-19, 16:58 GMT, Alan Cox wrote: > "mayonaisse" +10!!! Mat?j From tibbs at math.uh.edu Wed Dec 19 20:18:43 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2007 14:18:43 -0600 Subject: Delays in package processing In-Reply-To: <4769766F.3010306@serpentine.com> References: <4769766F.3010306@serpentine.com> Message-ID: >>>>> "BO" == Bryan O'Sullivan writes: BO> For example, there are some packages in the F-8 pending queue that BO> have been there for six weeks. Is that really the same issue? We've certainly had an updates push within the past six weeks, and it was my understanding that when that happens everything that is pushable is pushed. The oldest package in in pending state that has a "push to stable" request is xorg-x11-drv-ati-6.7.196-2.fc8 which was superceded by a later released before it could be pushed. - J< From tcallawa at redhat.com Wed Dec 19 20:21:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Dec 2007 15:21:59 -0500 Subject: Mock: loss of login shell In-Reply-To: <47697B8D.1020107@redhat.com> References: <47697B8D.1020107@redhat.com> Message-ID: <1198095719.3400.19.camel@localhost.localdomain> On Wed, 2007-12-19 at 14:14 -0600, Steve Conklin wrote: > This was covered briefly in a couple of emails on this list a couple of > weeks ago but I see this as a bug, further discussion please . . . > > Mock no longer uses a login shell for builds. > > The way I discovered this is that the ipsec-tools package stopped > building. The reason is that it has a BuildRequires for the krb5-devel > package, from which it uses krb5-config. > > krb5-config is installed in /usr/kerberos/bin/, and the user's path is > provided by /etc/profile.d/krb5-devel.sh > > No user shell, therefore no path, and configure fails to find krb5-config. A lot of the qt dependent packages are in the same boat, one of mine hit this today. ~spot From jspaleta at gmail.com Wed Dec 19 20:43:42 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 11:43:42 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <47697974.4060401@gmail.com> References: <20071218003853.GA12552@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> <20071219094603.GJ9741@tango.0pointer.de> <47697974.4060401@gmail.com> Message-ID: <604aa7910712191243l3317652cx4c84ba2081b2d5fd@mail.gmail.com> On Dec 19, 2007 11:05 AM, Les Mikesell wrote: > I just don't see the conceptual difference between this device and > (say) a tape device. It seems as silly to give exclusive access to a > sound device based on an assumed proximity as it would with a tape > device that is likely to also be needed for scheduled jobs - and will > need exclusive access. And even stranger to tie access to some > particular window manager startup when many different ones may be > running along with processes not running under X and ones tunneled via > ssh instead of having a local session. Maybe there is no conceptual difference... which is why I think we're expressing frustration at the wrong piece of the new world order. Now that the default hal rules no longer "hide" internal disk drive partitions from gnome-volume-manager even if they are explicitly listed in fstab, I imagine this will also be a cause for frustration similar to the tape drive or the audio hardware scenario. Same goes for cd changers. I think the underlying problem is that advanced hardware access policy technology is advancing far more rapidly than local administrators are able to keep up with and its disrupting workflow that has been used for years. It's the bargain price of rapid innovation. I don't think there are insurmountable things going on, I just don't think we have a good enough understanding on how to use HAL/CK/PK to do local policy hardware access customizations, so we end up fighting the technologies instead of reconfiguration them. What we need to understand better as local sysadmins is how PolicyKit, ConsoleKit, and Hal can be re-configured to support well defined multuser environments scenarios, and limit how session related daemons get access to hardware. I don't know about you, but I learn best by having one or two tasked-based examples of how to reconfigure these things. For example having an example on how to write new configurations for these technologies that let me pre-emptively get access to a sound output for mpd in such a way that the user desktop PA daemon loses control would be a good read. Or how to reconfigure things so local tape/harddrive partitions are restricted from console user access so they can be used by automated backup services running out of cron. And I don't mean "find the hal policy definition file that came with F7 and drop it on your system." We need to actually have from scratch examples to work through, so we can understand the logic of constructing the configuration, not cookie cutter recipes to 'fix' things. I'll also say that I've seen the same sort of frustrations being expressed of selinux when it was introduced. The recent blog posts from Dan Walsh concerning how to actually reconfigure the selinux policy to get non-default things done have been exactly the sort of "re-learning" material that all the new technologies are going to need. The lock down of x-guest environment blog posts in particular have been good to help me think about actually using selinux to get something done and not just finding ways to disable selinux because its in the way. What we really need is this sort re-configure "Use CK/PK/Hal" to get something cool done. Unfortunately, as with the case of the selinux stuff, we really need the people who grok these technologies to produce this "re-learning" material, because the rest of us are just completely and utterly lost and are going to continue to work around these technologies instead of attempting to use them. Questions for the future. Can we develop drop-in configurations to replace the default configs for CK/PK/Hal which provide a better starting point for defined multi-user usage cases? Can we develop graphical tools which help tweak those configs for local needs? Will this tie into sabayon? I would think there would be a compelling RHEL need to introduce some local admin-centric helper tools for local hardware access policy decisions, so local admins will start to reach for the new technology as a solution instead of fighting it by just trying to turn it off or work around it. -jef"And by we.. I mean not me."spaleta From jspaleta at gmail.com Wed Dec 19 20:49:27 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 11:49:27 -0900 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198094493.3400.15.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> <1198094493.3400.15.camel@localhost.localdomain> Message-ID: <604aa7910712191249l5f944c43w8c3117ada9fa40f9@mail.gmail.com> On Dec 19, 2007 11:01 AM, Tom spot Callaway wrote: > There is no Fedora 10. There can never be a 10. > > We have to either skip to 11, or rename again. The problem is you merged Core and Extras a few releases too early. The drop of "Core" was the renaming event that you forced at the 10 mark. -jef From jos at xos.nl Wed Dec 19 21:00:10 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 19 Dec 2007 22:00:10 +0100 Subject: Mock: loss of login shell In-Reply-To: <47697B8D.1020107@redhat.com> References: <47697B8D.1020107@redhat.com> Message-ID: <20071219210010.GA15878@jasmine.xos.nl> On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote: > Mock no longer uses a login shell for builds. > > The way I discovered this is that the ipsec-tools package stopped > building. The reason is that it has a BuildRequires for the krb5-devel > package, from which it uses krb5-config. > > krb5-config is installed in /usr/kerberos/bin/, and the user's path is > provided by /etc/profile.d/krb5-devel.sh > > No user shell, therefore no path, and configure fails to find krb5-config. I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. The same holds for some JVM's, IIRC. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jkeating at redhat.com Wed Dec 19 21:12:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Dec 2007 16:12:42 -0500 Subject: Mock: loss of login shell In-Reply-To: <20071219210010.GA15878@jasmine.xos.nl> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> Message-ID: <20071219161242.1a54e2b7@redhat.com> On Wed, 19 Dec 2007 22:00:10 +0100 Jos Vos wrote: > I think mock is wrong. It's obvious that the devel packages assume > developers (like package builders, either human or not ;-)) run the > /etc/profile.d scripts. The same holds for some JVM's, IIRC. How does this work though when installing the -devel packages? Are you expected to log out and log back into your shell to actually do something useful? That doesn't seem right to me. -- 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 lowen at pari.edu Wed Dec 19 21:16:53 2007 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Dec 2007 16:16:53 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071219124901.3cb895a0@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <200712191616.53204.lowen@pari.edu> On Wednesday 19 December 2007, Jesse Keating wrote: > On Wed, 19 Dec 2007 12:39:52 -0500 > > Adam Jackson wrote: > > Bathysphere > > I like this one. +1 That would be a real deep reference. Fold back over, get ten to be Marshall (Chan Marshall sang Bathysphere for Cat Power)..... Then ours goes to 11! Yuck. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From opensource at till.name Wed Dec 19 21:22:23 2007 From: opensource at till.name (Till Maas) Date: Wed, 19 Dec 2007 22:22:23 +0100 Subject: Mock: loss of login shell In-Reply-To: <20071219161242.1a54e2b7@redhat.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <20071219161242.1a54e2b7@redhat.com> Message-ID: <200712192222.34262.opensource@till.name> On Mi Dezember 19 2007, Jesse Keating wrote: > On Wed, 19 Dec 2007 22:00:10 +0100 > > Jos Vos wrote: > > I think mock is wrong. It's obvious that the devel packages assume > > developers (like package builders, either human or not ;-)) run the > > /etc/profile.d scripts. The same holds for some JVM's, IIRC. > > How does this work though when installing the -devel packages? Are you > expected to log out and log back into your shell to actually do > something useful? That doesn't seem right to me. This is how it works with every package that drops something into /etc/profile.d. Why is it not right for -devel packages? 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 Wed Dec 19 22:02:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Dec 2007 17:02:02 -0500 Subject: Mock: loss of login shell In-Reply-To: <200712192222.34262.opensource@till.name> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <20071219161242.1a54e2b7@redhat.com> <200712192222.34262.opensource@till.name> Message-ID: <20071219170202.14209ad9@redhat.com> On Wed, 19 Dec 2007 22:22:23 +0100 Till Maas wrote: > This is how it works with every package that drops something > into /etc/profile.d. Why is it not right for -devel packages? I didn't ask if it was done elsewhere. I think it's a terrible user experience, that if use of a package is going to depend on shell variables, and you have to reload your environment to make use of 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 buildsys at redhat.com Wed Dec 19 22:02:49 2007 From: buildsys at redhat.com (Build System) Date: Wed, 19 Dec 2007 17:02:49 -0500 Subject: rawhide report: 20071219 changes Message-ID: <200712192202.lBJM2nhx007172@porkchop.devel.redhat.com> New package CriticalMass SDL/OpenGL space shoot'em up game also known as critter New package netbsd-iscsi User-space implementation of iSCSI target from NetBSD project New package starplot-contrib Stellar data set for use by the StarPlot tool New package tinyxml A simple, small, C++ XML parser New package trac-doxygen-plugin Integrates doxygen documentation into Trac New package trac-xmlrpc-plugin Allows Trac plugins to export their interface via XML-RPC New package xqilla10 XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C New package xstar Program that simulates the movement of stars Updated Packages: Macaulay2-0.9.95-9.fc9 ---------------------- * Tue Dec 18 2007 Rex Dieter 0.9.95-9 - Provides: macaulay2 - respin against new(er) factory,libfac,ntl NetworkManager-1:0.7.0-0.8.svn3181.fc9 -------------------------------------- * Tue Dec 18 2007 Dan Williams - 1:0.7.0-0.8.svn3181 - Fixes to work better with new libnl (rh #401761) * Tue Dec 18 2007 Dan Williams - 1:0.7.0-0.8.svn3180 - Fix WPA/WPA2 Enterprise Phase2 connections (rh #388471) * Wed Dec 05 2007 Dan Williams - 1:0.7.0-0.8.svn3138 - Fix applet connection comparison which failed to send connection updated signals to NM in some cases - Make VPN connection applet more robust against plugin failures PackageKit-0.1.4-3.fc9 ---------------------- * Mon Dec 17 2007 Robin Norwood - 0.1.4-3 - fix rpm -V issues by ghosting data files - Resolves: rhbz#408401 PolicyKit-0.7-4.fc9 ------------------- * Thu Dec 06 2007 David Zeuthen - 0.7-4.fc9 - Only run bash completion script if using bash (#418471) * Thu Dec 06 2007 David Zeuthen - 0.7-3.fc9 - Conflict with older hal release * Thu Dec 06 2007 David Zeuthen - 0.7-2.fc9 - BR intltool and adjust License to MIT PolicyKit-gnome-0.7-2.fc9 ------------------------- * Tue Dec 18 2007 David Zeuthen - 0.7-2.fc9 - Avoid crashing when an authorization is blocked for a user without ~/.face acpitool-0.4.7-2.fc9 -------------------- * Thu May 24 2007 Patrice Dumas 0.4.7-2 - update to 0.4.7 * Fri Oct 06 2006 Patrice Dumas 0.4.6-2 - set Group to Applications/System (fix #209230) * Mon Aug 28 2006 Patrice Dumas 0.4.6-1 - update to 0.4.6 adns-1.4-2.fc9 -------------- * Wed Dec 19 2007 Adam Tkac 1.4-2 - don't ship static libadns.a * Wed Dec 19 2007 Adam Tkac 1.4-1 - updated to 1.4 - CVS cleanup - use autoreconf - build with -fpic instead -fPIC anaconda-11.4.0.11-1 -------------------- * Mon Dec 17 2007 Jeremy Katz - 11.4.0.11-1 - Validation of root password with cracklib (hhara) - Minor fixes to liveinst shell script (katzj) - Fix path to swapoff (katzj) - Make doMethodComplete not depend on the yum backend (katzj) - Remove another line related to the release notes (hhara) - GPLv2+ changes. (dcantrell) asterisk-1.4.16-1.fc9 --------------------- * Tue Dec 18 2007 Jeffrey C. Ollie - 1.4.16-1 - Update to 1.4.16 to fix security bug. asunder-1.0-1.fc9 ----------------- * Tue Dec 18 2007 Marcin Zajaczkowski - 1.0-1 - updated to 1.0 autofs-1:5.0.2-23 ----------------- * Tue Dec 18 2007 Ian Kent - 5.0.2-23 - Bug 397591 SELinux is preventing /sbin/rpc.statd (rpcd_t) "search" to (sysctl_fs_t). - prevent fork between fd open and setting of FD_CLOEXEC. avahi-0.6.22-4.fc9 ------------------ * Tue Dec 18 2007 Lubomir Kundrak - 0.6.22-4 - Make bvnc call vncviewer instead of xvncviewer - Let ui-tools depend on necessary packages * Mon Dec 17 2007 Lennart Poettering - 0.6.22-3 - Add missing intltool dependency * Mon Dec 17 2007 Lennart Poettering - 0.6.22-2 - Fix mistag babl-0.0.16-1.fc9 ----------------- * Mon Nov 26 2007 Deji Akingunola - 0.0.16-1 - Update to 0.0.16 release - License change from GPLv2+ to GPLv3+ bitmap-1.0.3-3.fc9 ------------------ * Mon Dec 17 2007 Patrice Dumas 1.0.3-3 - keep timestamps * Mon Jan 29 2007 Patrice Dumas 1.0.3-2 - update to 1.0.3 * Tue Oct 10 2006 Patrice Dumas 1.0.2-3 - use consistently %{buildroot} - provides xorg-x11-%{name}-devel bzflag-2.0.10-1.fc9 ------------------- * Mon Dec 17 2007 Nils Philippsen 2.0.10-1 - version 2.0.10 claws-mail-3.2.0-1.fc9 ---------------------- * Mon Dec 17 2007 Andreas Bierfert - 3.2.0-1 - version upgrade control-center-1:2.21.2-3.fc9 ----------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.2-3 - Support the gtk-im-module setting cppunit-1.12.0-4.fc9 -------------------- * Mon Dec 17 2007 Patrice Dumas 1.12.0-4 - remove libdir reference to cppunit-config, should fix multiarch conflict (#340951) - fix encoding and remove windows related files in examples - keep timestamps cups-1:1.3.5-1.fc9 ------------------ * Tue Dec 18 2007 Tim Waugh 1:1.3.5-1 - 1.3.5. * Mon Dec 10 2007 Tim Waugh 1:1.3.4-5 - Rebuilt with higher release number. * Tue Dec 04 2007 Warren Togami 1:1.3.4-3 - rebuild cyphesis-0.5.15-2.fc9 --------------------- * Tue Dec 18 2007 Wart 0.5.15-2 - Move log files so they get they get the correct context ecryptfs-utils-36-0.fc9 ----------------------- * Tue Dec 18 2007 Mike Halcrow 36-0 - Cipher selection detects .gz ko files; bump to version 36 * Mon Dec 17 2007 Mike Halcrow 35-0 - Cleanups to cipher selection; bump to version 35 * Mon Dec 17 2007 Mike Halcrow 34-0 - Fix OpenSSL key module; bump to version 34 elektra-0.6.10-6.fc9 -------------------- * Mon Dec 17 2007 Patrice Dumas 0.6.10-6 - keep some timestamps. Many are not kept since some files are generated, and install-sh is used for others (with nobase_) empathy-0.21.4-1.fc9 -------------------- * Mon Dec 17 2007 Peter Gordon - 0.21.4-1 - Update to new upstream release (0.21.4) eog-2.21.3-1.fc9 ---------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 epiphany-2.21.4-1.fc9 --------------------- * Mon Dec 17 2007 Christopher Aillon - 2.21.4-1 - Update to 2.21.4 * Thu Nov 29 2007 Martin Stransky - Polished the wrapper patch esmtp-0.6.0-3.fc9 ----------------- * Tue Dec 18 2007 Patrice Dumas 0.6.0-3 - keep more timestamps - add a Requires(preun) for alternatives evolution-2.21.4-1.fc9 ---------------------- * Mon Dec 17 2007 Matthew Barnes - 2.21.4-1.fc9 - Update to 2.21.4 - Expunge unused patches. - Bump eds_version to 2.21.4 for new Camel functions. * Mon Dec 10 2007 Matthew Barnes - 2.21.3-4.fc9 - Split junk filtering plugins into evolution-bogofilter and evolution-spamassassin subpackages, each of which requires the necessary backend packages. (RH bug #377381) * Wed Dec 05 2007 Matthew Barnes - 2.21.3-3.fc9 - Bump eds_version to 2.21.3 and gtkhtml_version to 3.17.3. evolution-data-server-2.21.4-1.fc9 ---------------------------------- * Mon Dec 17 2007 Matthew Barnes - 2.21.4-1.fc9 - Update to 2.21.4 - Require gtk-doc >= 1.9. evolution-exchange-2.21.4-1.fc9 ------------------------------- * Mon Dec 17 2007 Matthew Barnes - 2.21.4-1.fc9 - Update to 2.21.4 - Bump eds_version to 2.21.4 for new Camel functions. exiv2-0.16-0.3.pre1.fc9 ----------------------- * Mon Dec 17 2007 Rex Dieter 0.16-0.3.pre1 - CVE-2007-6353 (#425921, #425924) * Mon Nov 26 2007 Rex Dieter 0.16-0.2.pre1 - -libs subpkg toggle (f8+) factory-3.0.3-1.fc9 ------------------- * Tue Dec 18 2007 Rex Dieter 3.0.3-1 - factory-3-0-3 fbreader-0.8.8-2.fc9 -------------------- * Wed Dec 19 2007 Michel Salim - 0.8.8-2 - Fix inclusion of debug files where libdir=/usr/lib (bz #411891) freeipmi-0.5.1-1.fc9 -------------------- * Tue Dec 18 2007 Phil Knirsch 0.5.1-1 - Update to freeipmi-0.5.1 * Mon Nov 19 2007 Albert Chu 0.5.0 - Remove ipmimonitoring subpackage. Merge into head package. ganglia-3.0.6-1.fc9 ------------------- * Mon Dec 17 2007 Jarod Wilson 3.0.6-1 - New upstream release (security fix for web frontend cross-scripting vulnerability) gcalctool-5.21.4-1.fc9 ---------------------- * Tue Dec 18 2007 Matthias Clasen - 5.21.4-1 - Update to 5.21.4 gegl-0.0.14-1.fc9 ----------------- * Sat Dec 08 2007 Deji Akingunola - 0.0.14-1 - Update to 0.0.14 release - License change from GPLv2+ to GPLv3+ gimp-2:2.4.3-1.fc9 ------------------ * Mon Dec 17 2007 Nils Philippsen - 2:2.4.3-1 - version 2.4.3 Changes in GIMP 2.4.3 ===================== - avoid filename encoding problems in the WMF import plug-in (bug #499329) - fixed horizontal flipping of linked layers (bug #499161) - fixed a missing update in the Lighting plug-in UI (bug #500317) - fixed a potential crash in the projection code (bug #500178) - fixed a minor Makefile issue (bug #500826) - removed some pointless warnings from the JPEG and TIFF load plug-ins - fixed size calculation for the image size warning dialog (bug #329468) - fixed loading of tool options for the rectangle tools (bug #498948) - push/pop a context in the Fog filter - fixed potential crashes in the Python binding - corrected grid drawing with non-integer spacing (bug #502374) - fixed grid snapping for coordinates less than the grid offset - made the healing brush work properly when dragged (bug #492575) - update tool state when a device change happens (bug #493176) - improved validation of strings sent over the wire (bug #498207) - fixed integer check in Script-Fu (bug #498207) - fixed potential out-of-memory problem in Script-Fu - translation updates (ca, cs, de, gl, it, ko, lt, sv, uk) * Wed Nov 28 2007 Nils Philippsen - 2:2.4.2-2 - fix typo to build internal print plugin from F8 onwards (#401931) * Thu Nov 22 2007 Nils Philippsen - 2:2.4.2-1 - version 2.4.2 Changes in GIMP 2.4.2 ===================== - removed broken and useless HSV Graph script (bug #491311) - update the histogram when a color correction tool is cancelled (bug #493639) - fixed a crash with certain plug-in or script descriptions (bug #492718) - corrected a tooltip (bug #495564) - fixed a crash when GIMP is run without any modules (bug #495863) - fixed error handling in the TIFF plug-in - fixed a problem with Sample points - fixed a crash when merging layers in indexed image (bug #495990) - update the histogram when painting (bug #494049) - fixed another problem with merge operations on indexed images (bug #496437) - fixed crash in TIFF plug-in when saving indexed images (bug #497103) - changed defaults so that a system monitor profile is only used when the user explicitely enabled this feature (bug #496890) - fixed endless loop when running equalize on transparent areas (bug #497291) - fixed heap corruption in GimpColorScale widget that caused a crash in the Compose plug-in (bug #399484) - fixed use of background color in Particle Trace script (bug #498282) - set the image menu insensitive when there's no image opened (bug #498511) - translation updates (ca, et, it, lt, pt, pt_BR, sr, sv) glabels-2.1.5-1.fc9 ------------------- * Sun Dec 16 2007 Peter Gordon - 2.1.5-1 - Update to new upstream development snapshot (2.1.5). gnome-games-1:2.21.4-1.fc9 -------------------------- * Tue Dec 18 2007 Matthias Clasen - 1:2.21.4-1 - Update to 2.21.4 gnome-icon-theme-2.21.4-1.fc9 ----------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-keyring-2.21.4-1.fc9 -------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-python2-desktop-2.21.1-1.fc9 ---------------------------------- * Sun Dec 16 2007 Matthew Barnes - 2.21.1-1.fc9 - Update to 2.21.1 - New subpackage: gnome-python2-evolution - Change totem-devel BR to totem-pl-parser-devel. gnome-system-monitor-2.21.4-1.fc9 --------------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnucash-2.2.2-1.fc9 ------------------- * Tue Dec 18 2007 Bill Nottingham - 2.2.2-1 - update to 2.2.2 * Thu Oct 25 2007 Bill Nottingham - 2.2.1-4 - multilib fixes (#341331, #357161, #246382) * Wed Oct 10 2007 Bill Nottingham - 2.2.1-3 - silence binreloc warning gnupg2-2.0.8-0.1.rc1.fc9 ------------------------ * Mon Dec 17 2007 Rex Dieter 2.0.8-0.1.rc1 - gnupg2-2.0.8rc1 gpsbabel-1.3.4-1.fc9 -------------------- gtk-doc-1.9-2.fc9 ----------------- * Tue Dec 18 2007 Matthias Clasen - 1.9-2 - Fix a problem in gtk-doc.make gtk2-2.12.3-4.fc9 ----------------- * Tue Dec 18 2007 Matthias Clasen - 2.12.3-4 - Fix a gtk-doc problem - Work around a kernel problem in the build system * Mon Dec 17 2007 Matthias Clasen - 2.12.3-3 - Add a setting to change input methods gtk2-engines-2.13.2-1.fc9 ------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 * Wed Dec 05 2007 Matthias Clasen - 2.13.1-1 - Update to 2.13.1 gtkdatabox-0.8.2.0-1.fc9 ------------------------ * Tue Dec 18 2007 Eric Work 0.8.2.0-1 - new upstream version - drop patch compilefix - enable libglade support gtkhtml3-3.17.4-1.fc9 --------------------- * Mon Dec 17 2007 Matthew Barnes - 3.17.4-1.fc9 - Update to 3.17.4 gtkpod-0.99.12-1.fc9 -------------------- * Tue Dec 11 2007 Todd Zullinger - 0.99.12-1 - update to 0.99.12 gucharmap-2.21.4-1.fc9 ---------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 hexedit-1.2.12-8.fc9 -------------------- * Mon Dec 17 2007 Jiri Moskovcak - 1.2.12-8 - minor spec file fixes hunspell-bg-4.1-1.fc9 --------------------- * Tue Dec 18 2007 Caolan McNamara - 4.1-1 - latest version imlib-1:1.9.15-6.fc9 -------------------- * Tue Dec 18 2007 Paul Howarth 1:1.9.15-6 - include patch to fix a DoS caused via a BMP image with a Bits Per Page (BPP) value of 0 (#426091, CVE-2007-3568); thanks to Peter Volkov at Gentoo for the heads-up - remove URL tag; this legacy package has no active upstream source, and documentation for it is gradually disappearing from the Internet * Wed Nov 28 2007 Adam Jackson 1:1.9.15-5 - imlib-1.9.15-check-for-shm-pixmaps.patch: MIT-SHM pixmaps are optional, so check that they exist before using them. (#357241) * Thu Aug 09 2007 Paul Howarth 1:1.9.15-4 - re-clarify license as GNU Lesser General Public License v2 or later (LGPLv2+) isomaster-1.3-1.fc9 ------------------- * Tue Dec 18 2007 Marcin Zajaczkowski - 1.3-1 - updated to 1.3 isync-1.0.3-6.fc9 ----------------- * Mon Dec 17 2007 Lubomir Kundrak 1.0.3-6 - gmail returns SEARCH with no argument (#420721) iwl4965-firmware-4.44.1.20-1 ---------------------------- * Tue Dec 18 2007 kwizart < kwizart at gmail.com > - 4.44.1.20-1 - Update v1 to 4.44.1.20 - Improve keep timestramps - Obsoletes iwlwifi-4965-ucode jd-1.9.8-0.4.beta071218.fc9 --------------------------- * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 * Sun Dec 09 2007 Mamoru Tasaka - Switch from openssl to gnutls jfbterm-0.4.7-15.fc9 -------------------- * Mon Dec 17 2007 Mamoru Tasaka - 0.4.7-15 - Supress gcc warning on 64 bits kdebase-workspace-3.97.0-3.fc9 ------------------------------ * Mon Dec 17 2007 Rex Dieter 3.97.0-3 - Requires: coreutils dbus-x11 xorg-x11-apps xorg-x11-utils xorg-x11-server-utils (used in startkde) - drop pam configs that were previously moved to kde-settings kdebase3-3.5.8-24.fc9 --------------------- * Mon Dec 17 2007 Rex Dieter - 3.5.8-24 - Requires: coreutils mktemp xorg-x11-apps xorg-x11-utils xorg-x11-server-utils (used in startkde) - include htdig,man deps (and new startkde ones) in non-compat pkg only * Thu Dec 13 2007 Rex Dieter - 3.5.8-22 - nspluginviewer: respin flash patch with +gtk_init (#410651) - use kde's kde.desktop for xsession support kdelibs-6:3.97.0-8.fc9 ---------------------- * Tue Dec 18 2007 Kevin Kofler 3.97.0-8 - don't put binaries into kdelibs-common, they drag in kdelibs (#417251) * Mon Dec 17 2007 Kevin Kofler 3.97.0-7 - split out kdelibs-common on F9+ (shared with KDE 3) (#417251) - Requires: kdelibs-common (F9+) (#417251) kdelibs3-3.5.8-20.fc9 --------------------- * Mon Dec 17 2007 Kevin Kofler 3.5.8-20 - Requires: kdelibs-common (F9+) (#417251) kdesdk-3.97.0-8.fc9 ------------------- * Wed Dec 19 2007 Kevin Kofler 3.97.0-8 - update Kompare from SVN (rev 750443) kernel-2.6.24-0.115.rc5.git5.fc9 -------------------------------- * Wed Dec 19 2007 Dave Airlie - Update drm upstream patches and add basic r500 drm support * Tue Dec 18 2007 Chuck Ebbert - Enable CIFS upcall support. * Tue Dec 18 2007 Kyle McMartin - add --with sparse for people^Wsomeone who might care libepc-0.3.1-1.fc9 ------------------ * Tue Dec 18 2007 Brian Pepple - 0.3.1-1 - Update to 0.3.1. - drop pk-config patch. fixed upstream. libfac-3.0.3-1.fc9 ------------------ * Tue Dec 18 2007 Rex Dieter 3.0.3-1 - libfac-3.0.3 libflaim-4.9.989-18.fc9 ----------------------- * Mon Dec 17 2007 Christopher Brown - 4.9.989-18 - exclude static archive from devel package * Sun Nov 18 2007 Christopher Brown - 4.9.989-17 - bump releasever libgdiplus-1.2.6-1.fc9 ---------------------- * Thu Nov 22 2007 Paul F. Johnson 1.2.6-1 - bump to latest preview version libgnome-2.20.1-3.fc9 --------------------- * Tue Dec 18 2007 Matthias Clasen - 2.20.1-3 - Add schema for gtk-im-module GConf key libgnomekbd-2.21.4.1-1.fc9 -------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4.1-1 - Update to 2.21.4.1 libgpod-0.6.0-2.fc9 ------------------- * Wed Dec 19 2007 Todd Zullinger - 0.6.0-2 - add the NEWS file, which contains some info on getting newer iPods working - split out API docs into a separate package - set %defattr for python-gpod libnl-1.0-0.15.pre8.git20071218.fc9 ----------------------------------- * Tue Dec 18 2007 Dan Williams - 1.0-0.15.pre8.git20071218 - Handle removal of include/linux/ip_mp_alg.h in 2.6.24 * Tue Dec 18 2007 Dan Williams - 1.0-0.14.pre8.git20071217 - devel package should require kernel-headers * Mon Dec 17 2007 Dan Williams - 1.0-0.13.pre8.git20071217 - Add dist tag to revision librtas-1.3.3-2.fc9 ------------------- * Tue Dec 18 2007 David Cantrell - 1.3.3-2 - Spec cleanups * Tue Dec 18 2007 David Cantrell - 1.3.3-1 - Upgraded to librtas-1.3.3 (#253522) libtirpc-0.1.7-14.fc9 --------------------- * Mon Dec 17 2007 Steve Dickson 0.1.7-14 - Fixed typo in /etc/netconfig file (bz 414471) libvirt-0.4.0-1.fc9 ------------------- * Tue Dec 18 2007 Daniel Veillard - 0.4.0-1.fc8 - Release of 0.4.0 - SASL based authentication - PolicyKit authentication - improved NUMA and statistics support - lots of assorted improvements, bugfixes and cleanups - documentation and localization improvements libwpd-0.8.13-2.fc9 ------------------- * Mon Dec 17 2007 Caolan McNamara - 0.8.13-2 - strangely 0.8.13-1 never appeared in rawhide lm_sensors-3.0.0-3.fc9 ---------------------- * Tue Dec 18 2007 Hans de Goede 3.0.0-3 - Fix sensors.conf errors with certain chips (patch send in by upstream) lyx-1.5.3-1.fc9 --------------- * Mon Dec 17 2007 Rex Dieter 1.5.3-1 - lyx-1.5.3 * Tue Dec 04 2007 Rex Dieter 1.5.2-2 - drop scriptlet optimization hack m17n-contrib-1.1.3-4.fc9 ------------------------ * Tue Dec 18 2007 Parag Nemade -1.1.3-4.fc9 - Resolves: rh#404081, rh#419691 * Mon Aug 13 2007 Parag Nemade - update License tag m4-1.4.10-2.fc9 --------------- * Mon Dec 17 2007 Vitezslav Crhonek - 1.4.10-2 - Fix vasnprintf puts %n into a writeable format string in all cases Resolves: #345651 man-pages-2.73-1.fc9 -------------------- * Mon Dec 17 2007 Ivana Varekova - 2.73-1 - update to 2.73 * Tue Dec 04 2007 Ivana Varekova - 2.69-1 - update to 2.69 * Thu Nov 22 2007 Ivana Varekova - 2.68-1 - update to 2.68 man-pages-fr-2.40.0-11.fc9 -------------------------- * Tue Dec 18 2007 Marcela Maslanova 2.40.0-11 - fix #425051 exclude vipw * Tue Sep 18 2007 Marcela Maslanova 2.40.0-10 - rebuild with correct sources man-pages-ja-20071215-1.fc9 --------------------------- * Mon Dec 17 2007 Akira TAGOH - 20071215-1 - updates to 20071215. - remove vipw.8 to solve the file conflict to shadow-utils. man-pages-pl-0.24-4.fc9 ----------------------- * Mon Dec 17 2007 Ivana Varekova - 0.24-4 - remove groupmems.8 (#425778) maxima-5.13.99-0.3.rc2.fc9 -------------------------- * Mon Dec 17 2007 Rex Dieter 5.13.99-0.3.rc2 - disable gcl (for now, doesn't build atm) * Mon Dec 17 2007 Rex Dieter 5.13.99-0.2.rc2 - maxima-5.13.99rc2 mcrypt-2.6.7-1.fc9 ------------------ * Mon Dec 17 2007 Tom "spot" Callaway 2.6.7-1 - 2.6.7 - fix bugs in rfc2440.c (resolves bugzilla 418481) metacity-2.21.5-1.fc9 --------------------- * Wed Dec 19 2007 Matthias Clasen - 2.21.5-1 - Update to 2.21.5, including the new compositor mfiler2-4.0.0e-1.fc9 -------------------- * Wed Dec 19 2007 Mamoru Tasaka - 4.0.0e-1 - 4.0.0e ntl-5.4.1-1.fc9 --------------- * Sat Dec 08 2007 Rex Dieter 5.4.1-1 - ntl-5.4.1 orca-2.21.4-1.fc9 ----------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 pango-1.19.2-1.fc9 ------------------ * Tue Dec 18 2007 Matthias Clasen - 1.19.2-1 - Update to 1.19.2 perl-Email-MIME-Attachment-Stripper-1.314-2.fc9 ----------------------------------------------- * Fri Nov 30 2007 Tom "spot" Callaway - 1.314-2 - add missing BR perl-ExtUtils-PkgConfig-1.08-1.fc9 ---------------------------------- * Fri Nov 30 2007 Tom "spot" Callaway - 1.08-1 - 1.08 perl-File-HomeDir-0.66-1.fc9 ---------------------------- * Fri Nov 30 2007 Tom "spot" Callaway - 0.66-1 - 0.66 perl-File-MMagic-XS-0.09003-1.fc9 --------------------------------- * Mon Dec 17 2007 Tom "spot" Callaway 0.09003-1 - bump to 0.09003 perl-Geo-Functions-0.07-1.fc9 ----------------------------- * Mon Dec 17 2007 Tom "spot" Callaway - 0.07-1 - bump to 0.07 perl-Sub-Uplevel-0.18-1.fc9 --------------------------- * Mon Dec 17 2007 Ralf Cors??pius - 0.18-1 - Update to 0.18. perl-Tk-804.027-13.fc9 ---------------------- * Wed Dec 19 2007 Andreas Bierfert - 804.027-13 - fix BR picard-0.9.0-5.fc9 ------------------ * Wed Dec 19 2007 Alex Lancaster 0.9.0-5 - Add support for python eggs for F9+ * Wed Dec 19 2007 Alex Lancaster 0.9.0-4 - Update to proper release: 0.9.0 - Drop plugins directory patch, applied upstream policycoreutils-2.0.33-4.fc9 ---------------------------- * Wed Dec 19 2007 Dan Walsh 2.0.33-4 - Fix sepolgen to be able to parse Fedora 9 policy Handle ifelse statements Handle refpolicywarn inside of define Add init.if and inetd.if into parse Add parse_file to syntax error message proftpd-1.3.1-3.fc9 ------------------- * Mon Dec 17 2007 Matthias Saou 1.3.1-3 - Rebuild for new openssl, patch from Paul Howarth. * Mon Oct 22 2007 Matthias Saou 1.3.1-2 - Include openldap schema file for quota support (Fran Taylor, #291891). - Include FDS compatible LDIF file for quota support (converted). - Prefix source welcome.msg for consistency. puppet-0.24.0-2.fc9 ------------------- * Mon Dec 17 2007 David Lutterkort - 0.24.0-2 - Use updated upstream tarball that contains yumhelper.py python-nevow-0.9.26-1.fc9 ------------------------- * Mon Dec 17 2007 Matthias Saou 0.9.26-1 - Update to 0.9.26. - Include new egg directory and twisted/plugins/nevow_widget.py files. qtpfsgui-1.9.0-1.fc9 -------------------- * Sun Dec 16 2007 Douglas E. Warner 1.9.0-1 - update to version 1.9.0 rhpxl-0.49-3.fc9 ---------------- * Mon Dec 17 2007 Jeremy Katz - 0.49-3 - Fix traceback in last patch (#421261) rpcbind-0.1.4-12.fc9 -------------------- * Mon Dec 17 2007 Steve Dickson 0.1.4-12 - Changed is_loopback() and check_access() see if the calling address is an address on a local interface, just not a loopback address (bz 358621). rxvt-unicode-8.8-1.fc9 ---------------------- * Mon Dec 17 2007 Andreas Bierfert - 8.8-1 - version upgrade sear-0.6.3-7.fc9 ---------------- * Tue Dec 18 2007 Wart 0.6.3-7 - Add patch to support eris-1.3.13 selinux-policy-3.2.4-5.fc9 -------------------------- * Wed Dec 19 2007 Dan Walsh 3.2.4-5 - Fix munin file context * Tue Dec 18 2007 Dan Walsh 3.2.4-4 - Allow cron to run unconfined apps * Mon Dec 17 2007 Dan Walsh 3.2.4-3 - Modify default login to unconfined_u shared-mime-info-0.23-1.fc9 --------------------------- * Tue Dec 18 2007 - Bastien Nocera - 0.23-1 - Update to 0.23 swfdec-0.5.5-1.fc9 ------------------ * Mon Dec 17 2007 Brian Pepple - 0.5.5-1 - Update to 0.5.5. swfdec-gnome-0.5.5-1.fc9 ------------------------ swfdec-mozilla-0.5.5-1.fc9 -------------------------- * Mon Dec 17 2007 Brian Pepple - 0.5.5-1 - Update to 0.5.5. sylpheed-2.4.7-4 ---------------- * Mon Dec 17 2007 Michael Schwendt - 2.4.7-4 - Upstreamed patch lead to discovery of similar memory leaks in syldap.c system-config-printer-0.7.78-3.fc9 ---------------------------------- * Mon Dec 17 2007 Tim Waugh 0.7.78-3 - Install Python egg-info file. - Updated pycups to 1.9.32. system-config-rootpassword-1.99.3-1.fc9 --------------------------------------- * Tue Dec 18 2007 Lubomir Kundrak - 1.99.3-1 - New version to address various issues to pass the review #226467 * Wed Nov 21 2007 Lubomir Kundrak - 1.99.2-1 - New versions, with two new translations and more correct desktop file - pygtk2 is actually not needed, s-c-r happily runs in text mode * Wed Nov 21 2007 Lubomir Kundrak - 1.99.0-1 - Bump version taxipilot-0.9.2-5.fc9 --------------------- * Wed Dec 19 2007 Hans de Goede 0.9.2-5 - Add patch by Rex Dieter to no longer BuildRequire kdemultimedia3-devel, as that is going away, we now require arts-devel instead (bz 410851) - Revert "Put our own private lib in a subdir of /usr/lib so that we no longer become multilib (bz 343261)" change, as that breaks sound - Add a patch which ensures artsd gets started if needed texlive-texmf-2007-4.fc9 ------------------------ * Mon Dec 17 2007 Jindrich Novy - 2007-4 - fix cmap path sed substitution * Mon Dec 10 2007 Jindrich Novy - 2007-3 - readd symlinks to gs maps (#418091) * Thu Dec 06 2007 Jindrich Novy - 2007-2 - don't conflict with tetex-doc (#413141) - remove tex4ht from texlive, it's packaged separately (#411501) tile-0.8.2-1.fc9 ---------------- * Sun Dec 16 2007 Wart - 0.8.2-1 - Update to 0.8.2 tokyocabinet-1.1.4-1.fc9 ------------------------ tomboy-0.9.2-1.fc9 ------------------ * Tue Dec 18 2007 Matthias Clasen - 0.9.2-1 - Update to 0.9.2 tracker-0.6.4-3.fc9 ------------------- * Fri Dec 14 2007 Deji Akingunola - 0.6.4-3 - Undo the patch, seems to be issues (bug #426060) vinagre-0.4-1.fc9 ----------------- * Thu Dec 13 2007 - Bastien Nocera - 0.4-1 - Update to 0.4 and drop obsolete patches wireshark-0.99.7-2.fc9 ---------------------- * Wed Dec 19 2007 Radek Vok??l 0.99.7-2 - fix crash in unprivileged mode (#317681) * Tue Dec 18 2007 Radek Vok??l 0.99.7-1 - upgrade to 0.99.7 xchat-1:2.8.4-8.fc9 ------------------- * Wed Dec 19 2007 Kevin Kofler - 1:2.8.4-8 - apply xc284-fix-scrollbfdleak.diff from upstream xfce-mcs-plugins-4.4.2-2.fc9 ---------------------------- * Mon Dec 17 2007 Kevin Fenzi - 4.4.2-2 - Add patch for mouse button crash (fixes #425925) xorg-x11-drv-ati-6.7.196-3.fc9 ------------------------------ * Wed Dec 19 2007 Dave Airlie 6.7.196-3 - radeon-git-upstream-fixes.patch - update for latest git master - radeon-6.7.196-atombios-support.patch - update for r500/r600 * Mon Dec 17 2007 Adam Jackson 6.7.196-2 - *-6.7.196-alloca.patch: Fix ALLOCATE_LOCAL failures. * Wed Nov 14 2007 Adam Jackson 6.7.196-1 - xf86-video-ati 6.7.196 xorg-x11-drv-vmmouse-12.4.3-2.fc9 --------------------------------- * Tue Dec 18 2007 Jeremy Katz - 12.4.3-2 - Rebuild for new xserver xorg-x11-fonts-7.2-5.fc9 ------------------------ * Tue Dec 18 2007 Tom "spot" Callaway - 7.2-5 - Remove bh-ttf and bh-type1 (Luxi fonts) and truetype subpackage, due to licensing issues (#317641) - Correct license tag yum-updatesd-1:0.9-1.fc9 ------------------------ * Mon Dec 17 2007 Jeremy Katz - 1:0.9-1 - More mail fixes (Pierre Ossman) * Wed Dec 05 2007 Jeremy Katz - 1:0.8-1 - Use sendmail (Pierre Ossman, #397711) - Don't wake up as often (#391571) - Improve mail output (Pierre Ossman, #387181) - Fix some tracebacks (#387051, #374801) * Fri Oct 12 2007 Jeremy Katz - 1:0.7-1 - fix error when download is set, but no packages are available (#329361) zabbix-1.4.4-1.fc9 ------------------ * Mon Dec 17 2007 Jarod Wilson - 1.4.4-1 - New upstream release - Fixes two crasher bugs in 1.4.3 release Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nagios-plugins-snmp-disk-proc - 1.0-3.fc7.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.x86_64 requires libcrypto.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc requires libcrypto.so.6 octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) nagios-plugins-snmp-disk-proc - 1.0-3.fc7.ppc64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) From tcallawa at redhat.com Wed Dec 19 22:02:47 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Dec 2007 17:02:47 -0500 Subject: Mock: loss of login shell In-Reply-To: <20071219170202.14209ad9@redhat.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <20071219161242.1a54e2b7@redhat.com> <200712192222.34262.opensource@till.name> <20071219170202.14209ad9@redhat.com> Message-ID: <1198101767.3400.30.camel@localhost.localdomain> On Wed, 2007-12-19 at 17:02 -0500, Jesse Keating wrote: > On Wed, 19 Dec 2007 22:22:23 +0100 > Till Maas wrote: > > > This is how it works with every package that drops something > > into /etc/profile.d. Why is it not right for -devel packages? > > I didn't ask if it was done elsewhere. I think it's a terrible user > experience, that if use of a package is going to depend on shell > variables, and you have to reload your environment to make use of them. Perhaps these scripts should be sourced in %post? ~spot From jos at xos.nl Wed Dec 19 22:08:40 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 19 Dec 2007 23:08:40 +0100 Subject: Mock: loss of login shell In-Reply-To: <20071219170202.14209ad9@redhat.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <20071219161242.1a54e2b7@redhat.com> <200712192222.34262.opensource@till.name> <20071219170202.14209ad9@redhat.com> Message-ID: <20071219220840.GB15878@jasmine.xos.nl> On Wed, Dec 19, 2007 at 05:02:02PM -0500, Jesse Keating wrote: > I didn't ask if it was done elsewhere. I think it's a terrible user > experience, that if use of a package is going to depend on shell > variables, and you have to reload your environment to make use of them. I see your point, but by adding packages you're in fact changing your system. Sometimes even a reboot is required. And when your package has a service that is started by default (and thus is expected to run after installing the package), this service will only be started after a reboot (or manually, of course). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jos at xos.nl Wed Dec 19 22:10:48 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 19 Dec 2007 23:10:48 +0100 Subject: Mock: loss of login shell In-Reply-To: <1198101767.3400.30.camel@localhost.localdomain> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <20071219161242.1a54e2b7@redhat.com> <200712192222.34262.opensource@till.name> <20071219170202.14209ad9@redhat.com> <1198101767.3400.30.camel@localhost.localdomain> Message-ID: <20071219221048.GC15878@jasmine.xos.nl> On Wed, Dec 19, 2007 at 05:02:47PM -0500, Tom spot Callaway wrote: > Perhaps these scripts should be sourced in %post? Useless, as %post is an own shell, everything sourced there is lost immediately. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From walters at redhat.com Wed Dec 19 22:21:32 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Dec 2007 17:21:32 -0500 Subject: Mock: loss of login shell In-Reply-To: <20071219210010.GA15878@jasmine.xos.nl> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> Message-ID: <1198102892.6556.8.camel@space-ghost.verbum.private> On Wed, 2007-12-19 at 22:00 +0100, Jos Vos wrote: > On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote: > > > Mock no longer uses a login shell for builds. > > > > The way I discovered this is that the ipsec-tools package stopped > > building. The reason is that it has a BuildRequires for the krb5-devel > > package, from which it uses krb5-config. > > > > krb5-config is installed in /usr/kerberos/bin/, and the user's path is > > provided by /etc/profile.d/krb5-devel.sh > > > > No user shell, therefore no path, and configure fails to find krb5-config. > > I think mock is wrong. It's obvious that the devel packages assume > developers (like package builders, either human or not ;-)) run the > /etc/profile.d scripts. T It's only broken development packages which require setting environment variables like this. The correct way to do parallel installation is: http://www106.pair.com/rhp/parallel.html I'm sure there's some historical reason krb5-config is not in /usr/bin, but it's a design flaw in the software. The environment variable approach seems easy (no need to rename binaries), but falls over when you need to compile applications against multiple library versions. From Michael_E_Brown at dell.com Wed Dec 19 22:22:54 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 16:22:54 -0600 Subject: Mock: loss of login shell In-Reply-To: <47697B8D.1020107@redhat.com> References: <47697B8D.1020107@redhat.com> Message-ID: <20071219222254.GB5428@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote: > This was covered briefly in a couple of emails on this list a couple of > weeks ago but I see this as a bug, further discussion please . . . > > Mock no longer uses a login shell for builds. Incorrect. Mock *NEVER* used a login shell for builds. It *just* *so* *happened* that your personal account's environment variables *leaked* into the chroot. This is wrong on so many different levels it's not even funny. If your host environment variables were different from the chroot's (building F-9 packages on F-7 host, for instance) and any of the paths were changed, then your build would silently get the wrong results. The new mock behaviour is that the environment is cleaned, and host environment variables wont get leaked into the chroot. > The way I discovered this is that the ipsec-tools package stopped > building. The reason is that it has a BuildRequires for the krb5-devel > package, from which it uses krb5-config. > > krb5-config is installed in /usr/kerberos/bin/, and the user's path is > provided by /etc/profile.d/krb5-devel.sh > > No user shell, therefore no path, and configure fails to find krb5-config. > > The simple solution for this is to add the following to the %build > section of the spec file for ipsec-tools: > > source /etc/profile.d/krb5-devel.sh Seems to me pkgconfig or some other such mechanism should be preferred over /etc/profile.d/. What happens to those poor users who use an alternate shell? > Having put that into the spec file, there's potential for what would > otherwise be a perfectly acceptable change to the krb5 package to break > builds of other packages that have a BuildRequire for it. pkgconfig. > I'm afraid that this might lead to a proliferation of small changes to > spec files that create unneeded dependencies. > > I'm interested in what other people think about this. A) We wont ever again let host env vars pollute the chroot. period. B) Why not just do a %post -p '/bin/bash -l'? -- Michael From galibert at pobox.com Wed Dec 19 22:58:57 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 19 Dec 2007 23:58:57 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <604aa7910712191243l3317652cx4c84ba2081b2d5fd@mail.gmail.com> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> <20071219094603.GJ9741@tango.0pointer.de> <47697974.4060401@gmail.com> <604aa7910712191243l3317652cx4c84ba2081b2d5fd@mail.gmail.com> Message-ID: <20071219225857.GA84674@dspnet.fr.eu.org> On Wed, Dec 19, 2007 at 11:43:42AM -0900, Jeff Spaleta wrote: > I think the underlying problem is that advanced hardware access policy > technology is advancing far more rapidly than local administrators are > able to keep up with and its disrupting workflow that has been used > for years. Yes, there is a lot of that. You also have to add the fact that some of these newflangled thingies sometimes do not have the capability to cover what the previous systems could do, as we can see in NM's case. So there are two steps there, find out what the new system can actually do, and how it can be configured to do it. Of course, having the main maintainer taking questions trying to answer that as personal attacks on his work is not making the task easy. OG. From Michael_E_Brown at dell.com Wed Dec 19 23:13:17 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 17:13:17 -0600 Subject: Mock: loss of login shell In-Reply-To: <1198102892.6556.8.camel@space-ghost.verbum.private> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> Message-ID: <20071219231316.GC5428@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 05:21:32PM -0500, Colin Walters wrote: > > On Wed, 2007-12-19 at 22:00 +0100, Jos Vos wrote: > > On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote: > > > > > Mock no longer uses a login shell for builds. > > > > > > The way I discovered this is that the ipsec-tools package stopped > > > building. The reason is that it has a BuildRequires for the krb5-devel > > > package, from which it uses krb5-config. > > > > > > krb5-config is installed in /usr/kerberos/bin/, and the user's path is > > > provided by /etc/profile.d/krb5-devel.sh > > > > > > No user shell, therefore no path, and configure fails to find krb5-config. > > > > I think mock is wrong. It's obvious that the devel packages assume > > developers (like package builders, either human or not ;-)) run the > > /etc/profile.d scripts. T > > It's only broken development packages which require setting environment > variables like this. The correct way to do parallel installation is: > > http://www106.pair.com/rhp/parallel.html > > I'm sure there's some historical reason krb5-config is not in /usr/bin, > but it's a design flaw in the software. > > The environment variable approach seems easy (no need to rename > binaries), but falls over when you need to compile applications against > multiple library versions. So, are we going to mandate in the packaging guidelines that packages *not* use environment variables and that all packages should use pkg-config? That is the issue here. Because if we dont do that, then we end up in the odd situation where a legal package that passes review cannot be built with the official fedora build tool. -- Michael From jspaleta at gmail.com Wed Dec 19 23:37:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Dec 2007 14:37:22 -0900 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219225857.GA84674@dspnet.fr.eu.org> References: <20071218113735.GA20976@free.fr> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> <20071219094603.GJ9741@tango.0pointer.de> <47697974.4060401@gmail.com> <604aa7910712191243l3317652cx4c84ba2081b2d5fd@mail.gmail.com> <20071219225857.GA84674@dspnet.fr.eu.org> Message-ID: <604aa7910712191537x287a610bqefb157ce8d188293@mail.gmail.com> On Dec 19, 2007 1:58 PM, Olivier Galibert wrote: > So there are two steps there, find out what the new system can > actually do, and how it can be configured to do it. Of course, having > the main maintainer taking questions trying to answer that as personal > attacks on his work is not making the task easy. I don't think I'd single one person out in the thread. Mailinglists are tough mediums to work in for..passionate discussions. We lose a lot of human communication cues as to tone and intent without vocal or facial expressions. The asynchronous nature also hampers emotional flow of the discussion. Not to mention problematic culturalism and slang expressions which babelfish or google translate doesn't handle all that well. Here are the basic rules of thumb I work by in mailinglist threads. 1) When a thread gets to 50+ posts with over a dozen participants I don't expect anyone to keep up with specifically who has said what. There will be bleed over from one post to another in how responses are handled. If there's a lot of activity in the thread, I absolutely expect to have my arguments and my tone to be confused with someone else's at some point. Just like I don't expect to keep everyone's opinions separated correctly even if gmail does color code people for me. 2) Passion is easily confused as aggression in a mailinglist, and as a result I tend to be more deliberate in tone and verbosity as the importance of the post and scope of the audience increases. While I might be able to get away with something like "you are smoking crack" or "did you mom drop you on your head when you were a baby" in a face-to-face meeting at FudCon as an initial volley into a technical conversation, I'm certainly not going to be able to do it in a mailinglist without some sort of momentum sucking backlash due to my tone. 3) Generally if I read it like it was a personal attack aimed at me, then I know there's been a miscommunication at some point prior, and we need to backtrack a little bit and try to clear that up. Other than in a rare few cases, I find that messages which read as personal attacks are actual redirected misunderstandings or frustrations which if aren't resolved will continue to silently sabotage any constructive dialog. I'm not going to waste time trying to convince the other person not to launch any more attacks, or try to blame them for being rude. The conversations off the rails at the point, and making the bad behavior the focus of the conversation only makes everyone defensive and less likely to want to continue talking about the original topic. -jef"isnt there something mpd like that is gst based out there to play with?"spaleta From walters at redhat.com Wed Dec 19 23:37:04 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Dec 2007 18:37:04 -0500 Subject: Mock: loss of login shell In-Reply-To: <20071219231316.GC5428@humbolt.us.dell.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> <20071219231316.GC5428@humbolt.us.dell.com> Message-ID: <1198107424.6556.27.camel@space-ghost.verbum.private> On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote: > So, are we going to mandate in the packaging guidelines that packages > *not* use environment variables Thinking about this a bit more the krb thing is really ugly but probably not something that needs to be prohibited. Having mock use a login shell isn't the end of the world. The way to think about this is that's it's just as broken as library software which ships a binary named foo-config for libfoo2 and libfoo3; there is a conflict between /usr/bin/foo-config and so you can't have them both installed at the same time. > and that all packages should use > pkg-config? pkg-config is a good way to sanely manage development libraries, but it's not the one true way (i.e. we don't need to mandate it) - if some software wants to do something else that's fine, as long as they do it correctly =) A link to that page though in the guidelines would be a good idea so we can help upstreams understand how to be a good Linux citizen. From Michael_E_Brown at dell.com Wed Dec 19 23:41:57 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 17:41:57 -0600 Subject: Mock: loss of login shell In-Reply-To: <1198107424.6556.27.camel@space-ghost.verbum.private> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> <20071219231316.GC5428@humbolt.us.dell.com> <1198107424.6556.27.camel@space-ghost.verbum.private> Message-ID: <20071219234157.GD5428@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 06:37:04PM -0500, Colin Walters wrote: > On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote: > > > So, are we going to mandate in the packaging guidelines that packages > > *not* use environment variables > > Thinking about this a bit more the krb thing is really ugly but probably > not something that needs to be prohibited. Having mock use a login > shell isn't the end of the world. > > The way to think about this is that's it's just as broken as library > software which ships a binary named foo-config for libfoo2 and libfoo3; > there is a conflict between /usr/bin/foo-config and so you can't have > them both installed at the same time. > > > and that all packages should use > > pkg-config? > > pkg-config is a good way to sanely manage development libraries, but > it's not the one true way (i.e. we don't need to mandate it) - if some > software wants to do something else that's fine, as long as they do it > correctly =) A link to that page though in the guidelines would be a > good idea so we can help upstreams understand how to be a good Linux > citizen. Ok. So it seems that we have general consensus that it wouldnt be the end of the world for mock to use a login shell. I have checked in a patch to upstream mock git repository. Can some of the affected parties please check it out and see if it fixes your issue? We can release a fixed version soon if this works out. -- Michael From Michael_E_Brown at dell.com Wed Dec 19 23:44:56 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 19 Dec 2007 17:44:56 -0600 Subject: Mock: loss of login shell In-Reply-To: <20071219234157.GD5428@humbolt.us.dell.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> <20071219231316.GC5428@humbolt.us.dell.com> <1198107424.6556.27.camel@space-ghost.verbum.private> <20071219234157.GD5428@humbolt.us.dell.com> Message-ID: <20071219234456.GE5428@humbolt.us.dell.com> On Wed, Dec 19, 2007 at 05:41:57PM -0600, Michael E Brown wrote: > On Wed, Dec 19, 2007 at 06:37:04PM -0500, Colin Walters wrote: > > On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote: > > > > > So, are we going to mandate in the packaging guidelines that packages > > > *not* use environment variables > > > > Thinking about this a bit more the krb thing is really ugly but probably > > not something that needs to be prohibited. Having mock use a login > > shell isn't the end of the world. > > > > The way to think about this is that's it's just as broken as library > > software which ships a binary named foo-config for libfoo2 and libfoo3; > > there is a conflict between /usr/bin/foo-config and so you can't have > > them both installed at the same time. > > > > > and that all packages should use > > > pkg-config? > > > > pkg-config is a good way to sanely manage development libraries, but > > it's not the one true way (i.e. we don't need to mandate it) - if some > > software wants to do something else that's fine, as long as they do it > > correctly =) A link to that page though in the guidelines would be a > > good idea so we can help upstreams understand how to be a good Linux > > citizen. > > Ok. So it seems that we have general consensus that it wouldnt be the > end of the world for mock to use a login shell. > > I have checked in a patch to upstream mock git repository. Sorry forgot to post link: git://git.fedorahosted.org/git/mock.git > Can some of the affected parties please check it out and see if it fixes > your issue? We can release a fixed version soon if this works out. -- Michael From lesmikesell at gmail.com Thu Dec 20 00:02:59 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 19 Dec 2007 18:02:59 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219225857.GA84674@dspnet.fr.eu.org> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <476818BE.2080308@gmail.com> <20071218205748.GC3360@tango.0pointer.de> <604aa7910712181303q32723dc9q1a545e6dd53c782e@mail.gmail.com> <47684AA4.5090606@gmail.com> <20071219094603.GJ9741@tango.0pointer.de> <47697974.4060401@gmail.com> <604aa7910712191243l3317652cx4c84ba2081b2d5fd@mail.gmail.com> <20071219225857.GA84674@dspnet.fr.eu.org> Message-ID: <4769B133.1030607@gmail.com> Olivier Galibert wrote: > On Wed, Dec 19, 2007 at 11:43:42AM -0900, Jeff Spaleta wrote: >> I think the underlying problem is that advanced hardware access policy >> technology is advancing far more rapidly than local administrators are >> able to keep up with and its disrupting workflow that has been used >> for years. > > Yes, there is a lot of that. You also have to add the fact that some > of these newflangled thingies sometimes do not have the capability to > cover what the previous systems could do, as we can see in NM's case. I'd just like to understand why arbitrating access to devices is suddenly seen as a new problem when in fact the facilities have been built into unix and its clones for decades. Or why any of those facilities need to be broken because you want to guess that someone near the console is somehow special or you want the most recent login session or console switch to win at everyone else's expense. > So there are two steps there, find out what the new system can > actually do, and how it can be configured to do it. Of course, having > the main maintainer taking questions trying to answer that as personal > attacks on his work is not making the task easy. That could easily be avoided posting links to the documentation that explains why these choices were necessary and what you get in return. If that exists, I don't know where to find it. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Thu Dec 20 00:08:51 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 19 Dec 2007 16:08:51 -0800 Subject: user switching [was Re: how is pulseaudio supposed to work?] In-Reply-To: <20071218230834.GA20140@jadzia.bu.edu> References: <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071218230834.GA20140@jadzia.bu.edu> Message-ID: <4769B293.6000708@gmail.com> Matthew Miller wrote: > On Tue, Dec 18, 2007 at 10:54:43PM +0100, Olivier Galibert wrote: >> - Both the GF & I are usually logged on that machine, her with KDE on >> Ctrl-Alt-F7 and me with fvwm2 on Ctrl-Alt-F8. Adding pulseaudio -D in >> my startup wouldn't be a problem. >> - User switching, as it is, is just C-A-F7/C-A-F8 > > I'm glad to hear of someone else doing this. Is gdm in rawhide all broken > for you too? I used to regularly use two separate X servers both started and maintained by gdm. For each of them I could login the same user (to a different desktop session) or a different user, it worked very seamlessly. I haven't found the need to be doing that for awhile though so can't say whether rawhide has issues with it. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mschwendt.tmp0701.nospam at arcor.de Thu Dec 20 04:39:23 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Dec 2007 05:39:23 +0100 Subject: Delays in package processing In-Reply-To: <1198094151.3400.13.camel@localhost.localdomain> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> Message-ID: <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Dec 2007 14:55:51 -0500, Tom "spot" Callaway wrote: > > On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: > > > Is the package signing step done by hand? That's been my understanding, > > but maybe I'm missing something. It reminds me of Sigourney Weaver's > > role in "Galaxy Quest": a seemingly needless insertion of people into > > the process. > > > > If so, why? Can we switch to an automated process? > > It is currently a manual process, and Jesse Keating has been working for > some time to make an open source signing server that will work for > Fedora's infrastructure needs but also be useful for anyone. A signing-server doesn't fix everything. It may help with the security implications of giving away the key password as was done for Extras. But hoping for much more frequent or automated pushes of non-critical updates would be insane. Releasing new repodata and new packages too often would make the repositories a moving target for all mirrors. The updates repository is continuously flooded with version upgrades, which move farther away from the tested gold release of the distribution only to break due to new bugs, which then require further updates. From bos at serpentine.com Thu Dec 20 05:05:32 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 19 Dec 2007 21:05:32 -0800 Subject: Delays in package processing In-Reply-To: <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <4769F81C.8060001@serpentine.com> Michael Schwendt wrote: > A signing-server doesn't fix everything. It may help with the security > implications of giving away the key password as was done for Extras. But > hoping for much more frequent or automated pushes of non-critical updates > would be insane. Well, one of the things I was hoping to have come out of my initial message was some transparency. It's useful to know that, for example, frequent pushes of updates is a problem for mirrors. It would be most valuable to have something like the package update wiki page updated with a list of "here's what to expect, and why, once you submit an update request", because right now information like the above isn't captured anywhere that I can find. Not having any idea what to expect is no fun. References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1198131169.3656.34.camel@beck.corsepiu.local> On Thu, 2007-12-20 at 05:39 +0100, Michael Schwendt wrote: > On Wed, 19 Dec 2007 14:55:51 -0500, Tom "spot" Callaway wrote: > > > > > On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: > > > > > Is the package signing step done by hand? That's been my understanding, > > > but maybe I'm missing something. It reminds me of Sigourney Weaver's > > > role in "Galaxy Quest": a seemingly needless insertion of people into > > > the process. > > > > > > If so, why? Can we switch to an automated process? > > > > It is currently a manual process, and Jesse Keating has been working for > > some time to make an open source signing server that will work for > > Fedora's infrastructure needs but also be useful for anyone. > > A signing-server doesn't fix everything. It may help with the security > implications of giving away the key password as was done for Extras. But > hoping for much more frequent or automated pushes of non-critical updates > would be insane. Isn't testing what is supposed to implement the "delay queue", which is what you seem to be asking for. > Releasing new repodata and new packages too often would > make the repositories a moving target for all mirrors. The updates > repository is continuously flooded with version upgrades, which move > farther away from the tested gold release of the distribution only to > break due to new bugs, which then require further updates. At the same time Fedora+updates is suffering from bugs not receiving fixes in reasonable time. To put it bluntly: * As a packager, I feel strangled by current release practice. * As a user I am gradually feeling annoyed by seeing bugs not getting fixed. * If I were still a "low bandwidth user" I would quit Fedora now, because updates are being pushed in "big chunks" blocking internet access for hours once a week, instead of being fed with "small chunks" in shorte? intervals. Ralf From lordmorgul at gmail.com Thu Dec 20 07:32:34 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 19 Dec 2007 23:32:34 -0800 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <604aa7910712191249l5f944c43w8c3117ada9fa40f9@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> <1198094493.3400.15.camel@localhost.localdomain> <604aa7910712191249l5f944c43w8c3117ada9fa40f9@mail.gmail.com> Message-ID: <476A1A92.1090708@gmail.com> Jeff Spaleta wrote: > On Dec 19, 2007 11:01 AM, Tom spot Callaway wrote: >> There is no Fedora 10. There can never be a 10. >> >> We have to either skip to 11, or rename again. > > The problem is you merged Core and Extras a few releases too early. > The drop of "Core" was the renaming event that you forced at the 10 > mark. > > -jef Perhaps after 9 then... the plan for "Fedora More" can commence starting at 1 and world domination will be inevitable. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From fedora at leemhuis.info Thu Dec 20 07:41:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 08:41:24 +0100 Subject: Delays in package processing In-Reply-To: <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <476A1CA4.2040009@leemhuis.info> On 20.12.2007 05:39, Michael Schwendt wrote: > On Wed, 19 Dec 2007 14:55:51 -0500, Tom "spot" Callaway wrote: >> On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: >>> Is the package signing step done by hand? That's been my understanding, >>> but maybe I'm missing something. It reminds me of Sigourney Weaver's >>> role in "Galaxy Quest": a seemingly needless insertion of people into >>> the process. >>> If so, why? Can we switch to an automated process? >> It is currently a manual process, and Jesse Keating has been working for >> some time to make an open source signing server that will work for >> Fedora's infrastructure needs but also be useful for anyone. Just wondering: Is Jesse the only one that does pushes? Maybe we should give at least one other person access to the signing key? > A signing-server doesn't fix everything. It may help with the security > implications of giving away the key password as was done for Extras. But > hoping for much more frequent or automated pushes of non-critical updates > would be insane. Releasing new repodata and new packages too often would > make the repositories a moving target for all mirrors. Agreed, but on the other hand there are currently up to four (or even more) days between pushes afaics (the last one right now for example was on 15 December 2007): * for normal updates that's not a problem, but I think four days are a to long delay for updates that fix security issues. * I've seen packages where that were requested to updates-testing in bodhi that were requested to stable just a few days after that -- the packager afaics had assumed the package had been in the testing repos for a few days, but in fact it never was as push never happened, so the package made it straight to the stable repos; doing pushed to testing more often might make sense And, BTW, what's exactly the problem with "moving target for all mirrors"? There were (are?) yum problems iirc (?), but I suppose we can fix them if we want? CU thl (?) -- downloading metadata from one mirror, download error on it, switching to another mirror that has even new push where the file yum tries to download is already is gone again From lordmorgul at gmail.com Thu Dec 20 07:49:56 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 19 Dec 2007 23:49:56 -0800 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198027755.18986.140.camel@localhost> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> <1198027755.18986.140.camel@localhost> Message-ID: <476A1EA4.2040401@gmail.com> Callum Lerwick wrote: > I think we should keep to things easily mascot-able. People like cute > mascots. I never really considered 'Werewolf' to be a part of the 'cute mascots' creature category. Although getting a connection from Werewolf to a cute mascot might not be impossible... Werewolf *is a big hairy beast* Quatchi is a sasquatch mascot! http://en.wikipedia.org/wiki/Quatchi Less on the cute side, but still a hairy beast Bigfoot (would never pass legal)... but maybe 1. *Woodwose* (medieval hairy wildman legend) http://en.wikipedia.org/wiki/Woodwose 2. *Barmanou* http://en.wikipedia.org/wiki/Barmanou -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Thu Dec 20 07:52:30 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 19 Dec 2007 23:52:30 -0800 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1197995712.2522.1.camel@scrappy.miketc.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <200712181125.21403.lowen@pari.edu> <1197995712.2522.1.camel@scrappy.miketc.com> Message-ID: <476A1F3E.1010904@gmail.com> Mike Chambers wrote: > On Tue, 2007-12-18 at 11:25 -0500, Lamar Owen wrote: >> On Tuesday 18 December 2007, Josh Boyer wrote: >>> That's right... it's time to start naming the Fedora 9 release. We're >>> starting early this release to give the Fedora Art team time to come up >>> with some great art for F9, and really because there is no reason to >>> wait so long anyway. >> Tennin Six Months. >> >> (Tennin is a shapeshifting entity in Japanese Buddhism; Werewolf is a >> shapeshifting entitity). > > Sasquatch --> Both are VERY hairy! Oh +1, I just sent an email to the list on sasquatch/hairy beast and then noticed yours already here. :) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From fedora at leemhuis.info Thu Dec 20 08:15:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 09:15:57 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198090164.4860.3.camel@kennedy> References: <1198090164.4860.3.camel@kennedy> Message-ID: <476A24BD.70906@leemhuis.info> On 19.12.2007 19:49, Brian Pepple wrote: > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 > > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - > f13 I'd like to ask FESCo to please not realize the PackageACLOpening proposal without the NewMaintainerContainment. In fact if FESCo should I'll continue to lock down my packages just because I fear the risk that a just-sponsored-contributers puts something bad (e.g. malicious code) into one of my packages in CVS (even if then there are much better targets to get bad code out to users easily) and uses the CTRL+C trick to prevent a commit message. While on the CTRL+C issue to prevent commit messages: will FESCo continue to ignore it? Further: I'd like to ask FESCo to add a rule to that all proposals have to be posted to this list as full text with a special tag in the subject (something like [Proposal for FESCo voting]) -- currently its IMHO way to easy to miss a proposal that come up for FESCo voting. And often only links gets posted to the wiki pages -- the result afaics is that only a few people click on the link, even less read, and even less comment on it; if they comment then in the wiki, where others miss it. IOW: no real discussion comes up and contributers don't get involved into the decision finding process. That's not what FESCo wants -- or is it? CU knurd From martin.sourada at seznam.cz Thu Dec 20 08:23:40 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 20 Dec 2007 09:23:40 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <476A1EA4.2040401@gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> <1198027755.18986.140.camel@localhost> <476A1EA4.2040401@gmail.com> Message-ID: <1198139020.2952.1.camel@pc-notebook.kolej.mff.cuni.cz> On Thu, 2007-12-20 at 08:49 +0100, Andrew Farris wrote: *strip* > 1. *Woodwose* (medieval hairy wildman legend) http://en.wikipedia.org/wiki/Woodwose > Hey, I like the sound of this one... Martin *strip* From stransky at redhat.com Thu Dec 20 08:22:46 2007 From: stransky at redhat.com (Martin Stransky) Date: Thu, 20 Dec 2007 09:22:46 +0100 Subject: Firefox 3 Beta 2 in Rawhide Message-ID: <476A2656.5060704@redhat.com> Hello, Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on). If you're interested and don't want to switch to rawhide, you can run Firefox 3 on Fedora 8, too. Just download and compile the latest xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install firefox from rawhide. There's one side effect of this update. The former firefox-devel package has been removed from rawhide and gecko-libs 1.8 is no more shipped. All packages have to run with xulrunner (gecko-libs 1.9) now. If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide. Happy testing&hacking! :) ma. From martin.sourada at seznam.cz Thu Dec 20 08:41:54 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 20 Dec 2007 09:41:54 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote: > Hello, > > Firefox 3 has finally landed in Rawhide. It's a slightly unpolished > version and we appreciate if you test it and report all issues to > bugzilla (like missing locales, broken plugins and so on). > > If you're interested and don't want to switch to rawhide, you can run > Firefox 3 on Fedora 8, too. Just download and compile the latest > xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install > firefox from rawhide. > > There's one side effect of this update. The former firefox-devel package > has been removed from rawhide and gecko-libs 1.8 is no more shipped. All > packages have to run with xulrunner (gecko-libs 1.9) now. > > If you're a package maintainer and your package already uses xulrunner, > please rebuild it against the new rawhide version. Xulrunner directory > has been changed and many gecko packages (if not all) are linked with > --rpath linker directive. As long as rpath is used you have to rebuild > gecko-libs based packages after each xulrunner change so please consider > to remove it. Gecko libraries are registered system wide by > /etc/ld.so.conf.d and rpath should not be necessary in rawhide. > > Happy testing&hacking! :) > > ma. > Hi, That's good news! Just some little questions. Has epiphany been ported on xulrunner or do I need to wait just a little more to upgrade firefox? Are you interested also in gtk rendering issues? I noticed so far (using mozilla's nightly builds of FF3) that the close buttons on tabs aren't highlighted on mouseover action and checkboxes and radiobuttons seems to have slightly wrong positioning when displayed on web pages. Also widget's backgrounds seem to be derived from window's background, but IMHO it should be derived from page element background it is on (but this is really just a small issue). Thanks, Martin From stransky at redhat.com Thu Dec 20 08:58:59 2007 From: stransky at redhat.com (Martin Stransky) Date: Thu, 20 Dec 2007 09:58:59 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> References: <476A2656.5060704@redhat.com> <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <476A2ED3.2020103@redhat.com> Martin Sourada wrote: > That's good news! Just some little questions. Has epiphany been ported > on xulrunner or do I need to wait just a little more to upgrade firefox? Epiphany in rawhide still runs with firefox-devel, xulrunner support will be included in epiphany-2.22. > Are you interested also in gtk rendering issues? I noticed so far (using > mozilla's nightly builds of FF3) that the close buttons on tabs aren't > highlighted on mouseover action and checkboxes and radiobuttons seems to > have slightly wrong positioning when displayed on web pages. Also > widget's backgrounds seem to be derived from window's background, but > IMHO it should be derived from page element background it is on (but > this is really just a small issue). Please check if that issues are in the fedora package and when they are not fedora related please report them at upstream. We generally don't have an ability to fix all bugs. ma. From Christian.Iseli at licr.org Thu Dec 20 09:50:16 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 20 Dec 2007 10:50:16 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198094493.3400.15.camel@localhost.localdomain> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> <7f692fec0712181112r26932fc1r4fd9d1220718875@mail.gmail.com> <47694C32.5040000@redhat.com> <1198094493.3400.15.camel@localhost.localdomain> Message-ID: <20071220105016.2a866f0f@ludwig-alpha.unil.ch> On Wed, 19 Dec 2007 15:01:33 -0500, Tom "spot" Callaway wrote: > There is no Fedora 10. There can never be a 10. > > We have to either skip to 11, or rename again. Fedora 0xA ? ;) C From lordmorgul at gmail.com Thu Dec 20 09:51:39 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 20 Dec 2007 01:51:39 -0800 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198139020.2952.1.camel@pc-notebook.kolej.mff.cuni.cz> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <20071218140807.GA2287@localhost.localdomain> <1198027755.18986.140.camel@localhost> <476A1EA4.2040401@gmail.com> <1198139020.2952.1.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <476A3B2B.4040404@gmail.com> Martin Sourada wrote: > On Thu, 2007-12-20 at 08:49 +0100, Andrew Farris wrote: > *strip* >> 1. *Woodwose* (medieval hairy wildman legend) http://en.wikipedia.org/wiki/Woodwose >> > Hey, I like the sound of this one... Yeah, Woodwose has a nice common word length and matching letter positioning with Werewolf too, even better than just a basic isa relationship. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From gilboad at gmail.com Thu Dec 20 09:53:08 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 20 Dec 2007 11:53:08 +0200 Subject: rescue.iso images? Message-ID: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> Hello all, Please forgive me if it has been asked before, but, when can we expect to see rawhide installation isos and/or vmlinuz+initrd sets? I'd like to reinstall my rawhide machine, and I rather start from a rawhide kit (instead of using F8 as a base) Thanks, - Gilboa. From fedora at camperquake.de Thu Dec 20 09:53:26 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Dec 2007 10:53:26 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <20071220105326.13c9eb3e@dhcp03.addix.net> Hi. On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote: > Firefox 3 has finally landed in Rawhide. It's a slightly unpolished > version and we appreciate if you test it and report all issues to > bugzilla (like missing locales, broken plugins and so on). Does not start for me (says "Could not fild compatible GRE between version 1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and installed, so all deps are met. From redhat at olen.net Thu Dec 20 09:58:32 2007 From: redhat at olen.net (Ola Thoresen) Date: Thu, 20 Dec 2007 10:58:32 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220105326.13c9eb3e@dhcp03.addix.net> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> Message-ID: <476A3CC8.4070908@olen.net> Ralf Ertzinger wrote: > Hi. > > On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote: > >> Firefox 3 has finally landed in Rawhide. It's a slightly unpolished >> version and we appreciate if you test it and report all issues to >> bugzilla (like missing locales, broken plugins and so on). > > Does not start for me (says "Could not fild compatible GRE between version > 1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and > installed, so all deps are met. > Had the same problem. Seems like it needs xulrunner from koji as well. After I installed that it starts fine (although most of my Add-ons are incompatible). Rgds. Ola (T) -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From lordmorgul at gmail.com Thu Dec 20 10:16:03 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 20 Dec 2007 02:16:03 -0800 Subject: rescue.iso images? In-Reply-To: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> Message-ID: <476A40E3.6050506@gmail.com> Gilboa Davara wrote: > Hello all, > > Please forgive me if it has been asked before, but, when can we expect > to see rawhide installation isos and/or vmlinuz+initrd sets? > I'd like to reinstall my rawhide machine, and I rather start from a > rawhide kit (instead of using F8 as a base) > > Thanks, > - Gilboa. Generally no rawhide iso spin is done until the -testX release, which isn't until early january for test1. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From nicolas.mailhot at laposte.net Thu Dec 20 10:21:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 20 Dec 2007 11:21:29 +0100 (CET) Subject: Mock: loss of login shell In-Reply-To: <20071219231316.GC5428@humbolt.us.dell.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> <20071219231316.GC5428@humbolt.us.dell.com> Message-ID: <57375.192.54.193.53.1198146089.squirrel@rousalka.dyndns.org> Java-side we've had build processes that depended on env variable for some years but the files containing those variables have always been explicitely sourced by build scripts without relying on profile.d -- Nicolas Mailhot From fedora at camperquake.de Thu Dec 20 10:22:55 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Dec 2007 11:22:55 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A3CC8.4070908@olen.net> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> Message-ID: <20071220112255.5a79fc1e@dhcp03.addix.net> Hi. On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote: > Had the same problem. Seems like it needs xulrunner from koji as > well. After I installed that it starts fine (although most of my > Add-ons are incompatible). adding "extensions.checkCompatibility = false" to about:config got some of them back (especially adblock, which is quite essential). From stransky at redhat.com Thu Dec 20 10:30:37 2007 From: stransky at redhat.com (Martin Stransky) Date: Thu, 20 Dec 2007 11:30:37 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220105326.13c9eb3e@dhcp03.addix.net> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> Message-ID: <476A444D.1030001@redhat.com> Ralf Ertzinger wrote: > Does not start for me (says "Could not fild compatible GRE between version > 1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and > installed, so all deps are met. It requires xulrunner-1.9-0.beta2, fixed in firefox-3.0-0.beta2.2.fc9. From kevin.kofler at chello.at Thu Dec 20 11:02:57 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 20 Dec 2007 11:02:57 +0000 (UTC) Subject: Putting K3b back onto the DVDs? Message-ID: It has been brought to my attention (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/) that K3b is no longer available on the DVD images (since the Core-Extras merge). As far as I can tell, this is because it is marked only as "optional" and not "default" in the sound-and-video group? As K3b is probably the best Free CD/DVD burning program around, the burning tool of choice of most KDE users and even several GNOME users, I think it would be great if this could be put back onto the DVD images in F9. Can this be added to the pungi kickstart config? Kevin Kofler From jcm at redhat.com Thu Dec 20 11:10:29 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 20 Dec 2007 06:10:29 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: Message-ID: <1198149029.3205.101.camel@perihelion> On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > It has been brought to my attention > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/) that K3b is > no longer available on the DVD images (since the Core-Extras merge). As far as > I can tell, this is because it is marked only as "optional" and not "default" > in the sound-and-video group? As K3b is probably the best Free CD/DVD burning > program around, the burning tool of choice of most KDE users and even several > GNOME users, I think it would be great if this could be put back onto the DVD > images in F9. Can this be added to the pungi kickstart config? +1 Jon. From paul at all-the-johnsons.co.uk Thu Dec 20 11:17:50 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 20 Dec 2007 11:17:50 +0000 Subject: Submitting packages for review Message-ID: <1198149470.4702.3.camel@T7.Linux> Hi, Shows how long I've been out of the loop here! I've uploaded mono-addins to http://pfj.fedorapeople.org, but there is now nothing on bugzilla and nothing I can spot on the wiki for submitting packages for review. How do I do it? 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 debarshi.ray at gmail.com Thu Dec 20 11:24:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 20 Dec 2007 16:54:55 +0530 Subject: Submitting packages for review In-Reply-To: <1198149470.4702.3.camel@T7.Linux> References: <1198149470.4702.3.camel@T7.Linux> Message-ID: <3170f42f0712200324n1576b022ueb288e3130efa630@mail.gmail.com> http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From jfrieben at freesurf.fr Thu Dec 20 11:32:30 2007 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 20 Dec 2007 12:32:30 +0100 (CET) Subject: rescue.iso images? In-Reply-To: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> Message-ID: <63023.89.246.169.126.1198150350.squirrel@arlette.freesurf.fr> > Hello all, > > Please forgive me if it has been asked before, but, when can we expect > to see rawhide installation isos and/or vmlinuz+initrd sets? > I'd like to reinstall my rawhide machine, and I rather start from a > rawhide kit (instead of using F8 as a base) > > Thanks, > - Gilboa. You should be able to use the F8 install media or rescue CD to do a net install from a rawhide mirror. This used to work for me. From laroche at redhat.com Thu Dec 20 11:38:12 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 20 Dec 2007 12:38:12 +0100 Subject: Mock: loss of login shell In-Reply-To: <20071219234157.GD5428@humbolt.us.dell.com> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> <1198102892.6556.8.camel@space-ghost.verbum.private> <20071219231316.GC5428@humbolt.us.dell.com> <1198107424.6556.27.camel@space-ghost.verbum.private> <20071219234157.GD5428@humbolt.us.dell.com> Message-ID: <20071220113812.GA6294@dudweiler.stuttgart.redhat.com> > Ok. So it seems that we have general consensus that it wouldnt be the > end of the world for mock to use a login shell. > > I have checked in a patch to upstream mock git repository. This is a good change for mock. +1. regards, Florian La Roche From buildsys at redhat.com Thu Dec 20 12:17:36 2007 From: buildsys at redhat.com (Build System) Date: Thu, 20 Dec 2007 07:17:36 -0500 Subject: rawhide report: 20071220 changes Message-ID: <200712201217.lBKCHag6009411@porkchop.devel.redhat.com> New package trousers Implementation of the TCG's Software Stack v1.2 Specification Updated Packages: aqbanking-2.3.2-4.fc9 --------------------- * Wed Dec 19 2007 Bill Nottingham - 2.3.2-4 - kbanking-devel needs to require qbanking-devel (#426265) asterisk-1.4.16.1-1.fc9 ----------------------- * Wed Dec 19 2007 Jeffrey C. Ollie - 1.4.16.1-1 - Update to the real 1.4.16.1. * Wed Dec 19 2007 Jeffrey C. Ollie - 1.4.16-2 - Add patch to bring source up to version 1.4.16.1 which will be released shortly to fix some crasher bugs introduced by 1.4.16. bind-32:9.5.0-21.b1.fc9 ----------------------- * Wed Dec 19 2007 Adam Tkac 32:9.5.0-21.b1 - fixed typo in post section (CVE-2007-6283) * Wed Dec 19 2007 Adam Tkac 32:9.5.0-20.b1 - removed obsoleted triggers - CVE-2007-6283 * Wed Dec 12 2007 Adam Tkac 32:9.5.0-19.2.b1 - added dst/gssapi.h to -devel subpackage (#419091) - improved fix for (#417431) bzflag-2.0.10-2.fc9 ------------------- * Mon Dec 17 2007 Nils Philippsen 2.0.10-2 - build and package plugins dhcpv6-1.0.4-1.fc9 ------------------ * Wed Dec 19 2007 David Cantrell - 1.0.4-1 - Upgraded to new upstream version, dhcpv6-1.0.4 - RPM scriptlet updates - Update URL and Source lines to reflect new project location ecryptfs-utils-37-0.fc9 ----------------------- * Wed Dec 19 2007 Mike Halcrow 37-0 - Remove unsupported ciphers; bump to version 37 enchant-1:1.3.0-2.fc9 --------------------- * Wed Dec 19 2007 Caolan McNamara 1:1.3.0-2.fc9 - tell enchant where the myspell dictionaries are evolution-sharp-0.15.4-1.fc9 ---------------------------- * Wed Dec 19 2007 Matthew Barnes - 0.15.4-1.fc9 - Update to 0.15.4 fbreader-0.8.8a-1.fc9 --------------------- * Thu Dec 20 2007 Michel Salim - 0.8.8a-1 - Update to 0.8.8a - Workaround for PDB format handler when reading certain files firefox-3.0-0.beta2.1.fc9 ------------------------- * Tue Dec 18 2007 Martin Stransky 3.0-0.beta2.1 - moved to XUL Runner and updated to 3.0b3pre - removed firefox-devel package, gecko-libs is provided by xulrunner-devel now. gdm-1:2.21.2-0.2007.11.20.7.fc9 ------------------------------- * Wed Dec 19 2007 Ray Strode - 1:2.21.2-0.2007.11.20.7 - Improve animation to be less jumpy gnu-efi-3.0d-1.fc9 ------------------ * Wed Dec 19 2007 Peter Jones - 3.0d-1 - Update to 3.0d gpodder-0.10.3-1.fc9 -------------------- * Mon Dec 17 2007 Jef Spaleta 0.10.3-1 - New Upstream version gtk2-2.12.3-5.fc9 ----------------- * Wed Dec 19 2007 Colin Walters - 2.12.3-5 - BR libXcomposite-devel so we get the sexiness, also pull it in in the devel package. * Tue Dec 18 2007 Matthias Clasen - 2.12.3-4 - Fix a gtk-doc problem - Work around a kernel problem in the build system * Mon Dec 17 2007 Matthias Clasen - 2.12.3-3 - Add a setting to change input methods ipsec-tools-0.7-8.fc9 --------------------- * Wed Dec 19 2007 Steve Conklin - 0.7-8 - sourced krb5-devel.sh to set path * Tue Dec 18 2007 Steve Conklin - 0.7-7 - bumped for retag * Tue Dec 18 2007 Steve Conklin - 0.7-6 - Added a patch for context size change - Resolves #413331 racoon dies with buffer overflow in MCS/MLS loopback itcl-3.3-0.11.RC1.fc9 --------------------- * Wed Dec 19 2007 Wart - 3.3-0.11.RC1 - Move libtcl shared library to %{_libdir} so that applications linked against itcl can find it. (BZ #372791) itk-3.3-0.8.RC1.fc9 ------------------- * Wed Dec 19 2007 Wart - 3.3-0.8.RC1 - Move libitk shared library to %{_libdir} so that applications linked against itk can find it. (BZ #372791) kmymoney2-0.8.8-1.fc9 --------------------- * Wed Dec 19 2007 Rex Dieter 0.8.8-1 - kmymoney2-0.8.8 - --enable-kbanking * Sat Dec 08 2007 Rex Dieter 0.8.7-5 - BR: kdelibs3-devel libdhcp-1.99.3-1.fc9 -------------------- * Wed Dec 19 2007 David Cantrell - 1.99.3 - Upgrade to libdhcp-1.99.3 - Rebuild for new libnl libgpod-0.6.0-3.fc9 ------------------- * Wed Dec 19 2007 Todd Zullinger - 0.6.0-3 - BR docbook-style-xsl to ensure the python docs are built correctly liferea-1.4.10-1.fc9 -------------------- * Wed Dec 19 2007 Brian Pepple - 1.4.10-1 - Update to 1.4.10. - Update feed patch. mfiler2-4.0.1-1.fc9 ------------------- * Thu Dec 20 2007 Mamoru Tasaka - 4.0.1-1 - 4.0.1 mock-0.9.4-1.fc9 ---------------- * Wed Dec 19 2007 Michael Brown - 0.9.4-1 - Result dir was not honoring --uniqueext= - make rpmbuild run under a chroot login shell - mock is now noarch due to drop of all binary components - add tmpfs plugin (disabled by default) - slightly more friendly logs. nagios-plugins-snmp-disk-proc-1.1-1.fc9 --------------------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.1-1 - correct URL - bump to 1.1 - fix license - Patch is obsolete nautilus-2.20.0-7.fc9 --------------------- * Wed Dec 19 2007 - Bastien Nocera - 2.20.0-7 - Update audio preview patch to check for aliases (#381401) * Tue Oct 30 2007 - Bastien Nocera - 2.20.0-6 - Fix audio preview command-line to use decodebin so playbin doesn't pop up a window for videos detected as audio * Tue Oct 16 2007 - Bastien Nocera - 2.20.0-5 - Add patch from upstream to get audio preview working again (#332251) openvrml-0.17.0-2.fc9 --------------------- * Wed Dec 19 2007 Braden McDaniel - 0.17.0-2 - Removed %check. The "browser" test fails on ppc due to what looks like a probable compiler bug. * Wed Dec 19 2007 Braden McDaniel - 0.17.0-1 - Updated to 0.17.0 - Changed license to LGPLv3+/GPLv3+ per OpenVRML 0.17.0 change. paraview-3.2.1-2.fc9 -------------------- * Tue Dec 18 2007 - Orion Poplawski - 3.2.1-2 - Name ld.so.conf.d file with .conf extension - Drop parallel make for now * Mon Dec 03 2007 - Orion Poplawski - 3.2.1-1 - Update to 3.2.1 - Use macros for version numbers - Add patches to fix documentation install location and use assistant-qt4, not install copies of Qt libraries, and not use rpath. - Install ld.so.conf.d file - Fixup desktop files * Thu Aug 23 2007 - Orion Poplawski - 3.0.2-2 - Update license tag to BSD - Fix make %{_smp_mflags} - Rebuild for ppc32 perl-File-HomeDir-0.67-1.fc9 ---------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 0.67-1 - 0.67 perl-Glib-1.162-1.fc9 --------------------- * Mon Dec 17 2007 Tom "spot" Callaway - 1.162-1 - 1.162 perl-Gtk2-1.162-1.fc9 --------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.162-1 - Update to 1.162 perl-IO-CaptureOutput-1.06-1.fc9 -------------------------------- * Wed Dec 19 2007 Tom "spot" Callaway 1.06-1 - bump to 1.06 perl-Image-Info-1.27-1.fc9 -------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.27-1 - bump to 1.27 perl-Image-Size-3.1-1.fc9 ------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 3.1-1 - bump to 3.1 - license change (now LGPLv2 or Artistic 2.0) perl-Log-Dispatch-2.20-1.fc9 ---------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 2.20-1 - bump to 2.20 perl-MIME-Types-1.23-1.fc9 -------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.23-1 - bump to 1.23 perl-Net-Domain-TLD-1.67-1.fc9 ------------------------------ perl-Net-GPSD-0.36-1.fc9 ------------------------ * Wed Dec 19 2007 Tom "spot" Callaway - 0.36-1 - bump to 0.36 perl-OLE-Storage_Lite-0.15-1.fc9 -------------------------------- * Wed Dec 19 2007 Tom "spot" Callaway 0.15-1 - 0.15 perl-PPI-1.201-1.fc9 -------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.201-1 - bump to 1.201 perl-Scalar-Properties-0.13-1.fc9.1 ----------------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 0.13-1.1 - BR: Test::More perl-Set-Scalar-1.22-1.fc9 -------------------------- perl-Test-Manifest-1.22-1.fc9 ----------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.22-1 - 1.22 - license fix perl-Test-SubCalls-1.07-1.fc9 ----------------------------- perl-Tree-DAG_Node-1.06-1.fc9 ----------------------------- * Wed Dec 19 2007 Tom "spot" Callaway - 1.06-1 - 1.06 policycoreutils-2.0.34-1.fc9 ---------------------------- * Wed Dec 19 2007 Dan Walsh 2.0.34-1 - Update to upstream rosegarden4-1.6.0-1.fc7 ----------------------- * Wed Dec 12 2007 Callum Lerwick - 1.6.0-1 - New upstream version. - Patch cmakelists to use our optflags. (bz330631) * Wed May 02 2007 Callum Lerwick - 1.5.1-1 - New upstream version. * Tue Feb 13 2007 Callum Lerwick - 1.5.0-1 - New upstream version. ruby-activerecord-2.0.1-1.fc9 ----------------------------- * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version ruby-activesupport-2.0.1-1.fc9 ------------------------------ * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version rubygem-actionmailer-2.0.1-1.fc9 -------------------------------- * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version rubygem-actionpack-2.0.1-1.fc9 ------------------------------ * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version rubygem-activerecord-2.0.1-1.fc9 -------------------------------- * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version rubygem-activesupport-2.0.1-1.fc9 --------------------------------- * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version rubygem-rails-2.0.1-1.fc9 ------------------------- * Mon Dec 10 2007 David Lutterkort - 2.0.1-1 - New version - No dependency on actionwebservce anymore, depend on activeresource instead selinux-policy-3.2.5-2.fc9 -------------------------- * Wed Dec 19 2007 Dan Walsh 3.2.5-2 - Zero out customizable types * Wed Dec 19 2007 Dan Walsh 3.2.5-1 - Fix definiton of admin_home_t swfdec-0.5.5-2.fc9 ------------------ * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 - Build w/ pulse audio support. swfdec-gnome-0.5.5-2.fc9 ------------------------ * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 - Rebuild for pulse audio enable swfdec. swfdec-mozilla-0.5.5-2.fc9 -------------------------- * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 - Drop BR on alsa-libs-devel. - Rebuild for pulseaudio-enabled swfdec. tar-2:1.19-1.fc9 ---------------- * Mon Dec 17 2007 Radek Brich 2:1.19-1 - upgrade to 1.19 - updated xattrs patch, removed 3 upstream patches xorg-x11-drv-radeonhd-1.0.0-0.4.20071219git.fc9 ----------------------------------------------- * Wed Dec 19 2007 Hans Ulrich Niedermann - 1.0.0-0.4.20071219git - New snapshot (upstream commit 861debbf8d649ce09d53d5880f819757ac9c7814) - 861debbf: Make the driver build with the latest ustream git server sources again. - 9120f95f: Delete a spurious git_version.h.new when doing make clean. - e98195bd: Don't fail immediately when git-rev-parse fails. - 6d9a6709: IDs: Asus M2A-VM should now no longer need a connector table. - 521bcace: DxGRPH: Fix graphics engine colour issues (hopefully). - 47f8a6f7: Add support for HDMI connectors. - 21e1c6c4: Get EDID block for panels from AtomBIOS even if there is a special Mode. - 492e94c3: LVDS: Fix 18/24 bit dithering and disable spatial dither. - 55f89f69: LVDS: Fix FPDI handling. - ef51931a: HPD pin swapping logic. - 9741c5be: TMDSA: properly add macro control for 0x7149 (M56) - dcfd91c2: TMDSA/B: add macro control values for 0x71C6 (RV530) - c784c92a: TMDSA: add macro control for 0x7147 (M56) - 5acefe5c: ID: 0x724B: Sapphire Radeon X1900 GT - 1a1d110f: Restore: Fix VGA textmode restore when VSYNC length is 0. xulrunner-1.9-0.beta2.1.fc9 --------------------------- * Wed Dec 12 2007 Martin Stransky 1.9-0.beta2.1 - updated to Beta 2. - moved SDK to xulrunner-sdk Broken deps for i386 ---------------------------------------------------------- Miro - 1.0-2.fc9.i386 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.i386 requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnomesword - 2.3.1-3.fc9.i386 requires libxpcom_core.so gnomesword - 2.3.1-3.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 gxine - 0.5.11-14.fc9.i386 requires gecko-libs = 0:1.9b2pre kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071014-5.fc9.i386 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 rubygem-rails - 2.0.1-1.fc9.noarch requires rubygem(activeresource) = 0:2.0.1 showimg-mysql - 0.9.5-13.fc8.i386 requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.i386 requires libcrypto.so.6 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- Miro - 1.0-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.x86_64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnomesword - 2.3.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnomesword - 2.3.1-3.fc9.x86_64 requires libxpcom_core.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) gxine - 0.5.11-14.fc9.x86_64 requires gecko-libs = 0:1.9b2pre kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071014-5.fc9.x86_64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 rubygem-rails - 2.0.1-1.fc9.noarch requires rubygem(activeresource) = 0:2.0.1 showimg-mysql - 0.9.5-13.fc8.x86_64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.x86_64 requires libssl.so.6()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnomesword - 2.3.1-3.fc9.ppc requires libxpcom_core.so gnomesword - 2.3.1-3.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 gxine - 0.5.11-14.fc9.ppc requires gecko-libs = 0:1.9b2pre kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071014-5.fc9.ppc requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 rubygem-rails - 2.0.1-1.fc9.noarch requires rubygem(activeresource) = 0:2.0.1 showimg-mysql - 0.9.5-13.fc8.ppc requires libssl.so.6 showimg-mysql - 0.9.5-13.fc8.ppc requires libcrypto.so.6 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnomesword - 2.3.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnomesword - 2.3.1-3.fc9.ppc64 requires libxpcom_core.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) gxine - 0.5.11-14.fc9.ppc64 requires gecko-libs = 0:1.9b2pre kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071014-5.fc9.ppc64 requires octave(api) = 0:api-v30 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 rubygem-rails - 2.0.1-1.fc9.noarch requires rubygem(activeresource) = 0:2.0.1 showimg-mysql - 0.9.5-13.fc8.ppc64 requires libcrypto.so.6()(64bit) showimg-mysql - 0.9.5-13.fc8.ppc64 requires libssl.so.6()(64bit) From pingoufc4 at yahoo.fr Thu Dec 20 11:20:51 2007 From: pingoufc4 at yahoo.fr (pingou) Date: Thu, 20 Dec 2007 12:20:51 +0100 Subject: Submitting packages for review In-Reply-To: <1198149470.4702.3.camel@T7.Linux> References: <1198149470.4702.3.camel@T7.Linux> Message-ID: <476A5013.1000909@yahoo.fr> Paul wrote: > Hi, > > Shows how long I've been out of the loop here! > > I've uploaded mono-addins to http://pfj.fedorapeople.org, but there is > now nothing on bugzilla and nothing I can spot on the wiki for > submitting packages for review. > > How do I do it? > I think this will help you http://fedoraproject.org/wiki/PackageMaintainers/Join Cheers, P.Yves ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From caillon at redhat.com Thu Dec 20 12:25:55 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 20 Dec 2007 13:25:55 +0100 Subject: nm-0.7 (final) release, schedule? In-Reply-To: References: Message-ID: <476A5F53.4090900@redhat.com> On 12/19/2007 04:12 PM, Rex Dieter wrote: > Per > http://mail.gnome.org/archives/networkmanager-list/2007-December/msg00294.html > anyone have a notion of a nm-0.7 release schedule? > > If nm-0.7 is good enough to be included in fedora(8), it ought to be close > to good enough for a formal release, no? Only if you assume that upstream's release goals match Fedora's. Which is not likely given they are on a feature-based release schedule, whilst we're time driven. From caillon at redhat.com Thu Dec 20 12:43:15 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 20 Dec 2007 13:43:15 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> References: <476A2656.5060704@redhat.com> <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <476A6363.1050104@redhat.com> On 12/20/2007 09:41 AM, Martin Sourada wrote: > That's good news! Just some little questions. Has epiphany been ported > on xulrunner or do I need to wait just a little more to upgrade firefox? Christian Persch has a private branch that he's been working on that he hasn't released yet, to get it to more or less work. He said he wants to clean up the code for it, but it depends on when he feels like releasing it. I'm not sure when that will be, but hopefully soon. :-) > Are you interested also in gtk rendering issues? Getting linux type issues sorted is one of the reasons we're shipping FF3 in rawhide now. Before it becomes final and "too late" to fix any non-security/stability type things. Please report bugs upstream since we're taking it pretty much as-is. Additionally, please check any bugs you may have filed in RH bugzilla about firefox 2, to see if they still exist in FF3. > I noticed so far (using > mozilla's nightly builds of FF3) that the close buttons on tabs aren't > highlighted on mouseover action and checkboxes and radiobuttons seems to > have slightly wrong positioning when displayed on web pages. Please report it upstream, if you haven't! Nobody can fix it without knowing about it. This is the reason it's a beta still. > Also > widget's backgrounds seem to be derived from window's background, but > IMHO it should be derived from page element background it is on (but > this is really just a small issue). More upstream, please :-) From martin.sourada at seznam.cz Thu Dec 20 12:47:39 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 20 Dec 2007 13:47:39 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A6363.1050104@redhat.com> References: <476A2656.5060704@redhat.com> <1198140115.2952.9.camel@pc-notebook.kolej.mff.cuni.cz> <476A6363.1050104@redhat.com> Message-ID: <1198154859.2952.27.camel@pc-notebook.kolej.mff.cuni.cz> On Thu, 2007-12-20 at 13:43 +0100, Christopher Aillon wrote: > On 12/20/2007 09:41 AM, Martin Sourada wrote: > > That's good news! Just some little questions. Has epiphany been ported > > on xulrunner or do I need to wait just a little more to upgrade firefox? > > Christian Persch has a private branch that he's been working on that he > hasn't released yet, to get it to more or less work. He said he wants > to clean up the code for it, but it depends on when he feels like > releasing it. I'm not sure when that will be, but hopefully soon. :-) > > > > Are you interested also in gtk rendering issues? > > Getting linux type issues sorted is one of the reasons we're shipping > FF3 in rawhide now. Before it becomes final and "too late" to fix any > non-security/stability type things. > > Please report bugs upstream since we're taking it pretty much as-is. > Additionally, please check any bugs you may have filed in RH bugzilla > about firefox 2, to see if they still exist in FF3. > > > I noticed so far (using > > mozilla's nightly builds of FF3) that the close buttons on tabs aren't > > highlighted on mouseover action and checkboxes and radiobuttons seems to > > have slightly wrong positioning when displayed on web pages. > > Please report it upstream, if you haven't! Nobody can fix it without > knowing about it. This is the reason it's a beta still. > > > Also > > widget's backgrounds seem to be derived from window's background, but > > IMHO it should be derived from page element background it is on (but > > this is really just a small issue). > > More upstream, please :-) OK, will do when I am at home :) Thanks, Martin From limb at jcomserv.net Thu Dec 20 12:48:41 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 20 Dec 2007 06:48:41 -0600 (CST) Subject: This seems to be getting worse In-Reply-To: <20071218184603.7015dbd1@damaestrojr> References: <20071218184603.7015dbd1@damaestrojr> Message-ID: <39631.63.85.68.164.1198154921.squirrel@mail.jcomserv.net> > On Tue, 18 Dec 2007 19:49:07 -0500 > Neal Becker wrote: > >> Warning: don't show this to children >> http://fedora.org/ >> > > ... or the kitten gets it ... No, that's rawhide. :) > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jwboyer at gmail.com Thu Dec 20 13:01:09 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 20 Dec 2007 07:01:09 -0600 Subject: Delays in package processing In-Reply-To: <476A1CA4.2040009@leemhuis.info> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> Message-ID: <20071220070109.0b77ea57@hansolo.jdub.homelinux.org> On Thu, 20 Dec 2007 08:41:24 +0100 Thorsten Leemhuis wrote: > On 20.12.2007 05:39, Michael Schwendt wrote: > > On Wed, 19 Dec 2007 14:55:51 -0500, Tom "spot" Callaway wrote: > >> On Wed, 2007-12-19 at 11:52 -0800, Bryan O'Sullivan wrote: > >>> Is the package signing step done by hand? That's been my understanding, > >>> but maybe I'm missing something. It reminds me of Sigourney Weaver's > >>> role in "Galaxy Quest": a seemingly needless insertion of people into > >>> the process. > >>> If so, why? Can we switch to an automated process? > >> It is currently a manual process, and Jesse Keating has been working for > >> some time to make an open source signing server that will work for > >> Fedora's infrastructure needs but also be useful for anyone. > > Just wondering: Is Jesse the only one that does pushes? Maybe we should > give at least one other person access to the signing key? Essentially, he is. Others have access to the key but Jesse does the pushes 9 times out of 10. That is a major reason for the signing server. It allows others to help out without having to know the super sekret key. josh From jwboyer at gmail.com Thu Dec 20 13:03:49 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 20 Dec 2007 07:03:49 -0600 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A24BD.70906@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> Message-ID: <20071220070349.7916f0e1@hansolo.jdub.homelinux.org> On Thu, 20 Dec 2007 09:15:57 +0100 Thorsten Leemhuis wrote: > > Further: I'd like to ask FESCo to add a rule to that all proposals have > to be posted to this list as full text with a special tag in the subject > (something like [Proposal for FESCo voting]) -- currently its IMHO way > to easy to miss a proposal that come up for FESCo voting. And often only > links gets posted to the wiki pages -- the result afaics is that only a > few people click on the link, even less read, and even less comment on > it; if they comment then in the wiki, where others miss it. +1 > IOW: no real discussion comes up and contributers don't get involved > into the decision finding process. That's not what FESCo wants -- or is it? No. josh From jima at beer.tclug.org Thu Dec 20 13:17:20 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 20 Dec 2007 07:17:20 -0600 (CST) Subject: Putting K3b back onto the DVDs? In-Reply-To: References: Message-ID: On Thu, 20 Dec 2007, Kevin Kofler wrote: > As K3b is probably the best Free CD/DVD burning program around, the > burning tool of choice of most KDE users and even several GNOME users, I > think it would be great if this could be put back onto the DVD images in > F9. Can this be added to the pungi kickstart config? I can attest to its universal appeal; even when I was primarily a GNOME user, I still found K3b to be the best option available. I say +1, too. :-) Jima From mike at miketc.com Thu Dec 20 13:17:57 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 20 Dec 2007 07:17:57 -0600 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220112255.5a79fc1e@dhcp03.addix.net> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> Message-ID: <1198156677.4120.0.camel@scrappy.miketc.com> On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote: > > > Had the same problem. Seems like it needs xulrunner from koji as > > well. After I installed that it starts fine (although most of my > > Add-ons are incompatible). > > adding "extensions.checkCompatibility = false" to about:config got > some of them back (especially adblock, which is quite essential). Does it work OK with java-icedtea-plugin and also flash? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From fedora at camperquake.de Thu Dec 20 13:23:43 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Dec 2007 14:23:43 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198156677.4120.0.camel@scrappy.miketc.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> Message-ID: <20071220142343.5c190ea8@dhcp03.addix.net> Hi. On Thu, 20 Dec 2007 07:17:57 -0600, Mike Chambers wrote: > Does it work OK with java-icedtea-plugin and also flash? Flash works, and I know no Java-Applets that work with icedtea (even in Firefox 2). From poelstra at redhat.com Thu Dec 20 00:22:04 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 19 Dec 2007 16:22:04 -0800 Subject: Stalled Proposed Features for F9 Message-ID: <4769B5AC.9030603@redhat.com> Happy Holidays! The following feature pages are in CategoryProposedFedora9 which indicates that the feature owner is requesting that FESCo vote on them at the next meeting. I have not raised these features to FESCo for a vote because certain parts of the pages are incomplete and it doesn't make sense for FESCo to review a feature when all the information is not present. http://fedoraproject.org/wiki/Releases/FeatureXULRunner http://fedoraproject.org/wiki/Releases/FeatureVolumeControl http://fedoraproject.org/wiki/Releases/FeatureRPMYumEnhancements http://fedoraproject.org/wiki/Features/NewGdm http://fedoraproject.org/wiki/Features/RandrSupport http://fedoraproject.org/wiki/Features/XenPvops http://fedoraproject.org/wiki/Releases/FeatureFirefox3 http://fedoraproject.org/wiki/Features/GCC4.3 http://fedoraproject.org/wiki/Features/EFI More information can be found here: http://fedoraproject.org/wiki/Features/Dashboard I have contacted many of the feature owners individually. If pages remain in their present state by 2008-01-01 I will change their category to CategoryProposedFeature. Thanks, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From denis at poolshark.org Thu Dec 20 13:31:19 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 20 Dec 2007 14:31:19 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: Message-ID: <476A6EA7.3050904@poolshark.org> Jima wrote: > On Thu, 20 Dec 2007, Kevin Kofler wrote: >> As K3b is probably the best Free CD/DVD burning program around, the >> burning tool of choice of most KDE users and even several GNOME users, >> I think it would be great if this could be put back onto the DVD >> images in F9. Can this be added to the pungi kickstart config? > > I can attest to its universal appeal; even when I was primarily a GNOME > user, I still found K3b to be the best option available. I say +1, too. did you try brasero ? From jkeating at redhat.com Thu Dec 20 13:46:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 08:46:11 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A24BD.70906@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> Message-ID: <20071220084611.448771b4@redhat.com> On Thu, 20 Dec 2007 09:15:57 +0100 Thorsten Leemhuis wrote: > I'd like to ask FESCo to please not realize the PackageACLOpening > proposal without the NewMaintainerContainment. In fact if FESCo should > I'll continue to lock down my packages just because I fear the risk > that a just-sponsored-contributers puts something bad (e.g. malicious > code) into one of my packages in CVS (even if then there are much > better targets to get bad code out to users easily) and uses the > CTRL+C trick to prevent a commit message. I see them as somewhat related as well. However if you notice from the proposal that maintainers will be given the opportunity to easily opt-out of opening their packages, so that we /could/ if we so choose do the opening now before new maintainer containment is in full swing, since that will likely prove to take longer to set up. > > While on the CTRL+C issue to prevent commit messages: will FESCo > continue to ignore it? From what I gather in the past, there is no way to fix this outside of moving to a different SCM. I could be wrong, but quite frankly on the list of things I'd like to accomplish, fixing this is pretty low on the list. I don't think /anybody/ in FESCo would turn down a fix for this, should some enterprising soul provide one. > > Further: I'd like to ask FESCo to add a rule to that all proposals > have to be posted to this list as full text with a special tag in the > subject (something like [Proposal for FESCo voting]) -- currently its > IMHO way to easy to miss a proposal that come up for FESCo voting. > And often only links gets posted to the wiki pages -- the result > afaics is that only a few people click on the link, even less read, > and even less comment on it; if they comment then in the wiki, where > others miss it. That's not a terrible idea. Would you be willing to work up a "how to propose something to FESCo" page on the wiki? I looked for one once I created an easy to use wiki template that can optionally be used for creating proposals, but I couldn't find it. Would you like to make one? > IOW: no real discussion comes up and contributers don't get involved > into the decision finding process. That's not what FESCo wants -- or > is it? Nope, that's not what we want at all. -- 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 Thu Dec 20 13:50:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 08:50:09 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220142343.5c190ea8@dhcp03.addix.net> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> Message-ID: <20071220085009.1f5afdb5@redhat.com> On Thu, 20 Dec 2007 14:23:43 +0100 Ralf Ertzinger wrote: > Java-Applets that work with icedtea > (even in Firefox 2). Huh. Every java applet I've come across has worked in IcedTea. -- 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 Thu Dec 20 13:51:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 08:51:13 -0500 Subject: rescue.iso images? In-Reply-To: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> Message-ID: <20071220085113.5559cec9@redhat.com> On Thu, 20 Dec 2007 11:53:08 +0200 "Gilboa Davara" wrote: > Please forgive me if it has been asked before, but, when can we expect > to see rawhide installation isos and/or vmlinuz+initrd sets? They're attempted each night ( boot.iso which has the vmlinuz+initrd+stage1 stuff ). However due to the nature of rawhide, it often fails. However it looks like last night we at least got images for i386 and ppc. -- 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.roberts.uk at googlemail.com Thu Dec 20 13:48:09 2007 From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts) Date: Thu, 20 Dec 2007 13:48:09 +0000 Subject: rescue.iso images? In-Reply-To: <20071220085113.5559cec9@redhat.com> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> <20071220085113.5559cec9@redhat.com> Message-ID: <1198158489.3495.0.camel@localhost.localdomain> On Thu, 2007-12-20 at 08:51 -0500, Jesse Keating wrote: > On Thu, 20 Dec 2007 11:53:08 +0200 > "Gilboa Davara" wrote: > > > Please forgive me if it has been asked before, but, when can we expect > > to see rawhide installation isos and/or vmlinuz+initrd sets? > > They're attempted each night ( boot.iso which has the > vmlinuz+initrd+stage1 stuff ). However due to the nature of rawhide, > it often fails. However it looks like last night we at least got > images for i386 and ppc. And these get distributed to the mirrors right!? Sorry if that's a stupid question... Jon From pbrobinson at gmail.com Thu Dec 20 13:53:28 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 20 Dec 2007 13:53:28 +0000 Subject: rawhide report: 20071220 changes In-Reply-To: <200712201217.lBKCHag6009411@porkchop.devel.redhat.com> References: <200712201217.lBKCHag6009411@porkchop.devel.redhat.com> Message-ID: <5256d0b0712200553g788db9f7o361f65d3c0388cfd@mail.gmail.com> > swfdec-0.5.5-2.fc9 > ------------------ > * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 > - Build w/ pulse audio support. > Probably not a whole lot of point enabling the PulseAudio support yet as it doesn't yet work. See this post from a couple of days ago, not that audio worked when it was compiled with alsa. https://www.redhat.com/archives/fedora-test-list/2007-December/msg00399.html Peter From rc040203 at freenet.de Thu Dec 20 14:01:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Dec 2007 15:01:16 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A24BD.70906@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> Message-ID: <1198159276.3656.88.camel@beck.corsepiu.local> On Thu, 2007-12-20 at 09:15 +0100, Thorsten Leemhuis wrote: > On 19.12.2007 19:49, Brian Pepple wrote: > > /topic MISC - > > http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 > > > > /topic MISC - > > http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - > > f13 > > I'd like to ask FESCo to please not realize the PackageACLOpening > proposal without the NewMaintainerContainment. -1 PackageACLOpening is a step into the right direction to colaborative maintainership, to less bureaucracy and to a more efficient and flexible workflow. However, I find coupling it to NewMaintainerContainment would void most of the benefits PackageACLOpening opens, because it ties access to a small group ("sponsors"). That said, I think it should be extended to a more general notion of "groups", e.g. SIGs, -specialists, etc., such that groups on people can collaborate on groups of packages[1]. Ralf [1] E.g. perl packages. The perl-SIG recently tried to add "perl-sig" as owner of a larger set of packages whose maintainer got AWOL, but we've been told that the packagedb doesn't support this. We ended up with dividing the dead packages between us, and "informally mutually granting" access. If the NewMaintainerContainment became effective, we probably would have to resort to explicitly adding us to all of our packages (I am talking about several 100s of packages). From fedora at camperquake.de Thu Dec 20 14:03:08 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Dec 2007 15:03:08 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220085009.1f5afdb5@redhat.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> Message-ID: <20071220150308.4fac205f@dhcp03.addix.net> Hi. On Thu, 20 Dec 2007 08:50:09 -0500, Jesse Keating wrote: > > Java-Applets that work with icedtea > > (even in Firefox 2). > > Huh. Every java applet I've come across has worked in IcedTea. Well, most of those I come across don't. Not that I care about Java applets in general, but from time to time I look at the state of icedtea. From caillon at redhat.com Thu Dec 20 14:07:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 20 Dec 2007 15:07:22 +0100 Subject: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198090164.4860.3.camel@kennedy> References: <1198090164.4860.3.camel@kennedy> Message-ID: <476A771A.30001@redhat.com> On 12/19/2007 07:49 PM, 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 18:00 UTC > in #fedora-meeting on irc.freenode.org: I will be unable to attend, sadly. > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 +1 *IFF* NewMaintainerContainment is approved. > > /topic MISC - > http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - > f13 In general, +1. Discussion points: * How do maintainers get added to the elevated group? N number of people in the elevated group vouch for them. I think a good number of N is 2. * What maintainers are grandfathered in? We need to ensure that packagers that sometimes need to touch a large portion of packages that they don't own (for dependency rebuilds, package cleanup, rel-eng, etc) are still able to. * Formal process for revoking access. We should probably have a way to revoke access in the unlikely case someone goes postal... > > /topic Status Update: Compat Policy > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy "It also means that security changes, fixes, etc. " Huh? :-) I think the idea is right, but it could be better organized. Bulleted lists make things easy to see. Something like.... http://caillon.fedorapeople.org/compat.html From jkeating at redhat.com Thu Dec 20 14:09:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 09:09:03 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198159276.3656.88.camel@beck.corsepiu.local> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <1198159276.3656.88.camel@beck.corsepiu.local> Message-ID: <20071220090903.13e3782e@redhat.com> On Thu, 20 Dec 2007 15:01:16 +0100 Ralf Corsepius wrote: > However, I find coupling it to NewMaintainerContainment would void > most of the benefits PackageACLOpening opens, because it ties access > to a small group ("sponsors"). That said, I think it should be > extended to a more general notion of "groups", e.g. SIGs, > -specialists, etc., such that groups on people can collaborate > on groups of packages[1]. > > Ralf > > [1] E.g. perl packages. The perl-SIG recently tried to add "perl-sig" > as owner of a larger set of packages whose maintainer got AWOL, but > we've been told that the packagedb doesn't support this. We ended up > with dividing the dead packages between us, and "informally mutually > granting" access. If the NewMaintainerContainment became effective, we > probably would have to resort to explicitly adding us to all of our > packages (I am talking about several 100s of packages). Please don't think that new maintainer containment is a set in stone proposal. In fact, one of the open questions is who gets added to the set of folks who gain wide access. I want that group to be as big as possible, just not inclusive of new packagers. -- 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 caillon at redhat.com Thu Dec 20 14:10:20 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 20 Dec 2007 15:10:20 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198156677.4120.0.camel@scrappy.miketc.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> Message-ID: <476A77CC.5040906@redhat.com> On 12/20/2007 02:17 PM, Mike Chambers wrote: > On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote: >> Hi. >> >> On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote: >> >>> Had the same problem. Seems like it needs xulrunner from koji as >>> well. After I installed that it starts fine (although most of my >>> Add-ons are incompatible). >> adding "extensions.checkCompatibility = false" to about:config got >> some of them back (especially adblock, which is quite essential). > > Does it work OK with java-icedtea-plugin and also flash? To avoid answering everyone's "does it work with XYZ?" questions, I'm going to suggest you try it and file bugs if it doesn't. :-) From jkeating at redhat.com Thu Dec 20 14:13:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 09:13:08 -0500 Subject: rescue.iso images? In-Reply-To: <1198158489.3495.0.camel@localhost.localdomain> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> <20071220085113.5559cec9@redhat.com> <1198158489.3495.0.camel@localhost.localdomain> Message-ID: <20071220091308.2544b126@redhat.com> On Thu, 20 Dec 2007 13:48:09 +0000 Jonathan Roberts wrote: > And these get distributed to the mirrors right!? Sorry if that's a > stupid question... Yes, you can find them in the os/images/ directory of i386, x86_64, and ppc arches. -- 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 marc at mwiriadi.id.au Thu Dec 20 14:13:41 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Thu, 20 Dec 2007 23:13:41 +0900 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: Message-ID: <1198160022.3142.0.camel@localhost.localdomain> On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > It has been brought to my attention > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/) that K3b is > no longer available on the DVD images (since the Core-Extras merge). As far as > I can tell, this is because it is marked only as "optional" and not "default" > in the sound-and-video group? As K3b is probably the best Free CD/DVD burning > program around, the burning tool of choice of most KDE users and even several > GNOME users, I think it would be great if this could be put back onto the DVD > images in F9. Can this be added to the pungi kickstart config? > > Kevin Kofler > +1 and I run Gnome Cheers, Marc From fedora at leemhuis.info Thu Dec 20 14:25:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 15:25:47 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <20071220084611.448771b4@redhat.com> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> Message-ID: <476A7B6B.90700@leemhuis.info> On 20.12.2007 14:46, Jesse Keating wrote: > On Thu, 20 Dec 2007 09:15:57 +0100 > Thorsten Leemhuis wrote: >> I'd like to ask FESCo to please not realize the PackageACLOpening >> proposal without the NewMaintainerContainment. In fact if FESCo should >> I'll continue to lock down my packages just because I fear the risk >> that a just-sponsored-contributers puts something bad (e.g. malicious >> code) into one of my packages in CVS (even if then there are much >> better targets to get bad code out to users easily) and uses the >> CTRL+C trick to prevent a commit message. > I see them as somewhat related as well. However if you notice from the > proposal that maintainers will be given the opportunity to easily > opt-out of opening their packages, so that we /could/ if we so choose > do the opening now before new maintainer containment is in full swing, > since that will likely prove to take longer to set up. Well, sure, but it might mean double work for some maintainers (first agreed to open, later close again when the containment is in full swing). The end results also might be quite different depending on how and when the "PackageACLOpening" is announced, as most people won't flip the bits twice. Currently the whole things sounds a bit like: now: ACLs for all packages get removed by default to allow everyone access everywhere to fix things soon after: we do a proper solution where trusted people get access everywhere as giving everyone (including freshly sponsored contributers) access everywhere is a security risk I'd much prefer to omit the first step, continue a few weeks more with the current practice and merge the "PackageACLOpening" into the "NewMaintainerContainment" with a sane default. /me wonders if we actually need a "Package open for all cvsextras members" at all once the NewMaintainerContainment is in place; why should we give new packagers access on packages they should not deal with? >> While on the CTRL+C issue to prevent commit messages: will FESCo >> continue to ignore it? > From what I gather in the past, there is no way to fix this outside of > moving to a different SCM. Last time we looked was about one year ago and for Extras only. Now after the merge the problem IMHO is way more dangerous as more popular packages (better targets) are in the mix. >> Further: I'd like to ask FESCo to add a rule to that all proposals >> have to be posted to this list as full text with a special tag in the >> subject (something like [Proposal for FESCo voting]) -- currently its >> IMHO way to easy to miss a proposal that come up for FESCo voting. >> And often only links gets posted to the wiki pages -- the result >> afaics is that only a few people click on the link, even less read, >> and even less comment on it; if they comment then in the wiki, where >> others miss it. > That's not a terrible idea. Would you be willing to work up a "how to > propose something to FESCo" page on the wiki? I looked for one once I > created an easy to use wiki template that can optionally be used for > creating proposals, but I couldn't find it. Would you like to make one? I wrote that months ago already ;-) See: http://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines Section "Meeting shall be quick"; [...] So we need to get informations exchanged all of the time and prepare the meetings properly. That means for example: [...] * proposals need to be written before the meetings and put up for discussion or further enhancements for some time -- discussions should happen on fedora-devel-list normally, as that allows non-FESCo-members to get involved, too (and that's what we want!). The results from the discussion should be integrated into the proposal. Mention things that are controversial in the status section and we'll discuss them in the meetings. Clarifying the wording or adding something like a "proposal must be in the wiki and posted as full text (by copying the sourcecode of the wikipage) to the list" somewhere should do the trick and is likely way better then yet another inflexible template or written down bureaucracy ("to do you have to follow ") Cu knurd From jkeating at redhat.com Thu Dec 20 14:34:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 09:34:43 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A7B6B.90700@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> Message-ID: <20071220093443.3ccdca2a@redhat.com> On Thu, 20 Dec 2007 15:25:47 +0100 Thorsten Leemhuis wrote: > then yet another inflexible template Is this a thinly veiled dig at the proposal template I created? Do you have actual feedback you'd like to give 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 fedora at leemhuis.info Thu Dec 20 14:44:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 15:44:43 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198159276.3656.88.camel@beck.corsepiu.local> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <1198159276.3656.88.camel@beck.corsepiu.local> Message-ID: <476A7FDB.9020609@leemhuis.info> On 20.12.2007 15:01, Ralf Corsepius wrote: > On Thu, 2007-12-20 at 09:15 +0100, Thorsten Leemhuis wrote: >> On 19.12.2007 19:49, Brian Pepple wrote: >>> /topic MISC - >>> http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 >>> >>> /topic MISC - >>> http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - >>> f13 >> I'd like to ask FESCo to please not realize the PackageACLOpening >> proposal without the NewMaintainerContainment. > -1 > PackageACLOpening is a step into the right direction to colaborative > maintainership, to less bureaucracy and to a more efficient and flexible > workflow. I'm all for "colaborative maintainership,"(I'd call it wiki-style maintenance effort), but I don't think that means we need to remove all things that protect the security of the bits we provide. Opening CVS more sounds to me like having a club house with all the valuable things that were created over the past years in it and all inner doors unlocked where every just approved club member gets a key to the entrance. Would you do that in a club with over 500 members where it's not that hard to become a club member? > However, I find coupling it to NewMaintainerContainment would void most > of the benefits PackageACLOpening opens, because it ties access to a > small group ("sponsors"). See f13's post, it's not about sponsors, they are just a example and a group of contributers we trust. I agree with f13 that the group needs to be bigger then just sponsors (albeit I afaics want it a bit smaller then what f13 thinks about) > That said, I think it should be extended to a > more general notion of "groups", e.g. SIGs, -specialists, etc., > such that groups on people can collaborate on groups of packages[1]. Sounds good -- maybe that could be added to NewMaintainerContainment, as the changes that are needed for that are likely similar? > [...] CU thl From dimi at lattica.com Thu Dec 20 14:49:49 2007 From: dimi at lattica.com (Dimi Paun) Date: Thu, 20 Dec 2007 09:49:49 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220085009.1f5afdb5@redhat.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> Message-ID: <1198162189.5000.195.camel@dimi.lattica.com> On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote: > Huh. Every java applet I've come across has worked in IcedTea. Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly. In fact, for some cases the situation is worse than not having Java, because it looks like its available (and thus prevent a decent fallback), and when they start they block/crash the browser. -- Dimi Paun Lattica, Inc. From fedora at leemhuis.info Thu Dec 20 14:54:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 15:54:27 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <20071220093443.3ccdca2a@redhat.com> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> Message-ID: <476A8223.8080902@leemhuis.info> On 20.12.2007 15:34, Jesse Keating wrote: > On Thu, 20 Dec 2007 15:25:47 +0100 > Thorsten Leemhuis wrote: > >> then yet another inflexible template > Is this a thinly veiled dig at the proposal template I created? Do you > have actual feedback you'd like to give on it? You mean http://fedoraproject.org/wiki/Development/FescoProposalTemplate ? No, looks fine and certainly is helpful for those that want to be guided. But sometimes it might be easier for people to say it in different ways, and that should be allowed. And a problem I fear a lot is this: Contributer: "I want to do foo, to do bar" FESCo: "Please use the template" Contributer: "But foo is self-explaining. Why do I have to write such a lengthy proposal? I have no time for such crap." End result: nothing gets done. Cu knurd From jkeating at redhat.com Thu Dec 20 14:59:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 09:59:10 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A8223.8080902@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> <476A8223.8080902@leemhuis.info> Message-ID: <20071220095910.65932554@redhat.com> On Thu, 20 Dec 2007 15:54:27 +0100 Thorsten Leemhuis wrote: > No, looks fine and certainly is helpful for those that want to be > guided. But sometimes it might be easier for people to say it in > different ways, and that should be allowed. And a problem I fear a lot > is this: > > Contributer: "I want to do foo, to do bar" > > FESCo: "Please use the template" > > Contributer: "But foo is self-explaining. Why do I have to write such > a lengthy proposal? I have no time for such crap." > > End result: nothing gets done. That's why it's listed as optional. -- 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 overholt at redhat.com Thu Dec 20 14:59:54 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 20 Dec 2007 09:59:54 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198162189.5000.195.camel@dimi.lattica.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <1198162189.5000.195.camel@dimi.lattica.com> Message-ID: <20071220145953.GA17821@redhat.com> * Dimi Paun [2007-12-20 09:50]: > > On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote: > > Huh. Every java applet I've come across has worked in IcedTea. > > Sorry, but situation is not that rosy. Trivial applets > work, that's true, but more complicated (and interesting > ones) depend on LiveConnect, and those break badly. This is being worked on. It's not trivial and there is no free implementation at the moment. I'm sure Tom Fitzsimmons and others would love help in this area if anyone is able to give it. Andrew -------------- 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 Dec 20 15:00:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 10:00:25 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198162189.5000.195.camel@dimi.lattica.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <1198162189.5000.195.camel@dimi.lattica.com> Message-ID: <20071220100025.6c35ff35@redhat.com> On Thu, 20 Dec 2007 09:49:49 -0500 Dimi Paun wrote: > Sorry, but situation is not that rosy. Trivial applets > work, that's true, but more complicated (and interesting > ones) depend on LiveConnect, and those break badly. > > In fact, for some cases the situation is worse than > not having Java, because it looks like its available > (and thus prevent a decent fallback), and when they > start they block/crash the browser. How much of that is icedtea vs just not being java 1.5 or 1.4, given that icedtea is 1.7 I think. -- 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 Thu Dec 20 15:05:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Dec 2007 16:05:21 +0100 Subject: Delays in package processing In-Reply-To: <1198131169.3656.34.camel@beck.corsepiu.local> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> Message-ID: <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Dec 2007 07:12:49 +0100, Ralf Corsepius wrote: > Isn't testing what is supposed to implement the "delay queue", which is > what you seem to be asking for. It is circumvented too easily. Packagers raise the karma for their own packages. Release people don't reject quick pushes from testing to stable, which are not security related or critical. Updates-testing is just not popular enough due to the bad smell of burnt guinea-pigs. The packagers see it as a just another hurdle on the road to getting package updates published. The users don't like a never-ending stream of updates to download when it doesn't fix their very own list of problems. > > The updates > > repository is continuously flooded with version upgrades, which move > > farther away from the tested gold release of the distribution only to > > break due to new bugs, which then require further updates. > > At the same time Fedora+updates is suffering from bugs not receiving > fixes in reasonable time. Is this because they sit in "pending" without being pushed for several days? Or is this because the packages contain bugs which are not fixed or which are fixed only in rawhide? > To put it bluntly: > * As a packager, I feel strangled by current release practice. What do you want? Daily pushes? Would that suffice? Immediate [automatic] pushes of security/critical fixes when the packager clicks a button? > * As a user I am gradually feeling annoyed by seeing bugs not getting > fixed. Our users frequently see update announcements, but the tools don't find these updates because only the master site has them. It is not obvious that it takes 24 hours or days for mirrors to offer the updates. > * If I were still a "low bandwidth user" I would quit Fedora now, > because updates are being pushed in "big chunks" blocking internet > access for hours once a week, instead of being fed with "small chunks" > in shorte? intervals. The problem is that too many updates don't fix real-world problems or issues reported in bugzilla tickets. They are ordinary minor version updates with no or questionable benefit (such as uninteresting changes, huge autotools updates, dangerous from-scratch-rewrites, stuff that invalidates the results of the fedora development testing period, spec "fixes" for packages that built fine, superfluous %config modifications which trigger .rpm{new,save} and annoy users who actually use the software). From mschwendt.tmp0701.nospam at arcor.de Thu Dec 20 15:05:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Dec 2007 16:05:28 +0100 Subject: Delays in package processing In-Reply-To: <476A1CA4.2040009@leemhuis.info> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> Message-ID: <20071220160528.9a1fea8b.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Dec 2007 08:41:24 +0100, Thorsten Leemhuis wrote: > [...] there are currently up to four (or even > more) days between pushes afaics (the last one right now for example was > on 15 December 2007): > > * for normal updates that's not a problem, but I think four days are a > to long delay for updates that fix security issues. If that is true, then wtf is the purpose of the "security" check-box in bodhi if it doesn't inform release engineers about the necessity to push a security related update? For Extras I've asked packagers to mark their packages appropriately (in the cvs commit comment or %changelog entry, adding the CVE id or stating that it's a "security/vulnerability fix") in order to help deciding when to push the next time or what to push quickly with a delayed build report. > And, BTW, what's exactly the problem with "moving target for all > mirrors"? There were (are?) yum problems iirc (?), but I suppose we can > fix them if we want? If the master site is modified too often, the window, during which mirrors can sync a complete set [*] of changes, becomes smaller. I guess Matt Domsch can tell how often mirrors sync on average. [*] packages plus matching metadata > CU > thl > > (?) -- downloading metadata from one mirror, download error on it, > switching to another mirror that has even new push where the file yum > tries to download is already is gone again That's one of the problems. Files not found, persistent metadata checksum errors (older repomd.xml from previous mirror in conjunction with newer metadata from other mirrors), users seeing update announcements but tools not seeing the updates [yet]. And last but not least, do you like being notified about system updates daily? First there's a series of minor version updates for some package, then upstream releases the next stable major version, and the packager smacks his lips because it's so exiciting to push that hot new stuff to Fedora 7+8+development instead of giving it time to test it in development. From ericsbinaryworld at gmail.com Thu Dec 20 15:07:06 2007 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Thu, 20 Dec 2007 10:07:06 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198160022.3142.0.camel@localhost.localdomain> References: <1198160022.3142.0.camel@localhost.localdomain> Message-ID: <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> I also use K3B. In comparison all of the Gnome burners are crap. (And I primarily use Gnome) On Dec 20, 2007 9:13 AM, Marc Wiriadisastra wrote: > > On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > > It has been brought to my attention > > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/) that > K3b is > > no longer available on the DVD images (since the Core-Extras merge). As > far as > > I can tell, this is because it is marked only as "optional" and not > "default" > > in the sound-and-video group? As K3b is probably the best Free CD/DVD > burning > > program around, the burning tool of choice of most KDE users and even > several > > GNOME users, I think it would be great if this could be put back onto > the DVD > > images in F9. Can this be added to the pungi kickstart config? > > > > Kevin Kofler > > > +1 and I run Gnome > > Cheers, > > Marc > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Eric Mesa http://www.ericsbinaryworld.com http://server.ericsbinaryworld.com "Do not worry about those things that are outside of your circle of influence. For since they are outside of your power to control them it is simply a waste of time and energy to dwell on them. Instead, turn your attention to those things that you can control and grow your influence in those areas and you will see the effects begin to trickle out to those items that were previously out of your power to influence." ? Eric Mesa inspired by Covey's 7 Habits of Highly Effective People -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpepple at fedoraproject.org Thu Dec 20 15:12:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 20 Dec 2007 10:12:18 -0500 Subject: rawhide report: 20071220 changes In-Reply-To: <5256d0b0712200553g788db9f7o361f65d3c0388cfd@mail.gmail.com> References: <200712201217.lBKCHag6009411@porkchop.devel.redhat.com> <5256d0b0712200553g788db9f7o361f65d3c0388cfd@mail.gmail.com> Message-ID: <1198163538.7053.3.camel@nixon> On Thu, 2007-12-20 at 13:53 +0000, Peter Robinson wrote: > > swfdec-0.5.5-2.fc9 > > ------------------ > > * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 > > - Build w/ pulse audio support. > > > > Probably not a whole lot of point enabling the PulseAudio support yet > as it doesn't yet work. See this post from a couple of days ago, not > that audio worked when it was compiled with alsa. > > https://www.redhat.com/archives/fedora-test-list/2007-December/msg00399.html Um, I was the one that wrote that message, so I obviously was aware of it. I spent some time working with upstream yesterday, and was able to get the pa support to work in Rawhide. 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 bpepple at fedoraproject.org Thu Dec 20 15:24:01 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 20 Dec 2007 10:24:01 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A8223.8080902@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> <476A8223.8080902@leemhuis.info> Message-ID: <1198164241.2376.1.camel@nixon> On Thu, 2007-12-20 at 15:54 +0100, Thorsten Leemhuis wrote: > > You mean > http://fedoraproject.org/wiki/Development/FescoProposalTemplate ? > > No, looks fine and certainly is helpful for those that want to be > guided. But sometimes it might be easier for people to say it in > different ways, and that should be allowed. And a problem I fear a lot > is this: > > Contributer: "I want to do foo, to do bar" > > FESCo: "Please use the template" > > Contributer: "But foo is self-explaining. Why do I have to write such a > lengthy proposal? I have no time for such crap." > > End result: nothing gets done. That is why the proposal template isn't mandatory, merely suggested. 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 Dec 20 15:37:05 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 21 Dec 2007 00:37:05 +0900 Subject: Delays in package processing In-Reply-To: <1198131169.3656.34.camel@beck.corsepiu.local> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> Message-ID: <476A8C21.10701@ioa.s.u-tokyo.ac.jp> Ralf Corsepius wrote, at 12/20/2007 03:12 PM +9:00: > To put it bluntly: > * As a packager, I feel strangled by current release practice. > * As a user I am gradually feeling annoyed by seeing bugs not getting > fixed. Actually it is annoying for both me and the reporter that - I received a bug report from a Fedora user about some crashing bugs - I replied to him that I fixed them in release foo and the reporter confirmed it - I requested to push the rpms to stable on Sunday - But they have not been pushed even on Friday.... (in Japan it is already Friday now) Regards, Mamoru From jkeating at redhat.com Thu Dec 20 15:40:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 10:40:02 -0500 Subject: Delays in package processing In-Reply-To: <476A8C21.10701@ioa.s.u-tokyo.ac.jp> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <476A8C21.10701@ioa.s.u-tokyo.ac.jp> Message-ID: <20071220104002.15f73f32@redhat.com> On Fri, 21 Dec 2007 00:37:05 +0900 Mamoru Tasaka wrote: > - I requested to push the rpms to stable on Sunday > - But they have not been pushed even on Friday.... (in Japan it is > already Friday now) We had a buildsystem refresh over the weekend which led to delays in pushing with bodhi. I did finally get a push out last night though. -- 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 Thu Dec 20 15:46:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 16:46:57 +0100 Subject: Delays in package processing In-Reply-To: <20071220160528.9a1fea8b.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> <20071220160528.9a1fea8b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <476A8E71.806@leemhuis.info> On 20.12.2007 16:05, Michael Schwendt wrote: > On Thu, 20 Dec 2007 08:41:24 +0100, Thorsten Leemhuis wrote: > >> [...] there are currently up to four (or even >> more) days between pushes afaics (the last one right now for example was >> on 15 December 2007): >> * for normal updates that's not a problem, but I think four days are a >> to long delay for updates that fix security issues. > If that is true, Not sure, but the number of security updates in one push looks a bit odd now and then; take for example https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3308 Fixes multiple CVEs, but seems it took round about 7 days from build to the proper repos. The maintainer might be responsible for parts of this timeframe -- but it looks like it took 2 days from koji/bodhi creation to testing, and five from testing to stable. > then wtf is the purpose of the "security" check-box in > bodhi if it doesn't inform release engineers about the necessity to push a > security related update? I suppose part of the reason is to add a [SECURITY] to the subject and mark it properly in the metadata. > [...] >> And, BTW, what's exactly the problem with "moving target for all >> mirrors"? There were (are?) yum problems iirc (?), but I suppose we can >> fix them if we want? > If the master site is modified too often, the window, during which mirrors > can sync a complete set [*] of changes, becomes smaller. I guess Matt > Domsch can tell how often mirrors sync on average. But one the other hand pushing a lot more packages at once makes the dataset bigger, which makes the windows smaller for that sync. But I don't care much. >> (?) -- downloading metadata from one mirror, download error on it, >> switching to another mirror that has even new push where the file yum >> tries to download is already is gone again > That's one of the problems. Files not found, persistent metadata checksum > errors (older repomd.xml from previous mirror in conjunction with newer > metadata from other mirrors), users seeing update announcements but tools > not seeing the updates [yet]. Yeah, I've seen it as well. Should we file bugs (or are there bugs about it already?)? skvidal? > And last but not least, do you like being > notified about system updates daily? If they are security or otherwise relevant: yes. Queuing the other stuff for a once-a-week-push might be okay to the stable repos (but testing more often would be nice). > First there's a series of minor > version updates for some package, then upstream releases the next stable > major version, and the packager smacks his lips because it's so exiciting > to push that hot new stuff to Fedora 7+8+development instead of giving it > time to test it in development. +1 CU knurd From overholt at redhat.com Thu Dec 20 15:49:42 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 20 Dec 2007 10:49:42 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220100025.6c35ff35@redhat.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <1198162189.5000.195.camel@dimi.lattica.com> <20071220100025.6c35ff35@redhat.com> Message-ID: <20071220154942.GA19347@redhat.com> * Jesse Keating [2007-12-20 10:00]: > On Thu, 20 Dec 2007 09:49:49 -0500 > Dimi Paun wrote: > > > Sorry, but situation is not that rosy. Trivial applets > > work, that's true, but more complicated (and interesting > > ones) depend on LiveConnect, and those break badly. > > > > In fact, for some cases the situation is worse than > > not having Java, because it looks like its available > > (and thus prevent a decent fallback), and when they > > start they block/crash the browser. > > How much of that is icedtea vs just not being java 1.5 or 1.4, given > that icedtea is 1.7 I think. None. LiveConnect is the java<->javascript bridge. Tom Fitzsimmons is working on it. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Dec 20 15:50:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 16:50:33 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198164241.2376.1.camel@nixon> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> <476A8223.8080902@leemhuis.info> <1198164241.2376.1.camel@nixon> Message-ID: <476A8F49.5030002@leemhuis.info> On 20.12.2007 16:24, Brian Pepple wrote: > On Thu, 2007-12-20 at 15:54 +0100, Thorsten Leemhuis wrote: >> You mean >> http://fedoraproject.org/wiki/Development/FescoProposalTemplate ? >> >> No, looks fine and certainly is helpful for those that want to be >> guided. But sometimes it might be easier for people to say it in >> different ways, and that should be allowed. And a problem I fear a lot >> is this: >> Contributer: "I want to do foo, to do bar" >> FESCo: "Please use the template" >> Contributer: "But foo is self-explaining. Why do I have to write such a >> lengthy proposal? I have no time for such crap." >> End result: nothing gets done. > That is why the proposal template isn't mandatory, merely suggested. I didn't say otherwise. I made the "I have something self-explaining that should be corrected without writing a proposal"-experience with another committee in Fedora-land ;-) Cu knurd From tcallawa at redhat.com Thu Dec 20 15:54:15 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 20 Dec 2007 10:54:15 -0500 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <476A8F49.5030002@leemhuis.info> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> <476A8223.8080902@leemhuis.info> <1198164241.2376.1.camel@nixon> <476A8F49.5030002@leemhuis.info> Message-ID: <1198166055.3370.13.camel@localhost.localdomain> On Thu, 2007-12-20 at 16:50 +0100, Thorsten Leemhuis wrote: > I didn't say otherwise. I made the "I have something self-explaining > that should be corrected without writing a proposal"-experience with > another committee in Fedora-land ;-) Since I'm assuming that you're talking about the FPC here, let me state the reason why the FPC requires that all proposals be written up: Because otherwise, we forget about them. If they're written up on the wiki and added to our agenda list, then we remember them and discuss them. We don't even require any format. Just write it up, put it in the list. If you can summarize the change in a single sentence, you can even just add that to the agenda. See: http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure ~spot (ps. if you're not talking about the FPC, my apologies, just think of this as a reminder for everyone on how to get issues on our radar) From pbrobinson at gmail.com Thu Dec 20 16:06:19 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 20 Dec 2007 16:06:19 +0000 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <5256d0b0712200806o780b30f3j25cbe943fe268e75@mail.gmail.com> On Dec 20, 2007 8:22 AM, Martin Stransky wrote: > Hello, > > Firefox 3 has finally landed in Rawhide. It's a slightly unpolished > version and we appreciate if you test it and report all issues to > bugzilla (like missing locales, broken plugins and so on). > > If you're interested and don't want to switch to rawhide, you can run > Firefox 3 on Fedora 8, too. Just download and compile the latest > xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install > firefox from rawhide. > > There's one side effect of this update. The former firefox-devel package > has been removed from rawhide and gecko-libs 1.8 is no more shipped. All > packages have to run with xulrunner (gecko-libs 1.9) now. > > If you're a package maintainer and your package already uses xulrunner, > please rebuild it against the new rawhide version. Xulrunner directory > has been changed and many gecko packages (if not all) are linked with > --rpath linker directive. As long as rpath is used you have to rebuild > gecko-libs based packages after each xulrunner change so please consider > to remove it. Gecko libraries are registered system wide by > /etc/ld.so.conf.d and rpath should not be necessary in rawhide. > > Happy testing&hacking! :) Is anyone seeing issues with adding sites with problematic SSL cert (self generated etc) to the exceptions list? I get the error "If you still wish to add an exception for this site, you can do so in your advanced encryption settings." but if I go into prefs -> advanced -> encryption I don't see the option to add exceptions. Or am i just looking in the wrong location. Other than that its excellent! Peter From jkeating at redhat.com Thu Dec 20 16:08:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Dec 2007 11:08:35 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <5256d0b0712200806o780b30f3j25cbe943fe268e75@mail.gmail.com> References: <476A2656.5060704@redhat.com> <5256d0b0712200806o780b30f3j25cbe943fe268e75@mail.gmail.com> Message-ID: <20071220110835.7573267b@redhat.com> On Thu, 20 Dec 2007 16:06:19 +0000 "Peter Robinson" wrote: > Is anyone seeing issues with adding sites with problematic SSL cert > (self generated etc) to the exceptions list? I get the error "If you > still wish to add an exception for this site, you can do so in your > advanced encryption settings." but if I go into prefs -> advanced -> > encryption I don't see the option to add exceptions. Or am i just > looking in the wrong location. Other than that its excellent! You have to click on View Certificates. -- 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 pbrobinson at gmail.com Thu Dec 20 16:17:48 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 20 Dec 2007 16:17:48 +0000 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220110835.7573267b@redhat.com> References: <476A2656.5060704@redhat.com> <5256d0b0712200806o780b30f3j25cbe943fe268e75@mail.gmail.com> <20071220110835.7573267b@redhat.com> Message-ID: <5256d0b0712200817k4872a856s6d0eb10d0a782d5e@mail.gmail.com> > > Is anyone seeing issues with adding sites with problematic SSL cert > > (self generated etc) to the exceptions list? I get the error "If you > > still wish to add an exception for this site, you can do so in your > > advanced encryption settings." but if I go into prefs -> advanced -> > > encryption I don't see the option to add exceptions. Or am i just > > looking in the wrong location. Other than that its excellent! > > You have to click on View Certificates. Ah yes. So you do. So intuitive :) Thanks for your help. Pete From fedora at leemhuis.info Thu Dec 20 16:22:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Dec 2007 17:22:45 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <1198166055.3370.13.camel@localhost.localdomain> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <20071220084611.448771b4@redhat.com> <476A7B6B.90700@leemhuis.info> <20071220093443.3ccdca2a@redhat.com> <476A8223.8080902@leemhuis.info> <1198164241.2376.1.camel@nixon> <476A8F49.5030002@leemhuis.info> <1198166055.3370.13.camel@localhost.localdomain> Message-ID: <476A96D5.8040108@leemhuis.info> On 20.12.2007 16:54, Tom "spot" Callaway wrote: > On Thu, 2007-12-20 at 16:50 +0100, Thorsten Leemhuis wrote: > >> I didn't say otherwise. I made the "I have something self-explaining >> that should be corrected without writing a proposal"-experience with >> another committee in Fedora-land ;-) > > Since I'm assuming that you're talking about the FPC here, let me state > the reason why the FPC requires that all proposals be written up: > Because otherwise, we forget about them. > > If they're written up on the wiki and added to our agenda list, then we > remember them and discuss them. a) if there wasn't ACLs in the wiki then I would have done the change in question myself after a proper discussion on the mailing list. No need to discuss that in the IRC meetings, no need for wiki changes, less work for the committee, no need to remember about it for days or weeks. In short: less bureaucracy for everyone. Sure, if a agreement can't be found on the list, then the committee in question needs to take care of it, which brings be to point b: b) if you want it written down to prevent that you forget it then you have to write it down yourself now and then if the one that brings a issue up doesn't do it. That's how I handled it in FESCo when I was chair and that's how I handle in EPEL atm as well. Sure, I sometimes missed issues, don't notice that something should be discussed further and some things fall of the radar after some weeks -- but I bring a lot of things up in the EPEL SIG meetings that were raised on the list, even if the reporter has moved on to something else in between. That what I expect from a committee and it's chair. And sure, I would be happier if people always take care of stuff they bring up own their own. But they don't, I have to live with it and take care of the stuff to make sure things get improved, as a lot of people don't have the energy do deal with committees. CU knurd From tonynelson at georgeanelson.com Thu Dec 20 16:34:18 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 20 Dec 2007 11:34:18 -0500 Subject: Delays in package processing In-Reply-To: <476A1CA4.2040009@leemhuis.info> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> Message-ID: At 8:41 AM +0100 12/20/07, Thorsten Leemhuis wrote: ... >And, BTW, what's exactly the problem with "moving target for all >mirrors"? There were (are?) yum problems iirc (1), but I suppose we can >fix them if we want? > >CU >thl > >(1) -- downloading metadata from one mirror, download error on it, >switching to another mirror that has even new push where the file yum >tries to download is already is gone again I used to have trouble with that until I wrote StableMirror. Among other things, it makes sure that each mirror it uses has the same date as the cached metadata, by checking the tiny repomd.xml when it switches mirrors. -- ____________________________________________________________________ TonyN.:' ' From kevin.kofler at chello.at Thu Dec 20 15:58:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 20 Dec 2007 15:58:52 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > It is circumvented too easily. Packagers raise the karma for their own > packages. Release people don't reject quick pushes from testing to stable, > which are not security related or critical. Why should they? Release engineering plays an important role in Fedora, but they are a small team compared to the huge number of package maintainers, they cannot really be expected to know more about the package than its maintainer. The maintainer should be the one who knows best what to push. There are already complaints that Fedora is too bureaucratic, having to justify "criticalness" of each upgrade makes it worse, not better. > The problem is that too many updates don't fix real-world problems or > issues reported in bugzilla tickets. > > They are ordinary minor version updates with no or questionable benefit Many of those minor version updates do fix real-world bugs. In general, that's the entire point of releasing an update upstream. Even if they aren't listed in bugzilla.redhat.com, that doesn't mean they didn't affect Fedora. > (such as uninteresting changes, huge autotools updates, Now if the ONLY changes are just autotools updates or other cleanups with no actual effect (like "change variable names to be more readable"), I agree that it doesn't make much sense to push the update. But maintainers normally don't push these. ;-) And then there are cases where an autotools update can actually fix problems, e.g. rpath-related issues, libtool dependency bloat, ... Maybe even issues which are more serious for the end-user than these, though I don't have a good example on hand. > dangerous from-scratch-rewrites, Sometimes partial rewrites are the only way to fix bugs (in a reasonable timeframe). For example, the KDE 3.5.7 KMail IMAP filtering regression was fixed by switching to the kdepim enterprise branch where the IMAP code had seen significant changes. > stuff that invalidates the results of the fedora development testing period, That's a pretty vague statement. I don't think any of the updates being pushed really do that. > spec "fixes" for packages that built fine, That's also too vague. Sure, pushing an update only for a fixed License tag is lame, but not many packagers did that. Some specfile issues are noticeable by the end user, e.g. unowned directories which can stray around on the file system, wrong permissions etc. And in many cases, the specfile cleanups were simply part of an upgrade to fix an actual issue which was synced from the development branch. Using the same specfile everywhere reduces the amount of maintenance needed and also reduces the risk of a screwup which was missed during Rawhide testing. > superfluous %config modifications which trigger .rpm{new,save} and annoy > users who actually use the software). Configuration changes are also usually done for a reason. Kevin Kofler From ville.skytta at iki.fi Thu Dec 20 17:02:34 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 20 Dec 2007 19:02:34 +0200 Subject: Mock: loss of login shell In-Reply-To: <20071219210010.GA15878@jasmine.xos.nl> References: <47697B8D.1020107@redhat.com> <20071219210010.GA15878@jasmine.xos.nl> Message-ID: <200712201902.36690.ville.skytta@iki.fi> On Wednesday 19 December 2007, Jos Vos wrote: > It's obvious that the devel packages assume > developers (like package builders, either human or not ;-)) run the > /etc/profile.d scripts. I disagree. Things should Just Work, and in this particular case that's easily accomplished by sourcing whatever needs to be sourced during the build in specfiles. From kevin.kofler at chello.at Thu Dec 20 16:05:48 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 20 Dec 2007 16:05:48 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> <20071220160528.9a1fea8b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > And last but not least, do you like being > notified about system updates daily? I poll for updates several times a day using Synaptic, I'd be perfectly happy to get new updates at each poll. If the notifications are annoying, then just poll manually, that way you get updates only when you're ready for them. :-) Kevin Kofler From Michael_E_Brown at dell.com Thu Dec 20 17:30:40 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 20 Dec 2007 11:30:40 -0600 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220085009.1f5afdb5@redhat.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> Message-ID: <20071220173039.GF5428@humbolt.us.dell.com> On Thu, Dec 20, 2007 at 08:50:09AM -0500, Jesse Keating wrote: > On Thu, 20 Dec 2007 14:23:43 +0100 > Ralf Ertzinger wrote: > > > Java-Applets that work with icedtea > > (even in Firefox 2). > > Huh. Every java applet I've come across has worked in IcedTea. Citrix Java ICA client doesnt work with IcedTea. Worse, native ICA client has bugs with seamless windows. Workaround is to disable seamless windows. -- Michael From david at fubar.dk Thu Dec 20 18:14:52 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 20 Dec 2007 13:14:52 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <1198037682.19318.89.camel@localhost.localdomain> References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219015529.GA24979@nostromo.devel.redhat.com> <1198030261.19318.83.camel@localhost.localdomain> <20071218222128.779d1d88@redhat.com> <1198037682.19318.89.camel@localhost.localdomain> Message-ID: <1198174492.10388.5.camel@oneill.fubar.dk> On Tue, 2007-12-18 at 23:14 -0500, Simo Sorce wrote: > It seem to me that this PA thing has the noble goal of making audio > easier to work with on a Desktop, and then you expect people to fiddle > manually with ConsoleKit/PolicyKit to make a trivial configuration > change for a common case? It's not difficult, it's just new. Hint 1: polkit-gnome-authorization Hint 2: http://people.freedesktop.org/~david/how-to-allow-audio-for-inactive-sessions.png David From jspaleta at gmail.com Thu Dec 20 18:37:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 20 Dec 2007 09:37:08 -0900 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198162189.5000.195.camel@dimi.lattica.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <1198162189.5000.195.camel@dimi.lattica.com> Message-ID: <604aa7910712201037wdbdb096r9051772296877460@mail.gmail.com> On Dec 20, 2007 5:49 AM, Dimi Paun wrote: > > On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote: > > Huh. Every java applet I've come across has worked in IcedTea. > > Sorry, but situation is not that rosy. Trivial applets > work, that's true, but more complicated (and interesting > ones) depend on LiveConnect, and those break badly. All I know is, the realtime display java applet for the superdarn radar system works... and that's all i need. -jef"Now if I could just get the license of superdarn related C libraries changed so I could re-distribute them, I could start submitting packages to Fedora and work on a superdarn spin"spaleta From mschwendt.tmp0701.nospam at arcor.de Thu Dec 20 19:05:48 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Dec 2007 20:05:48 +0100 Subject: Delays in package processing In-Reply-To: References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Dec 2007 15:58:52 +0000 (UTC), Kevin Kofler wrote: > > It is circumvented too easily. Packagers raise the karma for their own > > packages. Release people don't reject quick pushes from testing to stable, > > which are not security related or critical. > > Why should they? The answer is above. To enforce that packages stay in updates-testing for a certain period of time unless they are marked as security/emergency. We need to give the user community time to take notice of test-updates, take pre-cautions (e.g. use multi-boot or a test-machine) and actually help with testing updates. > Release engineering plays an important role in Fedora, but > they are a small team compared to the huge number of package maintainers, they > cannot really be expected to know more about the package than its maintainer. > The maintainer should be the one who knows best what to push. For many software projects and their release habits, as a packager you need to be very careful about what upstream releases you take for a stable distribution that has undergone a long development/testing cycle. Even so-called "minor" updates often break in lots of ways. The steady stream of updates where upstream releases are packaged and published in less than 24 hours is too much of a risk in my view. > There are already complaints that Fedora is too bureaucratic, having to > justify "criticalness" of each upgrade makes it worse, not better. That's easy. The spec %changelog entry already ought to explain why the update is important. It's the many hundreds small/minor/unimportant updates which fill the updates repository and drift away from the original release of the distribution. It leads to a scenario where after firstboot you are offered so many packages that you're annoyed. Anyway, the rest of your mail only tells me that you disagree and that it is unlikely that we will agree on it ever. I don't see any need to comment on any excerpts in detail. From mschwendt.tmp0701.nospam at arcor.de Thu Dec 20 19:09:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Dec 2007 20:09:25 +0100 Subject: Delays in package processing In-Reply-To: References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <476A1CA4.2040009@leemhuis.info> <20071220160528.9a1fea8b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071220200925.845e665f.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Dec 2007 16:05:48 +0000 (UTC), Kevin Kofler wrote: > > And last but not least, do you like being > > notified about system updates daily? > > I poll for updates several times a day using Synaptic, I'd be perfectly happy > to get new updates at each poll. Users in message boards and mailing-lists disagree and consider the Fedora updates madness a poor joke. > If the notifications are annoying, then just poll manually, that way you get > updates only when you're ready for them. :-) Which is what I do for some time, simply because there are too many updates. I've disabled updates-testing, too, after the k3b incident pissed me off. I've been almost successfully persuaded into switching my primary machine to CentOS. From ggw at wolves.durham.nc.us Thu Dec 20 19:16:04 2007 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Thu, 20 Dec 2007 14:16:04 -0500 Subject: rescue.iso images? In-Reply-To: <1198158489.3495.0.camel@localhost.localdomain> References: <9050516b0712200153i5a561bcn58ca9210ddbdbb@mail.gmail.com> <20071220085113.5559cec9@redhat.com> <1198158489.3495.0.camel@localhost.localdomain> Message-ID: <20071220191604.GA3215@wolves.durham.nc.us> On Thu, Dec 20, 2007 at 01:48:09PM +0000, Jonathan Roberts wrote: > > On Thu, 2007-12-20 at 08:51 -0500, Jesse Keating wrote: > > On Thu, 20 Dec 2007 11:53:08 +0200 > > "Gilboa Davara" wrote: > > > > > Please forgive me if it has been asked before, but, when can we expect > > > to see rawhide installation isos and/or vmlinuz+initrd sets? > > > > They're attempted each night ( boot.iso which has the > > vmlinuz+initrd+stage1 stuff ). However due to the nature of rawhide, > > it often fails. However it looks like last night we at least got > > images for i386 and ppc. > > And these get distributed to the mirrors right!? Sorry if that's a > stupid question... > > Jon The only stupid question is one that is not asked. :-) I discovered that my favorite mirror (to remain nameless) has stopped reflecting the images directory for development. for Development/Rawhide I now use a different mirror. -- Wolfe From jspaleta at gmail.com Thu Dec 20 19:19:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 20 Dec 2007 10:19:48 -0900 Subject: Delays in package processing In-Reply-To: <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> On Dec 20, 2007 10:05 AM, Michael Schwendt wrote: > That's easy. The spec %changelog entry already ought to explain why the > update is important. It's the many hundreds small/minor/unimportant > updates which fill the updates repository and drift away from the original > release of the distribution. It leads to a scenario where after firstboot > you are offered so many packages that you're annoyed. The spoken question here is... are we doing releases the 'right' way for our target users? Is our release and updates policy inconsistent? If lots and lots of updates cause annoyance for fresh installed users, should we be making a bigger deal about point people to re-spins as an option? Do we need to find a secondary way to send updates out to people? If re really are producing significant updates churn for non-security updates could we snapshot the updates tree at regular times and offer it as a torrent image for people to download and use as a local media repository? So when you get the gold image, you can also suck down the latest updates snapshot image and apply updates that way instead of over the network after firstboot? Also assuming we can have client side tools which could be told to "update only package updates flagged as security related" on a daily basis from the network, people could grab a snapshot of the updates tree when they want to for anything non-critical. -jef From Jochen at herr-schmitt.de Thu Dec 20 19:35:34 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 20 Dec 2007 20:35:34 +0100 Subject: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting In-Reply-To: <20071220090903.13e3782e@redhat.com> References: <1198090164.4860.3.camel@kennedy> <476A24BD.70906@leemhuis.info> <1198159276.3656.88.camel@beck.corsepiu.local> <20071220090903.13e3782e@redhat.com> Message-ID: <0ML31I-1J5RBJ2NdR-0003Y8@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 20 Dec 2007 09:09:03 -0500, you wrote: >Please don't think that new maintainer containment is a set in stone >proposal. In fact, one of the open questions is who gets added to the >set of folks who gain wide access. I want that group to be as big as >possible, just not inclusive of new packagers. On the propasal you can read something about a karma system to evaluate the new mainteiner from the new maintainers group into the whole access group. Because that means some effort of changes on the FAS to implement this idea, I will suggest a time expiration idea. The new maintainer will added into the new maintainers group after he was approved from his sponsor. After a time periode for example two months a group add request to the whole access group will be generated automaticly on the FAS. Now the sponsor have to approve this new group request for the new maintainer, so he can get into the regular whol access group. On a second step we may implement the discussed karma system. But I see the need for a guildlines about how a newbie can earn the karma he needs to rise into the whole access group. For the groupname I will suggest: cvsnew Group for the new maintainers cvsextras General group for the packagers A second topic should be finding a new name for the cvsextras group, because the name of this group is related on the obsolete Fedora Extras project. My suggust may be cvspckg which stands for Cvs PaCKeGers. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) Charset: us-ascii wj8DBQFHasQQT2AHK6txfgwRAifHAJ0WhbxJaXToF13S7puC2Ygbi1hyigCgtElV LGDcqWUXja/2H+RhNdYPcRI= =JVaa -----END PGP SIGNATURE----- From ml at deadbabylon.de Thu Dec 20 20:13:05 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 20 Dec 2007 21:13:05 +0100 Subject: KDE-SIG weekly report (48/2007) In-Reply-To: References: <200712182349.49371.ml@deadbabylon.de> <200712190022.08231.ml@deadbabylon.de> Message-ID: <200712202113.10204.ml@deadbabylon.de> Am Mi 19.Dezember 2007 schrieb Kevin Kofler: > Sebastian Vahl deadbabylon.de> writes: > > Of course this should be 2008-01-03 :) > > Actually I suggested 2008-01-02 (Wednesday), but 2008-01-03 (Thursday) > would also be possible. I probably won't be available at Wednesday, so I've picked Thursday as the suggestion. Sebastian -------------- 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 tibbs at math.uh.edu Thu Dec 20 20:23:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Dec 2007 14:23:12 -0600 Subject: Merge reviews targeted for F9 Message-ID: FESCo has identified a base set of merge which we'd like to see completed by F9 release. We've generated the list by asking pungi to gather a minimal set of packages consisting of the mandatory members of group @base plus their dependencies and the kernel. This may not constitute a bootable system but it's at least a start. Of the initial set, 63 reviews had not yet been completed. As I type this, a couple of additional have been closed, leaving 61, some of which are currently assigned. The current status and full list are available by viewing the F9MergeReviewTarget tracker bug: ---- https://bugzilla.redhat.com/show_bug.cgi?id=F9MergeReviewTarget ---- Note that doing merge reviews is not much different than doing regular reviews; the main difference is that the packages are already in the distro and can be checked out of CVS. This makes it easy to see the built packages and also to tweak the specfiles and generate patches. Reviewers are encouraged to attach patches to the review tickets to speed up the process; in some cases, the maintainer may ask you simply to commit agreed-upon fixes. So, 61 reviews to go. I'm going to try to do ten by FUDCon; we'll see how far I can get. Anyone care to match me? And who is brave enough to review glibc, gcc or the kernel? - J< From braden at endoframe.com Thu Dec 20 20:53:18 2007 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 20 Dec 2007 15:53:18 -0500 Subject: License change: openvrml Message-ID: <476AD63E.2000706@endoframe.com> With the 0.17.0 release, openvrml's license has changed from LGPLv2+ for the libraries and GPLv2+ for the executables to LGPLv3+ for the libraries an GPLv3+ for the executables. -- Braden McDaniel e-mail: Jabber: From cjdahlin at ncsu.edu Thu Dec 20 21:17:49 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 20 Dec 2007 16:17:49 -0500 Subject: This seems to be getting worse In-Reply-To: References: Message-ID: <476ADBFD.40506@ncsu.edu> Neal Becker wrote: > Warning: don't show this to children > http://fedora.org/ > > It now shows me a 403. Guess I missed the party. From jwboyer at gmail.com Thu Dec 20 22:28:52 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 20 Dec 2007 16:28:52 -0600 Subject: This seems to be getting worse In-Reply-To: <476ADBFD.40506@ncsu.edu> References: <476ADBFD.40506@ncsu.edu> Message-ID: <20071220162852.39a9c478@hansolo.jdub.homelinux.org> On Thu, 20 Dec 2007 16:17:49 -0500 Casey Dahlin wrote: > Neal Becker wrote: > > Warning: don't show this to children > > http://fedora.org/ > > > > > It now shows me a 403. Guess I missed the party. http://jwboyer.fedoraproject.org/Screenshot.png From pertusus at free.fr Thu Dec 20 23:37:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 21 Dec 2007 00:37:44 +0100 Subject: Merge reviews targeted for F9 In-Reply-To: References: Message-ID: <20071220233744.GB4951@free.fr> On Thu, Dec 20, 2007 at 02:23:12PM -0600, Jason L Tibbitts III wrote: > > So, 61 reviews to go. I'm going to try to do ten by FUDCon; we'll see > how far I can get. Anyone care to match me? And who is brave enough > to review glibc, gcc or the kernel? Big packages are clearly in need for reviewers, but many merge review are waiting for packagers to fix things. Having comment not taken into account for months doesn't really give a motivation to do more merge reviews. Of course this FESCo initiative is there to move things forward, but in my experience, reviewers are much more reactive than packagers. Also maybe it is the right time to incitate former core packagers that have too much packages or too much work and cannot really take care of their packages, but cannot be considered MIA either since they are @redhat and are still there, to ask for co-maintainer. -- Pat From kwade at redhat.com Thu Dec 20 23:57:20 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Dec 2007 15:57:20 -0800 Subject: Wiki Migration In-Reply-To: <47637B56.2040905@googlemail.com> References: <4762E5F5.4010206@redhat.com> <47637B56.2040905@googlemail.com> Message-ID: <1198195040.3593.131.camel@erato.phig.org> On Sat, 2007-12-15 at 07:59 +0100, Tim Lauridsen wrote: > A good plan for reorganizing the content is needed. I think Fedora Docs needs to take this on. No, we don't have resources for it. But a better wiki situation would bring more Docs contributors. If you want to help Docs with "owning the spirit of the wiki" (the content), please join us on fedora-docs-list in discussion. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 kwade at redhat.com Fri Dec 21 00:00:23 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Dec 2007 16:00:23 -0800 Subject: Wiki Migration In-Reply-To: <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> Message-ID: <1198195223.3593.135.camel@erato.phig.org> On Sat, 2007-12-15 at 09:23 -0600, King InuYasha wrote: > If we do decide to move to a CMS A CMS solves a different set of problems than a wiki. The core of what makes a CMS useful (workflow and management of content over time, levels of control (ACLs) for certain content) is anathema to what a wiki is (fast changes, many hands involved, rapidly moving content through time.) There is no reason we cannot have both. It is why daMaestro is rolling out Plone for docs.fedoraproject.org. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 Christian.Iseli at licr.org Fri Dec 21 00:13:59 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 21 Dec 2007 01:13:59 +0100 Subject: Fedora Package Status of Dec 21, 2007 Message-ID: <20071221011359.4731ce9f@ludwig-alpha.unil.ch> Hi folks, Here is this month's update (sorry for the slower update rate)... On the bright side, the wiki update went so fast I just sat there blinking for a while... To whoever made the wiki editing fast again: congrats dude(s)! There's a ton of open bug reports. The fact they all seem to have been recently touched is, I hope, a sign something is actually happening to close a bunch. Cheers, Christian ==== Fedora Package Status of Dec 21, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners stats: - 5423 packages - 8962 binary rpms in devel - 90 orphans - 56 packages not available in devel or release ajackson at redhat dot com libwiimote alexl at users dot sourceforge dot net sqlite2 andreas dot bierfert at lowlatency dot de syncekonnector andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ngircd bdpepple at gmail dot com galago-filesystem bdpepple at gmail dot com gaim-galago caolanm at redhat dot com hunspell-he cweyl at alumni dot drew dot edu gaim-gaym davidz at redhat dot com redhat-artwork dbhole at redhat dot com dom2-core-tests debarshi dot ray at gmail dot com starplot-yale5 debarshi dot ray at gmail dot com starplot-gliese3 dennis at ausil dot us silo devrim at commandprompt dot com postgresql-pgpool-ha dlehman at redhat dot com system-config-kdump dlutter at redhat dot com ruby-libvirt dlutter at redhat dot com rubygem-activeresource dwalsh at redhat dot com xguest jafo at tummy dot com python-mechanoid jkeating at redhat dot com tux jmp at safe dot ca clement jorton at redhat dot com libc-client jorton at redhat dot com newt-perl kanarip at kanarip dot com pyjigdo key at linux dot vnet dot ibm dot com tpm-tools konradr at linux dot vnet dot ibm dot com ibmasm kwizart at gmail dot com xorg-x11-drv-ivtv kwizart at gmail dot com ivtv-firmware matthias at rpmforge dot net glusterfs matthias at rpmforge dot net gnome-themes-extras matthias at rpmforge dot net csync2 mmahut at redhat dot com nightfall mmahut at redhat dot com libopensync-plugin-sunbird noah at coderanger dot net rainbow noah at coderanger dot net python-olpcgames oliver at linux-kernel dot at aboot orion at cora dot nwra dot com eclipse-photran overholt at redhat dot com eclipse-nlspackager overholt at redhat dot com eclipse-sdk-nls paul at all-the-johnsons dot co dot uk mysql-connector-net pertusus at free dot fr ivman pknirsch at redhat dot com freeimpi 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 unrar tcallawa at redhat dot com amanith tcallawa at redhat dot com perl-Email-Date-Format tmraz at redhat dot com openssl097a twaugh at redhat dot com desktop-printing vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wtogami at redhat dot com firefox-32 yufanyufan at gmail dot com audacious-plugins-docklet - 2 packages not available in devel but present in release gauret at free dot fr pdftohtml lvm-team at redhat dot com device-mapper - 8 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861,372161,374611 eclipse ben at bagu.org cyrus-imapd tjanouse at redhat.com gnome-themes-extras marc at mwiriadi.id.au pam_mysql i at stingr.net https://bugzilla.redhat.com/buglist.cgi?bug_id=221717,224458,250970,252049 agg caolanm at redhat.com libsilc wtogami at redhat.com ivtv-firmware axel.thimm at atrpms.net asm2 vivekl at redhat.com - 1 packages present in the development repo which have no owners entry s390utils - 4 orphaned packages, yet available in devel cgi-util gkrellm-weather thinkfinger windowlab FE-ACCEPT packages stats: - 3727 accepted, closed package reviews - 48 accepted, closed package reviews not in repo - 16 accepted, closed package reviews not in owners - 63 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 246 open tickets - 30 closed tickets FE-NEW packages stats: - 793 open tickets FE-NEEDSPONSOR packages stats: - 22 open tickets FE-Legal packages stats: - 4 open tickets OPEN-BUGS packages stats: - 9838 open tickets CVS stats: - 5428 packages with a devel directory - 4 packages with no owners entry F-8 glibc32 glibc64 tdma - 273 packages were dropped from Fedora Maintainers stats: - 455 maintainers - 3 inactive maintainers with open bugs - 1 inactive maintainers Dropped Fedora packages: - 95 packages were dropped since Fedora 7 Comps.xml files stats: - 2633 packages in comps-f9 file - 1303 packages missing from comps-f9 file - 16 packages in comps-f9 but not in repo - 2644 packages in comps-f8 file - 1233 packages missing from comps-f8 file - 7 packages in comps-f8 but not in repo From bpepple at fedoraproject.org Fri Dec 21 00:42:00 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 20 Dec 2007 19:42:00 -0500 Subject: FESCo Meeting Summary for 2007-12-20 Message-ID: <1198197720.3072.2.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Jeremy Katz (jeremy) * Kevin Fenzi (nirik) * Tom Callaway (spot) = Absent = * Josh Boyer (jwb) * Christopher Aillon (caillon) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Christian Iseli (c4chris) = Summary = == Automate the mailings of multiarch conflicts == * Discussed automating mailing of multarch conflicts. FESCo agreed that this is a good idea, and needs help from the community on implementing this. For people interested in working on this, please refer to the IRC log for more details. == Compat Packages Policy == * FESCo discussed the compat package policy that jeremy has been working on. bpepple will work on finishing this since jeremy is fairly busy, and having something ready after New Year's. == FUDCon FESCo meeting == * Discussed briefly having a FESCo meeting at FUDCon, and getting voip-support for the FESCo members not going to FUDCon. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2007-12-20.html 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 ngompa13 at gmail.com Fri Dec 21 00:47:08 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Thu, 20 Dec 2007 18:47:08 -0600 Subject: Wiki Migration In-Reply-To: <1198195223.3593.135.camel@erato.phig.org> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <1198195223.3593.135.camel@erato.phig.org> Message-ID: <8278b1b0712201647v5dd4fc25nde6af24ad2b8f19c@mail.gmail.com> I was aware of that, which is why I suggested Enano CMS. It is a hybrid of a wiki and a CMS, implementing literally the best of both worlds. On Dec 20, 2007 6:00 PM, Karsten Wade wrote: > On Sat, 2007-12-15 at 09:23 -0600, King InuYasha wrote: > > If we do decide to move to a CMS > > A CMS solves a different set of problems than a wiki. > > The core of what makes a CMS useful (workflow and management of content > over time, levels of control (ACLs) for certain content) is anathema to > what a wiki is (fast changes, many hands involved, rapidly moving > content through time.) > > There is no reason we cannot have both. It is why daMaestro is rolling > out Plone for docs.fedoraproject.org. > > - Karsten > -- > Karsten Wade, Developer Community Mgr. > Dev Fu : http://developer.redhatmagazine.com > Fedora : http://quaid.fedorapeople.org > gpg key : AD0E0C41 > > -- > 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 jwboyer at gmail.com Fri Dec 21 01:30:47 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 20 Dec 2007 19:30:47 -0600 Subject: This seems to be getting worse In-Reply-To: <20071220162852.39a9c478@hansolo.jdub.homelinux.org> References: <476ADBFD.40506@ncsu.edu> <20071220162852.39a9c478@hansolo.jdub.homelinux.org> Message-ID: <20071220193047.00248377@hansolo.jdub.homelinux.org> On Thu, 20 Dec 2007 16:28:52 -0600 Josh Boyer wrote: > On Thu, 20 Dec 2007 16:17:49 -0500 > Casey Dahlin wrote: > > > Neal Becker wrote: > > > Warning: don't show this to children > > > http://fedora.org/ > > > > > > > > It now shows me a 403. Guess I missed the party. > > http://jwboyer.fedoraproject.org/Screenshot.png Grr. Make that http://jwboyer.fedorapeople.org/Screenshot.png josh From ndbecker2 at gmail.com Fri Dec 21 01:31:27 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Dec 2007 20:31:27 -0500 Subject: Wiki Migration References: <4762E5F5.4010206@redhat.com> Message-ID: Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > Why? From smooge at gmail.com Fri Dec 21 01:55:53 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 20 Dec 2007 18:55:53 -0700 Subject: Wiki Migration In-Reply-To: References: <4762E5F5.4010206@redhat.com> Message-ID: <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> On Dec 20, 2007 6:31 PM, Neal Becker wrote: > Mike McGrath wrote: > > > Ok, I'm just throwing this out there for discussion. > > > > We would like to migrate from Moin to another wiki. > > > Why? > >From reading Max's blog and many other emails 1) there doesn't seem to be someone dedicated to taking care of it. 2) there is a disconnect between the upstream moin people and fixes that have been needed. 3) it can cause major slowdowns and other stuff on the server because too many people have logged that they want changes to this or that or the other.. 4) and then there are the people who want something other than moin because it doesn't do it like fill in your own favorite wiki/program/etc. -- 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 ndbecker2 at gmail.com Fri Dec 21 01:55:55 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Dec 2007 20:55:55 -0500 Subject: Wiki Migration References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <1198195223.3593.135.camel@erato.phig.org> <8278b1b0712201647v5dd4fc25nde6af24ad2b8f19c@mail.gmail.com> Message-ID: King InuYasha wrote: > I was aware of that, which is why I suggested Enano CMS. It is a hybrid of > a wiki and a CMS, implementing literally the best of both worlds. > Requirements: * works with konq I don't know if Enano does. I just tried their demo site, and it manager to crash konq - a pretty rare occurance. From poelstra at redhat.com Fri Dec 21 02:38:16 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 20 Dec 2007 18:38:16 -0800 Subject: Wiki Migration In-Reply-To: <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> Message-ID: <476B2718.7060103@redhat.com> Stephen John Smoogen said the following on 12/20/2007 05:55 PM Pacific Time: > On Dec 20, 2007 6:31 PM, Neal Becker wrote: >> Mike McGrath wrote: >> >>> Ok, I'm just throwing this out there for discussion. >>> >>> We would like to migrate from Moin to another wiki. >>> >> Why? >> > >>From reading Max's blog and many other emails > > 1) there doesn't seem to be someone dedicated to taking care of it. > > 2) there is a disconnect between the upstream moin people and fixes > that have been needed. > > 3) it can cause major slowdowns and other stuff on the server because > too many people have logged that they want changes to this or that or > the other.. > > 4) and then there are the people who want something other than moin > because it doesn't do it like fill in your own favorite > wiki/program/etc. > > > 5) CategoryPage views are broken and generally not advised, though we use them for the feature process and it works most of the time except when it doesn't. 6) It can't handle release day From ndbecker2 at gmail.com Fri Dec 21 02:40:54 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Dec 2007 21:40:54 -0500 Subject: Wiki Migration References: <4762E5F5.4010206@redhat.com> <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> Message-ID: This is an excellent reference: http://www.wikimatrix.org/ One (unique?) advantage about moin is you don't need to deal with a dbms. From smooge at gmail.com Fri Dec 21 02:43:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 20 Dec 2007 19:43:39 -0700 Subject: Wiki Migration In-Reply-To: <476B2718.7060103@redhat.com> References: <4762E5F5.4010206@redhat.com> <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> <476B2718.7060103@redhat.com> Message-ID: <80d7e4090712201843v69181015va409333719e7d4aa@mail.gmail.com> On Dec 20, 2007 7:38 PM, John Poelstra wrote: > 6) It can't handle release day > What can beyond static html pages? This has been a problem with any website from RHL-5.0 onward.. we increase the CPU/Memory of the servers and we always fell back with static webpages for release day (or 12 hours into release day when the website had completely come to a standstill). -- 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 Fri Dec 21 03:00:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Dec 2007 20:00:29 -0700 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198156677.4120.0.camel@scrappy.miketc.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> Message-ID: <1198206029.5513.1.camel@localhost6.localdomain6> On Thu, 2007-12-20 at 07:17 -0600, Mike Chambers wrote: > Does it work OK with java-icedtea-plugin and also flash? On two x86_64s, one running Fedora 7 and the other 8, it runs the flash-plugin quite well (mostly YouTube) and IcedTea java plugin seems to run this applet alright: http://www.java.com/en/download/help/testvm.xml Again, that's on x86_64. -- Richi Plana From kwade at redhat.com Fri Dec 21 03:14:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Dec 2007 19:14:26 -0800 Subject: Wiki Migration In-Reply-To: <8278b1b0712201647v5dd4fc25nde6af24ad2b8f19c@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <5256d0b0712150243k3b24ad4bj44a2417d09a14762@mail.gmail.com> <8278b1b0712150723r2136165el3dada30378a9505b@mail.gmail.com> <1198195223.3593.135.camel@erato.phig.org> <8278b1b0712201647v5dd4fc25nde6af24ad2b8f19c@mail.gmail.com> Message-ID: <1198206866.3593.150.camel@erato.phig.org> On Thu, 2007-12-20 at 18:47 -0600, King InuYasha wrote: > I was aware of that, which is why I suggested Enano CMS. It is a > hybrid of a wiki and a CMS, implementing literally the best of both > worlds. Is it truly a wiki or does it just have a wiki-syntax-like editor capability? A wiki finds its success in being open and easy to edit. It is the easiest method to scratch an itch. This is where our wiki implementation has suffered the most (IMO.) I could see a CMS and a wiki engine integrated, in terms of using the same account system and having a method to move content between the two faces. But once you put that content under management, it is no longer the flexible content of a wiki. - Karsten > On Dec 20, 2007 6:00 PM, Karsten Wade wrote: > On Sat, 2007-12-15 at 09:23 -0600, King InuYasha wrote: > > If we do decide to move to a CMS > > > A CMS solves a different set of problems than a wiki. > > The core of what makes a CMS useful (workflow and management > of content > over time, levels of control (ACLs) for certain content) is > anathema to > what a wiki is (fast changes, many hands involved, rapidly > moving > content through time.) > > There is no reason we cannot have both. It is why daMaestro > is rolling > out Plone for docs.fedoraproject.org. > > > - Karsten > -- > Karsten Wade, Developer Community Mgr. > Dev Fu : http://developer.redhatmagazine.com > Fedora : http://quaid.fedorapeople.org > gpg key : AD0E0C41 > > > -- > 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 -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 shenson at redhat.com Fri Dec 21 03:13:12 2007 From: shenson at redhat.com (Scott Henson) Date: Thu, 20 Dec 2007 23:13:12 -0400 Subject: Wiki Migration In-Reply-To: References: <4762E5F5.4010206@redhat.com> <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> Message-ID: Neal Becker wrote: > This is an excellent reference: > > http://www.wikimatrix.org/ > > One (unique?) advantage about moin is you don't need to deal with a dbms. > Ikiwiki has the same advantage and IMHO does a better job at it. From mmcgrath at redhat.com Fri Dec 21 03:19:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 21:19:32 -0600 Subject: Wiki Migration In-Reply-To: <80d7e4090712201843v69181015va409333719e7d4aa@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> <476B2718.7060103@redhat.com> <80d7e4090712201843v69181015va409333719e7d4aa@mail.gmail.com> Message-ID: <476B30C4.7050201@redhat.com> Stephen John Smoogen wrote: > On Dec 20, 2007 7:38 PM, John Poelstra wrote: > > >> 6) It can't handle release day >> >> > > What can beyond static html pages? This has been a problem with any > website from RHL-5.0 onward.. we increase the CPU/Memory of the > servers and we always fell back with static webpages for release day > (or 12 hours into release day when the website had completely come to > a standstill). > Actually the issue here is Moin's inability to cache properly. We've actually added a psudo mod_headers / mod_cache type deal to get it to cache. This combined with the inability to run Moin in a cluster without something like GFS brings forth scaling issues. Moin is great for smaller deployments but I suspect we have long out-grown it. The wiki did OK this last release, we did some horrible things to it (that caused file corruption that we later had to go back and fix) but all in all the wiki was more available than not according to the logs (less than 1% 503 IIRC) Needless to say a lot of our problems are caused by design problems, not so much technical ones and thats what makes it so hard to stay with Moin. Having said that, moving away isn't very feasible either. We're in a tough spot for sure. -Mike From mmcgrath at redhat.com Fri Dec 21 03:21:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 21:21:07 -0600 Subject: Wiki Migration In-Reply-To: References: <4762E5F5.4010206@redhat.com> <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> Message-ID: <476B3123.8020303@redhat.com> Neal Becker wrote: > This is an excellent reference: > > http://www.wikimatrix.org/ > > One (unique?) advantage about moin is you don't need to deal with a dbms. > This has been one of the biggest disadvantages of Moin actually. As it doesn't have indexes (a db would) it becomes difficult to search and do things like Categories (mentioned later in the thread) also it makes running Moin across multiple servers as we do with almost all of our apps (even in house apps) incredibly difficult. -Mike From kwade at redhat.com Fri Dec 21 03:50:48 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Dec 2007 19:50:48 -0800 Subject: Wiki Migration In-Reply-To: <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> Message-ID: <1198209048.3593.157.camel@erato.phig.org> On Fri, 2007-12-14 at 11:35 -0900, Jeff Spaleta wrote: > If we were going to do it this way, is there any a-priori > restructuring that should be done in terms of wiki page namespace in > an effort to organize the content a bit? Id hate to take the same > pile and just move it into another room so that it still looks like > the same pile of stuff..but in a different room. We can do this regardless of changing anything. Sounds like a fun hackfest session[1] at FUDCon; I'll host. :) Meanwhile, let's discuss information architecture (organization) on f-websites-l, and Docs can work up a quick set of guidelines for: * Page ownership/stewardship to prevent stale content * Info arch * Lightweight 'wiki watching' steps (i.e., the opposite of the monstrous WikiEditing page.) - Karsten [1] http://fedoraproject.org/wiki/DocsProject/WikiGardening -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 Fri Dec 21 04:56:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 20 Dec 2007 22:56:39 -0600 Subject: This seems to be getting worse In-Reply-To: <20071220193047.00248377@hansolo.jdub.homelinux.org> References: <476ADBFD.40506@ncsu.edu> <20071220162852.39a9c478@hansolo.jdub.homelinux.org> <20071220193047.00248377@hansolo.jdub.homelinux.org> Message-ID: <1198212999.3486.28.camel@localhost> On Thu, 2007-12-20 at 19:30 -0600, Josh Boyer wrote: > > > It now shows me a 403. Guess I missed the party. > > > > http://jwboyer.fedoraproject.org/Screenshot.png > > Grr. Make that http://jwboyer.fedorapeople.org/Screenshot.png Those felines aren't even wet! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Dec 21 05:03:46 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 20 Dec 2007 21:03:46 -0800 Subject: Wiki Migration In-Reply-To: <476B2718.7060103@redhat.com> References: <4762E5F5.4010206@redhat.com> <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> <476B2718.7060103@redhat.com> Message-ID: <476B4932.5060900@gmail.com> John Poelstra wrote: > Stephen John Smoogen said the following on 12/20/2007 05:55 PM Pacific > Time: >> On Dec 20, 2007 6:31 PM, Neal Becker wrote: >>> Mike McGrath wrote: >>> >>>> Ok, I'm just throwing this out there for discussion. >>>> >>>> We would like to migrate from Moin to another wiki. >>>> >>> Why? >>> >> >>> From reading Max's blog and many other emails >> >> 1) there doesn't seem to be someone dedicated to taking care of it. >> >> 2) there is a disconnect between the upstream moin people and fixes >> that have been needed. >> >> 3) it can cause major slowdowns and other stuff on the server because >> too many people have logged that they want changes to this or that or >> the other.. >> >> 4) and then there are the people who want something other than moin >> because it doesn't do it like fill in your own favorite >> wiki/program/etc. >> >> >> > > 5) CategoryPage views are broken and generally not advised, though we > use them for the feature process and it works most of the time except > when it doesn't. > This can be worked on, though, using much the same way as the subscriber list/page code. MrBawb (Dan Drown) let us know that he's presented a second draft of our patch for that upstream. If they take that we can work on something similar to address this issue. > 6) It can't handle release day > We're getting closer though. Last release we did pretty well -- although some of what we did was not pretty. If we fixed categories we'd be partway there. Making it so the wiki could be run from multiple servers would go far towards getting us the rest of the way. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bbbush.yuan at gmail.com Fri Dec 21 05:41:45 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 21 Dec 2007 13:41:45 +0800 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> 2007/12/15, Mike McGrath : > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. > > We have yet to find any valid migration scripts that convert users, > histories, etc. > > What would YOU say if we made the current wiki read only, and made the > teams and people migrate important relevant content over to a blank wiki > by hand (copy and paste)? > > I think this would also allow us to trim up the wiki a bit. So the > question I'm asking is if we decided to go this route. How many of you > would hate the Infrastructure group? > Hi, Tell us the decision of Infrastructure team (the choice that you are going to convert to). As a wiki editor I don't expect a easy move but I must understand how that will affect our working flow first. Personally I like moinmoin because its setup is rather easy, and I have become familar with include-style page organization. I want a piece of moinmoin wiki theme that is used on fp.o, where to get that? Thanks! -- bbbush ^_^ From j.w.r.degoede at hhs.nl Fri Dec 21 06:24:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Dec 2007 07:24:25 +0100 Subject: Merge reviews targeted for F9 In-Reply-To: <20071220233744.GB4951@free.fr> References: <20071220233744.GB4951@free.fr> Message-ID: <476B5C19.5000909@hhs.nl> Patrice Dumas wrote: > On Thu, Dec 20, 2007 at 02:23:12PM -0600, Jason L Tibbitts III wrote: >> So, 61 reviews to go. I'm going to try to do ten by FUDCon; we'll see >> how far I can get. Anyone care to match me? And who is brave enough >> to review glibc, gcc or the kernel? > > Big packages are clearly in need for reviewers, but many merge review > are waiting for packagers to fix things. Having comment not taken into > account for months doesn't really give a motivation to do more merge > reviews. Of course this FESCo initiative is there to move things > forward, but in my experience, reviewers are much more reactive than > packagers. > > Also maybe it is the right time to incitate former core packagers that > have too much packages or too much work and cannot really take care of > their packages, but cannot be considered MIA either since they are > @redhat and are still there, to ask for co-maintainer. > Hear hear! I've lately become co-maintainer and even owner of several core packages, in the process closing on average about 5 open bugs per package and guiding those packages through the review process. So any owners of former core packagers who wants a co to help close all those nasty bugs and guide your package through review? For credentials ask Behdad, Phil Knirsch or Ray Strode. Regards, Hans From lordmorgul at gmail.com Fri Dec 21 07:14:48 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 20 Dec 2007 23:14:48 -0800 Subject: This seems to be getting worse In-Reply-To: <1198212999.3486.28.camel@localhost> References: <476ADBFD.40506@ncsu.edu> <20071220162852.39a9c478@hansolo.jdub.homelinux.org> <20071220193047.00248377@hansolo.jdub.homelinux.org> <1198212999.3486.28.camel@localhost> Message-ID: <476B67E8.9020002@gmail.com> Callum Lerwick wrote: > On Thu, 2007-12-20 at 19:30 -0600, Josh Boyer wrote: >>>> It now shows me a 403. Guess I missed the party. >>> http://jwboyer.fedoraproject.org/Screenshot.png >> Grr. Make that http://jwboyer.fedorapeople.org/Screenshot.png > > Those felines aren't even wet! Are felines supposed to be? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From nicu_fedora at nicubunu.ro Fri Dec 21 07:24:17 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 21 Dec 2007 09:24:17 +0200 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> Message-ID: <476B6A21.8060900@nicubunu.ro> Jon Ciesla wrote: > > Unicorn. Link = fictional creatures. Can we have longer names? I like Unicorn, but I think I like better Pink Unicorn (and for a cheap pun, dislike Unbelievable Unicorn) -- 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 mschwendt.tmp0701.nospam at arcor.de Fri Dec 21 08:46:18 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Dec 2007 09:46:18 +0100 Subject: Delays in package processing In-Reply-To: <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> Message-ID: <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Dec 2007 10:19:48 -0900, Jeff Spaleta wrote: > The spoken question here is... are we doing releases the 'right' way > for our target users? > Is our release and updates policy inconsistent? If you asked technical leadership these questions, what would they answer? *I* believe we flood our users with too many rushed/untested updates. It feels more and more like a rolling release which is not too far away from Rawhide. > If lots and lots of updates cause annoyance for fresh installed users, > should we be making a bigger deal about point people to re-spins > as an option? Certainly. Look at the size of the updates repository and also consider the number of packages, which have superseded eachother. Those users, who don't install a fresh Fedora release during the first two weeks, get to see several hundred updates the first time they run an update tool. And after installing so many updates, they see regressions. Plus packages that more often than necessary depend on eachother, because once again a "minor version update" of some library broke ABI compatibility and requires subsequent rebuilds of other packages. From fedora at leemhuis.info Fri Dec 21 09:12:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Dec 2007 10:12:43 +0100 Subject: Delays in package processing In-Reply-To: <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <476B838B.6080402@leemhuis.info> On 21.12.2007 09:46, Michael Schwendt wrote: > On Thu, 20 Dec 2007 10:19:48 -0900, Jeff Spaleta wrote: > [...] > *I* believe we flood our users with too many rushed/untested updates. It > feels more and more like a rolling release which is not too far away from > Rawhide. I think a kind of rolling release is something good -- especially as hardware-support in Linux is not done by separate drivers (like on Windows) and instead often bound to packages (like the linux kernel, sane, or hpijs). Thus is we IMHO want new version of those packages in the repo to support new hardware instead of forcing them to use rawhide or waiting up to six month until the next release. But On the other hand I agree that there are many rushed/untested updates. CU knurd From redhat at olen.net Fri Dec 21 09:26:34 2007 From: redhat at olen.net (Ola Thoresen) Date: Fri, 21 Dec 2007 10:26:34 +0100 Subject: Hardware or software problem with touchpad? Message-ID: <476B86CA.309@olen.net> For the last week or so my mouse pointer has behaved like crazy. This is on a standard Compal "noname" laptop with a touchpad. On my desktop (dell something) with an USB-mouse everyting works fine. Both are running rawhide, updated yesterday. The touchpad works fine for 10-20 seconds, before the cursor starts moving randomly up/down/left/right, clicking everything on its way. It only happens when I actually use the touchpad. So I can use tha laptop with no problem as long as I dont need the mouse. The issue is present with both gpm (console) and X (tested with GNOME and KDE). Before I post a bug (I searched bugzilla, but could not find anything that looked familiar) I thought i'd just check if this is something others might have experienced, or else it might really be a hardware-problem. Rgds. Ola (T) -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From mschwendt.tmp0701.nospam at arcor.de Fri Dec 21 09:53:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Dec 2007 10:53:35 +0100 Subject: Delays in package processing In-Reply-To: <476B838B.6080402@leemhuis.info> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> Message-ID: <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> On Fri, 21 Dec 2007 10:12:43 +0100, Thorsten Leemhuis wrote: > On 21.12.2007 09:46, Michael Schwendt wrote: > > On Thu, 20 Dec 2007 10:19:48 -0900, Jeff Spaleta wrote: > > [...] > > *I* believe we flood our users with too many rushed/untested updates. It > > feels more and more like a rolling release which is not too far away from > > Rawhide. > > I think a kind of rolling release is something good -- especially as > hardware-support in Linux is not done by separate drivers (like on > Windows) and instead often bound to packages (like the linux kernel, > sane, or hpijs). Thus is we IMHO want new version of those packages in > the repo to support new hardware instead of forcing them to use rawhide ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > or waiting up to six month until the next release. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hyperbole. There may be feature additions in updates, provided that they are subject to a reasonable amount of testing. > But On the other hand I agree that there are many rushed/untested updates. All I wish is that we don't throw away the results of the development cycle so carelessly: our choice of what components we add together to build packages, the testing, the freeze. Some packagers complain about bureaucracy, such as having to mail rel-eng when rawhide is frozen and they want a rebuild to be added. As soon as the distribution is released, the flood-gates open and packagers pipe out lots of version upgrades in form of updates which are pushed quickly. And the stream doesn't stop, because next week another "minor" version update is offered, again bearing the risk that it breaks. Then, the only excuse is that Fedora is not suitable in production environments. Do we want to drive away users to other platforms? From andreas.bierfert at lowlatency.de Fri Dec 21 10:01:49 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 21 Dec 2007 11:01:49 +0100 Subject: Attention Rawhide Users: synce upgrade Message-ID: <20071221110149.409e1146@alkaid.a.lan> Hi folks, I am planning over the next couple of days to upgrade all synce components to latest upstream. I don't think any rebuilds will be needed but its good to mention it here anyway. If there are any issues let me know. Best Regards, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caolanm at redhat.com Fri Dec 21 10:10:10 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 21 Dec 2007 10:10:10 +0000 Subject: Delays in package processing In-Reply-To: <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1198231811.5768.228.camel@Jehannum> On Fri, 2007-12-21 at 10:53 +0100, Michael Schwendt wrote: > On Fri, 21 Dec 2007 10:12:43 +0100, Thorsten Leemhuis wrote: > > But On the other hand I agree that there are many rushed/untested updates. > > All I wish is that we don't throw away the results of the development > cycle so carelessly: our choice of what components we add together to > build packages, the testing, the freeze. Yeah, we push *way* too many updates and too casually. In my own view an update should fix a clearly identified common crasher or some other serious problem, but definitely not just because a new version of a package appeared upstream. i.e. consider Fedora 8 as finished, done, dusted and only reluctantly update it due to necessity. Of course one OOo security/crasher update probably equals nearly everything else pushed as updates put together ;-) so I probably shouldn't comment. C. From fedora at leemhuis.info Fri Dec 21 10:17:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Dec 2007 11:17:33 +0100 Subject: Delays in package processing In-Reply-To: <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <476B92BD.2060808@leemhuis.info> On 21.12.2007 10:53, Michael Schwendt wrote: > On Fri, 21 Dec 2007 10:12:43 +0100, Thorsten Leemhuis wrote: >> On 21.12.2007 09:46, Michael Schwendt wrote: >>> On Thu, 20 Dec 2007 10:19:48 -0900, Jeff Spaleta wrote: >>> [...] >>> *I* believe we flood our users with too many rushed/untested updates. It >>> feels more and more like a rolling release which is not too far away from >>> Rawhide. >> I think a kind of rolling release is something good -- especially as >> hardware-support in Linux is not done by separate drivers (like on >> Windows) and instead often bound to packages (like the linux kernel, >> sane, or hpijs). Thus is we IMHO want new version of those packages in >> the repo to support new hardware instead of forcing them to use rawhide > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> or waiting up to six month until the next release. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Hyperbole. There may be feature additions in updates, provided that they > are subject to a reasonable amount of testing. Thx for your kind and friendly words. Sorry, you are barking up the wrong tree. Did I say otherwise? (okay, yes, maybe I drifted away to a "big picture view" a bit and didn't make that explicit ;-) ) Let me put it in different words: I prefer the current Fedora way with a steady pile of updates over what other other popular desktop distributions do where you don't get new drivers for a distribution once they were shipped. >> But On the other hand I agree that there are many rushed/untested updates. > All I wish is that we don't throw away the results of the development > cycle so carelessly: [...] +1 Especially building and shipping a new upstream release in all supported branches at nearly the same time seems totally wrong to me, but is what a lot of people do. Thx do the bodhi and the testing repos at least the releases for the stable branch now get a bit delayed. Cu knurd From pertusus at free.fr Fri Dec 21 10:32:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 21 Dec 2007 11:32:02 +0100 Subject: FESCo Meeting Summary for 2007-12-20 In-Reply-To: <1198197720.3072.2.camel@kennedy> References: <1198197720.3072.2.camel@kennedy> Message-ID: <20071221103202.GA26022@free.fr> On Thu, Dec 20, 2007 at 07:42:00PM -0500, Brian Pepple wrote: > == Automate the mailings of multiarch conflicts == > * Discussed automating mailing of multarch conflicts. FESCo agreed > that this is a good idea, and needs help from the community on > implementing this. For people interested in working on this, > please refer to the IRC log for more details. For the community to be helpful, a lot more of documentation is needed. I am ready to help, after all the script already exists, and mailing the result of the script shouldn't be very hard, but we need plenty of information, like how are mail sent on the computer that does that kind of tasks, how to get users mails, how can we test, where are the scripts, where are the packages, and so on and so forth. Maybe this information is somewhere, but currently I don't know where (I serched on the Infrastructure page, but didn't found anything like that). -- Pat From rc040203 at freenet.de Fri Dec 21 10:39:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Dec 2007 11:39:28 +0100 Subject: Delays in package processing In-Reply-To: <1198231811.5768.228.camel@Jehannum> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <1198231811.5768.228.camel@Jehannum> Message-ID: <1198233568.3656.307.camel@beck.corsepiu.local> On Fri, 2007-12-21 at 10:10 +0000, Caolan McNamara wrote: > On Fri, 2007-12-21 at 10:53 +0100, Michael Schwendt wrote: > > On Fri, 21 Dec 2007 10:12:43 +0100, Thorsten Leemhuis wrote: > > > But On the other hand I agree that there are many rushed/untested updates. > > > > All I wish is that we don't throw away the results of the development > > cycle so carelessly: our choice of what components we add together to > > build packages, the testing, the freeze. > > Yeah, we push *way* too many updates and too casually. Ask youself which and why? You will probably notice that in a standard installation most "really used" updates are related to kernel, OOo, evolution, firefox. The amount of updates these are seeing are outweighing many 100s of other package updates. And the package seeing the highest upgrade frequency and having the severest impact on everyday use without any doubt is everything related to SELinux. > Of course one OOo security/crasher update probably equals nearly > everything else pushed as updates put together ;-) Exactly. A couple of packages' "security updates" outweigh the rest. That's one reason for me saying trying to reduce the amount of updates is a waste of time and would lean to do being more aggressive on updates. I would expect this to lead to more stability and to _less_ updates in longer terms, because packages will see a wider exposure. Ralf From rc040203 at freenet.de Fri Dec 21 11:20:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Dec 2007 12:20:33 +0100 Subject: Delays in package processing In-Reply-To: <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> Message-ID: <1198236033.3656.329.camel@beck.corsepiu.local> On Thu, 2007-12-20 at 10:19 -0900, Jeff Spaleta wrote: > On Dec 20, 2007 10:05 AM, Michael Schwendt > wrote: > > That's easy. The spec %changelog entry already ought to explain why the > > update is important. It's the many hundreds small/minor/unimportant > > updates which fill the updates repository and drift away from the original > > release of the distribution. It leads to a scenario where after firstboot > > you are offered so many packages that you're annoyed. > > The spoken question here is... are we doing releases the 'right' way > for our target users? Which target user audience? As far as I am concerned (power user, developer): No, Fedora doesn't. > Is our release and updates policy inconsistent? Yes. I feel Fedora is applying rel-eng strategies which do not fit into a "forward looking" distro aiming at early adoption of "leading edge technology". IMO, it's natural for a leading edge/early technology adopter distro to see frequent updates. But also note that "leading edge" shouldn't mean "instable" or "premature". Unfortunately I also feel this is what some people (esp. some people at RH) seem to be wanting to treat Fedora as. > If lots and lots of updates cause annoyance for fresh installed users, > should we be making a bigger deal about point people to re-spins > as an option? Yes. I think, there should be regular respins of the disk-images. Just consider the current situation: The FC8 *.isos already have become obsolete and are not really worth downloading anymore. More generally speaking, /me thinks the concept of "gold image" has reached its technical limits and won't lead much further. A bit far fetching, I think, Fedora needs bootimages supporting networked installs directly from Everything/ and some means to cut isos to for local reuse after installation. > Also assuming we can have client > side tools which could be told to "update only package updates flagged > as security related" on a daily basis from the network, people could > grab a snapshot of the updates tree when they want to for anything > non-critical. No, it don't think this is useful. To low-bandwith users it's not the number of packages, which are causing problems, it's the mass (Which happen to originate from a handful of packages which normally are marked security update) and from unreliability of the technology underneath (such as mirrors out of sync, broken metadata, yum issues). Ralf From pbrobinson at gmail.com Fri Dec 21 11:29:48 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 21 Dec 2007 11:29:48 +0000 Subject: rawhide report: 20071220 changes In-Reply-To: <1198163538.7053.3.camel@nixon> References: <200712201217.lBKCHag6009411@porkchop.devel.redhat.com> <5256d0b0712200553g788db9f7o361f65d3c0388cfd@mail.gmail.com> <1198163538.7053.3.camel@nixon> Message-ID: <5256d0b0712210329l467ee859h9be67b8edd15f420@mail.gmail.com> On Dec 20, 2007 3:12 PM, Brian Pepple wrote: > > On Thu, 2007-12-20 at 13:53 +0000, Peter Robinson wrote: > > > swfdec-0.5.5-2.fc9 > > > ------------------ > > > * Wed Dec 19 2007 Brian Pepple - 0.5.5-2 > > > - Build w/ pulse audio support. > > > > > > > Probably not a whole lot of point enabling the PulseAudio support yet > > as it doesn't yet work. See this post from a couple of days ago, not > > that audio worked when it was compiled with alsa. > > > > https://www.redhat.com/archives/fedora-test-list/2007-December/msg00399.html > > Um, I was the one that wrote that message, so I obviously was aware of > it. I spent some time working with upstream yesterday, and was able to > get the pa support to work in Rawhide. Ah OK, I'll have another look and see how I go. Should it work with PA on Fedora8? I haven't had much luck with it up to now (either from rawhide packages or compiling it myself with either alsa or PA options compiled in). I can download the FLV separately or specify the URL and play it straight form totem with sound (not sure if swfdec uses gst or something else) but through the gnome player or the plugin it plays fine minus sounds. Peter From kevin.kofler at chello.at Fri Dec 21 11:41:54 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 21 Dec 2007 11:41:54 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > *I* believe we flood our users with too many rushed/untested updates. It > feels more and more like a rolling release A rolling release isn't necessarily a bad thing. The problem is not new software, it's unreliable software. Getting new stable software (such as upstream bugfix releases) in is a good thing. With Fedora, you get bugfixes and sometimes even new features very quickly, with a distribution doing security updates only (e.g. Debian stable) or almost (e.g. RHEL/CentOS), you often have to wait for months if not years to get a fix for your bug. Regressions are usually less of a problem than unfixed bugs: if there's a regression, I can rollback to the last working version, if there's an unfixed bug, there's nothing to upgrade or downgrade to. > which is not too far away from Rawhide. I separated out that part of the sentence because I disagree with the logic here. Are you seeing a major X.Org X11 upgrade with some regressions in F7/F8 updates? KDE 4 RCs? A rewritten GDM? Yet all this stuff is in Rawhide. Maintainers _know_ what kind of upgrades are not stable enough and/or change too much to push as updates to stable releases. So, sure, the updates are "rolling", but they're a lot more reliable than Rawhide. The main reason I like Fedora is because the releases are stable, yet up to date. I think we're doing a good job of separating the risky updates (-> Rawhide only) from the bugfix and/or riskless enhancement ones (-> updates). > Certainly. Look at the size of the updates repository and also consider > the number of packages, which have superseded eachother. Those users, who > don't install a fresh Fedora release during the first two weeks, get to > see several hundred updates the first time they run an update tool. That's a feature. > And after installing so many updates, they see regressions. Our problem here is that updates-testing doesn't get enough actual testing, not the updates per se. And I think the occasional regression, while annoying, is not as bad as sitting on hundreds of bugs and leaving users with an unusable system for months. > Plus packages that more often than necessary depend on eachother, because > once again a "minor version update" of some library broke ABI compatibility > and requires subsequent rebuilds of other packages. IMHO that's a non-issue. Kevin Kofler From kevin.kofler at chello.at Fri Dec 21 11:51:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 21 Dec 2007 11:51:03 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > Especially building and shipping a new upstream release in all supported > branches at nearly the same time seems totally wrong to me, but is what > a lot of people do. Thx do the bodhi and the testing repos at least the > releases for the stable branch now get a bit delayed. Sure, pushing straight to stable is not so great an idea in most cases, but I think pushing to testing at the same time we're pushing to Rawhide (or almost) is usually not bad timing (assuming the update is appropriate for the release in the first place). Testing is there to test things. Some big changes happen in Rawhide first and are then backported to stable releases if they're important enough, but for minor version updates to upstream bugfix releases, I don't see why they shouldn't hit testing at the same time as Rawhide. That's what I dislike about the way Debian handles unstable->testing transitions: the age of an update, by itself, is a very bad metric for its reliability. Big changes need more testing than trivial bugfixes. Holding packages for an arbitrary amount of time for no other reason than that said time has not elapsed yet only delays updates for no good reason. So please let's not get there. I think the current system where the maintainer decides when to push what where is really the best solution. Kevin Kofler From mike at miketc.com Fri Dec 21 13:28:29 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 21 Dec 2007 07:28:29 -0600 Subject: Adding Proview monitor Message-ID: <1198243709.5012.5.camel@scrappy.miketc.com> Karsten Hopp, I've reopened this bug due to the monitor still not appearing, neither in F8 nor rawhide packages. Just doing a *poke* so it's aware (and that am getting this for Christmas, so will need the driver in 4 days? hehe). -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From mike at miketc.com Fri Dec 21 13:35:30 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 21 Dec 2007 07:35:30 -0600 Subject: Adding Proview monitor In-Reply-To: <1198243709.5012.5.camel@scrappy.miketc.com> References: <1198243709.5012.5.camel@scrappy.miketc.com> Message-ID: <1198244130.2214.0.camel@scrappy.miketc.com> On Fri, 2007-12-21 at 07:28 -0600, Mike Chambers wrote: > Karsten Hopp, > > I've reopened this bug due to the monitor still not appearing, neither > in F8 nor rawhide packages. > > Just doing a *poke* so it's aware (and that am getting this for > Christmas, so will need the driver in 4 days? hehe). Sorry, forgot to add the bug #, doh! https://bugzilla.redhat.com/show_bug.cgi?id=363091 -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From jkeating at redhat.com Fri Dec 21 13:47:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 08:47:56 -0500 Subject: Delays in package processing In-Reply-To: <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071221084756.0dcc4e4c@redhat.com> On Fri, 21 Dec 2007 09:46:18 +0100 Michael Schwendt wrote: > *I* believe we flood our users with too many rushed/untested updates. > It feels more and more like a rolling release which is not too far > away from Rawhide. I tend to agree. Then again, I'm in the position of doing all the pushes so I have a unique view upon it. But it feels to me that packagers are all too eager to just release anything and everything across the releases, without regard to a 'stable 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 mschwendt.tmp0701.nospam at arcor.de Fri Dec 21 13:48:13 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Dec 2007 14:48:13 +0100 Subject: Delays in package processing In-Reply-To: <476B92BD.2060808@leemhuis.info> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> Message-ID: <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> On Fri, 21 Dec 2007 11:17:33 +0100, Thorsten Leemhuis wrote: > >>> [...] > >>> *I* believe we flood our users with too many rushed/untested updates. It > >>> feels more and more like a rolling release which is not too far away from > >>> Rawhide. > >> I think a kind of rolling release is something good -- especially as > >> hardware-support in Linux is not done by separate drivers (like on > >> Windows) and instead often bound to packages (like the linux kernel, > >> sane, or hpijs). Thus is we IMHO want new version of those packages in > >> the repo to support new hardware instead of forcing them to use rawhide > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> or waiting up to six month until the next release. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Hyperbole. There may be feature additions in updates, provided that they > > are subject to a reasonable amount of testing. > > Thx for your kind and friendly words. Where do you see unkind or unfriendly words? "Hyperbole" is just another word for "exaggeration", and above you did exactly that. You exaggerated by a clear margin. Actually, all those people who can't install F8 from media due to various problems (with unsupported hardware, undetected drives, kernel problems e.g.) are sort of forced to wait for the next release, which is after ~6 months. Unless there's a respin which incorporates anaconda/kernel/... updates that fixes the people's problems. And not many are courageous enough to try rawhide. > Sorry, you are barking up the wrong tree. No, I'm not. It's the same procedure as usual. I point out my concerns, and I'm not the only one who does that. Fedora, IMO, is becoming less attractive due to an overwhelming number of updates. Every update that doesn't just fix specific bugs (as in good old Red Hat Errata) bears the risk of breaking because of new bugs or incompatible changes. Recently, I've been hit by several bugs after applying updates without that I've done anything to the system myself. Something damaged my gnome panels, sound stopped working, gnome mixer caused trouble, the rushed k3b update broke dvd backups, occasionally the desktop stopped working until I pressed Alt+Tab, liferea became unreliable. Just some examples. Reason enough to reinstall. I don't want to make it more difficult for packagers to publish updates -- quality updates, well-tested packages which include accumulated bug-fixes. But, please, don't engage in those mad upgrade races with upstream projects and move away from the gold release of the distribution just to ship new stuff. It's like a never-ending loop in the development/testing cycle. An unstoppable stream of new packages which you need to evaluate and test against the packages which you use and build your own packages with. From jkeating at redhat.com Fri Dec 21 14:01:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 09:01:35 -0500 Subject: Delays in package processing In-Reply-To: <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071221090135.1ce95af7@redhat.com> On Fri, 21 Dec 2007 14:48:13 +0100 Michael Schwendt wrote: > I don't want to make it more difficult for packagers to publish > updates -- quality updates, well-tested packages which include > accumulated bug-fixes. But, please, don't engage in those mad upgrade > races with upstream projects and move away from the gold release of > the distribution just to ship new stuff. It's like a never-ending > loop in the development/testing cycle. An unstoppable stream of new > packages which you need to evaluate and test against the packages > which you use and build your own packages with. I agree with this a lot. We put a lot of effort into making a release work well, and we often get rave reviews for the release in the first few weeks. We also put a ton of effort into documentation and such. However after the first few weeks or the first month, the massive pile of not just bugfix updates, but new versions, major release changes, etc.. make what you install and then update look nothing like that initial release. Suddenly our documentation is no longer correct, our stability is gone, our great integration is gone, and we start to look like a very sloppy distribution once again, or rawhide. We have stable releases for a reason, so that they can remain stable for the (short) period of time they are active. We have a development stream for the purposes of developing new releases and preparing for that next stable release. I had hoped that common sense would prevail across our maintainers and that stable releases would be treated as such, stable releases not to be cheapened with lots of unnecessary updates just so that "users can get the latest stuff!". Unfortunately that doesn't seem to be what's happening. I don't want to introduce draconian policies and procedures to enforce this, mostly because there just isn't enough time in the day to supervise all the potential updates for whether they should go out or not. So I ask you, Fedora Community, how do we as a community ensure that our stable releases stay just that, stable? -- 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 Dec 21 13:59:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 07:59:49 -0600 Subject: Wiki Migration In-Reply-To: <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> Message-ID: <476BC6D5.4070802@redhat.com> Yuan Yijun wrote: > 2007/12/15, Mike McGrath : > > Hi, > > Tell us the decision of Infrastructure team (the choice that you are > going to convert to). As a wiki editor I don't expect a easy move but > I must understand how that will affect our working flow first. > Personally I like moinmoin because its setup is rather easy, and I > have become familar with include-style page organization. > > We've not made any actual decisions on what to do, we were just wanting to see what the others would say, pretty much all options are still on the table. > I want a piece of moinmoin wiki theme that is used on fp.o, where to get that? > http://cvs.fedoraproject.org/viewcvs/web/wiki/kindofblue/?root=fedora -Mike From rc040203 at freenet.de Fri Dec 21 14:17:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Dec 2007 15:17:18 +0100 Subject: Delays in package processing In-Reply-To: <20071221084756.0dcc4e4c@redhat.com> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> Message-ID: <1198246638.3656.355.camel@beck.corsepiu.local> On Fri, 2007-12-21 at 08:47 -0500, Jesse Keating wrote: > On Fri, 21 Dec 2007 09:46:18 +0100 > Michael Schwendt wrote: > > > *I* believe we flood our users with too many rushed/untested > updates. It feels more and more like a rolling release This would be great. > > which is not too far away from Rawhide. Well, I have to agree, to that extend that I feel FC8 "gold" had been in a shape which left much to be desired, better should not have been released and now is gradually maturing. > I tend to agree. Then again, I'm in the position of doing all the > pushes so I have a unique view upon it. But it feels to me that > packagers are all too eager to just release anything and everything > across the releases, without regard to a 'stable release'. It won't surprise you that I can't avoid to disagree vehemently. What you call "eager" in many cases is "bug-fixing across distros". Ralf From jkeating at redhat.com Fri Dec 21 14:30:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 09:30:18 -0500 Subject: Delays in package processing In-Reply-To: <1198246638.3656.355.camel@beck.corsepiu.local> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> Message-ID: <20071221093018.1fa832b9@redhat.com> On Fri, 21 Dec 2007 15:17:18 +0100 Ralf Corsepius wrote: > > I tend to agree. Then again, I'm in the position of doing all the > > pushes so I have a unique view upon it. But it feels to me that > > packagers are all too eager to just release anything and everything > > across the releases, without regard to a 'stable release'. > It won't surprise you that I can't avoid to disagree vehemently. What > you call "eager" in many cases is "bug-fixing across distros". Ralf, please don't confuse these things. I'm perfectly fine and encourage bugfixing across releases. What I'm discouraging is version upgrades for new features or spurious builds for spec fixes and other unnecessary things that are done across the releases trees, not just on rawhide. These are the things that I don't like to see, and these are the things that lessen the value of a 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 marc at mwiriadi.id.au Fri Dec 21 14:44:00 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Fri, 21 Dec 2007 23:44:00 +0900 Subject: Wiki Migration In-Reply-To: <476BC6D5.4070802@redhat.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> Message-ID: <1198248240.7443.31.camel@study.mwiriadi.id.au> On Fri, 2007-12-21 at 07:59 -0600, Mike McGrath wrote: > Yuan Yijun wrote: > > 2007/12/15, Mike McGrath : > > > > Hi, > > > > Tell us the decision of Infrastructure team (the choice that you are > > going to convert to). As a wiki editor I don't expect a easy move but > > I must understand how that will affect our working flow first. > > Personally I like moinmoin because its setup is rather easy, and I > > have become familar with include-style page organization. > > > > > > We've not made any actual decisions on what to do, we were just wanting > to see what the others would say, pretty much all options are still on > the table. > > > I want a piece of moinmoin wiki theme that is used on fp.o, where to get that? > > > > http://cvs.fedoraproject.org/viewcvs/web/wiki/kindofblue/?root=fedora > > -Mike > As discussed on IRC my vote is anything that has a CMS built into it. I personally feel a lot of things are done behind closed doors and really feeding the hungry public with information of whats coming up and things that have occurred is nothing but a bonus. I've been advised that plone does this as do other CMS/Wiki's out there. There are Java based one's out there already I'm not to sure how they fit into the scheme of things but information to help the marketing, ambassadors and other contributors to Fedora would be helpful. Cheers, Marc From valent.turkovic at gmail.com Fri Dec 21 14:48:33 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 21 Dec 2007 15:48:33 +0100 Subject: Fedora 8 review Message-ID: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> Hi, I listened to Linux Action Show and I really liked their review of Fedora 8. I believe that this is something Fedora users but also Fedora devels should listen. They give Fedora 8 a really hard but IMHO realistic review, so please listen to it. You can hear the clip with the review part of the podcast here: http://kernelreloaded.blog385.com/index.php/archives/fedora-8-audio-review/ http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review.ogg http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review_64kb.mp3 or you can listen the whole podcast here: http://www.linuxactionshow.com/?p=158 (Ogg version) http://www.linuxactionshow.com/?p=157 (MP3 version) Valent. -- 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 j.w.r.degoede at hhs.nl Fri Dec 21 14:49:12 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Dec 2007 15:49:12 +0100 Subject: Fedora 8 review In-Reply-To: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> Message-ID: <476BD268.1050009@hhs.nl> Valent Turkovic wrote: > Hi, I listened to Linux Action Show and I really liked their review of > Fedora 8. I believe that this is something Fedora users but also > Fedora devels should listen. > > They give Fedora 8 a really hard but IMHO realistic review, so please > listen to it. > > You can hear the clip with the review part of the podcast here: > http://kernelreloaded.blog385.com/index.php/archives/fedora-8-audio-review/ > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review.ogg > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review_64kb.mp3 > > or you can listen the whole podcast here: > http://www.linuxactionshow.com/?p=158 (Ogg version) > http://www.linuxactionshow.com/?p=157 (MP3 version) > > Valent. Any chance you can write up a good summary? Esp a list of points which they say need improvement, and you agree with, and which we are actually capable of improving (iow not support mp3 please, etc.). regards, Hans From mmcgrath at redhat.com Fri Dec 21 14:49:48 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 08:49:48 -0600 Subject: Wiki Migration In-Reply-To: <1198248240.7443.31.camel@study.mwiriadi.id.au> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> Message-ID: <476BD28C.8040804@redhat.com> Marc Wiriadisastra wrote: > On Fri, 2007-12-21 at 07:59 -0600, Mike McGrath wrote: > >> Yuan Yijun wrote: >> >>> 2007/12/15, Mike McGrath : >>> >>> Hi, >>> >>> Tell us the decision of Infrastructure team (the choice that you are >>> going to convert to). As a wiki editor I don't expect a easy move but >>> I must understand how that will affect our working flow first. >>> Personally I like moinmoin because its setup is rather easy, and I >>> have become familar with include-style page organization. >>> >>> >>> >> We've not made any actual decisions on what to do, we were just wanting >> to see what the others would say, pretty much all options are still on >> the table. >> >> >>> I want a piece of moinmoin wiki theme that is used on fp.o, where to get that? >>> >>> >> http://cvs.fedoraproject.org/viewcvs/web/wiki/kindofblue/?root=fedora >> >> -Mike >> >> > > As discussed on IRC my vote is anything that has a CMS built into it. > > I personally feel a lot of things are done behind closed doors and > really feeding the hungry public with information of whats coming up and > things that have occurred is nothing but a bonus. > This is completely false. On the websites (content) side: http://fedoraproject.org/wiki/Websites/ShowUs There's also the websites list, the docs list, #fedora-websites and #fedora-docs. If you're interested in the hosting side of things you'll want to talk to the Infrastructure team. We have weekly meetings, there's the #fedora-admin channel and the fedora-infrastructure-list. If you think we should replace the wiki with the CMS feel free to state your case on that list and we'll discuss but I think you'll find that for most content that would require a CMS the docs team handles that (and they're currently moving towards a CMS). If you think you can organize the wiki with a CMS and that its the best way to go, lets see the proposal. > I've been advised that plone does this as do other CMS/Wiki's out there. > There are Java based one's out there already I'm not to sure how they > fit into the scheme of things but information to help the marketing, > ambassadors and other contributors to Fedora would be helpful. We've been trying to get plone up and running for not 1, not 2 but going on 3 years now when February hits. We even have a big Plone advocate working on it with the docs team and yet its still not here. I'm not saying anything bad about the technology but I'm a pretty results oriented guy and the proof is in the pudding. Plone is a resource / attention needy application. I hope the docs guys get a good product out of it but in general I'd like to see Fedora's commitment to Plone stop there until such a time comes that it can play well with the language it was written in (just my 2 cents). -Mike From rc040203 at freenet.de Fri Dec 21 14:59:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Dec 2007 15:59:58 +0100 Subject: Delays in package processing In-Reply-To: <20071221093018.1fa832b9@redhat.com> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> Message-ID: <1198249198.3656.399.camel@beck.corsepiu.local> On Fri, 2007-12-21 at 09:30 -0500, Jesse Keating wrote: > On Fri, 21 Dec 2007 15:17:18 +0100 > Ralf Corsepius wrote: > > > > I tend to agree. Then again, I'm in the position of doing all the > > > pushes so I have a unique view upon it. But it feels to me that > > > packagers are all too eager to just release anything and everything > > > across the releases, without regard to a 'stable release'. > > It won't surprise you that I can't avoid to disagree vehemently. What > > you call "eager" in many cases is "bug-fixing across distros". > > > Ralf, please don't confuse these things. Rest assured, I don't confuse them - I feel you to be wanting to outlaw updating packages in released distros in general. > I'm perfectly fine and > encourage bugfixing across releases. What I'm discouraging is version > upgrades for new features or spurious builds for spec fixes and other > unnecessary things that are done across the releases trees, not just on > rawhide. Of cause such things are happening, I don't deny them, but ... how can you be sure these updates won't fix something you're not aware about? When I have look at the embarrassing shape some packages are in (eg. SELinux, evolution just to name a few), I can only conclude Fedora doesn't see enough updates (Fortunately some devs seem to have learned their lessons. Chapeau to mebrown who as I feel is doing a terrific job on getting mock on FC8 in a stable shape). > These are the things that I don't like to see, and these are > the things that lessen the value of a release. The problem is: Except of trivial cases, they are very hard to recognize to somebody who is not deeply familiar with a package. My current favorite example: Why has doxygen not yet been upgraded on Fedora 8? Shipping it for Fedora 8 doesn't directly fix anything in FC8 itself, except that it helps avoiding yum getting confused on some-multilib related issues for packages which will be rebuilt during FC8's life time, but ... The real benefit would happen outside of Fedora. Ralf From jkeating at redhat.com Fri Dec 21 15:10:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 10:10:09 -0500 Subject: Delays in package processing In-Reply-To: <1198249198.3656.399.camel@beck.corsepiu.local> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> <1198249198.3656.399.camel@beck.corsepiu.local> Message-ID: <20071221101009.2309d266@redhat.com> On Fri, 21 Dec 2007 15:59:58 +0100 Ralf Corsepius wrote: > > Ralf, please don't confuse these things. > Rest assured, I don't confuse them - I feel you to be wanting to > outlaw updating packages in released distros in general. Nope not at all. I just want those updates to count for something. > > > I'm perfectly fine and > > encourage bugfixing across releases. What I'm discouraging is > > version upgrades for new features or spurious builds for spec fixes > > and other unnecessary things that are done across the releases > > trees, not just on rawhide. > Of cause such things are happening, I don't deny them, but ... how can > you be sure these updates won't fix something you're not aware about? > > When I have look at the embarrassing shape some packages are in (eg. > SELinux, evolution just to name a few), I can only conclude Fedora > doesn't see enough updates (Fortunately some devs seem to have learned > their lessons. Chapeau to mebrown who as I feel is doing a terrific > job on getting mock on FC8 in a stable shape). > > > These are the things that I don't like to see, and these are > > the things that lessen the value of a release. > The problem is: Except of trivial cases, they are very hard to > recognize to somebody who is not deeply familiar with a package. I don't disagree that this is the person best to make the decision. What I'm asking for is ideas or thoughts on how to educate these folks on what the Project would like to see out of updates, so that they have some yardstick to measure their knowledge against to see if the update should really go out or not. > > My current favorite example: Why has doxygen not yet been upgraded on > Fedora 8? Shipping it for Fedora 8 doesn't directly fix anything in > FC8 itself, except that it helps avoiding yum getting confused on > some-multilib related issues for packages which will be rebuilt during > FC8's life time, but ... > > The real benefit would happen outside of 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 ivazqueznet at gmail.com Fri Dec 21 15:16:28 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 21 Dec 2007 10:16:28 -0500 Subject: Fedora 8 review In-Reply-To: <476BD268.1050009@hhs.nl> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> Message-ID: <1198250188.1765.6.camel@ignacio.lan> On Fri, 2007-12-21 at 15:49 +0100, Hans de Goede wrote: > Valent Turkovic wrote: > > Hi, I listened to Linux Action Show and I really liked their review of > > Fedora 8. I believe that this is something Fedora users but also > > Fedora devels should listen. > > Any chance you can write up a good summary? Esp a list of points which > they say need improvement, and you agree with, and which we are actually > capable of improving (iow not support mp3 please, etc.). https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00269.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 marc at mwiriadi.id.au Fri Dec 21 15:51:08 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sat, 22 Dec 2007 00:51:08 +0900 Subject: Wiki Migration In-Reply-To: <476BD28C.8040804@redhat.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> Message-ID: <1198252268.7443.46.camel@study.mwiriadi.id.au> > >> > > > > As discussed on IRC my vote is anything that has a CMS built into it. > > > > I personally feel a lot of things are done behind closed doors and > > really feeding the hungry public with information of whats coming up and > > things that have occurred is nothing but a bonus. > > > This is completely false. On the websites (content) side: > > http://fedoraproject.org/wiki/Websites/ShowUs There's also the websites > list, the docs list, #fedora-websites and #fedora-docs. > > If you're interested in the hosting side of things you'll want to talk > to the Infrastructure team. We have weekly meetings, there's the > #fedora-admin channel and the fedora-infrastructure-list. If you think > we should replace the wiki with the CMS feel free to state your case on > that list and we'll discuss but I think you'll find that for most > content that would require a CMS the docs team handles that (and they're > currently moving towards a CMS). If you think you can organize the wiki > with a CMS and that its the best way to go, lets see the proposal. > > I've been advised that plone does this as do other CMS/Wiki's out there. > > There are Java based one's out there already I'm not to sure how they > > fit into the scheme of things but information to help the marketing, > > ambassadors and other contributors to Fedora would be helpful. > > We've been trying to get plone up and running for not 1, not 2 but going > on 3 years now when February hits. We even have a big Plone advocate > working on it with the docs team and yet its still not here. I'm not > saying anything bad about the technology but I'm a pretty results > oriented guy and the proof is in the pudding. Plone is a resource / > attention needy application. I hope the docs guys get a good product > out of it but in general I'd like to see Fedora's commitment to Plone > stop there until such a time comes that it can play well with the > language it was written in (just my 2 cents). > > -Mike > While I understand that it isn't just one website I would like to think that there is sufficient technology around that an integrated wiki/cms type solution is out there for the sake of ease. While my suggestion of Plone is based on the small amount of information I have. I personally have not used it so my information is based on other people's opinions. My opinion is based on http://www.gentoo.org/ where they have links to associated sections. News is on the front page mainly the Newsletter but at least its a form of letting people know what is going on. I'm just hoping that there is a streamlined method out there. Developer puts a feature page in the wiki it gets approved it gets shifted to a news item that says we are trying to get x thing implemented by Fedora x. In my opinion it builds people's views of what to hope to expect. It's also an acknowledgment of work done behind the scenes when news is reported. A new yum version that is linked to feature x. Cheers, Marc From mmcgrath at redhat.com Fri Dec 21 15:49:08 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 09:49:08 -0600 Subject: Wiki Migration In-Reply-To: <1198252268.7443.46.camel@study.mwiriadi.id.au> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> Message-ID: <476BE074.4020703@redhat.com> Marc Wiriadisastra wrote: > > >>>> >>>> >>> As discussed on IRC my vote is anything that has a CMS built into it. >>> >>> I personally feel a lot of things are done behind closed doors and >>> really feeding the hungry public with information of whats coming up and >>> things that have occurred is nothing but a bonus. >>> >>> >> This is completely false. On the websites (content) side: >> >> http://fedoraproject.org/wiki/Websites/ShowUs There's also the websites >> list, the docs list, #fedora-websites and #fedora-docs. >> >> If you're interested in the hosting side of things you'll want to talk >> to the Infrastructure team. We have weekly meetings, there's the >> #fedora-admin channel and the fedora-infrastructure-list. If you think >> we should replace the wiki with the CMS feel free to state your case on >> that list and we'll discuss but I think you'll find that for most >> content that would require a CMS the docs team handles that (and they're >> currently moving towards a CMS). If you think you can organize the wiki >> with a CMS and that its the best way to go, lets see the proposal. >> >>> I've been advised that plone does this as do other CMS/Wiki's out there. >>> There are Java based one's out there already I'm not to sure how they >>> fit into the scheme of things but information to help the marketing, >>> ambassadors and other contributors to Fedora would be helpful. >>> >> We've been trying to get plone up and running for not 1, not 2 but going >> on 3 years now when February hits. We even have a big Plone advocate >> working on it with the docs team and yet its still not here. I'm not >> saying anything bad about the technology but I'm a pretty results >> oriented guy and the proof is in the pudding. Plone is a resource / >> attention needy application. I hope the docs guys get a good product >> out of it but in general I'd like to see Fedora's commitment to Plone >> stop there until such a time comes that it can play well with the >> language it was written in (just my 2 cents). >> >> -Mike >> >> > > While I understand that it isn't just one website I would like to think > that there is sufficient technology around that an integrated wiki/cms > type solution is out there for the sake of ease. > > While my suggestion of Plone is based on the small amount of information > I have. I personally have not used it so my information is based on > other people's opinions. > > My opinion is based on http://www.gentoo.org/ where they have links to > associated sections. News is on the front page mainly the Newsletter but > at least its a form of letting people know what is going on. > We have a rotating banner with Fedora Weekly News as well as a current open ticket: https://fedorahosted.org/fedora-infrastructure/ticket/178 for a news site. Just needs worker bees. > I'm just hoping that there is a streamlined method out there. Developer > puts a feature page in the wiki it gets approved it gets shifted to a > news item that says we are trying to get x thing implemented by Fedora > x. > Adding process is typically just the opposite of streamline. Anyone can go and alter the wiki right now (and are encouraged to do so) -Mike From skvidal at fedoraproject.org Fri Dec 21 16:03:54 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Dec 2007 11:03:54 -0500 Subject: Wiki Migration In-Reply-To: <1198252268.7443.46.camel@study.mwiriadi.id.au> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> Message-ID: <1198253034.23261.3.camel@cutter> On Sat, 2007-12-22 at 00:51 +0900, Marc Wiriadisastra wrote: > In my opinion it builds people's views of what to hope to expect. It's > also an acknowledgment of work done behind the scenes when news is > reported. A new yum version that is linked to feature x. That's not work done behind the scenes. That's work done upstream. fedora doesn't control the upstream feature-development process. -sv From marc at mwiriadi.id.au Fri Dec 21 16:09:55 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sat, 22 Dec 2007 01:09:55 +0900 Subject: Wiki Migration In-Reply-To: <476BE074.4020703@redhat.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> Message-ID: <1198253395.7443.58.camel@study.mwiriadi.id.au> On Fri, 2007-12-21 at 09:49 -0600, Mike McGrath wrote: > Marc Wiriadisastra wrote: > > > > > >>>> > >>>> > >>> As discussed on IRC my vote is anything that has a CMS built into it. > >>> > >>> I personally feel a lot of things are done behind closed doors and > >>> really feeding the hungry public with information of whats coming up and > >>> things that have occurred is nothing but a bonus. > >>> > >>> > >> This is completely false. On the websites (content) side: > >> > >> http://fedoraproject.org/wiki/Websites/ShowUs There's also the websites > >> list, the docs list, #fedora-websites and #fedora-docs. > >> > >> If you're interested in the hosting side of things you'll want to talk > >> to the Infrastructure team. We have weekly meetings, there's the > >> #fedora-admin channel and the fedora-infrastructure-list. If you think > >> we should replace the wiki with the CMS feel free to state your case on > >> that list and we'll discuss but I think you'll find that for most > >> content that would require a CMS the docs team handles that (and they're > >> currently moving towards a CMS). If you think you can organize the wiki > >> with a CMS and that its the best way to go, lets see the proposal. > >> > >>> I've been advised that plone does this as do other CMS/Wiki's out there. > >>> There are Java based one's out there already I'm not to sure how they > >>> fit into the scheme of things but information to help the marketing, > >>> ambassadors and other contributors to Fedora would be helpful. > >>> > >> We've been trying to get plone up and running for not 1, not 2 but going > >> on 3 years now when February hits. We even have a big Plone advocate > >> working on it with the docs team and yet its still not here. I'm not > >> saying anything bad about the technology but I'm a pretty results > >> oriented guy and the proof is in the pudding. Plone is a resource / > >> attention needy application. I hope the docs guys get a good product > >> out of it but in general I'd like to see Fedora's commitment to Plone > >> stop there until such a time comes that it can play well with the > >> language it was written in (just my 2 cents). > >> > >> -Mike > >> > >> > > > > While I understand that it isn't just one website I would like to think > > that there is sufficient technology around that an integrated wiki/cms > > type solution is out there for the sake of ease. > > > > While my suggestion of Plone is based on the small amount of information > > I have. I personally have not used it so my information is based on > > other people's opinions. > > > > My opinion is based on http://www.gentoo.org/ where they have links to > > associated sections. News is on the front page mainly the Newsletter but > > at least its a form of letting people know what is going on. > > > We have a rotating banner with Fedora Weekly News as well as a current > open ticket: > > https://fedorahosted.org/fedora-infrastructure/ticket/178 > > for a news site. Just needs worker bees. > > I'm just hoping that there is a streamlined method out there. Developer > > puts a feature page in the wiki it gets approved it gets shifted to a > > news item that says we are trying to get x thing implemented by Fedora > > x. > > > Adding process is typically just the opposite of streamline. Anyone can > go and alter the wiki right now (and are encouraged to do so) > > -Mike > Altering the wiki doesn't solve the issue of getting the latest news of what is happening out there. It will end up taking human hours to get information out. I'm not explaining myself correctly or what I'm explaining isn't viewed as what is needed. The simplest method is that we try and leverage the technology to reduce the hour required to look through the wiki and find the information. It then requires someone to transplant it and put it somewhere and somehow make it into a news item. Where are news posts place not including FWN? Where are the new features put in a concise linked up page? Where can workflow be organised in the sense of a doc created then authorised before release not docbook since cvs is used. It's not meant to restrict people further rather to make things more organised. It's meant to actually make things easier. It is a crap load of work without a doubt but I think if migration/change doesn't happen. It will take a significant amount of effort to do later. If it ever gets done later. I'm not advocating doing it in a month or two months just that it gets done before the wiki gets unwieldy. I've said my bit and I hope it has been explained sufficiently that people see a different point of view. Cheers, Marc From mschwendt.tmp0701.nospam at arcor.de Fri Dec 21 16:10:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Dec 2007 17:10:35 +0100 Subject: Delays in package processing In-Reply-To: <1198249198.3656.399.camel@beck.corsepiu.local> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> <1198249198.3656.399.camel@beck.corsepiu.local> Message-ID: <20071221171035.0ac8832d.mschwendt.tmp0701.nospam@arcor.de> On Fri, 21 Dec 2007 15:59:58 +0100, Ralf Corsepius wrote: > > On Fri, 2007-12-21 at 09:30 -0500, Jesse Keating wrote: > > On Fri, 21 Dec 2007 15:17:18 +0100 Ralf Corsepius wrote: > > > > I'm perfectly fine and > > encourage bugfixing across releases. What I'm discouraging is version > > upgrades for new features or spurious builds for spec fixes and other > > unnecessary things that are done across the releases trees, not just on > > rawhide. > > Of cause such things are happening, I don't deny them, but ... how can > you be sure these updates won't fix something you're not aware about? The more important question is: How do you find out they don't break anything [else]? You're baised, because you only see the _positive_ things in an update procedure that has the potential to increase product quality. Most likely that is because you intend to improve your packages (and the packages you depend on) gradually, and if you do it painstakingly you can succeed. Perhaps you pay close attention to changelogs and diffs when evaluating an upgrade, maybe you perform related tests. But can the same be said about all packagers? The Fedora community of packagers consists of many different types of people. Some are upstream themselves, some contribute upstream, some can fix bugs themselves, some cannot fix bugs themselves, some are heavy users of the software they package, some package more than they can use themselves regulary (and obviously depend heavily on feedback from community-testers), some have infinite trust in upstream release habits. This list is incomplete. Theoretically, updates can be fine. Version 1.0 of pkg foo contains bugs, version 1.0.1 fixes these bugs without breaking anything else. But we're not there yet. Many upstream projects are not there yet either. And if we modify our build requirements continously, we even increase the risk of adding bugs. Version upgrades often include more changes than just bug-fixes. Why take the step from the leading edge to the bleeding edge? From marc at mwiriadi.id.au Fri Dec 21 16:12:33 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sat, 22 Dec 2007 01:12:33 +0900 Subject: Wiki Migration In-Reply-To: <1198253034.23261.3.camel@cutter> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <1198253034.23261.3.camel@cutter> Message-ID: <1198253553.7443.62.camel@study.mwiriadi.id.au> On Fri, 2007-12-21 at 11:03 -0500, seth vidal wrote: > On Sat, 2007-12-22 at 00:51 +0900, Marc Wiriadisastra wrote: > > > In my opinion it builds people's views of what to hope to expect. It's > > also an acknowledgment of work done behind the scenes when news is > > reported. A new yum version that is linked to feature x. > > That's not work done behind the scenes. That's work done upstream. > > fedora doesn't control the upstream feature-development process. > > -sv > > http://fedoraproject.org/wiki/Features/IcedTea?highlight=%28feature%29 I'm talking about something like that. Where a feature page on the wiki has been added prior to F9 and development information and interest from the community can occur. When I put feature I meant the features in the wiki apologies for the misunderstanding. Cheers, Marc From ngompa13 at gmail.com Fri Dec 21 16:16:59 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 21 Dec 2007 10:16:59 -0600 Subject: Wiki Migration In-Reply-To: <476BE074.4020703@redhat.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> Message-ID: <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> The problem I'm seeing here is that Fedora is trying to find a balance between keeping spammers and other trash out while allowing as many people as possible to edit the wiki and put quality information in it. The result is this mess of a wiki we have right now, using Moin and connecting it partially to the Fedora Account System. As for CMS + Wiki thing, Enano by default in wiki mode allows anyone to edit, but it provides a simple option to switch it so that only logged in users can edit, and everything can be logged and reversed if necessary. The use of AES in Enano to do user authentication makes it much more secure than other CMSes for logged in accounts. If Fedora wants to allow free editing of the wiki, they need to disconnect the website from the Fedora Account System. The Fedora Account System connection to Moin is a bad idea because it is more or less a front of elitist kind of way. It says that you can register on the wiki, but in order to get access to edit the wiki, you have to set up a Fedora Account in FAS, get an SSH key, GPG key and all that other crock and mess that you really shouldn't have in dealing with a wiki. I have been talking to upstream about Enano, and through our talks, Enano has basic Postgres support. If we do decide to go with Enano, upstream has offered to help design the theme to look similar to the main website of Fedora project. Since he designed the Deluge website themes, I am confident that he could design it into Enano. Also for those who want to use static pages, Enano does expose an "anonymous API" that lets php pages designed to be static use certain functions of Enano, like the theming engine. The demo works fine in Konqueror included in Fedora 8. Are you using the demo at http://demo.enanocms.org ? The demo at opensourcecms.com doesn't work because they inject advert code into everything. A fix for that has already been pushed into Mercurial once it was discovered, but it is unknown whether or not OpenSourceCMS.com is aware of the issue. On Dec 21, 2007 9:49 AM, Mike McGrath wrote: > Marc Wiriadisastra wrote: > > > > > >>>> > >>>> > >>> As discussed on IRC my vote is anything that has a CMS built into it. > >>> > >>> I personally feel a lot of things are done behind closed doors and > >>> really feeding the hungry public with information of whats coming up > and > >>> things that have occurred is nothing but a bonus. > >>> > >>> > >> This is completely false. On the websites (content) side: > >> > >> http://fedoraproject.org/wiki/Websites/ShowUs There's also the websites > >> list, the docs list, #fedora-websites and #fedora-docs. > >> > >> If you're interested in the hosting side of things you'll want to talk > >> to the Infrastructure team. We have weekly meetings, there's the > >> #fedora-admin channel and the fedora-infrastructure-list. If you think > >> we should replace the wiki with the CMS feel free to state your case on > >> that list and we'll discuss but I think you'll find that for most > >> content that would require a CMS the docs team handles that (and > they're > >> currently moving towards a CMS). If you think you can organize the > wiki > >> with a CMS and that its the best way to go, lets see the proposal. > >> > >>> I've been advised that plone does this as do other CMS/Wiki's out > there. > >>> There are Java based one's out there already I'm not to sure how they > >>> fit into the scheme of things but information to help the marketing, > >>> ambassadors and other contributors to Fedora would be helpful. > >>> > >> We've been trying to get plone up and running for not 1, not 2 but > going > >> on 3 years now when February hits. We even have a big Plone advocate > >> working on it with the docs team and yet its still not here. I'm not > >> saying anything bad about the technology but I'm a pretty results > >> oriented guy and the proof is in the pudding. Plone is a resource / > >> attention needy application. I hope the docs guys get a good product > >> out of it but in general I'd like to see Fedora's commitment to Plone > >> stop there until such a time comes that it can play well with the > >> language it was written in (just my 2 cents). > >> > >> -Mike > >> > >> > > > > While I understand that it isn't just one website I would like to think > > that there is sufficient technology around that an integrated wiki/cms > > type solution is out there for the sake of ease. > > > > While my suggestion of Plone is based on the small amount of information > > I have. I personally have not used it so my information is based on > > other people's opinions. > > > > My opinion is based on http://www.gentoo.org/ where they have links to > > associated sections. News is on the front page mainly the Newsletter but > > at least its a form of letting people know what is going on. > > > We have a rotating banner with Fedora Weekly News as well as a current > open ticket: > > https://fedorahosted.org/fedora-infrastructure/ticket/178 > > for a news site. Just needs worker bees. > > I'm just hoping that there is a streamlined method out there. Developer > > puts a feature page in the wiki it gets approved it gets shifted to a > > news item that says we are trying to get x thing implemented by Fedora > > x. > > > Adding process is typically just the opposite of streamline. Anyone can > go and alter the wiki right now (and are encouraged to do so) > > -Mike > > -- > 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 mmcgrath at redhat.com Fri Dec 21 16:08:57 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 10:08:57 -0600 Subject: Wiki Migration In-Reply-To: <1198253553.7443.62.camel@study.mwiriadi.id.au> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <1198253034.23261.3.camel@cutter> <1198253553.7443.62.camel@study.mwiriadi.id.au> Message-ID: <476BE519.4020907@redhat.com> Marc Wiriadisastra wrote: > On Fri, 2007-12-21 at 11:03 -0500, seth vidal wrote: > >> On Sat, 2007-12-22 at 00:51 +0900, Marc Wiriadisastra wrote: >> >> >>> In my opinion it builds people's views of what to hope to expect. It's >>> also an acknowledgment of work done behind the scenes when news is >>> reported. A new yum version that is linked to feature x. >>> >> That's not work done behind the scenes. That's work done upstream. >> >> fedora doesn't control the upstream feature-development process. >> >> -sv >> >> >> > > http://fedoraproject.org/wiki/Features/IcedTea?highlight=%28feature%29 > I'm talking about something like that. > > Where a feature page on the wiki has been added prior to F9 and > development information and interest from the community can occur. > > When I put feature I meant the features in the wiki apologies for the > misunderstanding. > We did talk about this, 2 weeks ago, back when it was news. http://fedoraproject.org/wiki/FWN/Issue111#head-4ae540b1341a5481ff953fed42bba90b95d1e90f -Mike From mmcgrath at redhat.com Fri Dec 21 16:11:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 10:11:23 -0600 Subject: Wiki Migration In-Reply-To: <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> Message-ID: <476BE5AB.8060104@redhat.com> King InuYasha wrote: > The problem I'm seeing here is that Fedora is trying to find a balance > between keeping spammers and other trash out while allowing as many people > as possible to edit the wiki and put quality information in it. The result > is this mess of a wiki we have right now, using Moin and connecting it > partially to the Fedora Account System. > Actually its got nothing to do with spam its the legal requirement of a CLA. We're working for a clickthrough cla that will fix that. -Mike From rdieter at math.unl.edu Fri Dec 21 16:17:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 21 Dec 2007 10:17:29 -0600 Subject: uw-imap-2007 soname bump Message-ID: <476BE719.6030509@math.unl.edu> fyi, I'll be pushing uw-imap-2007 to rawhide later today, it includes a soname bump, so dependent packages need to be rebuilt, including: asterisk(-voicemail-imap) php(-imap) -- Rex _______________________________________________ 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 Fri Dec 21 16:25:17 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 21 Dec 2007 11:25:17 -0500 Subject: Delays in package processing In-Reply-To: <20071221090135.1ce95af7@redhat.com> References: <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> Message-ID: <20071221162517.GF8355@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I had hoped that common sense would prevail across our maintainers and > that stable releases would be treated as such, stable releases not to > be cheapened with lots of unnecessary updates just so that "users can > get the latest stuff!". Unfortunately that doesn't seem to be what's > happening. I don't want to introduce draconian policies and > procedures to enforce this, mostly because there just isn't enough time > in the day to supervise all the potential updates for whether they > should go out or not. > > So I ask you, Fedora Community, how do we as a community ensure that > our stable releases stay just that, stable? Well, it depends. For the stuff I maintain, I tend to follow different policies depending on the package: - Library versions do not get upgraded in a stable release - The more core a package is, it only gets updated with occasional severe bugfixes - it is not ever rebased. - More peripheral things, such as some desktop apps, get updated to the latest minor bugfix version Hard to say how much this works for everyone, though. Bill From kwade at redhat.com Fri Dec 21 16:27:10 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Dec 2007 08:27:10 -0800 Subject: Wiki Migration In-Reply-To: <476B30C4.7050201@redhat.com> References: <4762E5F5.4010206@redhat.com> <80d7e4090712201755l66cc2670q53980fb7de2003cd@mail.gmail.com> <476B2718.7060103@redhat.com> <80d7e4090712201843v69181015va409333719e7d4aa@mail.gmail.com> <476B30C4.7050201@redhat.com> Message-ID: <1198254430.3593.168.camel@erato.phig.org> On Thu, 2007-12-20 at 21:19 -0600, Mike McGrath wrote: > Having said that, moving away isn't very feasible either. We're in a > tough spot for sure. It just depends on what you define as feasible, and what your resource commitment is. You asked me earlier on IRC: "... just so I know are you generally in favor of Moin or just not in favor of migration issues + the uncertanty of the future wiki not having docbook?" Mainly the latter. I have no love lost for Moin Moin, although I think some of the invective I've seen is ill-placed; a wiki is a wiki, in the end, and all have similar drawbacks. Many projects use the wiki as part of their process, but AFAICT none of that process relies upon features special or unique to Moin Moin. OTOH, Fedora Docs _may_ rely upon parts of Moin that are special. We certainly have a lot of process tied up in Moin, from how markup works in the wiki so it makes predictable DocBook XML, to how we gather and organize Docs/Beats/ into the release notes. Unfortunately, even automated conversion may not help entirely, since overall the wiki is inconsistent in markup styles. Fortunately that is less of the case in the Docs.* namespace. Bottom line -- it *cannot* be a foregone conclusion that we are replacing Moin without first gaining consensus from Fedora Docs. How? Let's focus on features and specific tooling needs, list them out, and figure out how to get that with OtherWikis. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- 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 Dec 21 16:29:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 11:29:39 -0500 Subject: Delays in package processing In-Reply-To: <20071221162517.GF8355@nostromo.devel.redhat.com> References: <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> Message-ID: <20071221112939.2623479c@redhat.com> On Fri, 21 Dec 2007 11:25:17 -0500 Bill Nottingham wrote: > Well, it depends. For the stuff I maintain, I tend to follow different > policies depending on the package: > > - Library versions do not get upgraded in a stable release > - The more core a package is, it only gets updated with occasional > severe bugfixes - it is not ever rebased. > - More peripheral things, such as some desktop apps, get updated to > the latest minor bugfix version > > Hard to say how much this works for everyone, though. I think this is a very good example to go 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 hughsient at gmail.com Fri Dec 21 16:39:47 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 Dec 2007 16:39:47 +0000 Subject: [pm] Resume hooks not run In-Reply-To: References: Message-ID: <1198255187.1222.0.camel@hughsie-laptop> On Sun, 2007-11-18 at 07:41 +0000, Leo wrote: > Is there any difference between manually selecting "suspend" and > automatically "suspend" when inactive? > > They seem behave differently for no reason. Assuming you are using GNOME, none at all. Richard. From jwboyer at gmail.com Fri Dec 21 16:45:32 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 21 Dec 2007 10:45:32 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> Message-ID: <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> On Tue, 18 Dec 2007 07:27:09 -0600 Josh Boyer wrote: > > I will be collecting suggestions for 1 week so the cutoff for names is: > > December 25, 2007 We're off to a great start so far. Given the various vacation schedules of people, we're extending the cutoff for name suggestions to: Jan 1, 2008 Keep 'em coming! josh From ngompa13 at gmail.com Fri Dec 21 16:47:03 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 21 Dec 2007 10:47:03 -0600 Subject: Wiki Migration In-Reply-To: <476BE5AB.8060104@redhat.com> References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> <476BE5AB.8060104@redhat.com> Message-ID: <8278b1b0712210847n613c5d32gb9ce11a4383d4b6c@mail.gmail.com> Well, the CLA is a essentially a registration agreement, right? Well, a plugin could be written into Enano to require agreement during the registration process, essentially a clickthrough CLA. On Dec 21, 2007 10:11 AM, Mike McGrath wrote: > King InuYasha wrote: > > The problem I'm seeing here is that Fedora is trying to find a balance > > between keeping spammers and other trash out while allowing as many > people > > as possible to edit the wiki and put quality information in it. The > result > > is this mess of a wiki we have right now, using Moin and connecting it > > partially to the Fedora Account System. > > > > > Actually its got nothing to do with spam its the legal requirement of a > CLA. We're working for a clickthrough cla that will fix that. > > -Mike > > -- > 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 walters at redhat.com Fri Dec 21 16:54:01 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 21 Dec 2007 11:54:01 -0500 Subject: Delays in package processing In-Reply-To: <1198231811.5768.228.camel@Jehannum> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <1198231811.5768.228.camel@Jehannum> Message-ID: <1198256041.5619.6.camel@space-ghost.verbum.private> On Fri, 2007-12-21 at 10:10 +0000, Caolan McNamara wrote: > Yeah, we push *way* too many updates and too casually. In my own view an > update should fix a clearly identified common crasher or some other > serious problem, but definitely not just because a new version of a > package appeared upstream. There are many aspects to be taken into consideration; just because we ship all kinds of software in one format doesn't mean we should apply the same rules to all of them. Server software is obviously something to be very conservative with, for example. This implies all of their library dependencies too. Desktop software - how popular is it? Is it something we ship on the default Live CD? What are the risks of upgrading vs not? How good has upstream historically been about regressions? But we ship a fair amount of stuff that I would consider beta or even alpha - and upgrading those kinds of things to the new upstream version is often a nobrainer. From alan at clueserver.org Fri Dec 21 17:03:21 2007 From: alan at clueserver.org (Alan) Date: Fri, 21 Dec 2007 09:03:21 -0800 (PST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> Message-ID: <10409.198.182.194.170.1198256601.squirrel@clueserver.org> > On Tue, 18 Dec 2007 07:27:09 -0600 > Josh Boyer wrote: > >> >> I will be collecting suggestions for 1 week so the cutoff for names is: >> >> December 25, 2007 > > We're off to a great start so far. Given the various vacation > schedules of people, we're extending the cutoff for name suggestions to: > > Jan 1, 2008 > > Keep 'em coming! If we keep with the "monster" theme I suggest: "Phibes" Besides... Its from a Vincent Price movie. The Abominable Dr. Phibes (1971) Dr. Phibes: "My love, precious jewel and noble wife. Severed, too quickly, too cruelly from this life. I alone remain to give delivery of your pain. Nine killed you. Nine shall die. Nine times, nine! Nine killed you! Nine shall die! Nine eternities in DOOM!" From nicu_fedora at nicubunu.ro Fri Dec 21 17:05:26 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 21 Dec 2007 19:05:26 +0200 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> Message-ID: <476BF256.1060909@nicubunu.ro> Josh Boyer wrote: > On Tue, 18 Dec 2007 07:27:09 -0600 > Josh Boyer wrote: > >> I will be collecting suggestions for 1 week so the cutoff for names is: >> >> December 25, 2007 > > We're off to a great start so far. Given the various vacation > schedules of people, we're extending the cutoff for name suggestions to: > > Jan 1, 2008 OK. Probably the Art Team will not be able to make use of the name as we have a deadline for Round 1 in 8 January. We may delay it a bit (a week or so) but not much, and the legal clearing and community vote will take some additional time. -- 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 ngompa13 at gmail.com Fri Dec 21 17:07:20 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 21 Dec 2007 11:07:20 -0600 Subject: Fedora 8 review In-Reply-To: <1198250188.1765.6.camel@ignacio.lan> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> Message-ID: <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> I would have to agree with Chris and Bryan regarding Anaconda and the icon style. It seems that Anaconda has had more and more features tacked on it since its inception so long ago. Has Anaconda ever been rewritten or has anyone even considered rewriting Anaconda? The icon style issue could be fixed once the Echo Icons are finished... if they do get finished.... On Dec 21, 2007 9:16 AM, Ignacio Vazquez-Abrams wrote: > On Fri, 2007-12-21 at 15:49 +0100, Hans de Goede wrote: > > Valent Turkovic wrote: > > > Hi, I listened to Linux Action Show and I really liked their review of > > > Fedora 8. I believe that this is something Fedora users but also > > > Fedora devels should listen. > > > > Any chance you can write up a good summary? Esp a list of points which > > they say need improvement, and you agree with, and which we are actually > > capable of improving (iow not support mp3 please, etc.). > > > https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00269.html > > -- > Ignacio Vazquez-Abrams > > -- > 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 berrange at redhat.com Fri Dec 21 17:16:31 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 21 Dec 2007 17:16:31 +0000 Subject: Fedora 8 review In-Reply-To: <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> Message-ID: <20071221171631.GB27601@redhat.com> On Fri, Dec 21, 2007 at 11:07:20AM -0600, King InuYasha wrote: > I would have to agree with Chris and Bryan regarding Anaconda and the icon > style. It seems that Anaconda has had more and more features tacked on it > since its inception so long ago. Has Anaconda ever been rewritten or has > anyone even considered rewriting Anaconda? Re-writing something that on the whole works very well, just to fix a couple of minor UI issues & the way it sets up grub is nuts. Re-writing apps just because they're 'old' is very detrimental because inevitably you loose all the years of bugfixes that make the wierd edge-cases work. 'New' code merely looks clean at first because it never deals with the wierd edge-cases - once you fix all the edge case bugs to get parity you're back where you started. 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 debarshi.ray at gmail.com Fri Dec 21 17:16:18 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 21 Dec 2007 22:46:18 +0530 Subject: RFC: FEver and RPath checks in Koji Message-ID: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> I have a couple of proposals which I wanted to sound out. + Would it be possible to run FEver (http://fedoraproject.org/wiki/PackageMaintainers/FEver) on a regular basis? Currently I get the feeling that it is run manually at irregular intervals, and since I depend heavily on it for tracking upstream releases this often means that a release is missed occasionally. + Would it be a good idea to have rpath related checks in Koji? Although I use "%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot" in my ~/.rpmmacros, some rpath issues are only detected on x86_64 systems? Although I have a x86_64 desktop, it can be a bit problematic when a x86_64 system is not available. Such issues do not get detected during the Koji build resulting in violation of the packaging guidelines. Comments? Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From walters at redhat.com Fri Dec 21 17:18:28 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 21 Dec 2007 12:18:28 -0500 Subject: Fedora 8 review In-Reply-To: <20071221171631.GB27601@redhat.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> <20071221171631.GB27601@redhat.com> Message-ID: <1198257508.5619.10.camel@space-ghost.verbum.private> On Fri, 2007-12-21 at 17:16 +0000, Daniel P. Berrange wrote: > On Fri, Dec 21, 2007 at 11:07:20AM -0600, King InuYasha wrote: > > I would have to agree with Chris and Bryan regarding Anaconda and the icon > > style. It seems that Anaconda has had more and more features tacked on it > > since its inception so long ago. Has Anaconda ever been rewritten or has > > anyone even considered rewriting Anaconda? http://www.joelonsoftware.com/articles/fog0000000069.html From sundaram at fedoraproject.org Fri Dec 21 17:11:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Dec 2007 22:41:10 +0530 Subject: Fedora 8 review In-Reply-To: <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> Message-ID: <476BF3AE.5030302@fedoraproject.org> King InuYasha wrote: > I would have to agree with Chris and Bryan regarding Anaconda and the > icon style. It seems that Anaconda has had more and more features tacked > on it since its inception so long ago. Has Anaconda ever been rewritten > or has anyone even considered rewriting Anaconda? The icon style issue > could be fixed once the Echo Icons are finished... if they do get > finished.... Pretty much all software gets features tacked on over time. I didn't hear the review suggest anything close to a rewrite and a rewrite would be absolutely pointless anyway http://www.joelonsoftware.com/articles/fog0000000069.html Echo would get finished faster if there was more contributors. Rahul Ps: Don't top post. http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Rahul From ngompa13 at gmail.com Fri Dec 21 17:22:25 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 21 Dec 2007 11:22:25 -0600 Subject: Fedora 8 review In-Reply-To: <476BF3AE.5030302@fedoraproject.org> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> <476BF3AE.5030302@fedoraproject.org> Message-ID: <8278b1b0712210922p6acc42efy91d931d69fa93d8f@mail.gmail.com> On Dec 21, 2007 11:11 AM, Rahul Sundaram wrote: > King InuYasha wrote: > > I would have to agree with Chris and Bryan regarding Anaconda and the > > icon style. It seems that Anaconda has had more and more features tacked > > on it since its inception so long ago. Has Anaconda ever been rewritten > > or has anyone even considered rewriting Anaconda? The icon style issue > > could be fixed once the Echo Icons are finished... if they do get > > finished.... > > Pretty much all software gets features tacked on over time. I didn't > hear the review suggest anything close to a rewrite and a rewrite would > be absolutely pointless anyway > > http://www.joelonsoftware.com/articles/fog0000000069.html > > Echo would get finished faster if there was more contributors. > > Rahul > > Ps: Don't top post. > > Well, my beef with Anaconda is similar to Chris and Bryan's as well as I have noticed that Anaconda has been getting considerably slower each release. And in Fedora 5, Anaconda made the jump from requiring at least 192MB of RAM for GUI to 256MB of RAM for GUI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Dec 21 17:22:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 12:22:56 -0500 Subject: RFC: FEver and RPath checks in Koji In-Reply-To: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> References: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> Message-ID: <20071221122256.463f61c4@redhat.com> On Fri, 21 Dec 2007 22:46:18 +0530 "Debarshi 'Rishi' Ray" wrote: > + Would it be a good idea to have rpath related checks in Koji? > Although I use "%__arch_install_post /usr/lib/rpm/check-rpaths > /usr/lib/rpm/check-buildroot" > in my ~/.rpmmacros, some rpath issues are only detected on x86_64 > systems? Although I have a x86_64 desktop, it can be a bit problematic > when a x86_64 system is not available. Such issues do not get detected > during the Koji build resulting in violation of the packaging > guidelines. > > Comments? I'm pretty sure rpath checking is done in koji, due to the macros we install in redhat-config-rpm. -- 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 Dec 21 17:27:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 12:27:41 -0500 Subject: RFC: FEver and RPath checks in Koji In-Reply-To: <20071221122256.463f61c4@redhat.com> References: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> <20071221122256.463f61c4@redhat.com> Message-ID: <20071221122741.3ab8265a@redhat.com> On Fri, 21 Dec 2007 12:22:56 -0500 Jesse Keating wrote: > I'm pretty sure rpath checking is done in koji, due to the macros we > install in redhat-config-rpm. Looks like I'm mistaken. There was discussion on this, but apparently it didn't 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 paul at all-the-johnsons.co.uk Fri Dec 21 17:45:11 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 21 Dec 2007 17:45:11 +0000 Subject: Mono-addins and monodevelop Message-ID: <1198259111.4784.13.camel@T7.Linux> Hi, Monodevelop now requires mono-addins to build and also has a number of branches from it (like monodevelop-database and the likes). I've not yet built these new branches, but before beta 3 of monodevelop can hit rawhide, can someone please review mono-addins. This package is important as the plan is to move the likes of monodoc and other components to the add-in system. ?https://bugzilla.redhat.com/show_bug.cgi?id=426349 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 Fri Dec 21 17:56:57 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Dec 2007 11:56:57 -0600 Subject: Fedora 8 review In-Reply-To: <8278b1b0712210922p6acc42efy91d931d69fa93d8f@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> <476BF3AE.5030302@fedoraproject.org> <8278b1b0712210922p6acc42efy91d931d69fa93d8f@mail.gmail.com> Message-ID: <16de708d0712210956wbe9eef7xf7ef34c6e6c89cb9@mail.gmail.com> On Dec 21, 2007 11:22 AM, King InuYasha wrote: > On Dec 21, 2007 11:11 AM, Rahul Sundaram wrote: > > > > > King InuYasha wrote: > > > I would have to agree with Chris and Bryan regarding Anaconda and the > > > icon style. It seems that Anaconda has had more and more features tacked > > > on it since its inception so long ago. Has Anaconda ever been rewritten > > > or has anyone even considered rewriting Anaconda? The icon style issue > > > could be fixed once the Echo Icons are finished... if they do get > > > finished.... > > > > Pretty much all software gets features tacked on over time. I didn't > > hear the review suggest anything close to a rewrite and a rewrite would > > be absolutely pointless anyway > > > > > > http://www.joelonsoftware.com/articles/fog0000000069.html > > > > Echo would get finished faster if there was more contributors. > > > > Rahul > > > > Ps: Don't top post. > > > > > Well, my beef with Anaconda is similar to Chris and Bryan's as well as I > have noticed that Anaconda has been getting considerably slower each > release. And in Fedora 5, Anaconda made the jump from requiring at least > 192MB of RAM for GUI to 256MB of RAM for GUI. Frankly I think 256MB for GUI is fair. And yet, I think Anaconda doesn't have NEARLY enough features -- it's too linear for my tastes. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From eric.tanguy at univ-nantes.fr Fri Dec 21 18:00:49 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 21 Dec 2007 19:00:49 +0100 Subject: LSB compliant init file Message-ID: <1198260049.2839.4.camel@bureau.maison> I know http://fedoraproject.org/wiki/FCNewInit/Initscripts but i'm looking for a simple example in a package which is already LSB compliant. Thanks Eric From jdennis at redhat.com Fri Dec 21 18:11:45 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 21 Dec 2007 13:11:45 -0500 Subject: RFC: FEver and RPath checks in Koji In-Reply-To: <20071221122256.463f61c4@redhat.com> References: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> <20071221122256.463f61c4@redhat.com> Message-ID: <476C01E1.7070708@redhat.com> Jesse Keating wrote: > On Fri, 21 Dec 2007 22:46:18 +0530 > "Debarshi 'Rishi' Ray" wrote: > >> + Would it be a good idea to have rpath related checks in Koji? >> Although I use "%__arch_install_post /usr/lib/rpm/check-rpaths >> /usr/lib/rpm/check-buildroot" >> in my ~/.rpmmacros, some rpath issues are only detected on x86_64 >> systems? Although I have a x86_64 desktop, it can be a bit problematic >> when a x86_64 system is not available. Such issues do not get detected >> during the Koji build resulting in violation of the packaging >> guidelines. >> >> Comments? +1 > I'm pretty sure rpath checking is done in koji, due to the macros we > install in redhat-config-rpm. I don't believe so. We've been bitten by this recently. x86_64 builds will succeed in Koji but fail locally. This lead to the incorrect conclusion the problem was on the local machine because Koji builds are the gold standard reference thus the local machine had to have a problem. As we learned a few days ago the Koji build had the exact same rpath issue, however it wasn't flagged as a build error like it was locally. The red herring was an unfortunate waste of time because we were looking for the problem in the wrong place. -- John Dennis From kevin.kofler at chello.at Fri Dec 21 17:10:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 21 Dec 2007 17:10:53 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> <1198249198.3656.399.camel@beck.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > My current favorite example: Why has doxygen not yet been upgraded on > Fedora 8? Ask Than Ngo, he's the maintainer. Kevin Kofler From jspaleta at gmail.com Fri Dec 21 18:31:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 09:31:00 -0900 Subject: Delays in package processing In-Reply-To: <20071221162517.GF8355@nostromo.devel.redhat.com> References: <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> Message-ID: <604aa7910712211031m5d9d359coe891e130c26b8005@mail.gmail.com> On Dec 21, 2007 7:25 AM, Bill Nottingham wrote: > Well, it depends. For the stuff I maintain, I tend to follow different > policies depending on the package: > > - Library versions do not get upgraded in a stable release > - The more core a package is, it only gets updated with occasional > severe bugfixes - it is not ever rebased. > - More peripheral things, such as some desktop apps, get updated to > the latest minor bugfix version > > Hard to say how much this works for everyone, though. Let's start with this methodology. Can we split the repository binary packages into rough concentric rings that embodies "coreness." Call it Spaleta's 9 circles of Fedora Packaging Hell{tm} if you want. And then produce some aggregate stats as to how updates for those groups have been handled for F7 and so far for F8. Is the aggregate update policy inline which the methodology you just outlined...update churn goes down as you move into inner/lower packaging layers? Or is there an obvious deviation in the aggregate for a specific layer? -jef"and again by 'we' I mean 'not me'"spaleta From buildsys at redhat.com Fri Dec 21 18:40:08 2007 From: buildsys at redhat.com (Build System) Date: Fri, 21 Dec 2007 13:40:08 -0500 Subject: rawhide report: 20071221 changes Message-ID: <200712211840.lBLIe8ej021094@porkchop.devel.redhat.com> New package amanith Crossplatform framework for 2d/3d vector graphics New package fontmatrix A fonts manager New package perl-Email-Date-Format Produce RFC 2822 date strings New package ruby-libvirt Ruby bindings for libvirt New package rubygem-activeresource Active Record for web resources New package tpm-tools Management tools for the TPM hardware Updated Packages: alexandria-0.6.2-1.fc9 ---------------------- * Thu Dec 20 2007 Mamoru Tasaka - 0.6.2-1 - 0.6.2 - Two patches for 0.6.2b2 are removed. amarok-1.4.8-1.fc9 ------------------ * Thu Dec 20 2007 Rex Dieter 1.4.8-1 - amarok-1.4.8 * Fri Dec 07 2007 Alex Lancaster 1.4.7-14 - Rebuild for new openssl * Thu Nov 29 2007 Rex Dieter 1.4.7-13 - fix --with-mp4v2 handling (#346011#c5,6) anaconda-11.4.0.12-1 -------------------- * Thu Dec 20 2007 Jeremy Katz - 11.4.0.12-1 - Switch away from using kudzu in the loader (notting) - Use udev in the loader and a dynamically linked stage1 (notting) - Don't handle all aspects of module loading ourselves - just wrap modprobe. (notting) - Ensure there's an active net device (katzj) - Fix error reporting messages (sfernand, #242252). (clumens) - Don't immediately retry on downloading a package. (clumens) - Update to work with new system-config-keyboard. (clumens) azureus-3.0.3.4-4.fc9 --------------------- * Thu Dec 20 2007 Lillian Angel - 3.0.3.4-4 - Updated script to use new xulrunner-1.9pre - Updated release. bind-32:9.5.0-22.b1.fc9 ----------------------- * Thu Dec 20 2007 Adam Tkac 32:9.5.0-22.b1 - fixed regression caused by libidn2 patch (#426348) bzflag-2.0.10-3.fc9 ------------------- * Thu Dec 20 2007 Nils Philippsen 2.0.10-3 - fix global plugin directory * Wed Dec 19 2007 Nils Philippsen 2.0.10-2 - build and package plugins * Mon Dec 17 2007 Nils Philippsen 2.0.10-1 - version 2.0.10 deskbar-applet-2.21.4-1.fc9 --------------------------- * Thu Dec 20 2007 Luke Macken - 2.21.4-1 - 2.21.4 * Mon Dec 03 2007 Luke Macken - 2.21.3-1 - 2.21.3 firefox-3.0-0.beta2.2.fc9 ------------------------- * Thu Dec 20 2007 Martin Stransky 3.0-0.beta2.2 - fixed xulrunner dependency glade3-3.4.1-2.fc9 ------------------ * Fri Dec 21 2007 Debarshi Ray - 3.4.1-2 - Removed deletion of /var/lib/scrollkeeper for all distributions, except Fedora 7. * Thu Dec 20 2007 Debarshi Ray - 3.4.1-1 - Version bump to 3.4.1. glib2-2.15.0-1.fc9 ------------------ * Thu Dec 20 2007 Matthias Clasen - 2.15.0-1 - Update to 2.15.0 gnome-spell-1.0.8-2.fc9 ----------------------- * Thu Dec 20 2007 Caolan McNamara - 1.0.8-2.fc9 - Unify dictionaries, make gnome-spell use enchant gnome-terminal-2.21.4-1.fc9 --------------------------- * Fri Dec 21 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnomesword-2.3.1-4.fc9 ---------------------- * Thu Dec 20 2007 Deji Akingunola - 2.3.1-4 - Build with gtkhtml for now, until building with latest xulrunner is fixed gnupg2-2.0.8-1.fc9 ------------------ * Thu Dec 20 2007 Rex Dieter 2.0.8-1 - gnupg2-2.0.8 gtk-gnutella-0.96.4-3.fc9 ------------------------- * Thu Dec 20 2007 Dmitry Butskoy - 0.96.4-3 - Update hostiles.txt file to the latest upstream SVN version gtkspell-2.0.11-5.fc9 --------------------- * Thu Dec 20 2007 Matthew Barnes - 2.0.11-5.fc9 - Add patch for RH bug #245888 (use Enchant). haddock-0.9-2.fc9 ----------------- * Thu Dec 20 2007 Bryan O'Sullivan - 0.9-2 - Exclude alpha, ppc64 * Thu Dec 20 2007 Bryan O'Sullivan - 0.9-1 - update to 0.9 * Thu Aug 16 2007 Jens Petersen - update License field kdeadmin-7:3.97.0-3.fc9 ----------------------- * Thu Dec 20 2007 Kevin Kofler 3.97.0-3 - don't run kpackage through consolehelper, it can elevate privileges on demand (see also #344751, though that bug appears not to have affected KDE 4) kernel-2.6.24-0.118.rc5.git6.fc9 -------------------------------- * Thu Dec 20 2007 Dave Airlie - add MODULE_DEVICE_TABLE to radeon and i915 drivers * Wed Dec 19 2007 Kyle McMartin - 2.6.24-rc5-git6 * Wed Dec 19 2007 Dave Airlie - Update drm upstream patches and add basic r500 drm support libpri-1.4.3-1.fc9 ------------------ * Thu Dec 20 2007 Jeffrey C. Ollie - 1.4.3-1 - Update to 1.4.3. - Drop upstreamed patch. lvm2-2.02.29-5.fc9 ------------------ * Thu Dec 20 2007 Alasdair Kergon > - 2.02.29-5 - Fix libdevmapper readahead processing with snapshots (for example). metacity-2.21.5-2.fc9 --------------------- * Thu Dec 20 2007 Colin Walters - 2.21.5-2 - Add patch for avoiding moving windows across workspaces This makes clicking on links in firefox do what you want. http://bugzilla.gnome.org/show_bug.cgi?id=482354 mock-0.9.5-1.fc9 ---------------- * Thu Dec 20 2007 Michael Brown - 0.9.5-1 - really fix file-based BuildRequires mod_mono-1.2.6-1.1.fc9 ---------------------- * Thu Dec 20 2007 Paul F. Johnson 1.2.6-1.1 - remove arch ppc64 * Thu Nov 22 2007 Paul F. Johnson 1.2.6-1 - bump - url fix * Sun Nov 18 2007 Paul F. Johnson 1.2.5-1 - bump mono-1.2.6-6.1.fc9 ------------------ * Wed Dec 19 2007 Paul F. Johnson 1.2.6-6.1 - added BR libunwind-devel for ia64 (bz426180) - fix for LIBDIR problem * Sun Dec 16 2007 Paul F. Johnson 1.2.6-4 - bump new version - removed more redundant bits - url fix * Thu Nov 22 2007 Paul F. Johnson 1.2.6-1 - bump to preview 2 - removed redundant bits of the spec file mono-debugger-0.60-1.2.fc9 -------------------------- * Wed Dec 19 2007 Paul F. Johnson 0.60-1.2 - bump - use exclusivearch instead of exclude * Sun Dec 16 2007 Paul F. Johnson 0.50-2 - url fix * Sun Nov 18 2007 Paul F. Johnson 0.50-1 - bump ncarg-4.4.2-5.fc9 ----------------- * Thu Dec 20 2007 - Orion Poplawski - 4.4.2-5 - Add Requires libXext-devel to -devel package nspluginwrapper-0.9.91.5-17.fc9 ------------------------------- * Thu Dec 20 2007 Martin Stransky 0.9.91.5-17 - disabled xpcom support - it causes more troubles than advantages numactl-1.0.2-2.fc9 ------------------- * Thu Dec 20 2007 Neil Horman - 1.0.2-1 - Update numactl to fix get_mempolicy signature (bz 418551) octave-forge-20071212-4.fc9 --------------------------- * Thu Dec 20 2007 Quentin Spencer 20071212-4 - I give up. Disable parallel build. * Thu Dec 20 2007 Quentin Spencer 20071212-3 - Try the patch again. * Thu Dec 20 2007 Quentin Spencer 20071212-2 - Add patch to fix parallel build of odepkg and optiminterp (again). openoffice.org-1:2.3.1-9.10.fc9 ------------------------------- * Thu Dec 20 2007 Caolan McNamara - 1:2.3.1-9.10 - Resolves: rhbz#425701 add workspace.locales24.patch - Resolves: rhbz#423371 openoffice.org-2.3.1.ooo84621.sw.insertexcel.patch - add workspace.gcc430.patch for gcc 4.3.0 - add openoffice.org-2.3.1.ooo84770.svx.eventsmismatch.patch * Sun Dec 09 2007 Caolan McNamara - 1:2.3.1-9.9 - oops * Sat Dec 08 2007 Caolan McNamara - 1:2.3.1-9.8 - Resolves: rhbz#384401 attempt to allow davs:// to work perl-Email-Date-1.103-2.fc9 --------------------------- * Thu Dec 20 2007 Tom "spot" Callaway - 1.103-2 - add BR: Module::Pluggable perl-Email-Simple-Creator-1.424-1.fc9 ------------------------------------- * Thu Dec 20 2007 Tom "spot" Callaway - 1.424-1 - 1.424 perl-Test-Pod-1.26-2.fc9 ------------------------ * Thu Dec 20 2007 Tom "spot" Callaway - 1.26-2 - license tag fix policycoreutils-2.0.34-2.fc9 ---------------------------- * Thu Dec 20 2007 Dan Walsh 2.0.34-2 - Make sepolgen set error exit code when partial failure - audit2why now checks booleans for avc diagnosis revisor-2.0.5-14.fc9 -------------------- * Fri Nov 23 2007 Jeroen van Meeuwen 2.0.5-14 - import piruterrors - Minor fixes related to respinning Fedora for release - Applied patch from Alexander Todorov for filtering comps * Mon Nov 19 2007 Jeroen van Meeuwen 2.0.5-13 - Point at Everything, not Fedora - Add in ignore_list for pkglist_required() - Catch a Bob Jensen Corner Case - Minor bugfixes in packaging - Other minor fixes * Sat Oct 20 2007 Jonathan Steffan 2.0.5-5 - Update spec for release scim-python-0.1.7-1.fc9 ----------------------- * Fri Dec 21 2007 Huang Peng - 0.1.7-1 - Update to 0.1.7. selinux-policy-3.2.5-3.fc9 -------------------------- * Thu Dec 20 2007 Dan Walsh 3.2.5-3 - Run rpm in system_r showimg-0.9.5-16.fc9 -------------------- * Sun Dec 09 2007 Alex Lancaster - 0.9.5-16 - Drop versioning of kdebase3-devel BuildRequires * Sun Dec 09 2007 Alex Lancaster - 0.9.5-15 - BuildRequires: kdebase-devel -> kdebase3-devel * Sun Dec 09 2007 Alex Lancaster - 0.9.5-14 - Rebuild for new openssl soname bump sirius-0.8.0-12.fc9 ------------------- * Thu Dec 20 2007 Arindam Ghosh - 0.8.0-12 - Rebuild for F8 sound-juicer-2.21.0-1.fc9 ------------------------- * Fri Dec 21 2007 Matthias Clasen - 2.21.0-1 - Update to 2.21.0 system-config-firewall-1.1.0-1.fc9 ---------------------------------- * Thu Dec 20 2007 Thomas Woerner 1.1.0-1 - new default configurations: server, desktop - cleanup of wizard: dropped network connection tab - new option in wizard to keep configuration or load a default configuration - new menu entry and dialog to configure iptables and ip6tables service settings - some enhancements to the gtk_cellrenderercheck for better look and feel * Fri Dec 14 2007 Thomas Woerner 1.1.0-0 - ports are ports and services are services: there is a new service tag to enable services; a port is not enabling a service anymore - new conversion tool for 1.0.X to 1.1.X configuration - new version option for lokkit - wizard - dropped network connection selection tab - using keep configuration check instead of clear configuration check - added default configuration selection - gui: new menu for skill level and load default configuration - use choices in optparse, removed obsolete check functions texlive-2007-5.fc9 ------------------ * Mon Dec 17 2007 Jindrich Novy - 2007-5 - add tex virtual provide - BuildRequire texlive-fonts for kpathsea (thanks to Patrice Dumas) vte-0.16.11-1.fc9 ----------------- * Fri Dec 21 2007 Matthias Clasen - 0.16.11-1 - Update to 0.16.11 xchat-1:2.8.4-9.fc9 ------------------- * Thu Dec 20 2007 Adam Jackson 1:2.8.4-9 - xchat-2.8.4-shm-pixmaps.patch: MIT-SHM pixmaps are optional, and when using EXA they are not available. Check that the server supports them before trying to create them so we don't crash. * Wed Dec 19 2007 Kevin Kofler - 1:2.8.4-8 - apply xc284-fix-scrollbfdleak.diff from upstream * Wed Dec 05 2007 Christopher Aillon - 1:2.8.4-7 - Fix the icon key in the .desktop file to validate xulrunner-1.9-0.beta2.2.fc9 --------------------------- * Thu Dec 20 2007 Martin Stransky 1.9-0.beta2.2 - dependency fixes, obsoletes firefox < 3 and firefox-devel now zaptel-1.4.7.1-1.fc9 -------------------- * Thu Dec 20 2007 Jeffrey C. Ollie - 1.4.7.1-1 - Update to 1.4.7.1 - Drop upstreamed patch. Broken deps for i386 ---------------------------------------------------------- Miro - 1.0-2.fc9.i386 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.i386 requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 gxine - 0.5.11-14.fc9.i386 requires gecko-libs = 0:1.9b2pre kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- Miro - 1.0-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.x86_64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) gxine - 0.5.11-14.fc9.x86_64 requires gecko-libs = 0:1.9b2pre kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 gxine - 0.5.11-14.fc9.ppc requires gecko-libs = 0:1.9b2pre kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) gxine - 0.5.11-14.fc9.ppc64 requires gecko-libs = 0:1.9b2pre kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 From berrange at redhat.com Fri Dec 21 18:42:26 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 21 Dec 2007 18:42:26 +0000 Subject: Delays in package processing In-Reply-To: <20071221162517.GF8355@nostromo.devel.redhat.com> References: <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> Message-ID: <20071221184226.GD27601@redhat.com> On Fri, Dec 21, 2007 at 11:25:17AM -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I had hoped that common sense would prevail across our maintainers and > > that stable releases would be treated as such, stable releases not to > > be cheapened with lots of unnecessary updates just so that "users can > > get the latest stuff!". Unfortunately that doesn't seem to be what's > > happening. I don't want to introduce draconian policies and > > procedures to enforce this, mostly because there just isn't enough time > > in the day to supervise all the potential updates for whether they > > should go out or not. > > > > So I ask you, Fedora Community, how do we as a community ensure that > > our stable releases stay just that, stable? > > Well, it depends. For the stuff I maintain, I tend to follow different > policies depending on the package: > > - Library versions do not get upgraded in a stable release > - The more core a package is, it only gets updated with occasional > severe bugfixes - it is not ever rebased. > - More peripheral things, such as some desktop apps, get updated to > the latest minor bugfix version > > Hard to say how much this works for everyone, though. Not very well. I almost do the opposite with the virt stack We always upgrade libvirt in all supported Fedora releases because there is large demand for new virt features, but more importantly because upstream have strict rule that we never break ABI of the library, or syntax of the command line virsh tool. Occassionally there are bugs introduced, but on the whole upgrading all Fedora releases has brought in improved testing coverage & stability for all. Now for the GUI apps, I tend not to update existing releases to new versions, until the new version has been out in rawhide for at least several months & gotten positive feedback, because any UI changes are immediately noticed by people. Really what I'm saying is that the base library has very good stability across releases, while the UI layer is not so stable. So mandating that libraries are not upgraded, while perhipheral desktop apps can be upgraded is pretty much reverse of what is suitable for virt. 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 j.w.r.degoede at hhs.nl Fri Dec 21 18:46:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Dec 2007 19:46:41 +0100 Subject: Helping out with broken deps due to openssl changes Message-ID: <476C0A11.3060009@hhs.nl> Hi All, I noticed in todays rawhide report that there are still quite a few packages whcih are broken due to the openssl update. I know these are the non trivial rebuild cases. I would hereby like to offer to help. So anyone interested in receiving some help in getting their package(s) fixed? Regards, Hans From jkeating at redhat.com Fri Dec 21 18:51:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 13:51:24 -0500 Subject: Delays in package processing In-Reply-To: <20071221184226.GD27601@redhat.com> References: <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> Message-ID: <20071221135124.470ba99b@redhat.com> On Fri, 21 Dec 2007 18:42:26 +0000 "Daniel P. Berrange" wrote: > Really what I'm saying is that the base library has very good > stability across releases, while the UI layer is not so stable. So > mandating that libraries are not upgraded, while perhipheral desktop > apps can be upgraded is pretty much reverse of what is suitable for > virt. So I think you and Bill are accomplishing the same goal but with different steps involved. The commonality here is that you and Bill can take that goal and given the knowledge of the software you're working with use the appropriate steps to achieve the goal. How can we express the goal itself, rather than the methodology one might use to meet that goal? If we can express the goal, then we give maintainers the ability to determine how best to reach that goal with their own 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 cjdahlin at ncsu.edu Fri Dec 21 18:51:31 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Fri, 21 Dec 2007 13:51:31 -0500 Subject: This seems to be getting worse In-Reply-To: <476B67E8.9020002@gmail.com> References: <476ADBFD.40506@ncsu.edu> <20071220162852.39a9c478@hansolo.jdub.homelinux.org> <20071220193047.00248377@hansolo.jdub.homelinux.org> <1198212999.3486.28.camel@localhost> <476B67E8.9020002@gmail.com> Message-ID: <476C0B33.5040600@ncsu.edu> Andrew Farris wrote: > Callum Lerwick wrote: > >> On Thu, 2007-12-20 at 19:30 -0600, Josh Boyer wrote: >> >>>>> It now shows me a 403. Guess I missed the party. >>>>> >>>> http://jwboyer.fedoraproject.org/Screenshot.png >>>> >>> Grr. Make that http://jwboyer.fedorapeople.org/Screenshot.png >>> >> Those felines aren't even wet! >> > > Are felines supposed to be? > > Mmm...kitty From jwboyer at gmail.com Fri Dec 21 18:56:06 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 21 Dec 2007 12:56:06 -0600 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <476BF256.1060909@nicubunu.ro> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> Message-ID: <20071221125606.42247362@hansolo.jdub.homelinux.org> On Fri, 21 Dec 2007 19:05:26 +0200 Nicu Buculei wrote: > Josh Boyer wrote: > > On Tue, 18 Dec 2007 07:27:09 -0600 > > Josh Boyer wrote: > > > >> I will be collecting suggestions for 1 week so the cutoff for names is: > >> > >> December 25, 2007 > > > > We're off to a great start so far. Given the various vacation > > schedules of people, we're extending the cutoff for name suggestions to: > > > > Jan 1, 2008 > > OK. > Probably the Art Team will not be able to make use of the name as we > have a deadline for Round 1 in 8 January. We may delay it a bit (a week > or so) but not much, and the legal clearing and community vote will take > some additional time. The rest of the schedule didn't change. Lawyers take vacation too, so sending them a list of names the day after Christmas would have the exact same results as sending it to them on Jan 2. If legal can turn around the name list sooner than planned, we can move the vote up as well. We tried to make it easier for the Art team, we really did. Pesky holidays. josh From jspaleta at gmail.com Fri Dec 21 18:59:06 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 09:59:06 -0900 Subject: Delays in package processing In-Reply-To: <20071221135124.470ba99b@redhat.com> References: <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> Message-ID: <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> On Dec 21, 2007 9:51 AM, Jesse Keating wrote: > So I think you and Bill are accomplishing the same goal but with > different steps involved. The commonality here is that you and Bill > can take that goal and given the knowledge of the software you're > working with use the appropriate steps to achieve the goal. > > How can we express the goal itself, rather than the methodology one > might use to meet that goal? If we can express the goal, then we give > maintainers the ability to determine how best to reach that goal with > their own software. Isn't the goal to maximize the ratio of potential benefit to potential detriment with each update? How do we help individual maintainers get a good handle on that ratio? And how do we guage if there is a problem in some area in the repository with regard to this goal? It's pretty difficult to make a relative comparison from one software stack to another for different components and know whose doing better at keeping the ratio maximized. -jef From jspaleta at gmail.com Fri Dec 21 19:09:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 10:09:01 -0900 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <20071221125606.42247362@hansolo.jdub.homelinux.org> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> Message-ID: <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> On Dec 21, 2007 9:56 AM, Josh Boyer wrote: > We tried to make it easier for the Art team, we really did. Pesky > holidays. Just remember.. a vote for me for Galactic President is a vote for the abolishment of seasonal holidays and an establishment of the 8 day week (4 work days and a 4 day weekend.) -jef"crap I'm gonna miss tonight's winter solstice fireworks because I'll be curling"spaleta From pemboa at gmail.com Fri Dec 21 19:14:24 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Dec 2007 13:14:24 -0600 Subject: Fedora 8 review In-Reply-To: <476BD268.1050009@hhs.nl> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> Message-ID: <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> On Dec 21, 2007 8:49 AM, Hans de Goede wrote: > Valent Turkovic wrote: > > Hi, I listened to Linux Action Show and I really liked their review of > > Fedora 8. I believe that this is something Fedora users but also > > Fedora devels should listen. > > > > They give Fedora 8 a really hard but IMHO realistic review, so please > > listen to it. > > > > You can hear the clip with the review part of the podcast here: > > http://kernelreloaded.blog385.com/index.php/archives/fedora-8-audio-review/ > > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review.ogg > > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review_64kb.mp3 > > > > or you can listen the whole podcast here: > > http://www.linuxactionshow.com/?p=158 (Ogg version) > > http://www.linuxactionshow.com/?p=157 (MP3 version) > > > > Valent. > > Any chance you can write up a good summary? Esp a list of points which > they say need improvement, and you agree with, and which we are actually > capable of improving (iow not support mp3 please, etc.). > > regards, > > Hans Just the negatives: * well they didn't seem to like the Gnome theme at all * they kept making references to "Win2k" and "XP" * lack of gradients in notifications * anaconda - look is bland * anaconda - partitioning screen unintuitive * anaconda - not ready for average users (term wtf used) * anaconda makes assumptions about knowledge (I happen to think that anaconda should ask questions myself and alter UI accordingly) * live cd installer has 100% failure rate (failed at formatting portioning due to trying to copy files _during_ formatting) * really stressed how much live cd installer didn't work * by installation phase, was of the opinion that Fedora is the least polished distro currently * yum/pup still slow, but not as slow * grub screen ugly as sin, especially when followed up by rhgb (made reviewer grumpy) * Gnome online desktop - "not great" but probably "not ready for evaluation" * feels that Fedora still has an identity crisis: stuck between server and desktop * feels that if Fedora is just a proving ground, why should people use it at all other than for testing * reviewer(s) spent 2 weeks with Fedora before review, but will not keep it * reviewer(s) felt that other reviews were too lenient All in all really Gnome specific, so I have little to know opinion on it. Their sum opinion is that Fedora is only suited as a test platform - not as a server, not a desktop. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From skvidal at fedoraproject.org Fri Dec 21 19:13:37 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Dec 2007 14:13:37 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> Message-ID: <1198264417.23261.21.camel@cutter> On Fri, 2007-12-21 at 10:09 -0900, Jeff Spaleta wrote: > On Dec 21, 2007 9:56 AM, Josh Boyer wrote: > > We tried to make it easier for the Art team, we really did. Pesky > > holidays. > > Just remember.. a vote for me for Galactic President is a vote for the > abolishment of seasonal holidays and an establishment of the 8 day > week (4 work days and a 4 day weekend.) > > -jef"crap I'm gonna miss tonight's winter solstice fireworks because > I'll be curling"spaleta cmon, jef, put the rock in the house! -sv From smooge at gmail.com Fri Dec 21 19:20:03 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 21 Dec 2007 12:20:03 -0700 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198264417.23261.21.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> <1198264417.23261.21.camel@cutter> Message-ID: <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> On Dec 21, 2007 12:13 PM, seth vidal wrote: > > On Fri, 2007-12-21 at 10:09 -0900, Jeff Spaleta wrote: > > On Dec 21, 2007 9:56 AM, Josh Boyer wrote: > > > We tried to make it easier for the Art team, we really did. Pesky > > > holidays. > > > > Just remember.. a vote for me for Galactic President is a vote for the > > abolishment of seasonal holidays and an establishment of the 8 day > > week (4 work days and a 4 day weekend.) > > > > -jef"crap I'm gonna miss tonight's winter solstice fireworks because > > I'll be curling"spaleta > > cmon, jef, put the rock in the house! > I thought you were supposed to use a live rattlesnake when curling.. and you were judged by how frozen the snake was at the end of its run.. and how unpoisoned you were. -- 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 jspaleta at gmail.com Fri Dec 21 19:21:24 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 10:21:24 -0900 Subject: Fedora 8 review In-Reply-To: <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> Message-ID: <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> On Dec 21, 2007 10:14 AM, Arthur Pemberton wrote: > * live cd installer has 100% failure rate (failed at formatting > portioning due to trying to copy files _during_ formatting) > * really stressed how much live cd installer didn't work I guess that averages out to 50% failure rate if you take my livecd installs into account. Where these common filed issued that I'm not aware of? Or was this some sort of hiccup that we don't have reproducible reports for? -jef From debarshi.ray at gmail.com Fri Dec 21 19:22:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 22 Dec 2007 00:52:03 +0530 Subject: Delays in package processing In-Reply-To: <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> References: <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> Message-ID: <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> Have been reading this discussion with avid interest, and I would really like to see respins of a stable Fedora release. Personally I delay installing a new release on my machines till some of the common bugs have been detected to avoid any major regression. But recently I hit a installer bug on my MacBook for Fedora 8, and although it was documented in the Wiki, there is no way one can benefit much without a respin. However I do not know how much painful and extra burden this will be for the release team, but if we can atleast have a respin for critical kernel and installer fixes/improvements, it would be super. Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From pemboa at gmail.com Fri Dec 21 19:25:33 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Dec 2007 13:25:33 -0600 Subject: Fedora 8 review In-Reply-To: <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> Message-ID: <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> On Dec 21, 2007 1:21 PM, Jeff Spaleta wrote: > On Dec 21, 2007 10:14 AM, Arthur Pemberton wrote: > > * live cd installer has 100% failure rate (failed at formatting > > portioning due to trying to copy files _during_ formatting) > > * really stressed how much live cd installer didn't work > > I guess that averages out to 50% failure rate if you take my livecd > installs into account. > Where these common filed issued that I'm not aware of? Or was this > some sort of hiccup that we don't have reproducible reports for? > > -jef Well from memory of the reviewers statements he tried combinations of the following options: * native/VM * customized/customized * target drive partitioned / unpartitioned * different physical machines -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Fri Dec 21 19:26:06 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 10:26:06 -0900 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> <1198264417.23261.21.camel@cutter> <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> Message-ID: <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> On Dec 21, 2007 10:20 AM, Stephen John Smoogen wrote: > I thought you were supposed to use a live rattlesnake when curling.. > and you were judged by how frozen the snake was at the end of its > run.. and how unpoisoned you were. Snakes don't live here natively. In fact I'm not sure there is any animal up here that could be considered poisonous... unless you consider bear claws toxic. -jef"haven't seen a moose in town yet since it turned cold. The one who slept in my backyard last winter seems to have left for better digs."spaleta From jkeating at redhat.com Fri Dec 21 19:49:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 14:49:58 -0500 Subject: Delays in package processing In-Reply-To: <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> References: <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> Message-ID: <20071221144958.510a456e@redhat.com> On Sat, 22 Dec 2007 00:52:03 +0530 "Debarshi 'Rishi' Ray" wrote: > However I do not know how much painful and extra burden this will be > for the release team, but if we can atleast have a respin for critical > kernel and installer fixes/improvements, it would be super. See Fedora Unity. -- 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 Fri Dec 21 19:53:20 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 22 Dec 2007 01:23:20 +0530 Subject: Delays in package processing In-Reply-To: <20071221144958.510a456e@redhat.com> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <20071221144958.510a456e@redhat.com> Message-ID: <3170f42f0712211153i453db332l6f32d929f9e9c238@mail.gmail.com> >> However I do not know how much painful and extra burden this will be >> for the release team, but if we can atleast have a respin for critical >> kernel and installer fixes/improvements, it would be super. > See Fedora Unity. I am aware of them, but was told that those are not "official Fedora" releases. Can we do this within Fedora itself? Or would that be too much of a pain? Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From jspaleta at gmail.com Fri Dec 21 19:54:29 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 10:54:29 -0900 Subject: Fedora 8 review In-Reply-To: <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> Message-ID: <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> On Dec 21, 2007 10:25 AM, Arthur Pemberton wrote: > Well from memory of the reviewers statements he tried combinations of > the following options: > > * native/VM > * customized/customized > * target drive partitioned / unpartitioned > * different physical machines Does ANY of this translate to filed bugs from other people experiencing the same issues? Do we have any additional reports. I'll let you in on a little secret. The number one thing I absolutely LOATH with regard to linux operating system reviewers is the absolutely lack of any effort for them to drive their problems into the bug reporting systems so they can get a reasonable look and then fixed. The next rant is aimed at every single reviewer on in the laypress and not to these people specifically. What I write below is my personal reaction to what I see as a generally negative influence on linux distributions in general by laypress reviewers in general. SHAME ON ALL OF THEM for sensationalizing the problems while standing in their self righous pulpit on top of thier little ant hill, instead of participating in a transparent open process that can be used to start driving fixes for things. It helps noone to sit on this problems, without filing them. Every single reviewer who does this sort of crap, and doesn't reference a live bug ticket associated with each an every hardware problem is a drag on the system for EVERY openly developed distribution out there, not just Fedora. They represent a culture where the user is a consumer and not a culture where the user is a collaborator. Fedora isn't a product that we are selling, its a process by which developers and users come together to get shit done. Its a fact, we're gonna see hardware problems interspersed in the wild. We will never be 100% free of hardware bugs...ever. And I want reviewers to be honest about the problems. If they have problems I want them to write about them, because its a reality check. But reviewers need to cooperate with us as part of the open process and actually reference bug tickets corresponding each and every serious problem in their reviews, readers/viewers/listeners know exactly where to go to look for solutions to these problems as they are developed. If reviewers actually cared about open development in any significant way (without introducing bias into their evaluations of any particular distribution), they will all start to reference bug report tickets for every hardware problem or crasher problem when they talk about them in their reviews. We can all agree that hardware problems or crasher problems are worth filing. UI issues are tougher to get consensous on. I hereby make this a personal challenge to every single laypress reviewer out there. Stop sensationalizing problems, and start helping your readers appreciate the value of participating in open development by being role models on how to interact with developers to file issues. You can't participate like this for other software, stop squandering the opportunity to help users to see the opportunity to have an impact on the software they are using. -jef From jkeating at redhat.com Fri Dec 21 20:00:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Dec 2007 15:00:46 -0500 Subject: Delays in package processing In-Reply-To: <3170f42f0712211153i453db332l6f32d929f9e9c238@mail.gmail.com> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <20071221144958.510a456e@redhat.com> <3170f42f0712211153i453db332l6f32d929f9e9c238@mail.gmail.com> Message-ID: <20071221150046.5097a0d3@redhat.com> On Sat, 22 Dec 2007 01:23:20 +0530 "Debarshi 'Rishi' Ray" wrote: > I am aware of them, but was told that those are not "official Fedora" > releases. Can we do this within Fedora itself? Or would that be too > much of a pain? It's a very large task to take on, and mostly would have to be done by those that are trying to get the /next/ release ready. -- 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 smooge at gmail.com Fri Dec 21 20:08:41 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 21 Dec 2007 13:08:41 -0700 Subject: Fedora 8 review In-Reply-To: <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> Message-ID: <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> On Dec 21, 2007 12:54 PM, Jeff Spaleta wrote: > I hereby make this a personal challenge to every single laypress > reviewer out there. Stop sensationalizing problems, and start helping > your readers appreciate the value of participating in open development > by being role models on how to interact with developers to file > issues. You can't participate like this for other software, stop > squandering the opportunity to help users to see the opportunity to > have an impact on the software they are using. > But.. but.. but... you are going to completely make sensational press not a money maker. If John Dvorak, ESR, etc can't stand around yelling about how something sucks because it didnt fit their little world view.. how are they going to sell ads, books, or t-shirts? -- 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 jspaleta at gmail.com Fri Dec 21 20:19:04 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 11:19:04 -0900 Subject: Delays in package processing In-Reply-To: <3170f42f0712211153i453db332l6f32d929f9e9c238@mail.gmail.com> References: <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <20071221144958.510a456e@redhat.com> <3170f42f0712211153i453db332l6f32d929f9e9c238@mail.gmail.com> Message-ID: <604aa7910712211219m244e0d8fr7a121401e76e6f13@mail.gmail.com> On Dec 21, 2007 10:53 AM, Debarshi 'Rishi' Ray wrote: > I am aware of them, but was told that those are not "official Fedora" > releases. Can we do this within Fedora itself? Or would that be too > much of a pain? How important is "official" to you? And what does "official" actually mean? Is there no room for very active Fedora community groups to take ownership for some of the technical services to provide an overall wider set of services? If Fedora as a project started making the re-spins instead of Unity, aren't we essential taking control away from them for doing a good job and providing a popular service? Is that necessarily the best thing to do for the overall health of the community? My understanding is the Re-spins are built using all Fedora built packages. But because they don't go through the same release-eng process as our gold releases, they aren't "Official." If they went through they same process...they'd be gold releases and not re-spins and would take as as much (or close) effort to put together as a gold release. So overall the Re-spins are some sort of middle ground that we as a Project don't really know how to position in our offerings. We care and stress the importance of the release process that leads to gold releases. We want people to make use of those releases exactly because we know more about how those packages interact together as compared to updated packages. But at the same time we know Re-spins have value for people who are bitten by bugs in the gold releases, or who want to save band by not having to download packages twice. We also like the fact Unity is out there breaking trails doing innovative stuff, self organization of community to drive innovation isn't a bad thing. So we have to be careful and deliberate about how we deal with re-spins. We want to craft a message that says, gold releases are what we prefer you use because we believe in the process leading up to those releases, but re-spins are a value-added option provided by our innovative community that we have absolutely no problems with you trying, but we can't vouch for as strongly as the gold releases. Personally I think the re-spins are a fabulous service that Unity is offering. Have I ever used them, nope.... not once... I'm an early adopter and active tester leading up to the gold releases. So I'm exactly the person a re-spin doesn't have a lot of value for. -jef From jspaleta at gmail.com Fri Dec 21 20:19:58 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 11:19:58 -0900 Subject: Fedora 8 review In-Reply-To: <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> Message-ID: <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> On Dec 21, 2007 11:08 AM, Stephen John Smoogen wrote: > But.. but.. but... you are going to completely make sensational press > not a money maker. If John Dvorak, ESR, etc can't stand around yelling > about how something sucks because it didnt fit their little world > view.. how are they going to sell ads, books, or t-shirts? Yell all you want, just reference the corresponding tickets next to the rant. -jef From cjdahlin at ncsu.edu Fri Dec 21 20:32:46 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Fri, 21 Dec 2007 15:32:46 -0500 Subject: Fedora 8 review In-Reply-To: <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> Message-ID: <476C22EE.3030807@ncsu.edu> Jeff Spaleta wrote: > On Dec 21, 2007 11:08 AM, Stephen John Smoogen wrote: > >> But.. but.. but... you are going to completely make sensational press >> not a money maker. If John Dvorak, ESR, etc can't stand around yelling >> about how something sucks because it didnt fit their little world >> view.. how are they going to sell ads, books, or t-shirts? >> > > Yell all you want, just reference the corresponding tickets next to the rant. > > -jef > > Does this all mean we aren't going to attempt to find and fix these problems? From sundaram at fedoraproject.org Fri Dec 21 20:33:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 22 Dec 2007 02:03:04 +0530 Subject: Fedora 8 review In-Reply-To: <476C22EE.3030807@ncsu.edu> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> <476C22EE.3030807@ncsu.edu> Message-ID: <476C2300.2020704@fedoraproject.org> Casey Dahlin wrote: > Jeff Spaleta wrote: >> On Dec 21, 2007 11:08 AM, Stephen John Smoogen wrote: >> >>> But.. but.. but... you are going to completely make sensational press >>> not a money maker. If John Dvorak, ESR, etc can't stand around yelling >>> about how something sucks because it didnt fit their little world >>> view.. how are they going to sell ads, books, or t-shirts? >>> >> >> Yell all you want, just reference the corresponding tickets next to >> the rant. >> >> -jef >> >> > Does this all mean we aren't going to attempt to find and fix these > problems? How do you expect anyone to fix the problems without even knowing what the problems are? Mails asking for more details went unanswered BTW. Rahul From alan at clueserver.org Fri Dec 21 20:46:30 2007 From: alan at clueserver.org (Alan) Date: Fri, 21 Dec 2007 12:46:30 -0800 (PST) Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> <1198264417.23261.21.camel@cutter> <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> Message-ID: <31843.198.182.194.170.1198269990.squirrel@clueserver.org> > On Dec 21, 2007 10:20 AM, Stephen John Smoogen wrote: >> I thought you were supposed to use a live rattlesnake when curling.. >> and you were judged by how frozen the snake was at the end of its >> run.. and how unpoisoned you were. > > Snakes don't live here natively. In fact I'm not sure there is any > animal up here that could be considered poisonous... unless you > consider bear claws toxic. Some types of Mosquitos are poisonous. (Whitesocks?) Bear claws are only toxic if you are a diabetic. > > -jef"haven't seen a moose in town yet since it turned cold. The one > who slept in my backyard last winter seems to have left for better > digs."spaleta My sister was once bitten by a moose. From cjdahlin at ncsu.edu Fri Dec 21 20:44:24 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Fri, 21 Dec 2007 15:44:24 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> <1198264417.23261.21.camel@cutter> <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> Message-ID: <476C25A8.3080303@ncsu.edu> Jeff Spaleta wrote: > On Dec 21, 2007 10:20 AM, Stephen John Smoogen wrote: > >> I thought you were supposed to use a live rattlesnake when curling.. >> and you were judged by how frozen the snake was at the end of its >> run.. and how unpoisoned you were. >> > > Snakes don't live here natively. In fact I'm not sure there is any > animal up here that could be considered poisonous... unless you > consider bear claws toxic. > > -jef"haven't seen a moose in town yet since it turned cold. The one > who slept in my backyard last winter seems to have left for better > digs."spaleta > > They are, as are many things. For example, gravity is toxic in large enough doses, and water is toxic if inhaled. From jspaleta at gmail.com Fri Dec 21 20:50:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 11:50:57 -0900 Subject: Fedora 8 review In-Reply-To: <476C22EE.3030807@ncsu.edu> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> <476C22EE.3030807@ncsu.edu> Message-ID: <604aa7910712211250n73884175k30a1a9d795cd832f@mail.gmail.com> On Dec 21, 2007 11:32 AM, Casey Dahlin wrote: > Does this all mean we aren't going to attempt to find and fix these > problems? Hardware issues are HARD, primarily because we have to look closely for reproducibly situations. I used the live cd on at least 3 different hardware configurations, two desktops and a laptop... workedforme. My effort to 'find' a livecd install problem failed to produce a problem. should I now right a review and say that based on my experience the livecd installer process is bulletproof? I mean I'm pretty much just as justified to do that. But it would be just as misleading. Hardware bugs are HARD and we need people reporting reproducible hardware failures so the right developers who do not have access to that hardware can start a dialog with the people who do. it doesn't get better people just stand on their soapbox and beat their chests in their little corner of the internet. The bug trackers are were dialog happens. The reviewers as a breed know this, and they avoid doing it deliberately. if a reviewer isn't at a minimum references an bug ticker for each crasher or hardware problem they have expressed, they simply do not care about open development. If I thought a boycott against such reviewers would actually be effective id call for one. But the reality is, their target readership are the people who do not actually understand what open development is actual about. So a boycott of the open-savvy readership won't do anything. What we can do however is start filling up all the talkbacks and comments sections we can find..demanding they start referencing bug ticket numbers for ALL openly developed software which they review. This isn't a Fedora specific thing. This is an open development thing. Everytime a reviewer fails to reference a bug ticket for a critical problem, we've miss an opportunity to show a user that open source development is responsive in a way that closed development can never be. -jef From james.antill at redhat.com Fri Dec 21 20:55:08 2007 From: james.antill at redhat.com (James Antill) Date: Fri, 21 Dec 2007 15:55:08 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <476C25A8.3080303@ncsu.edu> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <20071221104532.36ad41dc@hansolo.jdub.homelinux.org> <476BF256.1060909@nicubunu.ro> <20071221125606.42247362@hansolo.jdub.homelinux.org> <604aa7910712211109s6afd0f34q4585ab4220c215c7@mail.gmail.com> <1198264417.23261.21.camel@cutter> <80d7e4090712211120q7a1944f3xaf4cb8ace9ec73b0@mail.gmail.com> <604aa7910712211126m32fe74bcodbd575603370eacb@mail.gmail.com> <476C25A8.3080303@ncsu.edu> Message-ID: <1198270508.3860.2.camel@code.and.org> On Fri, 2007-12-21 at 15:44 -0500, Casey Dahlin wrote: > For example, gravity is toxic in large enough doses, and water is toxic > if inhaled. Actually water is just plain toxic, if you drink enough of it: http://en.wikipedia.org/wiki/Water_intoxication -- 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 rhallyx at mindspring.com Fri Dec 21 21:02:23 2007 From: rhallyx at mindspring.com (richard hally) Date: Fri, 21 Dec 2007 16:02:23 -0500 Subject: kernel problem in todays rawhide update Message-ID: <476C29DF.4050907@mindspring.com> While running yum update for todays rawhide update the following error occured: Updating : glib2-devel ####################### [34/75] Updating : dvipng ####################### [35/75] Installing: kernel ####################### [36/75] /sbin/new-kernel-pkg: line 254: /sbin/depmod: Permission denied nash received SIGSEGV! Backtrace (11): /sbin/nash[0x805315a] [0x110440] /lib/libglib-2.0.so.0[0x2d91a3] /usr/lib/libbdevid.so.6.0.24(bdevid_module_unload_all+0x31)[0x6cae37] /usr/lib/libbdevid.so.6.0.24(bdevid_destroy+0x2d)[0x6ca57c] /usr/lib/libnash.so.6.0.24[0x6a8198] /usr/lib/libnash.so.6.0.24(nash_vitals_destroy_probes+0x3f)[0x6a8810] /usr/lib/libnash.so.6.0.24(_nashFreeContext+0x1c)[0x698fd6] /sbin/nash[0x80536f4] /lib/libc.so.6(__libc_start_main+0xe0)[0x99d4a0] /sbin/nash[0x804ae71] -----------end------------- And nothing further, not even a prompt. After a ctrl-c, the following: error: %post(kernel-2.6.24-0.118.rc5.git6.fc9.i686) scriptlet failed, signal 2 [root at localhost ~]# What up? Richard From notting at redhat.com Fri Dec 21 21:21:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 21 Dec 2007 16:21:16 -0500 Subject: kernel problem in todays rawhide update In-Reply-To: <476C29DF.4050907@mindspring.com> References: <476C29DF.4050907@mindspring.com> Message-ID: <20071221212116.GC25435@nostromo.devel.redhat.com> richard hally (rhallyx at mindspring.com) said: > What up? Known issue, should be fixed tomorrow. Bill From rhally at mindspring.com Fri Dec 21 21:28:08 2007 From: rhally at mindspring.com (Richard Hally) Date: Fri, 21 Dec 2007 16:28:08 -0500 Subject: kernel problem in todays rawhide update In-Reply-To: <20071221212116.GC25435@nostromo.devel.redhat.com> References: <476C29DF.4050907@mindspring.com> <20071221212116.GC25435@nostromo.devel.redhat.com> Message-ID: <476C2FE8.1060601@mindspring.com> Bill Nottingham wrote: > richard hally (rhallyx at mindspring.com) said: >> What up? > > Known issue, should be fixed tomorrow. > > Bill > Thanks Bill. Merry Christmas everyone! Richard From janina at rednote.net Fri Dec 21 22:48:11 2007 From: janina at rednote.net (Janina Sajka) Date: Fri, 21 Dec 2007 17:48:11 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <20071221224811.GA14303@rednote.net> Martin Stransky writes: > Hello, > > Firefox 3 has finally landed in Rawhide. Oh, there really is a Santa! O frabjous day! Callooh! Callay! Janina From ml at deadbabylon.de Fri Dec 21 23:31:48 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sat, 22 Dec 2007 00:31:48 +0100 Subject: Fedora 8 review In-Reply-To: <604aa7910712211250n73884175k30a1a9d795cd832f@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476C22EE.3030807@ncsu.edu> <604aa7910712211250n73884175k30a1a9d795cd832f@mail.gmail.com> Message-ID: <200712220031.57945.ml@deadbabylon.de> Am Fr 21.Dezember 2007 schrieb Jeff Spaleta: > hardware > bugs are HARD and we need people reporting reproducible hardware > failures so the right developers who do not have access to that > hardware can start a dialog with the people who do. ?it doesn't get > better people just stand on their soapbox and beat their chests in > their little corner of the internet. ?The bug trackers are were dialog > happens. So what about releasing a top10 or top5 list of those bugs to fedora-test-list? Bugs, that are hard to track or repoduce. There maybe more people out there who could reproduce those bugs but haven't encountered them yet. ATM those bugs are limited to the people who are aware of them (mostly reporters and of course the assignees). Sebastian -------------- 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 Dec 21 23:49:07 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Dec 2007 14:49:07 -0900 Subject: Fedora 8 review In-Reply-To: <200712220031.57945.ml@deadbabylon.de> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476C22EE.3030807@ncsu.edu> <604aa7910712211250n73884175k30a1a9d795cd832f@mail.gmail.com> <200712220031.57945.ml@deadbabylon.de> Message-ID: <604aa7910712211549u588c8347l5fbf5d0fcebc9cdc@mail.gmail.com> On Dec 21, 2007 2:31 PM, Sebastian Vahl wrote: > So what about releasing a top10 or top5 list of those bugs to > fedora-test-list? Bugs, that are hard to track or repoduce. There maybe more > people out there who could reproduce those bugs but haven't encountered them > yet. ATM those bugs are limited to the people who are aware of them (mostly > reporters and of course the assignees). We have a CommonProblems page right now http://fedoraproject.org/wiki/Bugs/F8Common is that what you are looking for? But if we had reviewers doing their part and referencing bug tickets..it'd be pretty easy to compile an even better version of this page, just by reading reviews and seeing what reviewers ran into... if they actually cross-referenced tickets. But unless they are cross-referencing tickets they aren't generating this sort of community value in their editorial comments. I don't mind them point out the flaws that made it past testing, but they need to help us close the loop so we can get affected users the fixes and workarounds for those issues. I'd love to give reviewers credit for finding install problems and helping point people to resources to fix/workaround the issue, but right now its just not something they generally care about. Reviewers generally do not care about helping the open development process for any open project. -jef From jonathan.underwood at gmail.com Fri Dec 21 23:49:33 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 21 Dec 2007 23:49:33 +0000 Subject: LSB compliant init file In-Reply-To: <1198260049.2839.4.camel@bureau.maison> References: <1198260049.2839.4.camel@bureau.maison> Message-ID: <645d17210712211549u3e9858a7odd3d93bc3aebc447@mail.gmail.com> On 21/12/2007, Tanguy Eric wrote: > I know http://fedoraproject.org/wiki/FCNewInit/Initscripts but i'm > looking for a simple example in a package which is already LSB > compliant. > Thanks Have a look at the shorewall packages - in the move to version 4 I updated the init scripts to be LSB compliant. From ml at deadbabylon.de Fri Dec 21 23:56:13 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sat, 22 Dec 2007 00:56:13 +0100 Subject: Fedora 8 review In-Reply-To: <604aa7910712211549u588c8347l5fbf5d0fcebc9cdc@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <200712220031.57945.ml@deadbabylon.de> <604aa7910712211549u588c8347l5fbf5d0fcebc9cdc@mail.gmail.com> Message-ID: <200712220056.13455.ml@deadbabylon.de> Am Sa 22.Dezember 2007 schrieb Jeff Spaleta: > On Dec 21, 2007 2:31 PM, Sebastian Vahl wrote: > > So what about releasing a top10 or top5 list of those bugs to > > fedora-test-list? Bugs, that are hard to track or repoduce. There maybe > > more people out there who could reproduce those bugs but haven't > > encountered them yet. ATM those bugs are limited to the people who are > > aware of them (mostly reporters and of course the assignees). > > We have a CommonProblems page right now > http://fedoraproject.org/wiki/Bugs/F8Common > is that what you are looking for? > > But if we had reviewers doing their part and referencing bug > tickets..it'd be pretty easy to compile an even better version of this > page, just by reading reviews and seeing what reviewers ran into... if > they actually cross-referenced tickets. But unless they are > cross-referencing tickets they aren't generating this sort of > community value in their editorial comments. I don't mind them point > out the flaws that made it past testing, but they need to help us > close the loop so we can get affected users the fixes and workarounds > for those issues. I'd love to give reviewers credit for finding > install problems and helping point people to resources to > fix/workaround the issue, but right now its just not something they > generally care about. Reviewers generally do not care about helping > the open development process for any open project. > > -jef No. I've misread your mail a bit and was suggesting a top5 list of current rawhide hardware bugs which are hard to reproduce. With such a list these bugs could get more audience by other testers. Sry, this was a bit off topic. Sebastian -------------- 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 valent.turkovic at gmail.com Sat Dec 22 00:27:07 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Dec 2007 01:27:07 +0100 Subject: Fedora 8 review In-Reply-To: <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> Message-ID: <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> On 12/21/07, Arthur Pemberton wrote: > On Dec 21, 2007 8:49 AM, Hans de Goede wrote: > > Valent Turkovic wrote: > > > Hi, I listened to Linux Action Show and I really liked their review of > > > Fedora 8. I believe that this is something Fedora users but also > > > Fedora devels should listen. > > > > > > They give Fedora 8 a really hard but IMHO realistic review, so please > > > listen to it. > > > > > > You can hear the clip with the review part of the podcast here: > > > http://kernelreloaded.blog385.com/index.php/archives/fedora-8-audio-review/ > > > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review.ogg > > > http://www.archive.org/download/Fedora8ReviewlinuxActionShowEp067/Linuxactionshowep067-Fedora8Review_64kb.mp3 > > > > > > or you can listen the whole podcast here: > > > http://www.linuxactionshow.com/?p=158 (Ogg version) > > > http://www.linuxactionshow.com/?p=157 (MP3 version) > > > > > > Valent. > > > > Any chance you can write up a good summary? Esp a list of points which > > they say need improvement, and you agree with, and which we are actually > > capable of improving (iow not support mp3 please, etc.). > > > > regards, > > > > Hans > > > Just the negatives: Well they didn't say only the negative things, because as they say they still love and use fedora. You should really listen to this part of the podcast (20 minutes) > > * well they didn't seem to like the Gnome theme at all > * they kept making references to "Win2k" and "XP" I totally agree with them regarding Fedora 8 graphics look, and the wallpaper. No matter what you say but users judge desktops on how they look. You could argue with Fedora 7 looks vs Fedora Core 6 looks if you like one more that the other regarding your personal taste, but Fedora 8 wallpaper and complete look it really beneath the previously high quality standards brought by FC6 and F7. When I first saw F8 infnity theme on some wiki or a blog I looked at it and thought to myself "Not bad first attempt" because it looked only as someones first attempt which was obvious that wouldn't pass quality check... But I was suprise when I booted F8 for the first time and saw the same wallpaper, I was really shocked... Valent. -- 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 marc at mwiriadi.id.au Sat Dec 22 00:43:10 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sat, 22 Dec 2007 09:43:10 +0900 Subject: Fedora 8 review In-Reply-To: <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> Message-ID: <1198284190.7443.79.camel@study.mwiriadi.id.au> > > I totally agree with them regarding Fedora 8 graphics look, and the > wallpaper. No matter what you say but users judge desktops on how they > look. You could argue with Fedora 7 looks vs Fedora Core 6 looks if > you like one more that the other regarding your personal taste, but > Fedora 8 wallpaper and complete look it really beneath the previously > high quality standards brought by FC6 and F7. > > When I first saw F8 infnity theme on some wiki or a blog I looked at > it and thought to myself "Not bad first attempt" because it looked > only as someones first attempt which was obvious that wouldn't pass > quality check... But I was suprise when I booted F8 for the first time > and saw the same wallpaper, I was really shocked... > > Valent. > By the same token a lot of people really like it as well. One of the things I have noticed is that with themes is that everyone has a different taste. Personally I loved the DNA theme and disliked the baloons, the latest theme to me is brilliant. Cheers, Marc From jonathan.roberts.uk at googlemail.com Sat Dec 22 00:44:30 2007 From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts) Date: Sat, 22 Dec 2007 00:44:30 +0000 Subject: Fedora 8 review In-Reply-To: <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> Message-ID: <1198284270.2749.8.camel@localhost.localdomain> > I totally agree with them regarding Fedora 8 graphics look, and the > wallpaper. No matter what you say but users judge desktops on how they > look. You could argue with Fedora 7 looks vs Fedora Core 6 looks if > you like one more that the other regarding your personal taste, but > Fedora 8 wallpaper and complete look it really beneath the previously > high quality standards brought by FC6 and F7. Heh I hate to tell you but all art is subjective, and so Fedora 8's wallpaper and complete look are both subjective as well :p Take for example: Distrowatch on Fedora: "Its new artwork team in particular deserves high marks for its work..." and a few comments from the digg story about Fedora 8's artwork: "This **** is great! I want Fedora!" "this is much better than the current hot air balloons, thanks!" I'm sure there are just as many negative opinions out there - but it is subjective!! The same goes for the rest of this review: for every thing they commented on as being negative and not working, another review has commented on as being positive and working brilliantly! Of course, I agree with everything Jef said, if they want to point out something that's not working, by all means do it, but do it in a way that helps it get fixed!! Otherwise, why bother working in a field where openness and collaboration are the central points?! Jef, I think we should try and get your e-mail somewhere where reviewers are actually going to see it... Best, Jon From loupgaroublond at gmail.com Sat Dec 22 01:19:50 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 21 Dec 2007 20:19:50 -0500 Subject: Fedora 8 review In-Reply-To: <1198284270.2749.8.camel@localhost.localdomain> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> Message-ID: <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> On Dec 21, 2007 7:44 PM, Jonathan Roberts wrote: > Take for example: > > Distrowatch on Fedora: > > "Its new artwork team in particular deserves high marks for its work..." > > and a few comments from the digg story about Fedora 8's artwork: > > "This **** is great! I want Fedora!" > > "this is much better than the current hot air balloons, thanks!" Let's not forget the moment where I'm standing in front of a class about to give a presentation, and I have to reboot because I can't get X to recognize the projector without that. We're waiting for it to reboot, and I start telling them stories about how the Fedora Art team works, and just keeping people interested until I start the presentation. Let's see someone using Wintendo do that :P -Yaakov From lordmorgul at gmail.com Sat Dec 22 02:27:02 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 21 Dec 2007 18:27:02 -0800 Subject: Fedora 8 review In-Reply-To: <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> Message-ID: <476C75F6.9000009@gmail.com> Arthur Pemberton wrote: > * Gnome online desktop - "not great" but probably "not ready for evaluation" > * feels that Fedora still has an identity crisis: stuck between > server and desktop > * feels that if Fedora is just a proving ground, why should people > use it at all other than for testing > * reviewer(s) spent 2 weeks with Fedora before review, but will not keep it > * reviewer(s) felt that other reviews were too lenient > > > All in all really Gnome specific, so I have little to know opinion on > it. Their sum opinion is that Fedora is only suited as a test platform > - not as a server, not a desktop. Sounds like all things considered that F8 was a success by this review. Expecting Fedora to be 'polished' like a distro that never changes anything was a bad assumption for them from the start. The funny thing is there really is nothing more or less polished about Gnome in F8 than Ubuntu/Gentoo/etc... its Gnome! (which I love btw, just making the point its all pretty much just gnome) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From marc at mwiriadi.id.au Sat Dec 22 03:58:12 2007 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sat, 22 Dec 2007 12:58:12 +0900 Subject: Delays in package processing In-Reply-To: <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> References: <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> Message-ID: <1198295892.7443.94.camel@study.mwiriadi.id.au> On Sat, 2007-12-22 at 00:52 +0530, Debarshi 'Rishi' Ray wrote: > Have been reading this discussion with avid interest, and I would > really like to see respins of a stable Fedora release. Personally I > delay installing a new release on my machines till some of the common > bugs have been detected to avoid any major regression. But recently I > hit a installer bug on my MacBook for Fedora 8, and although it was > documented in the Wiki, there is no way one can benefit much without a > respin. > > However I do not know how much painful and extra burden this will be > for the release team, but if we can atleast have a respin for critical > kernel and installer fixes/improvements, it would be super. > > Cheers, > Debarshi Maybe half way through as in Fedora 8.5 or something like that where all the common bugs get fixed? My $0.02 Marc From pemboa at gmail.com Sat Dec 22 04:00:38 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Dec 2007 22:00:38 -0600 Subject: Fedora 8 review In-Reply-To: <476C75F6.9000009@gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <476C75F6.9000009@gmail.com> Message-ID: <16de708d0712212000w261a6935j64152873302ce351@mail.gmail.com> On Dec 21, 2007 8:27 PM, Andrew Farris wrote: > Arthur Pemberton wrote: > > * Gnome online desktop - "not great" but probably "not ready for evaluation" > > * feels that Fedora still has an identity crisis: stuck between > > server and desktop > > * feels that if Fedora is just a proving ground, why should people > > use it at all other than for testing > > * reviewer(s) spent 2 weeks with Fedora before review, but will not keep it > > * reviewer(s) felt that other reviews were too lenient > > > > > > All in all really Gnome specific, so I have little to know opinion on > > it. Their sum opinion is that Fedora is only suited as a test platform > > - not as a server, not a desktop. > > Sounds like all things considered that F8 was a success by this review. > Expecting Fedora to be 'polished' like a distro that never changes anything was > a bad assumption for them from the start. The funny thing is there really is > nothing more or less polished about Gnome in F8 than Ubuntu/Gentoo/etc... its > Gnome! (which I love btw, just making the point its all pretty much just gnome) They specifically expressed that they thought Ubuntu was more polished, even though they did not like the Ubuntu brown. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rnorwood at redhat.com Sat Dec 22 04:31:32 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 21 Dec 2007 23:31:32 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219091317.GB9741@tango.0pointer.de> (Lennart Poettering's message of "Wed, 19 Dec 2007 10:13:17 +0100") References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> Message-ID: Lennart Poettering writes: > On Tue, 18.12.07 19:23, Simo Sorce (ssorce at redhat.com) wrote: > >> > However, multi-seat support is not really available in CK yet. >> > >> > davidz and William Jon McCann can tell you more about this. >> >> Trying again, maybe you will answer my other question too. >> >> My normal use case is that I have rhythmbox running in my account which >> I tend to screenlock, when my wife wants to browse the web briefly she >> fast-switches to her account. >> >> What will PA do? Will it stop rhythmbox in the other session? If so why? >> What is the logic? I usually want to keep the music running. > > It will pause playback. When you switch back it will resume. Much like > MacOS does it. > > The idea is that speakers are IO devices much like the screen, > keyboard, and mice. I do believe that the normal case is that when you > switch sessions, you don't want to allow the inactive session to > record data from you microphone anymore or interfere with your audio > in otherwise. > > I know that some people want to continue playback when they switch to > a different session. However, I do not believe that this should be the > default. Maybe we will add support for this in a later version > somehow, but I do believe the right approach is to make sure that > inactive sessions cannot spy on the user who's active on the seat. Especially since the controls for the music playback are in the other session. The use case that I run into with F7 is: o Offspring #1 starts Battle For Wesnoth as his user. o Offspring #2 takes over the computer, switches to his own user, and wants to play some other game. For F7, the Wesnothy music keeps playing, and, to turn it off, the computer needs to switch back to Offspring #1's account, log in, and close his game. Then Offspring #2 can have sound. This sucks. I haven't installed F8 on The Offsprings computer yet, (I know, I know), but from what I understand, Pulseaudio should fix this very nicely. It would be just as bad if I were playing music. If a song I really hate comes up, and I don't have Offspring #1's password, there's no way to skip it. Terrible. I really can't understand how anyone would want the default behavior to be different. When some users might want audio from one user to keep playing as logged into another user, it sounds like they have to do some manual tweaks. No big deal. Keep up the great work on PA, Lennart. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From braden at endoframe.com Sat Dec 22 04:43:33 2007 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 21 Dec 2007 23:43:33 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <1198298613.3557.32.camel@hinge.endoframe.net> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote: [snip] > If you're a package maintainer and your package already uses xulrunner, > please rebuild it against the new rawhide version. Xulrunner directory > has been changed and many gecko packages (if not all) are linked with > --rpath linker directive. As long as rpath is used you have to rebuild > gecko-libs based packages after each xulrunner change so please consider > to remove it. Gecko libraries are registered system wide by > /etc/ld.so.conf.d and rpath should not be necessary in rawhide. But isn't it the case that the libraries in question do not have soversions? If the rpath is eliminated, how do we know when things really *do* need to break? -- Braden McDaniel e-mail: Jabber: From gilboad at gmail.com Sat Dec 22 05:50:25 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 07:50:25 +0200 Subject: x86_64/F8 -> rawhide breaks on missing (?) gnome-panel.i386 package. Message-ID: <1198302625.9132.4.camel@gilboa-home-dev.localdomain> --> Processing Dependency: libpanel-applet-2.so.0()(64bit) for package: gnome-panel ... ---> Package gnome-panel.x86_64 0:2.20.2-2.fc9 set to be updated ---> Package gnome-panel-libs.x86_64 0:2.20.2-2.fc9 set to be updated ... gnome-panel x86_64 2.20.2-2.fc9 development 3.5 M gnome-panel-libs x86_64 2.20.2-2.fc9 development 55 k ... file /etc/gconf/schemas/pager.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/panel-general.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/panel-global.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/panel-object.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/panel-toplevel.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/tasklist.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/window-list.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /etc/gconf/schemas/workspace-switcher.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/applications/gnome-panel.desktop from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/et/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/ga/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/he/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/pt_BR/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/sk/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 file /usr/share/locale/sl/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 - Gilboa From lordmorgul at gmail.com Sat Dec 22 07:02:44 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 21 Dec 2007 23:02:44 -0800 Subject: Hardware or software problem with touchpad? In-Reply-To: <476B86CA.309@olen.net> References: <476B86CA.309@olen.net> Message-ID: <476CB694.1080100@gmail.com> Ola Thoresen wrote: > For the last week or so my mouse pointer has behaved like crazy. This > is on a standard Compal "noname" laptop with a touchpad. On my desktop > (dell something) with an USB-mouse everyting works fine. > Both are running rawhide, updated yesterday. > > The touchpad works fine for 10-20 seconds, before the cursor starts > moving randomly up/down/left/right, clicking everything on its way. It > only happens when I actually use the touchpad. So I can use tha laptop > with no problem as long as I dont need the mouse. > The issue is present with both gpm (console) and X (tested with GNOME > and KDE). > > Before I post a bug (I searched bugzilla, but could not find anything > that looked familiar) I thought i'd just check if this is something > others might have experienced, or else it might really be a > hardware-problem. Have you tried disabling the hardware cursor option in xorg.conf? I believe this was posted to list a few times around the xorg release upgrade / abi change although I never had issues with my mouse still using hwcursor; that might help with erratic motion or laggy behavior. Try: Option "SWcursor" -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From debarshi.ray at gmail.com Sat Dec 22 07:45:47 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 22 Dec 2007 13:15:47 +0530 Subject: Delays in package processing In-Reply-To: <1198295892.7443.94.camel@study.mwiriadi.id.au> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> Message-ID: <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> > Maybe half way through as in Fedora 8.5 or something like that where all > the common bugs get fixed? Not all fixes, but just the installer specific ones would be enough. Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From rc040203 at freenet.de Sat Dec 22 08:02:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 22 Dec 2007 09:02:42 +0100 Subject: Delays in package processing In-Reply-To: References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> <1198249198.3656.399.camel@beck.corsepiu.local> Message-ID: <1198310562.3656.458.camel@beck.corsepiu.local> On Fri, 2007-12-21 at 17:10 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > My current favorite example: Why has doxygen not yet been upgraded on > > Fedora 8? > > Ask Than Ngo, he's the maintainer. This answer of yours already answers my question :) Ralf From rc040203 at freenet.de Sat Dec 22 08:16:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 22 Dec 2007 09:16:20 +0100 Subject: Delays in package processing In-Reply-To: <20071221171035.0ac8832d.mschwendt.tmp0701.nospam@arcor.de> References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <20071221084756.0dcc4e4c@redhat.com> <1198246638.3656.355.camel@beck.corsepiu.local> <20071221093018.1fa832b9@redhat.com> <1198249198.3656.399.camel@beck.corsepiu.local> <20071221171035.0ac8832d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1198311380.3656.471.camel@beck.corsepiu.local> On Fri, 2007-12-21 at 17:10 +0100, Michael Schwendt wrote: > On Fri, 21 Dec 2007 15:59:58 +0100, Ralf Corsepius wrote: > > > > > On Fri, 2007-12-21 at 09:30 -0500, Jesse Keating wrote: > > > On Fri, 21 Dec 2007 15:17:18 +0100 Ralf Corsepius wrote: > > > > > > I'm perfectly fine and > > > encourage bugfixing across releases. What I'm discouraging is version > > > upgrades for new features or spurious builds for spec fixes and other > > > unnecessary things that are done across the releases trees, not just on > > > rawhide. > > > > Of cause such things are happening, I don't deny them, but ... how can > > you be sure these updates won't fix something you're not aware about? > > The more important question is: How do you find out they don't break > anything [else]? I consider this aspect as non-important, because packages which don't work or break will hit back at the packagers and their upstreams in the in quite short terms, unless there are political, marketing or other reasons which overrule. Unfortunately the latter typically are those who prove to be those to be the really harmful ones. > You're baised, because you only see the _positive_ things in an update > procedure that has the potential to increase product quality. I don't think I am biased. I'd call it experience originating from long term involvement in OSS. In a nutshell, it's quite simple: OSS is an evolutionary process. Bugs, personal mistakes and faulty decisions are a natural part of this process. > Most likely > that is because you intend to improve your packages (and the packages you > depend on) gradually, and if you do it painstakingly you can succeed. > Perhaps you pay close attention to changelogs and diffs when evaluating an > upgrade, maybe you perform related tests. > But can the same be said about all packagers? Frankly speaking, I am expecting packagers to do this and regard this as their minimum duty. If they don't, they shouldn't be packagers and won't be packagers for long. > The Fedora community of > packagers consists of many different types of people. Some are upstream > themselves, some contribute upstream, some can fix bugs themselves, some > cannot fix bugs themselves, some are heavy users of the software they > package, some package more than they can use themselves regulary (and > obviously depend heavily on feedback from community-testers), some have > infinite trust in upstream release habits. This list is incomplete. No disagreement ... all packagers at some points in their career have been in one or more of the positions you descripe and made experiences on their own. Suppression, supervision and prohibition won't help, people need to go through learning curves themselves (Prohibition <-> moonshine ;) ) > Theoretically, updates can be fine. Version 1.0 of pkg foo contains bugs, > version 1.0.1 fixes these bugs without breaking anything else. But we're > not there yet. Many upstream projects are not there yet either. Then they should not be part of a stable distro, or at least no be part of the "mandatory parts". > And if we > modify our build requirements continously, we even increase the risk of > adding bugs. Version upgrades often include more changes than just > bug-fixes. Why take the step from the leading edge to the bleeding edge? Because Fedora already is the unstable bleeding edge? It's not because community packager added unstable stuff or did an unreasonable job, it's primarily because political and marketing forces outrule "reason". Ralf From valent.turkovic at gmail.com Sat Dec 22 08:33:30 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Dec 2007 09:33:30 +0100 Subject: Fedora 8 review In-Reply-To: <1198284270.2749.8.camel@localhost.localdomain> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> Message-ID: <64b14b300712220033j28ead9d4s9f67e78817d64fed@mail.gmail.com> On 12/22/07, Jonathan Roberts wrote: > > I totally agree with them regarding Fedora 8 graphics look, and the > > wallpaper. No matter what you say but users judge desktops on how they > > look. You could argue with Fedora 7 looks vs Fedora Core 6 looks if > > you like one more that the other regarding your personal taste, but > > Fedora 8 wallpaper and complete look it really beneath the previously > > high quality standards brought by FC6 and F7. > > Heh I hate to tell you but all art is subjective, and so Fedora 8's > wallpaper and complete look are both subjective as well :p > > Take for example: > > Distrowatch on Fedora: > > "Its new artwork team in particular deserves high marks for its work..." > > and a few comments from the digg story about Fedora 8's artwork: > > "This **** is great! I want Fedora!" > > "this is much better than the current hot air balloons, thanks!" > > I'm sure there are just as many negative opinions out there - but it is > subjective!! I know that is it subjective, but still FC6 had the best theme still, and it was downhill from there... F7 was OK, but F8 is just too simple. I believe that is can idea could be much more rafined... I'm not a designer myself but I worked for more than 10 years as design critic for bunch of designers and they usually respect my comments becuase I like to be objective and honest. The honest thing to say for F8 theme that it looks unfinished, that the design team didn't have time to finish it or if they intended to look as it looks now then they should rafinded it more... > The same goes for the rest of this review: for every thing they > commented on as being negative and not working, another review has > commented on as being positive and working brilliantly! Of course, I > agree with everything Jef said, if they want to point out something > that's not working, by all means do it, but do it in a way that helps it > get fixed!! Otherwise, why bother working in a field where openness and > collaboration are the central points?! > > Jef, I think we should try and get your e-mail somewhere where reviewers > are actually going to see it... I thought of it lastnight and did it already :) http://www.linuxactionshow.com/forum/comments.php?DiscussionID=2097&page=1#Item_1 > > Best, > > Jon Cheers, Valent. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- 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 gilboad at gmail.com Sat Dec 22 08:40:39 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 10:40:39 +0200 Subject: Fedora 8 review (OT, Changing X' configuration) In-Reply-To: <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> Message-ID: <1198312839.20340.3.camel@gilboa-home-dev.localdomain> On Fri, 2007-12-21 at 20:19 -0500, Yaakov Nemoy wrote: > On Dec 21, 2007 7:44 PM, Jonathan Roberts > wrote: > > Take for example: > > > > Distrowatch on Fedora: > > > > "Its new artwork team in particular deserves high marks for its work..." > > > > and a few comments from the digg story about Fedora 8's artwork: > > > > "This **** is great! I want Fedora!" > > > > "this is much better than the current hot air balloons, thanks!" > > Let's not forget the moment where I'm standing in front of a class > about to give a presentation, and I have to reboot because I can't get > X to recognize the projector without that. We're waiting for it to > reboot, and I start telling them stories about how the Fedora Art team > works, and just keeping people interested until I start the > presentation. > > Let's see someone using Wintendo do that :P > > -Yaakov > Restart?!?!?! Shouldn't Zap (Ctrl-Alt-BS) or Logout work? I can't remember ever having to restart the machine in-order to change something in X's configuration... (including driver.ko and X.org version updates) - Gilboa From kevin.kofler at chello.at Sat Dec 22 09:02:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 09:02:52 +0000 (UTC) Subject: Delays in package processing References: <4769766F.3010306@serpentine.com> <1198094151.3400.13.camel@localhost.localdomain> <20071220053923.be5c9fb0.mschwendt.tmp0701.nospam@arcor.de> <1198131169.3656.34.camel@beck.corsepiu.local> <20071220160521.fb1d124f.mschwendt.tmp0701.nospam@arcor.de> <20071220200548.a72c15ee.mschwendt.tmp0701.nospam@arcor.de> <604aa7910712201119k4bf5b490x8744cb3902875c20@mail.gmail.com> <20071221094618.d7bbb8fd.mschwendt.tmp0701.nospam@arcor.de> <476B838B.6080402@leemhuis.info> <20071221105335.53cd20c8.mschwendt.tmp0701.nospam@arcor.de> <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > Where do you see unkind or unfriendly words? "Hyperbole" is just another > word for "exaggeration", and above you did exactly that. You exaggerated > by a clear margin. Actually, all those people who can't install F8 from > media due to various problems (with unsupported hardware, undetected > drives, kernel problems e.g.) are sort of forced to wait for the next > release, which is after ~6 months. Unless there's a respin which > incorporates anaconda/kernel/... updates that fixes the people's > problems. And not many are courageous enough to try rawhide. Fedora Unity is working on a Fedora 8 respin with an updated kernel and a fixed Anaconda. And then there's also the option of bypassing the installer entirely (at least the buggy version): * install Fedora 7 (or an even older release, but upgrading from Fedora <=6 is going to be more painful due to the libata migration in Fedora 7) * yum install apt * point your /etc/apt/sources.list and/or /etc/apt/sources.list.d/*.list to Fedora 8 * fix apt's list of "essential" packages (/etc/apt/rpmpriorities), see: https://bugzilla.redhat.com/show_bug.cgi?id=426143 * apt-get update * apt-get dist-upgrade Kevin Kofler From kevin.kofler at chello.at Sat Dec 22 09:32:23 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 09:32:23 +0000 (UTC) Subject: FeatureDictionary patches for KDE Message-ID: I'm working on implementing: http://fedoraproject.org/wiki/Releases/FeatureDictionary in our KDE packages. This is the current situation: * KDE 4 uses an API called Sonnet for spellchecking. Sonnet already has an enchant backend, and it is the default recommended by upstream. There's also an aspell backend; we will probably drop the aspell-devel BR so we lose the hard aspell dependency, aspell can be used through enchant anyway (using enchant-aspell, which is about to be split into a separate subpackage according to FeatureDictionary). * The situation in KDE 3 is more complex. We'll be stuck with several KDE 3 apps for a while to come, so I had to find a solution there too. As KDE 3 has seen years of binary compatibility, there are 2 spellchecking implementations in kdelibs3: - legacy KSpell: That API uses command-line spellcheckers using the "ispell pipe interface". It doesn't use plugins, instead, everything is handled by 2 central classes. Rewriting this code to use libraries (e.g. enchant) properly is a lot of effort for this legacy code. Thus, I patched it to support the hunspell command line and its "ispell pipe interface" (which required only minor changes): http://repo.calcforge.org/f9/kdelibs-3.5.8-kspell-hunspell.diff The patch is preliminary, I still have to test that it works, and we also have to make sure the defaults are set up so hunspell is used by default, at least for new installations. - KSpell2: This is the API KDE 4's Sonnet is derived from. It uses spellchecking libraries and a plugin architecture. I backported Sonnet's enchant backend plugin from kdelibs 4 SVN to KSpell2: http://repo.calcforge.org/f9/kdelibs-3.5.8-kspell2-enchant.diff I did a minimum amount of testing on this one, it could probably use more. And here too, we'll want to make sure it is the default, most likely by not shipping any other KSpell2 backend. This comes "fresh out of the presses". I haven't added these patches to the Rawhide packages or submitted them upstream yet. Kevin Kofler From caolanm at redhat.com Sat Dec 22 09:55:32 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 22 Dec 2007 09:55:32 +0000 Subject: FeatureDictionary patches for KDE In-Reply-To: References: Message-ID: <1198317332.5768.357.camel@Jehannum> On Sat, 2007-12-22 at 09:32 +0000, Kevin Kofler wrote: > I'm working on implementing: > http://fedoraproject.org/wiki/Releases/FeatureDictionary > in our KDE packages. This is the current situation: > > * KDE 4 uses an API called Sonnet for spellchecking. Sonnet already has an > enchant backend > > - legacy KSpell: That API uses command-line spellcheckers using the "ispell > pipe interface". ... I patched it to support the hunspell command line and its > "ispell pipe interface" (which required only minor changes): > - KSpell2: This is the API KDE 4's Sonnet is derived from. It uses > spellchecking libraries and a plugin architecture. I backported Sonnet's > enchant backend plugin from kdelibs 4 SVN to KSpell2: Most excellent indeed, can you edit that wiki page and put those KDE notes in the Details page ? C. From jcm at redhat.com Sat Dec 22 09:56:49 2007 From: jcm at redhat.com (Jon Masters) Date: Sat, 22 Dec 2007 04:56:49 -0500 Subject: kernel problem in todays rawhide update In-Reply-To: <20071221212116.GC25435@nostromo.devel.redhat.com> References: <476C29DF.4050907@mindspring.com> <20071221212116.GC25435@nostromo.devel.redhat.com> Message-ID: <1198317409.24423.49.camel@perihelion> On Fri, 2007-12-21 at 16:21 -0500, Bill Nottingham wrote: > richard hally (rhallyx at mindspring.com) said: > > What up? > > Known issue, should be fixed tomorrow. You got a BZ, out of interest? Jon. From kevin.kofler at chello.at Sat Dec 22 10:47:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 10:47:08 +0000 (UTC) Subject: FeatureDictionary patches for KDE References: <1198317332.5768.357.camel@Jehannum> Message-ID: Caolan McNamara redhat.com> writes: > Most excellent indeed, can you edit that wiki page and put those KDE > notes in the Details page ? Done. Kevin Kofler From buildsys at redhat.com Sat Dec 22 12:16:32 2007 From: buildsys at redhat.com (Build System) Date: Sat, 22 Dec 2007 07:16:32 -0500 Subject: rawhide report: 20071222 changes Message-ID: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> New package eclipse-photran Eclipse Fortran Development Tools (Photran) plugin New package gvfs Backends for the gio framework in GLib New package ibmasm IBM Advanced System Management Drivers New package libwiimote Simple Wiimote Library for Linux New package libytnef TNEF Stream Parser Library New package perl-Class-Inner A perlish implementation of Java like inner classes New package perl-QWizard A very portable graphical question and answer wizard system New package trac-ticketdelete-plugin Remove tickets and ticket changes from Trac New package vdr-tvonscreen Enhanced EPG data viewer for VDR New package xguest Creates xguest user as a locked down user Updated Packages: PackageKit-0.1.5-1.fc9 ---------------------- * Fri Dec 21 2007 Robin Norwood - 0.1.5-1 - Update to latest upstream version: 0.1.5 - Remove polkit.patch for PolicyKit 0.7, no longer needed alpine-1.00-2.fc9 ----------------- * Sat Dec 22 2007 Rex Dieter 1.00-2 - --with-system-pinerc=%_sysconfdir/pine.conf --with-system-fixed-pinerc=%_sysconfdir/pine.conf.fixed (#426512) * Fri Dec 21 2007 Rex Dieter 1.00-1 - alpine-1.00 autofs-1:5.0.2-25 ----------------- * Fri Dec 21 2007 Ian Kent - 5.0.2-25 - Bug 426401: CVE-2007-6285 autofs default doesn't set nodev in /net [rawhide] - use mount option "nodev" for "-hosts" map unless "dev" is explicily specified. bouml-3.4-1.fc9 --------------- * Fri Dec 21 2007 Debarshi Ray - 3.4-1 - Version bump to 3.4. Closes Red Hat Bugzilla bug #426485. - Previous releases can not read a project saved with this version, but projects made by previous releases can be read. * Thu Nov 29 2007 Debarshi Ray - 3.3.3-1 - Version bump to 3.3.3. Closes Red Hat Bugzilla bug #398811. - Fixed usage of _remove_encoding to prevent failure on Fedora 7. * Sun Nov 25 2007 Debarshi Ray - 3.3.1-2 - Removed Encoding from Desktop Entry for all distributions, except Fedora 7. chkrootkit-0.48-1.fc9 --------------------- * Sat Dec 22 2007 Michael Schwendt - 0.48-1 - Update to 0.48 (new tests, enhanced tests, minor bug-fixes). clamav-0.92-3.fc9 ----------------- * Fri Dec 21 2007 Tom "spot" Callaway - 0.92-3 - updated to 0.92 (SECURITY): - CVE-2007-6335 MEW PE File Integer Overflow Vulnerability claws-mail-plugins-3.2.0-1.fc9 ------------------------------ * Mon Dec 17 2007 Andreas Bierfert - 3.2.0-1 - version upgrade - added tnef plugin control-center-1:2.21.4-1.fc9 ----------------------------- * Fri Dec 21 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 cyphesis-0.5.15-3.fc9 --------------------- * Tue Dec 18 2007 Wart 0.5.15-3 - Fix selinux permissions so that cyphesis can create its own log file. eel2-2.21.1-1.fc9 ----------------- * Fri Dec 21 2007 Matthias Clasen - 2.21.1-1 - Update to 2.21.1 firefox-3.0-0.beta2.3.fc9 ------------------------- * Sat Dec 22 2007 Christopher Aillon 3.0-0.beta2.3 - When there are both 32- and 64-bit versions of XPCOM installed on disk make sure to load the correct one. gchempaint-0.8.5-1.fc9 ---------------------- * Fri Dec 21 2007 Julian Sikorski - 0.8.5-1 - Updated to 0.8.5 - Cleaned up the spec - Switched back to usual rpath killer gdm-1:2.21.2-0.2007.11.20.8.fc9 ------------------------------- * Fri Dec 21 2007 Ray Strode - 1:2.21.2-0.2007.11.20.8 - Fix background (and other settings) git-1.5.3.7-2.fc9 ----------------- * Fri Dec 21 2007 James Bowes 1.5.3.7-2 - Have git metapackage require explicit versions (bug 247214) glib2-2.15.0-2.fc9 ------------------ * Fri Dec 21 2007 Caolan McNamara - 2.15.0-2 - add jakubs patch in so xulrunner will build and so gcc too glpi-0.70-1.fc9 --------------- * Fri Dec 21 2007 Remi Collet - 0.70-1 - 0.70 final gnome-chemistry-utils-0.8.5-1.fc9 --------------------------------- * Fri Dec 21 2007 Julian Sikorski - 0.8.5-1 - Updated to 0.8.5 - Conditionalised xulrunner usage gnome-desktop-2.21.4-1.fc9 -------------------------- * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-system-monitor-2.21.4-2.fc9 --------------------------------- * Fri Dec 21 2007 David Zeuthen - 2.21.4-2.fc9 - Add PolicyKit support gnupg-1.4.8-1 ------------- * Thu Dec 20 2007 Nalin Dahyabhai - 1.4.7-9 - update to 1.4.8, noting license change to GPLv3 gxine-0.5.11-15.fc9 ------------------- * Fri Dec 21 2007 Martin Sourada - 0.5.11-15 - rebuild for new xulrunner hunspell-fr-2.0.5-1.fc9 ----------------------- jd-1.9.8-0.4.svn1651.fc9 ------------------------ * Sat Dec 22 2007 Mamoru Tasaka - 1.9.8-0.4.svn1651 - svn 1651 * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 kernel-2.6.24-0.123.rc6.fc9 --------------------------- * Fri Dec 21 2007 David Woodhouse - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing * Fri Dec 21 2007 John W. Linville - Yet another round of wireless updates... * Thu Dec 20 2007 Kyle McMartin - 2.6.24-rc6 libgnomeui-2.20.1.1-2.fc9 ------------------------- * Sat Dec 22 2007 Matthias Clasen - 2.20.1.1-2 - Add the gvfs filechooser backend * Wed Oct 17 2007 Matthias Clasen - 2.20.1.1-1 - Update to 2.20.1.1 (fixes a crash in thumbnailing code) * Mon Oct 15 2007 Matthias Clasen - 2.20.1-1 - Update to 2.20.1 (translation updates, file chooser improvements) libgsf-1.14.7-2.fc9 ------------------- * Fri Dec 21 2007 Caolan McNamara 1.14.7-2 - Resolves: rhbz#426436 fix up python x86_64 import gsf librapi-0.10.0-2.fc9 -------------------- librra-0.10.0-2.fc9 ------------------- * Fri Dec 21 2007 Andreas Bierfert - 0.10.0-2 - rework BR * Wed May 09 2007 Aurelien Bompard 0.10.0-1 - version 0.10.0 libsynce-0.10.0-1.fc9 --------------------- mkinitrd-6.0.25-2.fc9 --------------------- * Fri Dec 21 2007 Peter Jones - 6.0.25-2 - Add BuildReq for util-linux-ng * Fri Dec 21 2007 Peter Jones - 6.0.25-1 - Don't remove two things from a GHashTable at the same time; it doesn't work with newer glib2. monotone-0.38-1.fc9 ------------------- * Fri Dec 21 2007 Roland McGrath - 0.38-1 - Updated for 0.38 release. nautilus-2.21.1-1.fc9 --------------------- * Fri Dec 21 2007 Matthias Clasen - 2.21.1-1 - Upodate to 2.21.1 * Wed Dec 19 2007 - Bastien Nocera - 2.20.0-7 - Update audio preview patch to check for aliases (#381401) * Tue Oct 30 2007 - Bastien Nocera - 2.20.0-6 - Fix audio preview command-line to use decodebin so playbin doesn't pop up a window for videos detected as audio octave-6:3.0.0-1.fc9 -------------------- * Fri Dec 21 2007 Quentin Spencer 3.0.0-1 - Update to 3.0.0. perl-DBIx-DBSchema-0.36-1.fc9 ----------------------------- * Sat Dec 22 2007 Ralf Cors??pius - 0.36-1 - Upstream update. - Remove DBIx-DBSchema-0.28-version.diff. perl-Net-DNS-0.61-4.fc9 ----------------------- * Fri Dec 21 2007 Paul Howarth - 0.61-4 - Fix file ownership for Nameserver subpackage - Fix argument order for find with -depth policycoreutils-2.0.34-3.fc9 ---------------------------- * Fri Dec 21 2007 Dan Walsh 2.0.34-3 - Catch SELINUX_ERR with audit2allow and generate policy rhythmbox-0.11.4-1.fc9 ---------------------- * Fri Dec 21 2007 Matthias Clasen - 0.11.4-1 - Update to 0.11.4 ruby-1.8.6.111-3.fc9 -------------------- * Fri Dec 21 2007 Akira TAGOH - 1.8.6.111-3 - Clean up the spec file. - Remove ruby-man-1.4.6 stuff. this is entirely the out-dated document. this could be replaced by ri. - Disable the static library building. * Tue Dec 04 2007 Release Engineering - 1.8.6.111-2 - Rebuild for openssl bump * Wed Oct 31 2007 Akira TAGOH - Fix the dead link. selinux-policy-3.2.5-4.fc9 -------------------------- * Thu Dec 20 2007 Dan Walsh 3.2.5-4 - Let all uncofined domains communicate with dbus unconfined sqlite-3.5.4-1.fc9 ------------------ * Fri Dec 21 2007 Panu Matilainen - 3.5.4-1 - Update to 3.5.4 (#413801) synce-serial-0.10.0-1.fc9 ------------------------- * Fri Dec 21 2007 Andreas Bierfert - correct Requires - fix #249031 udev rule system-config-firewall-1.1.1-1.fc9 ---------------------------------- * Fri Dec 21 2007 Thomas Woerner 1.1.1-1 - use radio buttons for skill menu entries to show active level - fixed convert-config problem if there is no configuration to convert (rhbz#426477) - minor string changes - new it and pt_BR translations uw-imap-2007-1.fc9 ------------------ * Fri Dec 21 2007 Rex Dieter 2007-1 - imap-2007 vdccm-0.10.1-1.fc9 ------------------ wireless-tools-1:29-1.fc9 ------------------------- * Sat Dec 22 2007 Christopher Aillon - 1:29-1 - Update to v29 stable release - Some minor cleanups for merge review * Fri Aug 24 2007 Christopher Aillon - 1:29-0.2.pre22 - Rebuild * Mon Aug 13 2007 Christopher Aillon - 1:29-0.1.pre22 - Update to 29pre22 - Update the license tag xulrunner-1.9-0.beta2.3.fc9 --------------------------- * Fri Dec 21 2007 Martin Stransky 1.9-0.beta2.3 - added java and plugin subdirs to plugin includes Broken deps for i386 ---------------------------------------------------------- Miro - 1.0-2.fc9.i386 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.i386 requires libgtkembedmoz.so asterisk-voicemail-imap - 1.4.16.1-1.fc9.i386 requires libc-client.so.2006 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 claws-mail-plugins-clamav - 3.2.0-1.fc9.i386 requires libclamav.so.2 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 gurlchecker - 0.10.1-4.fc8.i386 requires libclamav.so.2 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 klamav - 0.41.1-7.fc9.i386 requires libclamav.so.2 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071212-4.fc9.i386 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 plplot-octave - 5.8.0-4.fc9.i386 requires octave(api) = 0:api-v31 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- Miro - 1.0-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.x86_64 requires libgtkembedmoz.so()(64bit) asterisk-voicemail-imap - 1.4.16.1-1.fc9.x86_64 requires libc-client.so.2006()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-clamav - 3.2.0-1.fc9.x86_64 requires libclamav.so.2()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) gurlchecker - 0.10.1-4.fc8.x86_64 requires libclamav.so.2()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 klamav - 0.41.1-7.fc9.x86_64 requires libclamav.so.2()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071212-4.fc9.x86_64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-4.fc9.x86_64 requires octave(api) = 0:api-v31 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc requires libgtkembedmoz.so asterisk-voicemail-imap - 1.4.16.1-1.fc9.ppc requires libc-client.so.2006 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 claws-mail-plugins-clamav - 3.2.0-1.fc9.ppc requires libclamav.so.2 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 gurlchecker - 0.10.1-4.fc8.ppc requires libclamav.so.2 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 klamav - 0.41.1-7.fc9.ppc requires libclamav.so.2 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071212-4.fc9.ppc requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 plplot-octave - 5.8.0-4.fc9.ppc requires octave(api) = 0:api-v31 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-clamav - 3.2.0-1.fc9.ppc64 requires libclamav.so.2()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) gurlchecker - 0.10.1-4.fc8.ppc64 requires libclamav.so.2()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 klamav - 0.41.1-7.fc9.ppc64 requires libclamav.so.2()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-4.fc9.ppc64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-4.fc9.ppc64 requires octave(api) = 0:api-v31 ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(activerecord) = 0:1.15.6 rubygem-actionwebservice - 1.2.6-1.fc9.noarch requires rubygem(actionpack) = 0:1.13.6 From triad at df.lth.se Sat Dec 22 12:37:57 2007 From: triad at df.lth.se (Linus Walleij) Date: Sat, 22 Dec 2007 13:37:57 +0100 (CET) Subject: Yum broke in transaction, how to restore system? Message-ID: I had yum breaking in the middle of a transaction yesterday (kernel post scriptlet failed) so now some packages were installed but no "clean up" was done. Is there some archaic way of resolving this and run just the cleanups post-mortem? I never understood this quite, and yum manpage is not very helpful to unexpected situations... Actually this happening so seldom is an indication of how good yum actually is, so me not knowing the answer already is a GoodThing(TM). Linus From denis at poolshark.org Sat Dec 22 13:16:00 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 22 Dec 2007 14:16:00 +0100 Subject: Yum broke in transaction, how to restore system? In-Reply-To: References: Message-ID: <476D0E10.9040902@poolshark.org> Linus Walleij wrote: > I had yum breaking in the middle of a transaction yesterday (kernel post > scriptlet failed) so now some packages were installed but no "clean up" > was done. > > Is there some archaic way of resolving this and run just the cleanups > post-mortem? I never understood this quite, and yum manpage is not very > helpful to unexpected situations... > > Actually this happening so seldom is an indication of how good yum > actually is, so me not knowing the answer already is a GoodThing(TM). package-cleanup did it for me # yum -y install yum-utils # package-cleanup --cleandupes then check # package-cleanup --problems From sgrubb at redhat.com Sat Dec 22 13:28:48 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Dec 2007 08:28:48 -0500 Subject: kernels won't boot In-Reply-To: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> Message-ID: <200712220828.48202.sgrubb@redhat.com> On Saturday 22 December 2007 07:16:32 Build System wrote: > kernel-2.6.24-0.123.rc6.fc9 > --------------------------- > * Fri Dec 21 2007 David Woodhouse > - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing > > * Fri Dec 21 2007 John W. Linville > - Yet another round of wireless updates... > > * Thu Dec 20 2007 Kyle McMartin > - 2.6.24-rc6 After build 81, I have not been able to boot any of the x86_64 rawhide kernels. They all end with: Trying to resume from /sys/block/sda/sda3 Unable to access resume device (/sys/block/sda/sda3) Creating root device Mounting root filesystem mount: could not find '/dev/root' Setting up other filesystems Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Booting has failed. Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other people running into this? -Steve From benny+usenet at amorsen.dk Sat Dec 22 13:28:11 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 22 Dec 2007 14:28:11 +0100 Subject: Fedora 8 review (OT, Changing X' configuration) References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> <1198312839.20340.3.camel@gilboa-home-dev.localdomain> Message-ID: Gilboa Davara writes: > Restart?!?!?! > Shouldn't Zap (Ctrl-Alt-BS) or Logout work? It probably should, but it doesn't. > I can't remember ever having to restart the machine in-order to change > something in X's configuration... (including driver.ko and X.org version > updates) Welcome to laptops with ATI graphics. X often can't figure out how to turn on an output if the BIOS hasn't done it already. If you boot without the projector plugged in, the BIOS turns the VGA output off, and that's the end of that story. Hopefully ATI's new-found commitment to free software will help. /Benny From jkeating at redhat.com Sat Dec 22 13:32:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 08:32:01 -0500 Subject: Delays in package processing In-Reply-To: <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> Message-ID: <20071222083201.0885f0a9@redhat.com> On Sat, 22 Dec 2007 13:15:47 +0530 "Debarshi 'Rishi' Ray" wrote: > > Maybe half way through as in Fedora 8.5 or something like that > > where all the common bugs get fixed? > > Not all fixes, but just the installer specific ones would be enough. This assumes that the installer from F8 would get updates. It doesn't. Installer work is entirely done on the /next/ release, and interspersed with all the new features we're doing. To require the installer folks to work on updates to the old installer would be a sure way to stagnate future development. -- 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 Sat Dec 22 13:48:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Dec 2007 14:48:32 +0100 Subject: anaconda updates / respins (was: Re: Delays in package processing) In-Reply-To: <20071222083201.0885f0a9@redhat.com> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> <20071222083201.0885f0a9@redhat.com> Message-ID: <476D15B0.8020302@leemhuis.info> On 22.12.2007 14:32, Jesse Keating wrote: > On Sat, 22 Dec 2007 13:15:47 +0530 > "Debarshi 'Rishi' Ray" wrote: > >>> Maybe half way through as in Fedora 8.5 or something like that >>> where all the common bugs get fixed? >> Not all fixes, but just the installer specific ones would be enough. > This assumes that the installer from F8 would get updates. It > doesn't. Installer work is entirely done on the /next/ release, and > interspersed with all the new features we're doing. To require the > installer folks to work on updates to the old installer would be a sure > way to stagnate future development. Sorry, I might be shortsighted, but why is the installer different to other packages? Sure, it's a bit more work to produce updates for older releases, but isn't that what we do everywhere else as well? So why can't the installer guys do it as well? Further: we create update images like http://katzj.fedorapeople.org/updates-f8-yumloop.img so those problems we are talking about get analyzed and fixed already. But the fix is hard to access for some people; and it's a extra step you need to know about. All we'd need to do is to get this and similar *small* updates into a updated install iso image and we'd make a lot people happy that currently have a hard time installing Fedora. Cu knurd From musuruan at gmail.com Sat Dec 22 14:22:46 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Sat, 22 Dec 2007 15:22:46 +0100 Subject: License change for Tecnoballz Message-ID: <1198333366.23001.4.camel@localhost.localdomain> Hi all, tecnoballz 0.92 (I will submit soon an updated package) is now GPLv3+ (it was GPLv2+). Bye, Andrea. From sgrubb at redhat.com Sat Dec 22 14:30:21 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Dec 2007 09:30:21 -0500 Subject: /usr/bin/xetex has executable stack Message-ID: <200712220930.21451.sgrubb@redhat.com> Hi, Running a test across the distribution and it looks like a new program has popped up that needs an executable stack: [root ~]# /usr/bin/eu-readelf -l /usr/bin/xetex | grep STACK GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8 Does this app really need its stack to be executable? This could be a security risk. -Steve From subhodip at fedoraproject.org Sat Dec 22 14:58:10 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sat, 22 Dec 2007 20:28:10 +0530 Subject: where s my kernel Message-ID: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> hi ! i am currently using kernel 2.6.23.8-63.fc8.i686 , but i am unable to find it in /usr/src/kernels.. though i have kernel-devel installed ....... what i have missed to solve the problem -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From jkeating at redhat.com Sat Dec 22 15:01:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 10:01:53 -0500 Subject: anaconda updates / respins (was: Re: Delays in package processing) In-Reply-To: <476D15B0.8020302@leemhuis.info> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> <20071222083201.0885f0a9@redhat.com> <476D15B0.8020302@leemhuis.info> Message-ID: <20071222100153.3e0ce75a@redhat.com> On Sat, 22 Dec 2007 14:48:32 +0100 Thorsten Leemhuis wrote: > Sorry, I might be shortsighted, but why is the installer different to > other packages? Sure, it's a bit more work to produce updates for > older releases, but isn't that what we do everywhere else as well? So > why can't the installer guys do it as well? Because the installer team is roughly 4 people, who have to do installer work for RHEL4.* RHEL5.*, RHEL6, Fedora, and any other RH offering that happens to use an installer. Not to mention that these guys also own other software projects that get used in the above mentioned releases like libdhcp, parted, pykickstart, firstboot, mkinitrd, dmraid, grub, etc... These are some seriously overworked folks. If we want any chance at new features in Fedora releases, they have to be free to work on new features, rolling in fixes from the previous release as they go. > > Further: we create update images like > http://katzj.fedorapeople.org/updates-f8-yumloop.img > so those problems we are talking about get analyzed and fixed already. Many of the fixes put in update images are fixes in other pieces of software, like yum, and not anaconda itself. > But the fix is hard to access for some people; and it's a extra step > you need to know about. All we'd need to do is to get this and similar > *small* updates into a updated install iso image and we'd make a lot > people happy that currently have a hard time installing Fedora. That's what Unity does, and I applaud 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 jonathan.underwood at gmail.com Sat Dec 22 15:03:33 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 22 Dec 2007 15:03:33 +0000 Subject: where s my kernel In-Reply-To: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> References: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> Message-ID: <645d17210712220703t687b89bjb912dd0a6c19fa1a@mail.gmail.com> On 22/12/2007, subhodip biswas wrote: > hi ! > i am currently using kernel 2.6.23.8-63.fc8.i686 , but i am unable to > find it in /usr/src/kernels.. though i have kernel-devel installed > ....... what i have missed to solve the problem Your post is off topic for this list. Please ask your question on fedora-list at redhat.com From sundaram at fedoraproject.org Sat Dec 22 15:00:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 22 Dec 2007 20:30:01 +0530 Subject: where s my kernel In-Reply-To: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> References: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> Message-ID: <476D2671.8020707@fedoraproject.org> subhodip biswas wrote: > hi ! > i am currently using kernel 2.6.23.8-63.fc8.i686 , but i am unable to > find it in /usr/src/kernels.. though i have kernel-devel installed > ....... what i have missed to solve the problem kernel-devel has the kernel headers and not the source code. For installing the source code of a package # yum install yum-utils # yumdownloader --source # rpm -ivh Note that this is a question better suited for fedora-list. Rahul From 440volt.tux at gmail.com Sat Dec 22 15:15:15 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Sat, 22 Dec 2007 20:45:15 +0530 Subject: where s my kernel In-Reply-To: <476D2671.8020707@fedoraproject.org> References: <539333cb0712220658o4ad8119bs8e61210b1bb0fb1c@mail.gmail.com> <476D2671.8020707@fedoraproject.org> Message-ID: <539333cb0712220715u28949f02gb2d19ac9af79448f@mail.gmail.com> ok ...will do that -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From ndbecker2 at gmail.com Sat Dec 22 15:19:41 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Dec 2007 10:19:41 -0500 Subject: Firefox 3 Beta 2 in Rawhide References: <476A2656.5060704@redhat.com> Message-ID: Miro needs updating, I think. (This is on f8) --> Finished Dependency Resolution Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro From fedora at leemhuis.info Sat Dec 22 15:20:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Dec 2007 16:20:05 +0100 Subject: anaconda updates / respins In-Reply-To: <20071222100153.3e0ce75a@redhat.com> References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> <20071222083201.0885f0a9@redhat.com> <476D15B0.8020302@leemhuis.info> <20071222100153.3e0ce75a@redhat.com> Message-ID: <476D2B25.6010004@leemhuis.info> On 22.12.2007 16:01, Jesse Keating wrote: > On Sat, 22 Dec 2007 14:48:32 +0100 > Thorsten Leemhuis wrote: > >> Further: we create update images like >> http://katzj.fedorapeople.org/updates-f8-yumloop.img >> so those problems we are talking about get analyzed and fixed already. > Many of the fixes put in update images are fixes in other pieces of > software, like yum, and not anaconda itself. But those are afaics the ones that people are interested it. I'd even assume those where meant when we people mentioned "Fedora 8.5" or "Not all fixes, but just the installer specific ones would be enough." -- "install specific ones" is likely not anaconda for everyone ;) >> But the fix is hard to access for some people; and it's a extra step >> you need to know about. All we'd need to do is to get this and similar >> *small* updates into a updated install iso image and we'd make a lot >> people happy that currently have a hard time installing Fedora. > That's what Unity does, and I applaud them. I do as well, but seems with a bit of support from Fedora their stuff could be a lot better and easier to build: http://kanarip.blogspot.com/2007/09/updating-anaconda-between-releases.html Further: I think Fedora as a whole should be more flexible and have a experimental area; a place within the project where stuff like the respins can be developed and tested and easily become official once we see if it works. Cu knurd From mjs at CLEMSON.EDU Sat Dec 22 15:20:57 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 22 Dec 2007 10:20:57 -0500 Subject: Fedora 8 review (OT, Changing X' configuration) In-Reply-To: <1198312839.20340.3.camel@gilboa-home-dev.localdomain> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> <1198312839.20340.3.camel@gilboa-home-dev.localdomain> Message-ID: <1198336857.3594.11.camel@vincent52.localdomain> On Sat, 2007-12-22 at 10:40 +0200, Gilboa Davara wrote: > On Fri, 2007-12-21 at 20:19 -0500, Yaakov Nemoy wrote: > > Let's not forget the moment where I'm standing in front of a class > > about to give a presentation, and I have to reboot because I can't get > > X to recognize the projector without that. We're waiting for it to > > reboot, and I start telling them stories about how the Fedora Art team > > works, and just keeping people interested until I start the > > presentation. > > > > Let's see someone using Wintendo do that :P > > Restart?!?!?! > Shouldn't Zap (Ctrl-Alt-BS) or Logout work? > > I can't remember ever having to restart the machine in-order to change > something in X's configuration... (including driver.ko and X.org version > updates) On some machines, the external display DAC is off unless there is an external display attached at boot time. The controls for changing that state of affairs dynamically are unreliable in some X drivers. For example, I used to be able to cycle my Radeon-based Thinkpad through internal and external displays with a function key, but that stopped working in F8. (Will file bug soon...) -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From kevin.kofler at chello.at Sat Dec 22 15:20:06 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 15:20:06 +0000 (UTC) Subject: anaconda updates / respins (was: Re: Delays in package processing) References: <476B92BD.2060808@leemhuis.info> <20071221144813.e6a43475.mschwendt.tmp0701.nospam@arcor.de> <20071221090135.1ce95af7@redhat.com> <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> <20071222083201.0885f0a9@redhat.com> <476D15B0.8020302@leemhuis.info> <20071222100153.3e0ce75a@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > That's what Unity does, and I applaud them. Couldn't we give one of the Unity folks comaintainership of anaconda so they can push official updates to anaconda with backported fixes? They're working on backporting the most important Anaconda fixes for the F8 respin already, so why can't the fixes land in the F8 updates repository? Kevin Kofler From ndbecker2 at gmail.com Sat Dec 22 15:38:59 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Dec 2007 10:38:59 -0500 Subject: Firefox 3 Beta 2 in Rawhide References: <476A2656.5060704@redhat.com> Message-ID: Neal Becker wrote: > Miro needs updating, I think. > > (This is on f8) > --> Finished Dependency Resolution > Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro > > And then there's this: ERROR with rpm_check_debug vs depsolve: Package devhelp needs libgtkembedmoz.so, this is not available. Package devhelp needs gecko-libs = 1.8.1.10, this is not available. Package devhelp needs gecko-libs = 1.8.1.10, this is not available. From gilboad at gmail.com Sat Dec 22 16:20:30 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 18:20:30 +0200 Subject: Fedora 8 review (OT, Changing X' configuration) In-Reply-To: References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> <1198312839.20340.3.camel@gilboa-home-dev.localdomain> Message-ID: <1198340430.20340.8.camel@gilboa-home-dev.localdomain> On Sat, 2007-12-22 at 14:28 +0100, Benny Amorsen wrote: > Gilboa Davara writes: > > > Restart?!?!?! > > Shouldn't Zap (Ctrl-Alt-BS) or Logout work? > > It probably should, but it doesn't. > > > I can't remember ever having to restart the machine in-order to change > > something in X's configuration... (including driver.ko and X.org version > > updates) > > Welcome to laptops with ATI graphics. X often can't figure out how to > turn on an output if the BIOS hasn't done it already. If you boot > without the projector plugged in, the BIOS turns the VGA output off, > and that's the end of that story. OK. I understand. > > Hopefully ATI's new-found commitment to free software will help. Yep. Without the specs I doubt that OSS drivers will be able to reverse engineer the BIOS switches required to turn on the external DAC. - Gilboa From gilboad at gmail.com Sat Dec 22 16:45:07 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 18:45:07 +0200 Subject: F8->Devel + SELinux unbootable. Message-ID: <1198341907.20340.18.camel@gilboa-home-dev.localdomain> Hello all, I've create a VMWare guest with F8/x86_64 on it and immediately upgraded it to -devel. (Minus some small gnome-panel multi-lib breakage) However, once I reboot the machine (and init finished it course) I got an "ld 'x' re-spawning too fast" and when I try to ssh into the machine I get greeted by "/bin/bash: Permission denied". If I disable SELinux things seem to work just fine. Oh, I've relabeled the FS (fixfiles relabel, tried again with .autorelabel) but it didn't solve the problem. Any ideas? - Gilboa From gilboad at gmail.com Sat Dec 22 16:48:49 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 18:48:49 +0200 Subject: x86_64/F8 -> rawhide breaks on missing (?) gnome-panel.i386 package. In-Reply-To: <1198302625.9132.4.camel@gilboa-home-dev.localdomain> References: <1198302625.9132.4.camel@gilboa-home-dev.localdomain> Message-ID: <1198342129.20340.24.camel@gilboa-home-dev.localdomain> On Sat, 2007-12-22 at 07:50 +0200, Gilboa Davara wrote: > --> Processing Dependency: libpanel-applet-2.so.0()(64bit) for package: gnome-panel > ... > > ---> Package gnome-panel.x86_64 0:2.20.2-2.fc9 set to be updated > ---> Package gnome-panel-libs.x86_64 0:2.20.2-2.fc9 set to be updated > ... > > gnome-panel x86_64 2.20.2-2.fc9 development 3.5 M > gnome-panel-libs x86_64 2.20.2-2.fc9 development 55 k > ... > > file /etc/gconf/schemas/pager.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/panel-general.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/panel-global.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/panel-object.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/panel-toplevel.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/tasklist.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/window-list.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /etc/gconf/schemas/workspace-switcher.schemas from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/applications/gnome-panel.desktop from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/et/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/ga/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/he/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/pt_BR/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/sk/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > file /usr/share/locale/sl/LC_MESSAGES/gnome-panel-2.0.mo from install of gnome-panel-2.20.2-2.fc9 conflicts with file from package gnome-panel-2.20.1-1.fc8 > > - Gilboa Sorry for the noise. Should have sent it to -testing. - Gilboa From gilboad at gmail.com Sat Dec 22 16:49:14 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 22 Dec 2007 18:49:14 +0200 Subject: F8->Devel + SELinux unbootable. In-Reply-To: <1198341907.20340.18.camel@gilboa-home-dev.localdomain> References: <1198341907.20340.18.camel@gilboa-home-dev.localdomain> Message-ID: <1198342154.20340.26.camel@gilboa-home-dev.localdomain> On Sat, 2007-12-22 at 18:45 +0200, Gilboa Davara wrote: > Hello all, > > I've create a VMWare guest with F8/x86_64 on it and immediately upgraded > it to -devel. (Minus some small gnome-panel multi-lib breakage) > However, once I reboot the machine (and init finished it course) I got > an "ld 'x' re-spawning too fast" and when I try to ssh into the machine > I get greeted by "/bin/bash: Permission denied". > > If I disable SELinux things seem to work just fine. > > Oh, I've relabeled the FS (fixfiles relabel, tried again > with .autorelabel) but it didn't solve the problem. > > Any ideas? > - Gilboa > Sorry. Noise. Resending to -testing. - Gilboa From martin.sourada at seznam.cz Sat Dec 22 17:03:33 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 22 Dec 2007 18:03:33 +0100 Subject: Scrollbars rendering bug in Firefox? Message-ID: <1198343013.17725.12.camel@pc-notebook> Hi, I am currently in the process of remaking scrollbars for nodoka theme and I noticed strange issue when displayed in firefox. In F-8's firefox the secondary steppers are not displayed even if set in gtkrc, and the returned stepper ID is wrong - instead of stepper A it returns D and instead of D it returns A. See the attachments for more info. In Firefox 3 mozilla's nightly build there are A and D steppers OK, but the secondary ones are switched, so instead of B, C is rendered and otherwise. See the attachments for more info. In both firefox's the steppers are never disabled. See again attachments for more info. Is this a bug in firefox or somewhere else? In the clearlooks-gtk.png screenshots it is how it looks in most gtk applications, in the clearlooks-ephy.png sceenshots it is how it looks in epiphany from F-8 and in the clearlooks-ff3.png screenshots it is how it looks in firefox 3. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: clearlooks-ephy.png Type: image/png Size: 528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: clearlooks-ff3.png Type: image/png Size: 876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: clearlooks-gtk.png Type: image/png Size: 772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: steppers-id.png Type: image/png Size: 1067 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 lordmorgul at gmail.com Sat Dec 22 17:19:35 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 22 Dec 2007 09:19:35 -0800 Subject: kernels won't boot In-Reply-To: <200712220828.48202.sgrubb@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> Message-ID: <476D4727.3080606@gmail.com> Steve Grubb wrote: > On Saturday 22 December 2007 07:16:32 Build System wrote: >> kernel-2.6.24-0.123.rc6.fc9 >> --------------------------- >> * Fri Dec 21 2007 David Woodhouse >> - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing >> >> * Fri Dec 21 2007 John W. Linville >> - Yet another round of wireless updates... >> >> * Thu Dec 20 2007 Kyle McMartin >> - 2.6.24-rc6 > > > After build 81, I have not been able to boot any of the x86_64 rawhide > kernels. They all end with: > > Trying to resume from /sys/block/sda/sda3 > Unable to access resume device (/sys/block/sda/sda3) Are you actually hibernating and resuming from a diff kernel or what is going on here? It should not be trying to resume if you haven't had that kernel version booted before, looks like that might be the place to look for a what changes led to this. (and sorry I haven't tried to duplicate the prob yet) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From janina at rednote.net Sat Dec 22 17:40:41 2007 From: janina at rednote.net (Janina Sajka) Date: Sat, 22 Dec 2007 12:40:41 -0500 Subject: Firefox 3 Beta On x86_64--Does it work? Message-ID: <20071222174041.GB14303@rednote.net> Does the x86 FF3 work for anyone? It doesn't for me--but then it never did through the entire alpha cycle. To get a working FF3 on my two gui boxes, I have to manually retrieve i386 FF# and xul. Janina -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From myfedora at richip.dhs.org Sat Dec 22 17:48:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 22 Dec 2007 10:48:06 -0700 Subject: Firefox 3 Beta On x86_64--Does it work? In-Reply-To: <20071222174041.GB14303@rednote.net> References: <20071222174041.GB14303@rednote.net> Message-ID: <1198345686.29693.1.camel@localhost6.localdomain6> On Sat, 2007-12-22 at 12:40 -0500, Janina Sajka wrote: > Does the x86 FF3 work for anyone? It doesn't for me--but then it never > did through the entire alpha cycle. > > To get a working FF3 on my two gui boxes, I have to manually retrieve > i386 FF# and xul. Read my take here: https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01367.html In short, yes, though I compiled my own x86_64, ran i386 nspluginwrapper and have never tried the i386 FF3 binaries on an x86_64. -- Richi Plana From ndbecker2 at gmail.com Sat Dec 22 17:48:11 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Dec 2007 12:48:11 -0500 Subject: Firefox 3 Beta On x86_64--Does it work? References: <20071222174041.GB14303@rednote.net> Message-ID: Janina Sajka wrote: > Does the x86 FF3 work for anyone? It doesn't for me--but then it never > did through the entire alpha cycle. > > To get a working FF3 on my two gui boxes, I have to manually retrieve > i386 FF# and xul. > > Janina > Working for me - but, obviously, not all your favorite plugins will work. From myfedora at richip.dhs.org Sat Dec 22 17:54:52 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 22 Dec 2007 10:54:52 -0700 Subject: Fedora 8 review In-Reply-To: <1198257508.5619.10.camel@space-ghost.verbum.private> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <1198250188.1765.6.camel@ignacio.lan> <8278b1b0712210907u7b50f6a5hd0413b9c43767788@mail.gmail.com> <20071221171631.GB27601@redhat.com> <1198257508.5619.10.camel@space-ghost.verbum.private> Message-ID: <1198346092.29693.8.camel@localhost6.localdomain6> On Fri, 2007-12-21 at 12:18 -0500, Colin Walters wrote: > On Fri, 2007-12-21 at 17:16 +0000, Daniel P. Berrange wrote: > > On Fri, Dec 21, 2007 at 11:07:20AM -0600, King InuYasha wrote: > > > I would have to agree with Chris and Bryan regarding Anaconda and the icon > > > style. It seems that Anaconda has had more and more features tacked on it > > > since its inception so long ago. Has Anaconda ever been rewritten or has > > > anyone even considered rewriting Anaconda? > > http://www.joelonsoftware.com/articles/fog0000000069.html Let me first say that I have great respect for Joel Spolsky, but all the software rewrites I/we have done ended up with better, much more manageable software. Learned from the mistakes of the past and all that. One was a huge project that ended up with lesser lines of software that was much more easy to read. Another was ported to a slightly higher level language. Most just had subtle improvements that made the whole more elegant. If you're not smarter at the time you plan to do a rewrite, don't. -- Richi Plana From bloch at verdurin.com Sat Dec 22 16:42:14 2007 From: bloch at verdurin.com (Adam Huffman) Date: Sat, 22 Dec 2007 16:42:14 +0000 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <20071222164214.GE30935@asus.config> On Thu, 20 Dec 2007, Martin Stransky wrote: > Hello, > > Firefox 3 has finally landed in Rawhide. It's a slightly unpolished > version and we appreciate if you test it and report all issues to > bugzilla (like missing locales, broken plugins and so on). > > If you're interested and don't want to switch to rawhide, you can run > Firefox 3 on Fedora 8, too. Just download and compile the latest > xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install > firefox from rawhide. > I have installed it on F8 and it seems to have brought back the annoying behaviour of moving the Firefox window when opening a link. Is this Fedora-specific? From kevin.kofler at chello.at Sat Dec 22 18:06:59 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 18:06:59 +0000 (UTC) Subject: FeatureDictionary patches for KDE References: Message-ID: A small update: I wrote: > http://repo.calcforge.org/f9/kdelibs-3.5.8-kspell-hunspell.diff > The patch is preliminary, I still have to test that it works I did some testing now (thanks to LD_PRELOAD), it appears to work just fine. Kevin Kofler From tcallawa at redhat.com Sat Dec 22 18:15:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 22 Dec 2007 13:15:50 -0500 Subject: Firefox 3 Beta On x86_64--Does it work? In-Reply-To: <1198345686.29693.1.camel@localhost6.localdomain6> References: <20071222174041.GB14303@rednote.net> <1198345686.29693.1.camel@localhost6.localdomain6> Message-ID: <1198347350.6603.0.camel@localhost.localdomain> On Sat, 2007-12-22 at 10:48 -0700, Richi Plana wrote: > On Sat, 2007-12-22 at 12:40 -0500, Janina Sajka wrote: > > Does the x86 FF3 work for anyone? It doesn't for me--but then it never > > did through the entire alpha cycle. > > > > To get a working FF3 on my two gui boxes, I have to manually retrieve > > i386 FF# and xul. > > Read my take here: > https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01367.html > > In short, yes, though I compiled my own x86_64, ran i386 nspluginwrapper > and have never tried the i386 FF3 binaries on an x86_64. I'm running the i386 FF3 rawhide packages on x86_64 without problem (other than yum continually trying to replace them with x86_64 packages). ~spot From ndbecker2 at gmail.com Sat Dec 22 18:15:28 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Dec 2007 13:15:28 -0500 Subject: Firefox 3 Beta 2 in Rawhide References: <476A2656.5060704@redhat.com> Message-ID: I don't know what's causing this: gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet viewer: Failed to execute child process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such file or directory) So 2 things about this: 1) gcjwebplugin? I thought iced-tea replaced gcj. 2) Obviously that path is wrong - but I have clue where it came from To make things complicated, I have nspluginwrapper installed. But, I expect most Fedora x86_64 users also do. From ndbecker2 at gmail.com Sat Dec 22 18:50:12 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Dec 2007 13:50:12 -0500 Subject: Firefox 3 Beta 2 in Rawhide References: <476A2656.5060704@redhat.com> Message-ID: Neal Becker wrote: > I don't know what's causing this: > gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet > viewer: Failed to execute child > process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such > file or directory) > > So 2 things about this: > 1) gcjwebplugin? I thought iced-tea replaced gcj. > 2) Obviously that path is wrong - but I have clue where it came from > > To make things complicated, I have nspluginwrapper installed. But, I > expect most Fedora x86_64 users also do. > After removing nspluginwrapper, the problem is removed. BTW, I was testing using this page: http://www.java.com/en/download/help/testvm.xml From mjs at CLEMSON.EDU Sat Dec 22 19:28:21 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 22 Dec 2007 19:28:21 +0000 Subject: Vanilla kernel RPM? Message-ID: <1198351701.3594.23.camel@vincent52.localdomain> Some time back, there was a discussion on fedora-list about vanilla kernels. IIRC, Rahul offered to create an RPM for the vanilla kernel.org kernels with no Fedora patches or only security patches for those of us that wanted to test with vanilla kernels. I am wondering whatever happened to that proposal. I have a Thinkpad T61 with nVidia graphics. In F8, the machine refueses to suspend--it goes into suspend mode and then spontaneously comes out. This happens with the nVidia driver and the VESA driver (the nv driver still doesn't work 8^(...). In RHEL5, an identical machine running the VESA driver works perfectly. I'd like to try to help troubleshoot this (https://bugzilla.redhat.com/show_bug.cgi?id=254214), and I think having a vanilla kernel might be useful. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jwboyer at gmail.com Sat Dec 22 19:33:45 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 22 Dec 2007 13:33:45 -0600 Subject: Vanilla kernel RPM? In-Reply-To: <1198351701.3594.23.camel@vincent52.localdomain> References: <1198351701.3594.23.camel@vincent52.localdomain> Message-ID: <20071222133345.49eea037@hansolo.jdub.homelinux.org> On Sat, 22 Dec 2007 19:28:21 +0000 Matthew Saltzman wrote: > Some time back, there was a discussion on fedora-list about vanilla > kernels. IIRC, Rahul offered to create an RPM for the vanilla > kernel.org kernels with no Fedora patches or only security patches for > those of us that wanted to test with vanilla kernels. I am wondering > whatever happened to that proposal. > > I have a Thinkpad T61 with nVidia graphics. In F8, the machine refueses > to suspend--it goes into suspend mode and then spontaneously comes out. > This happens with the nVidia driver and the VESA driver (the nv driver > still doesn't work 8^(...). In RHEL5, an identical machine running the > VESA driver works perfectly. > > I'd like to try to help troubleshoot this > (https://bugzilla.redhat.com/show_bug.cgi?id=254214), and I think having > a vanilla kernel might be useful. > The specfile in rawhide has a vanilla option. All you have to do is run: make vanilla-$TARGET And it will build a vanilla kernel (with only patches for the config mechanisms IIRC). josh From nicolas.mailhot at laposte.net Sat Dec 22 19:39:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 22 Dec 2007 20:39:52 +0100 Subject: Vanilla kernel RPM? In-Reply-To: <20071222133345.49eea037@hansolo.jdub.homelinux.org> References: <1198351701.3594.23.camel@vincent52.localdomain> <20071222133345.49eea037@hansolo.jdub.homelinux.org> Message-ID: <1198352393.14553.2.camel@rousalka.dyndns.org> Le samedi 22 d?cembre 2007 ? 13:33 -0600, Josh Boyer a ?crit : > On Sat, 22 Dec 2007 19:28:21 +0000 > Matthew Saltzman wrote: > The specfile in rawhide has a vanilla option. All you have to do is > run: > > make vanilla-$TARGET > > And it will build a vanilla kernel (with only patches for the config > mechanisms IIRC). Does it really work? I know I had to move the oldconfig patch when I adapted the specfile to mm kernels (patch already posted, can rebase and re-post if someone wants to add mm build capabilities to fedora spec) -- 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 sgrubb at redhat.com Sat Dec 22 19:43:11 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Dec 2007 14:43:11 -0500 Subject: kernels won't boot In-Reply-To: <476D4727.3080606@gmail.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <476D4727.3080606@gmail.com> Message-ID: <200712221443.12091.sgrubb@redhat.com> On Saturday 22 December 2007 12:19:35 Andrew Farris wrote: > > After build 81, I have not been able to boot any of the x86_64 rawhide > > kernels. They all end with: > > > > Trying to resume from /sys/block/sda/sda3 > > Unable to access resume device (/sys/block/sda/sda3) > > Are you actually hibernating and resuming from a diff kernel or what is > going on here? Nope. I've never knowingly used hibernate. This machine is almost always just booted to runlevel 3. I just do the yum update followed by a reboot command. > It should not be trying to resume if you haven't had that kernel version > booted before, looks like that might be the place to look for a what changes > led to this. ?(and sorry I haven't tried to duplicate the prob yet) If no one else is seeing this, I might try to hook up a serial cable so that I can record the whole boot attempt and see where the first sign of trouble is. -Steve From lesmikesell at gmail.com Sat Dec 22 20:04:29 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 22 Dec 2007 14:04:29 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: References: <20071218003853.GA12552@tango.0pointer.de> <20071218082402.GB2530@free.fr> <20071218110045.GD1518@tango.0pointer.de> <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> Message-ID: <476D6DCD.2070202@gmail.com> Robin Norwood wrote: >> >> I know that some people want to continue playback when they switch to >> a different session. However, I do not believe that this should be the >> default. Maybe we will add support for this in a later version >> somehow, but I do believe the right approach is to make sure that >> inactive sessions cannot spy on the user who's active on the seat. > > Especially since the controls for the music playback are in the other > session. The use case that I run into with F7 is: > > o Offspring #1 starts Battle For Wesnoth as his user. > o Offspring #2 takes over the computer, switches to his own user, and > wants to play some other game. > > For F7, the Wesnothy music keeps playing, and, to turn it off, the > computer needs to switch back to Offspring #1's account, log in, and > close his game. Then Offspring #2 can have sound. > > This sucks. I haven't installed F8 on The Offsprings computer yet, (I > know, I know), but from what I understand, Pulseaudio should fix this > very nicely. And now for the opposite point of point of view... I find it very disturbing that if I have itunes on a mac playing a playlist with the output going to a receiver/speakers for the room, it is rudely interrupted if my wife wants to check her email. > It would be just as bad if I were playing music. If a song I really > hate comes up, and I don't have Offspring #1's password, there's no way > to skip it. Errr, if you don't like a song, don't schedule it to be played. > Terrible. I really can't understand how anyone would want > the default behavior to be different. > > When some users might want audio from one user to keep playing as logged > into another user, it sounds like they have to do some manual tweaks. > No big deal. I can understand a system that has barely outgrown single-user concepts or something designed as a toy for kids that don't know enough to clean up after themselves making abrupt decisions based on guesswork about what you might sometimes want. I don't understand it as default behavior for a system that is otherwise elegant in multi-user, multi-tasking operation and doing what you tell it to do. If I want it to to stop playing music that I've started, I'll tell it to, thank you. -- Les Mikesell lesmikesell at gmail.com From jwboyer at gmail.com Sat Dec 22 20:10:49 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 22 Dec 2007 14:10:49 -0600 Subject: Vanilla kernel RPM? In-Reply-To: <1198352393.14553.2.camel@rousalka.dyndns.org> References: <1198351701.3594.23.camel@vincent52.localdomain> <20071222133345.49eea037@hansolo.jdub.homelinux.org> <1198352393.14553.2.camel@rousalka.dyndns.org> Message-ID: <20071222141049.359b1931@hansolo.jdub.homelinux.org> On Sat, 22 Dec 2007 20:39:52 +0100 Nicolas Mailhot wrote: > > Le samedi 22 d?cembre 2007 ? 13:33 -0600, Josh Boyer a ?crit : > > On Sat, 22 Dec 2007 19:28:21 +0000 > > Matthew Saltzman wrote: > > > The specfile in rawhide has a vanilla option. All you have to do is > > run: > > > > make vanilla-$TARGET > > > > And it will build a vanilla kernel (with only patches for the config > > mechanisms IIRC). > > Does it really work? I know I had to move the oldconfig patch when I > adapted the specfile to mm kernels (patch already posted, can rebase and > re-post if someone wants to add mm build capabilities to fedora spec) It worked for me a while ago. Though I wasn't adding patches. I was just building what was in CVS without the extra patches. josh From valent.turkovic at gmail.com Sat Dec 22 20:43:57 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Dec 2007 21:43:57 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> Message-ID: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> On 12/20/07, Eric Mesa wrote: > I also use K3B. In comparison all of the Gnome burners are crap. (And I > primarily use Gnome) > > > On Dec 20, 2007 9:13 AM, Marc Wiriadisastra wrote: > > > > > > On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > > > > > It has been brought to my attention > > > > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/ > ) that K3b is > > > no longer available on the DVD images (since the Core-Extras merge). As > far as > > > I can tell, this is because it is marked only as "optional" and not > "default" > > > in the sound-and-video group? As K3b is probably the best Free CD/DVD > burning > > > program around, the burning tool of choice of most KDE users and even > several > > > GNOME users, I think it would be great if this could be put back onto > the DVD > > > images in F9. Can this be added to the pungi kickstart config? > > > > > > Kevin Kofler > > > > > +1 and I run Gnome +100 :) I asked for including K3b on Fedora Live CD and got chewed for it! Then I asked at least for Brassero and the answer was also no :( The reasoning was that there is already burning app on Gnome, the nautils gnome burning monstrocity :( Please put k3b or brassero on Fedora Live CD, please. Valent. -- 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 nicolas.mailhot at laposte.net Sat Dec 22 20:43:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 22 Dec 2007 21:43:57 +0100 Subject: Vanilla kernel RPM? In-Reply-To: <20071222141049.359b1931@hansolo.jdub.homelinux.org> References: <1198351701.3594.23.camel@vincent52.localdomain> <20071222133345.49eea037@hansolo.jdub.homelinux.org> <1198352393.14553.2.camel@rousalka.dyndns.org> <20071222141049.359b1931@hansolo.jdub.homelinux.org> Message-ID: <1198356237.15145.3.camel@rousalka.dyndns.org> Le samedi 22 d?cembre 2007 ? 14:10 -0600, Josh Boyer a ?crit : > On Sat, 22 Dec 2007 20:39:52 +0100 > Nicolas Mailhot wrote: > > > > > Le samedi 22 d?cembre 2007 ? 13:33 -0600, Josh Boyer a ?crit : > > > On Sat, 22 Dec 2007 19:28:21 +0000 > > > Matthew Saltzman wrote: > > > > > The specfile in rawhide has a vanilla option. All you have to do is > > > run: > > > > > > make vanilla-$TARGET > > > > > > And it will build a vanilla kernel (with only patches for the config > > > mechanisms IIRC). > > > > Does it really work? I know I had to move the oldconfig patch when I > > adapted the specfile to mm kernels (patch already posted, can rebase and > > re-post if someone wants to add mm build capabilities to fedora spec) > > It worked for me a while ago. Though I wasn't adding patches. I was > just building what was in CVS without the extra patches. IIRC the spec logic relies on a special make oldconfig target which is only available if the non-interactive oldconfig patch is applied on the kernel. Which means this particular patch can not be skipped even in the vanilla case. At least when I build mm kernels I need to kill every fedora patch except this one for things to work -- 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 valent.turkovic at gmail.com Sat Dec 22 21:07:45 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Dec 2007 22:07:45 +0100 Subject: Fedora and lack of audio communication with the community Message-ID: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> Hi, first excuse me if this is the wrong mailing list. If there is fedora-marketing or some similar :) mailing list please point me in the right direction. Fedora has a really strong emphasize on communication and openness, and that is true in most part from the open communication on mailing lists and irc channels. AFAIK there is no fedora podcast, there was one unofficial but it died and it produced only a few (great) shows. I also rarely see and fedora exposure in other podcasts; there are fedora reviews and usually podcast hosts do a interview with Max Spevack once or twice a year and that is it. Why? There are lots of great fedora community members, fedora devels and redhat people that would make great guests on lots of podcasts... I believe they should approach podcast hosts with some interesting Fedora related project, new feature or any other interesting topic and go from there... It would be even better if Fedora had an official podcast, or even better a few official and few unofficial :) I listen to few of the most interesting linux podcasts and one think that made me write this post was the Fedora 8 review and KDE4 review by Chris and Bryan form Linux Action Show podcast. They made a great show and reviewed Fedora 8 and gave their comments what they see as bad and good in Fedora 8 (LAS episode 67). They also said that KDE4 RC1 basically sucks or it should be still called beta not RC1. In the latest episode 68 Aaron Seigo from the KDE project got on as s guest to explain what is going on with the KDE 4.0 and that was a really revealing episode and really informative on multiple levels. This could be their best show to date. It would be great if somebody from Fedora agreed to do an interview for Linux Action Show regarding issues they have with Fedora 8. That would be a GREAT thing for us users and fans of Fedora... Thank you, Valent from Croatia. -- 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 bruno at wolff.to Sat Dec 22 21:19:21 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 22 Dec 2007 15:19:21 -0600 Subject: anaconda updates / respins (was: Re: Delays in package processing) In-Reply-To: <20071222100153.3e0ce75a@redhat.com> References: <20071221162517.GF8355@nostromo.devel.redhat.com> <20071221184226.GD27601@redhat.com> <20071221135124.470ba99b@redhat.com> <604aa7910712211059m2dde15e3lc2e5c44abec29ff5@mail.gmail.com> <3170f42f0712211122hbc93eadsad6640e15f110dec@mail.gmail.com> <1198295892.7443.94.camel@study.mwiriadi.id.au> <3170f42f0712212345x63734066w97e8392becad1258@mail.gmail.com> <20071222083201.0885f0a9@redhat.com> <476D15B0.8020302@leemhuis.info> <20071222100153.3e0ce75a@redhat.com> Message-ID: <20071222211921.GA14940@wolff.to> On Sat, Dec 22, 2007 at 10:01:53 -0500, Jesse Keating wrote: > > That's what Unity does, and I applaud them. Is there a way we can get Unity's work back into Fedora? If Fedora isn't using Anaconda to do official respins, it seems like letting Unity's backports get into the official Anaconda would be low risk. Its biggest impact would be on the people using revisor who are people that are going to want the fixes and who can deal with regressions if there are any. Publishing an updates.img as part of a package would also be nice. P.S. This weekend my plan is to create a custom Games Spin combining Unity's installer and updates.img with Everything, Updates and Updates-Testing using a slightly modified kickstart file (to add uqm to the Games Spin). Then hand out a few for Christmas to Relatives and Friends. In return for Unity's help, I'll try to see if I can do one of their test cases that hasn't been tested yet. From kevin.kofler at chello.at Sat Dec 22 21:30:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 21:30:08 +0000 (UTC) Subject: Fedora and lack of audio communication with the community References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> Message-ID: Valent Turkovic gmail.com> writes: > first excuse me if this is the wrong mailing list. If there is > fedora-marketing or some similar :) mailing list please point me in > the right direction. There is a fedora-marketing-list indeed. But to answer your suggestion: I personally don't understand why all the fuss about podcasts, IMHO written plaintext is more convenient for things like that (easier to skim over, easier to find a section when going back to something you already read, easier to search automatically (fulltext search), easier to find in a search engine too (fulltext indexing), no need to either put headphones on or have everyone around listen to the podcast too whether they want it or not, can be consumed on a machine with no sound at all (as in some offices) and of course faster to download too). Kevin Kofler From stickster at gmail.com Sat Dec 22 21:42:31 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 22 Dec 2007 16:42:31 -0500 Subject: Wiki Migration In-Reply-To: <1198209048.3593.157.camel@erato.phig.org> References: <4762E5F5.4010206@redhat.com> <604aa7910712141235y63a93c38u30185aa1f480208d@mail.gmail.com> <1198209048.3593.157.camel@erato.phig.org> Message-ID: <1198359751.5339.42.camel@localhost.localdomain> On Thu, 2007-12-20 at 19:50 -0800, Karsten Wade wrote: > On Fri, 2007-12-14 at 11:35 -0900, Jeff Spaleta wrote: > > If we were going to do it this way, is there any a-priori > > restructuring that should be done in terms of wiki page namespace in > > an effort to organize the content a bit? Id hate to take the same > > pile and just move it into another room so that it still looks like > > the same pile of stuff..but in a different room. > > We can do this regardless of changing anything. Sounds like a fun > hackfest session[1] at FUDCon; I'll host. :) Yes yes yes. I'll be there. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 bpepple at fedoraproject.org Sat Dec 22 21:13:13 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 22 Dec 2007 16:13:13 -0500 Subject: Fedora and lack of audio communication with the community In-Reply-To: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> Message-ID: <1198357993.2862.10.camel@kennedy> On Sat, 2007-12-22 at 22:07 +0100, Valent Turkovic wrote: > first excuse me if this is the wrong mailing list. If there is > fedora-marketing or some similar :) mailing list please point me in > the right direction. fedora-marketing-list at redhat.com 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 kevin.kofler at chello.at Sat Dec 22 21:58:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Dec 2007 21:58:05 +0000 (UTC) Subject: FeatureDictionary patches for KDE References: Message-ID: These patches have now been built for Rawhide and should show up in the public Rawhide in the next daily push. For the plugin-based architectures (KSpell2, Sonnet), we're now building the enchant backends only. (I disabled the Sonnet aspell backend and the KSpell2 aspell and ispell backends which were previously being built.) For the legacy KSpell (which uses command-line tools), I changed kde-settings to make hunspell the default. Kevin Kofler From valent.turkovic at gmail.com Sat Dec 22 23:08:36 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 23 Dec 2007 00:08:36 +0100 Subject: Fedora and lack of audio communication with the community In-Reply-To: <1198357993.2862.10.camel@kennedy> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <1198357993.2862.10.camel@kennedy> Message-ID: <64b14b300712221508n79e9b0d6pbd35b006df3ef7cb@mail.gmail.com> On 12/22/07, Brian Pepple wrote: > On Sat, 2007-12-22 at 22:07 +0100, Valent Turkovic wrote: > > first excuse me if this is the wrong mailing list. If there is > > fedora-marketing or some similar :) mailing list please point me in > > the right direction. > > fedora-marketing-list at redhat.com > > Later, > /B > -- Oh, thank you. But it stil believe that devels should read this because they are the ones that I would like to hear on some of the podcasts out there... -- 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 alexl at users.sourceforge.net Sat Dec 22 23:12:25 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 22 Dec 2007 16:12:25 -0700 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: (Neal Becker's message of "Sat\, 22 Dec 2007 10\:19\:41 -0500") References: <476A2656.5060704@redhat.com> Message-ID: >>>>> "NB" == Neal Becker writes: NB> Miro needs updating, I think. (This is on f8) --> Finished Dependency Resolution NB> Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by NB> package Miro Unfortunately this isn't as simple as a rebuild, this requires upstream changes to enable Miro to compile against xulrunner: https://bugzilla.redhat.com/show_bug.cgi?id=393521 There's a minimal patch on that bug, but it's incomplete and will need further work upstream to get it work properly (according to Martin Stransky, xulrunner maintainer). I've filed this bug upstream: http://bugzilla.pculture.org/show_bug.cgi?id=9370 but have had no response yet. (I'll try to bug the Miro maintainers on IRC). Many packages don't current compile out of the box against xulrunner unfortunately and require patches and/or adding support from-scratch in upstream, see the full list here: http://fedoraproject.org/wiki/Releases/FeatureXULRunner This will take a *lot* of work from various packagers to make sure that F-9 works out of the box. With all the packages that used to build against firefox and we should probably bug all those package maintainers to test the various packages and/or report things against upstream to give them time to fix them so these packages work properly. Otherwise, I fear, Release Engineering will be forced drop them from the next release (at least from the the final package list). Alex From mzerqung at 0pointer.de Sat Dec 22 23:13:01 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 23 Dec 2007 00:13:01 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <476D6DCD.2070202@gmail.com> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> Message-ID: <20071222231301.GB14315@tango.0pointer.de> On Sat, 22.12.07 14:04, Les Mikesell (lesmikesell at gmail.com) wrote: >> Terrible. I really can't understand how anyone would want >> the default behavior to be different. >> When some users might want audio from one user to keep playing as logged >> into another user, it sounds like they have to do some manual tweaks. >> No big deal. > > I can understand a system that has barely outgrown single-user concepts or > something designed as a toy for kids that don't know enough to clean up > after themselves making abrupt decisions based on guesswork about what you > might sometimes want. I don't understand it as default behavior for a > system that is otherwise elegant in multi-user, multi-tasking operation and > doing what you tell it to do. If I want it to to stop playing music that > I've started, I'll tell it to, thank you. Could we please just stop this ever-repeating discussion? I already wrote multiple times that I am aware that some people would like the music to continue to play while you switch sessions. And I also wrote multiple times that I will eventually add support for that, but it is not high-priority for me. I do believe that exclusive acccess to the audio devices should be our focus for now. (And I am not the only one thinking that) So, that is as good as it gets for now. If you are not happy with my choice of priorities, then feel free to contribute, I am happy to merge all (good quality) patches. This is Free Software after all, it's all about scratching your itches! Also, if multi-user Fedora behaves this way or that way by default -- how many people do you think will even notice? You're making way to much fuss about this minor aspect of f-u-s. Please let's stay focused and spend more time on actually hacking instead of reading and replying to multi-week-long flamewars! Thank you very much, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From drago01 at gmail.com Sat Dec 22 23:16:40 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 00:16:40 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default .. From valent.turkovic at gmail.com Sat Dec 22 23:18:59 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 23 Dec 2007 00:18:59 +0100 Subject: Fedora and lack of audio communication with the community In-Reply-To: References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> Message-ID: <64b14b300712221518r6ae3dc6eh7bf6143f88bb06f1@mail.gmail.com> On 12/22/07, Kevin Kofler wrote: > Valent Turkovic gmail.com> writes: > > first excuse me if this is the wrong mailing list. If there is > > fedora-marketing or some similar :) mailing list please point me in > > the right direction. > > There is a fedora-marketing-list indeed. > > But to answer your suggestion: I personally don't understand why all the fuss > about podcasts, IMHO written plaintext is more convenient for things like that > (easier to skim over, easier to find a section when going back to something you > already read, easier to search automatically (fulltext search), easier to find > in a search engine too (fulltext indexing), no need to either put headphones on > or have everyone around listen to the podcast too whether they want it or not, > can be consumed on a machine with no sound at all (as in some offices) and of > course faster to download too). > > Kevin Kofler > Try reading while on a bike :) or while driving... I don't sit all day at a computer screen, but there days that I do. When I'm at a computer I usually need something done and can't waste time reading reviews, blog posts and articles. I work out in the field, going to meetings, connecting cables, driving in the car... and during all those things (or in between) I can listen because I have my mind and ears free but not my eyes and hands. I find podcasts immensely valuable mean of getting news, reviews, fun and new data... Audio and podcasts are really nice medium for more than one author to give their opinion on one subject where text is usually only single point of view. Audio with more that one host give multiple, different and therefore more indepth views on subject at hand. I don't think that podcast replace text but there are places where podcasts have real multiple advantages over written (online or printed) text. And also you can take in account disabled and blind people who also benefit from audio medium. Valent. -- 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 denis at poolshark.org Sat Dec 22 23:27:21 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 23 Dec 2007 00:27:21 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> Message-ID: <476D9D59.30001@poolshark.org> Alex Lancaster wrote: > This will take a *lot* of work from various packagers to make sure > that F-9 works out of the box. With all the packages that used to > build against firefox and we should probably bug all those package > maintainers to test the various packages and/or report things against > upstream to give them time to fix them so these packages work > properly. Since i maintain galeon, i got word from an upstream developer that xulrunner is still not exactly in a nice state to work with. To quote him: "I'm holding off on this until mozilla sorts out the microb problem. Apparently a good chunk of the brokenness is due to a bunch of unreviewed microb (the n800 browser) patches being committed. They claim they are going to back them out. Hopefully after that, [galeon] won't be so crippled.". Galeon now compiles thanks to Martin's patch, but it still has a number of issues and disabled features.. I know almost nothing about mozilla/xulrunner upstream development, but I have to ask: it's not just them (the packages that depend on firefox) that have to be ready for xulrunner, will xulrunner also be ready for them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?) > Otherwise, I fear, Release Engineering will be forced drop > them from the next release (at least from the the final package list) If it comes to that, I hope we can debate whether it should not be xulrunner that gets dropped and firefox-devel restored (assuming that's even possible). -denis From galibert at pobox.com Sat Dec 22 23:40:01 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sun, 23 Dec 2007 00:40:01 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222231301.GB14315@tango.0pointer.de> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> Message-ID: <20071222234001.GA4116@dspnet.fr.eu.org> On Sun, Dec 23, 2007 at 12:13:01AM +0100, Lennart Poettering wrote: > I already wrote multiple times that I am aware that some people would > like the music to continue to play while you switch sessions. And I > also wrote multiple times that I will eventually add support for that, > but it is not high-priority for me. Eventually, a clear answer to my "Can PA do this?" question. Thanks. Now, to be a little clearer: is PA grabbing the device as soon as the user session is active, or only when sound needs to be played? The latter would be equivalent to the previous dmix situation. OG. From lesmikesell at gmail.com Sat Dec 22 23:40:20 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 22 Dec 2007 17:40:20 -0600 Subject: Fedora and lack of audio communication with the community In-Reply-To: References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> Message-ID: <476DA064.50603@gmail.com> Kevin Kofler wrote: > Valent Turkovic gmail.com> writes: >> first excuse me if this is the wrong mailing list. If there is >> fedora-marketing or some similar :) mailing list please point me in >> the right direction. > > There is a fedora-marketing-list indeed. > > But to answer your suggestion: I personally don't understand why all the fuss > about podcasts, IMHO written plaintext is more convenient for things like that > (easier to skim over, easier to find a section when going back to something you > already read, easier to search automatically (fulltext search), easier to find > in a search engine too (fulltext indexing), no need to either put headphones on > or have everyone around listen to the podcast too whether they want it or not, > can be consumed on a machine with no sound at all (as in some offices) and of > course faster to download too). One word: commuting. Podcasts do to talk radio (or the internet equivalent) what tivo does to television. While it is absurd to hope that an interesting personality will be chatting on a live broadcast and conclude at precisely the times you are trapped in your car for the daily commute, it is quite easy to subscribe to a podcast and automate the transfer of new content to your ipod/player. Then it is a matter of pushing the button to pause/continue at convenient times. It's also great if you work out regularly on a treadmill or similar device that doesn't require your full concentration. Sometimes way a person is saying comes across differently when you listen to an interview compared even to reading a transcript of the same thing. I tend to prefer the ones moderated by someone with actual broadcast experience like Leo Laporte or fast paced ones like CNET's Buzz Out Load. If you have access to a windows or mac box, fire up itunes and look at the huge (and free) selection aggregated at the itunes store. Most may be available by other means but that's the easiest way to browse a large choice in one place. I'm not sure if there is a pure-linux way to access this catalog or subscribe directly though. With itunes you click to subscribe and can configure it so new items automatically sync to an ipod when you connect to recharge and 'listened' podcasts are automatically deleted - and you can make a 'smart playlist' that keeps the newest items at the top. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Sat Dec 22 23:42:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 18:42:24 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222234001.GA4116@dspnet.fr.eu.org> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> <20071222234001.GA4116@dspnet.fr.eu.org> Message-ID: <20071222184224.559b7e6a@redhat.com> On Sun, 23 Dec 2007 00:40:01 +0100 Olivier Galibert wrote: > or only when sound needs to be played? Only when sound is needed, then it releases the device. -- 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 drago01 at gmail.com Sat Dec 22 23:42:49 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 00:42:49 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222234001.GA4116@dspnet.fr.eu.org> References: <4767C13C.4060601@poolshark.org> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> <20071222234001.GA4116@dspnet.fr.eu.org> Message-ID: On Dec 23, 2007 12:40 AM, Olivier Galibert wrote: > On Sun, Dec 23, 2007 at 12:13:01AM +0100, Lennart Poettering wrote: > > I already wrote multiple times that I am aware that some people would > > like the music to continue to play while you switch sessions. And I > > also wrote multiple times that I will eventually add support for that, > > but it is not high-priority for me. > > Eventually, a clear answer to my "Can PA do this?" question. Thanks. > > Now, to be a little clearer: is PA grabbing the device as soon as the > user session is active, or only when sound needs to be played? The > latter would be equivalent to the previous dmix situation. PA releases the sound devices after being idle for 1 sec (no sound played for 1 sec) From jkeating at redhat.com Sat Dec 22 23:43:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 18:43:09 -0500 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222184224.559b7e6a@redhat.com> References: <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> <20071222234001.GA4116@dspnet.fr.eu.org> <20071222184224.559b7e6a@redhat.com> Message-ID: <20071222184309.78f962f0@redhat.com> On Sat, 22 Dec 2007 18:42:24 -0500 Jesse Keating wrote: > > or only when sound needs to be played? > > Only when sound is needed, then it releases the device. Although for full disclosure, ConsoleKit and PolicyKit will hand over ACLs to the new user at login 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 galibert at pobox.com Sat Dec 22 23:51:37 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sun, 23 Dec 2007 00:51:37 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222184224.559b7e6a@redhat.com> References: <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> <20071222234001.GA4116@dspnet.fr.eu.org> <20071222184224.559b7e6a@redhat.com> Message-ID: <20071222235137.GC4116@dspnet.fr.eu.org> On Sat, Dec 22, 2007 at 06:42:24PM -0500, Jesse Keating wrote: > Only when sound is needed, then it releases the device. Good, so that makes it equivalent to the previous alsa situation. Excellent. So work can be done to give it better simultaneous multiuser support, but the situation in that area is no worse than what was previously, and we get PA's advantages. OG. From stickster at gmail.com Sun Dec 23 00:11:58 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 22 Dec 2007 19:11:58 -0500 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <1198002102.13693.12.camel@cutter> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <1197995889.19318.47.camel@localhost.localdomain> <200712181205.15928.silfreed@silfreed.net> <47680C89.7060607@redhat.com> <1198002102.13693.12.camel@cutter> Message-ID: <1198368718.5339.89.camel@localhost.localdomain> On Tue, 2007-12-18 at 13:21 -0500, seth vidal wrote: > Okay, but I want everyone to know about an important strategic > decision we have to make. > > Fedora 11 MUST be named "ours goes to" > Fedora "ours goes to" 11 > Optionally it could be named: Lumbar Puncture. > > > So we have to get from here to there. :) Fedora 9 == Gryphon (like Werewolf, a mythical creature) Fedora 10 == Eruption (like a gryphon, a feature of volcanoes) Fedora 11 == "Ours Goes To" (like "Eruption," a heavy metal cliche) Q.E.D. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 lesmikesell at gmail.com Sun Dec 23 00:23:28 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 22 Dec 2007 18:23:28 -0600 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071222231301.GB14315@tango.0pointer.de> References: <20071218113735.GA20976@free.fr> <4767C13C.4060601@poolshark.org> <20071218182916.GE28630@tango.0pointer.de> <4768181E.9000503@poolshark.org> <1198007910.11811.10.camel@rousalka.dyndns.org> <20071218231411.GH3360@tango.0pointer.de> <1198023829.19318.80.camel@localhost.localdomain> <20071219091317.GB9741@tango.0pointer.de> <476D6DCD.2070202@gmail.com> <20071222231301.GB14315@tango.0pointer.de> Message-ID: <476DAA80.8030006@gmail.com> Lennart Poettering wrote: >> I can understand a system that has barely outgrown single-user concepts or >> something designed as a toy for kids that don't know enough to clean up >> after themselves making abrupt decisions based on guesswork about what you >> might sometimes want. I don't understand it as default behavior for a >> system that is otherwise elegant in multi-user, multi-tasking operation and >> doing what you tell it to do. If I want it to to stop playing music that >> I've started, I'll tell it to, thank you. > > Could we please just stop this ever-repeating discussion? Maybe... But could you provide some assurance that your choice of behavior will either be well-documented or changed before being pushed into RHEL (and thus its clones)? > I already wrote multiple times that I am aware that some people would > like the music to continue to play while you switch sessions. And I > also wrote multiple times that I will eventually add support for that, > but it is not high-priority for me. > > I do believe that exclusive acccess to the audio devices should be our > focus for now. (And I am not the only one thinking that) Exclusive access isn't the issue (although I'd prefer multiplexing with an option to grab a kernel lock). Changing it as a side effect of mostly-unrelated events is. > So, that is as good as it gets for now. I'm very happy to know that the system includes the option to be configured so it takes away access whimsically - my complaint is not specifically about PA or its capabilities, just that this very un-unixlike and thus unexpected behavior is the default embedded in the distribution. > If you are not happy with my choice of priorities, then feel free to > contribute, I am happy to merge all (good quality) patches. This is > Free Software after all, it's all about scratching your itches! > > Also, if multi-user Fedora behaves this way or that way by default -- > how many people do you think will even notice? You're making way to > much fuss about this minor aspect of f-u-s. The fact that most people won't know is precisely my problem with this. In my opinion, people should damn well know what to expect from a unix-like OS. If everyone really thinks that the system should no longer do precisely what you tell it to do, please get that philosophy into the release notes and other publicity, or even better, make it a clear choice to be made at install/configuration time. I might even be convinced it was a good thing and choose it myself for some situations if it was a well-explained option. > Please let's stay focused and spend more time on actually hacking > instead of reading and replying to multi-week-long flamewars! I think you should expect flames about any unexpected behavior changes. What kind of person _wants_ surprises from his computer? This doesn't mean that changes can't be improvements, but they are better if they aren't surprising. -- Les Mikesell lesmikesell at gmail.com From loupgaroublond at gmail.com Sun Dec 23 00:24:11 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 22 Dec 2007 19:24:11 -0500 Subject: Fedora 8 review (OT, Changing X' configuration) In-Reply-To: <1198312839.20340.3.camel@gilboa-home-dev.localdomain> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <64b14b300712211627y15dd9d02n718544a5150923ec@mail.gmail.com> <1198284270.2749.8.camel@localhost.localdomain> <7f692fec0712211719y2bd33eb5h772ad123988f6e3@mail.gmail.com> <1198312839.20340.3.camel@gilboa-home-dev.localdomain> Message-ID: <7f692fec0712221624g5fb62617mbb54c1e7b86d4e25@mail.gmail.com> On Dec 22, 2007 3:40 AM, Gilboa Davara wrote: > > Let's not forget the moment where I'm standing in front of a class > > about to give a presentation, and I have to reboot because I can't get > > X to recognize the projector without that. We're waiting for it to > > reboot, and I start telling them stories about how the Fedora Art team > > works, and just keeping people interested until I start the > > presentation. > > > > Let's see someone using Wintendo do that :P > > > > -Yaakov > > > > Restart?!?!?! > Shouldn't Zap (Ctrl-Alt-BS) or Logout work? > > I can't remember ever having to restart the machine in-order to change > something in X's configuration... (including driver.ko and X.org version > updates) It's an Intel chip, GMA965. I probably could have restarted X, but you never know. Gateway puts funny stuff in their BIOSes, and it seemed like it would be a better idea to do something I know would work than wait on 5 possibilities. -Yaakov From cra at WPI.EDU Sun Dec 23 00:43:59 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 22 Dec 2007 19:43:59 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> Message-ID: <20071223004359.GF28987@angus.ind.WPI.EDU> On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote: > For me it refuses to load any site until I change > "network.dns.disableIPv6" to "true" > So I propose to make this the default .. Works fine for me without doing that. Let's not supposedly "fix" things by crippling new functionality and discouraging adoption of new technology, shall we? What is the real problem here? We should be focused on fixing that instead. From drago01 at gmail.com Sun Dec 23 00:46:48 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 01:46:48 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071223004359.GF28987@angus.ind.WPI.EDU> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> Message-ID: On Dec 23, 2007 1:43 AM, Chuck Anderson wrote: > > On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote: > > For me it refuses to load any site until I change > > "network.dns.disableIPv6" to "true" > > So I propose to make this the default .. > > Works fine for me without doing that. Let's not supposedly "fix" > things by crippling new functionality and discouraging adoption of new > technology, shall we? What is the real problem here? We should be > focused on fixing that instead. the problem is that it does not work with some ISP .. and thats not something that we can fix that easily (well or we can try to add some fallback logic) From lordmorgul at gmail.com Sun Dec 23 02:44:10 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 22 Dec 2007 18:44:10 -0800 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> Message-ID: <476DCB7A.4010606@gmail.com> drago01 wrote: > On Dec 23, 2007 1:43 AM, Chuck Anderson wrote: >> On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote: >>> For me it refuses to load any site until I change >>> "network.dns.disableIPv6" to "true" >>> So I propose to make this the default .. >> Works fine for me without doing that. Let's not supposedly "fix" >> things by crippling new functionality and discouraging adoption of new >> technology, shall we? What is the real problem here? We should be >> focused on fixing that instead. > > the problem is that it does not work with some ISP .. and thats not > something that we can fix that easily (well or we can try to add some > fallback logic) Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd suggest making sure your local network configuration has IPv6 disabled and see if that firefox now does not care whether IPv6 is not disabled. If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't configure an address for the family). The application should not choose to try and generate IPv6 traffic if it is not told you have IPv6 connectivity. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From subhodip at fedoraproject.org Sun Dec 23 08:37:32 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sun, 23 Dec 2007 14:07:32 +0530 Subject: what with mock ?? Message-ID: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> Hi ! every time i try to download fedora-packager ....yum fails giving the following error messege Error Downloading Packages: mock - 0.8.17-1.fc8.i386: failure: mock-0.8.17-1.fc8.i386.rpm from updates: [Errno 256] No more mirrors to try. while error from mirrors are " HTTP Error 404: Not Found" .. Is mock not available yet ?? what am i missing here ?? -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From stransky at redhat.com Sun Dec 23 08:50:51 2007 From: stransky at redhat.com (Martin Stransky) Date: Sun, 23 Dec 2007 09:50:51 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198298613.3557.32.camel@hinge.endoframe.net> References: <476A2656.5060704@redhat.com> <1198298613.3557.32.camel@hinge.endoframe.net> Message-ID: <476E216B.1040209@redhat.com> Braden McDaniel wrote: > On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote: > > [snip] > >> If you're a package maintainer and your package already uses xulrunner, >> please rebuild it against the new rawhide version. Xulrunner directory >> has been changed and many gecko packages (if not all) are linked with >> --rpath linker directive. As long as rpath is used you have to rebuild >> gecko-libs based packages after each xulrunner change so please consider >> to remove it. Gecko libraries are registered system wide by >> /etc/ld.so.conf.d and rpath should not be necessary in rawhide. > > But isn't it the case that the libraries in question do not have > soversions? > > If the rpath is eliminated, how do we know when things really *do* need > to break? gecko-libs 1.9 exports only frozen interfaces so ideally we don't need to rebuild any package unless we move to a completely new gecko (firefox 4 ;-)) From stransky at redhat.com Sun Dec 23 09:06:08 2007 From: stransky at redhat.com (Martin Stransky) Date: Sun, 23 Dec 2007 10:06:08 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476D9D59.30001@poolshark.org> References: <476A2656.5060704@redhat.com> <476D9D59.30001@poolshark.org> Message-ID: <476E2500.8000205@redhat.com> Denis Leroy wrote: > Since i maintain galeon, i got word from an upstream developer that > xulrunner is still not exactly in a nice state to work with. To quote > him: "I'm holding off on this until mozilla sorts out the microb > problem. Apparently a good chunk of the brokenness is due to a bunch of > unreviewed microb (the n800 browser) patches being committed. They claim > they are going to back them out. Hopefully after that, [galeon] won't be > so crippled.". > I know almost nothing about mozilla/xulrunner upstream development, but > I have to ask: it's not just them (the packages that depend on firefox) > that have to be ready for xulrunner, will xulrunner also be ready for > them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?) I hope this will be fixed before the final firefox 3 release. If you have any serious problem please file a bug at bugzilla.mozilla.org (or bugzilla.redhat.com and I'll move it upstream). Things are still fresh and any feedback is highly appreciated. > If it comes to that, I hope we can debate whether it should not be > xulrunner that gets dropped and firefox-devel restored (assuming that's > even possible). We are not going to ship two firefox versions (2 and 3). Xulrunner-devel is generally a firefox3-devel package, there isn't any difference and I believe all developers will be able to transfer their packages to Firefox 3 (or xulrunner in our distro). Martin From stransky at redhat.com Sun Dec 23 09:09:09 2007 From: stransky at redhat.com (Martin Stransky) Date: Sun, 23 Dec 2007 10:09:09 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071222164214.GE30935@asus.config> References: <476A2656.5060704@redhat.com> <20071222164214.GE30935@asus.config> Message-ID: <476E25B5.9050603@redhat.com> Adam Huffman wrote: > I have installed it on F8 and it seems to have brought back the annoying > behaviour of moving the Firefox window when opening a link. Is this > Fedora-specific? > Please check the generic upstream version (http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-2-now-available-for-download/) From debarshi.ray at gmail.com Sun Dec 23 10:24:48 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 23 Dec 2007 15:54:48 +0530 Subject: what with mock ?? In-Reply-To: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> Message-ID: <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> > Error Downloading Packages: > mock - 0.8.17-1.fc8.i386: failure: mock-0.8.17-1.fc8.i386.rpm from > updates: [Errno 256] No more mirrors to try. It seems we have Mock 0.8.18 and not 0.8.17: ftp://fedora.glug-nith.org/linux/updates/8/i386/mock-0.8.18-1.fc8.i386.rpm Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ * http://fedora.glug-nith.org/ * http://gnu.glug-nith.org/ * http://mirror.wbut.ac.in/ From buildsys at redhat.com Sun Dec 23 11:55:02 2007 From: buildsys at redhat.com (Build System) Date: Sun, 23 Dec 2007 06:55:02 -0500 Subject: rawhide report: 20071223 changes Message-ID: <200712231155.lBNBt2RZ006571@porkchop.devel.redhat.com> New package perl-Array-Diff Diff two arrays New package perl-Module-ExtractUse Find out what modules are used New package perl-Test-Unit The PerlUnit testing framework New package perl-Test-YAML-Valid Lets you test the validity of YAML files in unit tests New package pyjigdo Python version of Jigdo, slightly modified Removed package rubygem-actionwebservice Updated Packages: ardour-2.1-4.fc9 ---------------- * Fri Dec 21 2007 Hans de Goede 2.1-4 - Fix building of ardour on alpha machines (bz 425987) - Fix building with glib-2.15.0 asterisk-1.4.16.1-2.fc9 ----------------------- * Sat Dec 22 2007 Jeffrey C. Ollie - 1.4.16.1-2 - Bump release and rebuild to fix broken dep on uw-imap. contacts-0.8-1.fc9 ------------------ * Sat Dec 22 2007 Denis Leroy - 0.8-1 - Update to upstream 0.8 digikam-0.9.3-1.fc9 ------------------- * Sat Dec 22 2007 Marcin Garski 0.9.3-1 - Update to 0.9.3 - BR: libkexiv2-devel >= 0.1.6 libkdcraw-devel >= 0.1.2 gammu-1.17.0-1.fc9 ------------------ * Sat Dec 22 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.17.0-1 - Updated Release. glib2-2.15.0-4.fc9 ------------------ * Sat Dec 22 2007 Matthias Clasen - 2.15.0-4 - Another attempt * Sat Dec 22 2007 Matthias Clasen - 2.15.0-3 - Fix some errors in desktop files handling gnome-menus-2.21.3-1.fc9 ------------------------ * Sat Dec 22 2007 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 - Use gio for file monitoring hwdata-0.209-1.fc9 ------------------ * Sat Dec 22 2007 Karsten Hopp 0.209-1 - add Proview 926w monitor (#363091) * Sat Dec 22 2007 Karsten Hopp 0.208-1 - new release - drop dell-monitors patch, already included in tarball * Thu Dec 13 2007 Karsten Hopp 0.207-3 - fix License tag - add empty %build section for fedora-review jd-1.9.8-0.4.svn1658.fc9 ------------------------ * Sun Dec 23 2007 Mamoru Tasaka - 1.9.8-0.4.svn1658 - svn 1658 * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 kde-settings-4.0-6.fc9 ---------------------- * Sat Dec 22 2007 Kevin Kofler - 4.0-6 - kdeglobals: KSpell_Client=4 (Hunspell), add KSpell_Encoding=11 (UTF-8) kdelibs-6:3.97.0-9.fc9 ---------------------- * Sat Dec 22 2007 Kevin Kofler 3.97.0-9 - drop BR aspell-devel on F9+, use only enchant (FeatureDictionary) * Tue Dec 18 2007 Kevin Kofler 3.97.0-8 - don't put binaries into kdelibs-common, they drag in kdelibs (#417251) * Mon Dec 17 2007 Kevin Kofler 3.97.0-7 - split out kdelibs-common on F9+ (shared with KDE 3) (#417251) - Requires: kdelibs-common (F9+) (#417251) kdelibs3-3.5.8-22.fc9 --------------------- * Sat Dec 22 2007 Kevin Kofler 3.5.8-22 - BR enchant-devel instead of aspell-devel on F9+ (FeatureDictionary) - Requires: hunspell on F9+ (FeatureDictionary) - patch KSpell for hunspell support on F9+ (FeatureDictionary) - add and build enchant backend for KSpell2 (backported from Sonnet) on F9+ (FeatureDictionary) - don't build aspell and ispell backends for KSpell2 on F9+ (FeatureDictionary) * Fri Dec 21 2007 Luk???? Tinkl - 3.5.8-21 - updated Flash patch klamav-0.41.1-9.fc9 ------------------- * Sat Dec 22 2007 Andy Shevchenko 0.41.1-9 - rebuild against new clamav maxima-5.14.0-1.fc9 ------------------- * Sat Dec 22 2007 Rex Dieter 5.14.0-1 - maxima-5.14.0 memcached-1.2.4-2.fc9 --------------------- * Sat Dec 22 2007 Paul Lindner - 1.2.4-2 - Upgrade to memcached-1.2.4 * Fri Sep 07 2007 Konstantin Ryabitsev - 1.2.3-8 - Add selinux policies - Create our own system user monotone-0.38-2.fc9 ------------------- * Sat Dec 22 2007 Roland McGrath - 0.38-2 - Fix monotone-server user creation. (#426607) - Moved monotone-server database to /var/lib. (#426608) - Use monotone@ in server key name. (#426609) nautilus-image-converter-0.2.1-1.fc9 ------------------------------------ * Sat Dec 22 2007 Brian Pepple - 0.2.1-1 - Update to 0.2.1. perl-Test-AutoBuild-1.2.2-1.fc9 ------------------------------- * Sat Dec 22 2007 Daniel Berrange - 1.2.2-1.fc9 - Updated to 1.2.2 packages - Added git, darcs, monotone, bzr subpackages * Mon Dec 10 2007 Daniel P. Berrange - 1.2.1-3.fc9 - Avoid empty %post scripts (rhbz #423041) puppet-0.24.1-1.fc9 ------------------- * Sat Dec 22 2007 David Lutterkort - 0.24.1-1 - New version qt4-4.3.3-2.fc9 --------------- * Fri Dec 21 2007 Rex Dieter 4.3.3-2 - -doc: Requires: %name-assistant, omit assistant bin, -x11: Provides: %name-assistant (#147948) tomcat-native-1.1.12-1.fc9 -------------------------- * Sat Dec 22 2007 Ville Skytt?? - 1.1.12-1 - 1.12. Broken deps for i386 ---------------------------------------------------------- Miro - 1.0-2.fc9.i386 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.i386 requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 claws-mail-plugins-clamav - 3.2.0-1.fc9.i386 requires libclamav.so.2 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 gurlchecker - 0.10.1-4.fc8.i386 requires libclamav.so.2 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071212-4.fc9.i386 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 plplot-octave - 5.8.0-4.fc9.i386 requires octave(api) = 0:api-v31 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- Miro - 1.0-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.x86_64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-clamav - 3.2.0-1.fc9.x86_64 requires libclamav.so.2()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) gurlchecker - 0.10.1-4.fc8.x86_64 requires libclamav.so.2()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071212-4.fc9.x86_64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-4.fc9.x86_64 requires octave(api) = 0:api-v31 python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc requires libgtkembedmoz.so bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 claws-mail-plugins-clamav - 3.2.0-1.fc9.ppc requires libclamav.so.2 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 gurlchecker - 0.10.1-4.fc8.ppc requires libclamav.so.2 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071212-4.fc9.ppc requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 plplot-octave - 5.8.0-4.fc9.ppc requires octave(api) = 0:api-v31 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- Miro - 1.0-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 Miro - 1.0-2.fc9.ppc64 requires libgtkembedmoz.so()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) claws-mail-plugins-clamav - 3.2.0-1.fc9.ppc64 requires libclamav.so.2()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) gurlchecker - 0.10.1-4.fc8.ppc64 requires libclamav.so.2()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-4.fc9.ppc64 requires octave(api) = 0:api-v31 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) plplot-octave - 5.8.0-4.fc9.ppc64 requires octave(api) = 0:api-v31 ppl-swiprolog - 0.9-16.fc8.ppc64 requires pl >= 0:5.6.0 python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From musuruan at gmail.com Sun Dec 23 12:07:35 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Sun, 23 Dec 2007 13:07:35 +0100 Subject: Broken SDL since v1.2.12-4? Message-ID: <1198411655.7924.10.camel@localhost.localdomain> Hi all, yum just updated my SDL to 1.2.12-4.fc8.i386. Since that, I am no longer able to build any SDL dependent software. For example, with tecnoballz (which I was going to commit), I get the following configure error: [..] checking for SDL - version >= 0.11.0... no *** Could not run SDL test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means SDL was incorrectly installed *** or that you have moved SDL since it was installed. In the latter case, you *** may want to edit the sdl-config script: /usr/bin/sdl-config [..] config.log shows: [..] configure:4464: checking for sdl-config configure:4482: found /usr/bin/sdl-config configure:4495: result: /usr/bin/sdl-config configure:4504: checking for SDL - version >= 0.11.0 configure:4601: gcc -o conftest -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 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT conftest.c -lSDL -lpthread >&5 In file included from /usr/include/SDL/SDL_stdinc.h:28, from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:14: /usr/include/SDL/SDL_config.h:1:3: error: invalid preprocessing directive #Temporary /usr/include/SDL/SDL_config.h:2:3: error: invalid preprocessing directive #If In file included from /usr/include/SDL/SDL_stdinc.h:28, from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:14: /usr/include/SDL/SDL_config.h:3: error: expected identifier or '(' before '[' token In file included from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:14: /usr/include/SDL/SDL_stdinc.h:83: warning: data definition has no type or storage class /usr/include/SDL/SDL_stdinc.h:83: warning: type defaults to 'int' in declaration of 'SDL_bool' /usr/include/SDL/SDL_stdinc.h:86: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint8' /usr/include/SDL/SDL_stdinc.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint16' /usr/include/SDL/SDL_stdinc.h:90: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint32' /usr/include/SDL/SDL_stdinc.h:100: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_stdinc.h:109: error: 'Uint8' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:111: error: 'Uint16' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:113: error: 'Uint32' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:115: error: size of array 'SDL_dummy_uint64' is negative /usr/include/SDL/SDL_stdinc.h:116: error: size of array 'SDL_dummy_sint64' is negative In file included from /usr/include/SDL/SDL_audio.h:30, from /usr/include/SDL/SDL.h:30, from conftest.c:14: /usr/include/SDL/SDL_endian.h:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Swap16' /usr/include/SDL/SDL_endian.h:98: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Swap32' In file included from /usr/include/SDL/SDL_audio.h:31, from /usr/include/SDL/SDL.h:30, from conftest.c:14: /usr/include/SDL/SDL_mutex.h:84: error: expected ')' before 'initial_value' /usr/include/SDL/SDL_mutex.h:106: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_mutex.h:114: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_SemValue' /usr/include/SDL/SDL_mutex.h:154: error: expected declaration specifiers or '...' before 'Uint32' In file included from /usr/include/SDL/SDL_audio.h:32, from /usr/include/SDL/SDL.h:30, from conftest.c:14: /usr/include/SDL/SDL_thread.h:96: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ThreadID' /usr/include/SDL/SDL_thread.h:101: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetThreadID' In file included from /usr/include/SDL/SDL_audio.h:33, from /usr/include/SDL/SDL.h:30, from conftest.c:14: /usr/include/SDL/SDL_rwops.h:63: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_rwops.h:122: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadLE16' /usr/include/SDL/SDL_rwops.h:123: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadBE16' /usr/include/SDL/SDL_rwops.h:124: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadLE32' /usr/include/SDL/SDL_rwops.h:125: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadBE32' /usr/include/SDL/SDL_rwops.h:130: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_rwops.h:131: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_rwops.h:132: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_rwops.h:133: error: expected declaration specifiers or '...' before 'Uint32' In file included from /usr/include/SDL/SDL.h:30, from conftest.c:14: /usr/include/SDL/SDL_audio.h:44: error: expected specifier-qualifier-list before 'Uint16' /usr/include/SDL/SDL_audio.h:83: error: expected specifier-qualifier-list before 'Uint16' /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_audio.h:199: error: expected ')' before '*' token /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:230: error: expected ')' before '*' token In file included from /usr/include/SDL/SDL.h:31, from conftest.c:14: /usr/include/SDL/SDL_cdrom.h:62: error: expected specifier-qualifier-list before 'Uint8' In file included from /usr/include/SDL/SDL.h:32, from conftest.c:14: /usr/include/SDL/SDL_cpuinfo.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasRDTSC' /usr/include/SDL/SDL_cpuinfo.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasMMX' /usr/include/SDL/SDL_cpuinfo.h:47: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasMMXExt' /usr/include/SDL/SDL_cpuinfo.h:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Has3DNow' /usr/include/SDL/SDL_cpuinfo.h:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Has3DNowExt' /usr/include/SDL/SDL_cpuinfo.h:59: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasSSE' /usr/include/SDL/SDL_cpuinfo.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasSSE2' /usr/include/SDL/SDL_cpuinfo.h:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasAltiVec' In file included from /usr/include/SDL/SDL_events.h:30, from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_active.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetAppState' In file included from /usr/include/SDL/SDL_events.h:31, from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_keyboard.h:55: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_keyboard.h:96: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from /usr/include/SDL/SDL_mouse.h:30, from /usr/include/SDL/SDL_events.h:32, from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_video.h:45: error: expected specifier-qualifier-list before 'Uint16' /usr/include/SDL/SDL_video.h:49: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_video.h:64: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_video.h:89: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:150: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:184: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:240: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:276: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:287: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:348: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:395: warning: type defaults to 'int' in declaration of 'Uint16' /usr/include/SDL/SDL_video.h:395: error: expected ';', ',' or ')' before '*' token /usr/include/SDL/SDL_video.h:406: error: expected ')' before '*' token /usr/include/SDL/SDL_video.h:449: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_MapRGB' /usr/include/SDL/SDL_video.h:456: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_MapRGBA' /usr/include/SDL/SDL_video.h:463: error: expected ')' before 'pixel' /usr/include/SDL/SDL_video.h:469: error: expected ')' before 'pixel' /usr/include/SDL/SDL_video.h:508: error: expected ')' before 'flags' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_video.h:600: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_SetClipRect' /usr/include/SDL/SDL_video.h:622: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:718: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:758: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:838: error: expected declaration specifiers or '...' before 'Uint8' In file included from /usr/include/SDL/SDL_events.h:32, from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_mouse.h:42: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_mouse.h:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetMouseState' /usr/include/SDL/SDL_mouse.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetRelativeMouseState' /usr/include/SDL/SDL_mouse.h:68: error: expected ')' before 'x' /usr/include/SDL/SDL_mouse.h:84: error: expected ')' before '*' token In file included from /usr/include/SDL/SDL_events.h:33, from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_joystick.h:140: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_JoystickGetHat' /usr/include/SDL/SDL_joystick.h:153: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_JoystickGetButton' In file included from /usr/include/SDL/SDL.h:35, from conftest.c:14: /usr/include/SDL/SDL_events.h:113: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:120: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:128: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:138: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:147: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:155: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:164: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:177: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:188: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:195: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:200: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:205: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:215: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:221: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:265: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_events.h:328: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_EventState' In file included from /usr/include/SDL/SDL.h:40, from conftest.c:14: /usr/include/SDL/SDL_timer.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetTicks' /usr/include/SDL/SDL_timer.h:49: error: expected ')' before 'ms' /usr/include/SDL/SDL_timer.h:52: error: expected declaration specifiers or '...' before '*' token /usr/include/SDL/SDL_timer.h:52: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:82: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:94: error: expected declaration specifiers or '...' before '*' token /usr/include/SDL/SDL_timer.h:94: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:102: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:107: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_RemoveTimer' In file included from /usr/include/SDL/SDL.h:42, from conftest.c:14: /usr/include/SDL/SDL_version.h:43: error: expected specifier-qualifier-list before 'Uint8' In file included from conftest.c:14: /usr/include/SDL/SDL.h:69: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:72: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:75: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:81: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_WasInit' configure:4604: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "tecnoballz" | #define PACKAGE_TARNAME "tecnoballz" | #define PACKAGE_VERSION "0.91-cvs20050828" | #define PACKAGE_STRING "tecnoballz 0.91-cvs20050828" | #define PACKAGE_BUGREPORT "tecnoballz at tlk.fr" | #define PACKAGE "tecnoballz" | #define VERSION "0.91-cvs20050828" | /* end confdefs.h. */ | | #include | #include | #include | #include "SDL.h" | | char* | my_strdup (char *str) | { | char *new_str; | | if (str) | { | new_str = (char *)malloc ((strlen (str) + 1) * sizeof(char)); | strcpy (new_str, str); | } | else | new_str = NULL; | | return new_str; | } | | int main (int argc, char *argv[]) | { | int major, minor, micro; | char *tmp_version; | | /* This hangs on some systems (?) | system ("touch conf.sdltest"); | */ | { FILE *fp = fopen("conf.sdltest", "a"); if ( fp ) fclose(fp); } | | /* HP/UX 9 (%@#!) writes to sscanf strings */ | tmp_version = my_strdup("0.11.0"); | if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, µ) != 3) { | printf("%s, bad version string\n", "0.11.0"); | exit(1); | } | | if ((1 > major) || | ((1 == major) && (2 > minor)) || | ((1 == major) && (2 == minor) && (12 >= micro))) | { | return 0; | } | else | { | printf("\n*** 'sdl-config --version' returned %d.%d.%d, but the minimum version\n", 1, 2, 12); | printf("*** of SDL required is %d.%d.%d. If sdl-config is correct, then it is\n", major, minor, micro); | printf("*** best to upgrade to the required version.\n"); | printf("*** If sdl-config was wrong, set the environment variable SDL_CONFIG\n"); | printf("*** to point to the correct copy of sdl-config, and remove the file\n"); | printf("*** config.cache before re-running configure\n"); | return 1; | } | } | | configure:4638: result: no configure:4682: gcc -o conftest -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 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT conftest.c -lSDL -lpthread >&5 In file included from /usr/include/SDL/SDL_stdinc.h:28, from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:12: /usr/include/SDL/SDL_config.h:1:3: error: invalid preprocessing directive #Temporary /usr/include/SDL/SDL_config.h:2:3: error: invalid preprocessing directive #If In file included from /usr/include/SDL/SDL_stdinc.h:28, from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:12: /usr/include/SDL/SDL_config.h:3: error: expected identifier or '(' before '[' token In file included from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:28, from conftest.c:12: /usr/include/SDL/SDL_stdinc.h:83: warning: data definition has no type or storage class /usr/include/SDL/SDL_stdinc.h:83: warning: type defaults to 'int' in declaration of 'SDL_bool' /usr/include/SDL/SDL_stdinc.h:85: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Sint8' /usr/include/SDL/SDL_stdinc.h:86: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint8' /usr/include/SDL/SDL_stdinc.h:87: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Sint16' /usr/include/SDL/SDL_stdinc.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint16' /usr/include/SDL/SDL_stdinc.h:89: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Sint32' /usr/include/SDL/SDL_stdinc.h:90: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint32' /usr/include/SDL/SDL_stdinc.h:100: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_stdinc.h:109: error: 'Uint8' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:110: error: 'Sint8' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:111: error: 'Uint16' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:112: error: 'Sint16' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:113: error: 'Uint32' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:114: error: 'Sint32' undeclared here (not in a function) /usr/include/SDL/SDL_stdinc.h:115: error: size of array 'SDL_dummy_uint64' is negative /usr/include/SDL/SDL_stdinc.h:116: error: size of array 'SDL_dummy_sint64' is negative In file included from /usr/include/SDL/SDL_audio.h:30, from /usr/include/SDL/SDL.h:30, from conftest.c:12: /usr/include/SDL/SDL_endian.h:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Swap16' /usr/include/SDL/SDL_endian.h:98: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Swap32' In file included from /usr/include/SDL/SDL_audio.h:31, from /usr/include/SDL/SDL.h:30, from conftest.c:12: /usr/include/SDL/SDL_mutex.h:84: error: expected ')' before 'initial_value' /usr/include/SDL/SDL_mutex.h:106: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_mutex.h:114: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_SemValue' /usr/include/SDL/SDL_mutex.h:154: error: expected declaration specifiers or '...' before 'Uint32' In file included from /usr/include/SDL/SDL_audio.h:32, from /usr/include/SDL/SDL.h:30, from conftest.c:12: /usr/include/SDL/SDL_thread.h:96: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ThreadID' /usr/include/SDL/SDL_thread.h:101: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetThreadID' In file included from /usr/include/SDL/SDL_audio.h:33, from /usr/include/SDL/SDL.h:30, from conftest.c:12: /usr/include/SDL/SDL_rwops.h:63: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_rwops.h:122: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadLE16' /usr/include/SDL/SDL_rwops.h:123: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadBE16' /usr/include/SDL/SDL_rwops.h:124: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadLE32' /usr/include/SDL/SDL_rwops.h:125: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_ReadBE32' /usr/include/SDL/SDL_rwops.h:130: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_rwops.h:131: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_rwops.h:132: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_rwops.h:133: error: expected declaration specifiers or '...' before 'Uint32' In file included from /usr/include/SDL/SDL.h:30, from conftest.c:12: /usr/include/SDL/SDL_audio.h:44: error: expected specifier-qualifier-list before 'Uint16' /usr/include/SDL/SDL_audio.h:83: error: expected specifier-qualifier-list before 'Uint16' /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_audio.h:199: error: expected ')' before '*' token /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers or '...' before 'Uint16' /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_audio.h:230: error: expected ')' before '*' token In file included from /usr/include/SDL/SDL.h:31, from conftest.c:12: /usr/include/SDL/SDL_cdrom.h:62: error: expected specifier-qualifier-list before 'Uint8' In file included from /usr/include/SDL/SDL.h:32, from conftest.c:12: /usr/include/SDL/SDL_cpuinfo.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasRDTSC' /usr/include/SDL/SDL_cpuinfo.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasMMX' /usr/include/SDL/SDL_cpuinfo.h:47: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasMMXExt' /usr/include/SDL/SDL_cpuinfo.h:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Has3DNow' /usr/include/SDL/SDL_cpuinfo.h:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_Has3DNowExt' /usr/include/SDL/SDL_cpuinfo.h:59: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasSSE' /usr/include/SDL/SDL_cpuinfo.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasSSE2' /usr/include/SDL/SDL_cpuinfo.h:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_HasAltiVec' In file included from /usr/include/SDL/SDL_events.h:30, from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_active.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetAppState' In file included from /usr/include/SDL/SDL_events.h:31, from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_keyboard.h:55: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_keyboard.h:96: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from /usr/include/SDL/SDL_mouse.h:30, from /usr/include/SDL/SDL_events.h:32, from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_video.h:44: error: expected specifier-qualifier-list before 'Sint16' /usr/include/SDL/SDL_video.h:49: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_video.h:64: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_video.h:89: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:150: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:184: error: expected specifier-qualifier-list before 'Uint32' /usr/include/SDL/SDL_video.h:240: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:276: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:287: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:348: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Sint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Sint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:395: warning: type defaults to 'int' in declaration of 'Uint16' /usr/include/SDL/SDL_video.h:395: error: expected ';', ',' or ')' before '*' token /usr/include/SDL/SDL_video.h:406: error: expected ')' before '*' token /usr/include/SDL/SDL_video.h:449: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_MapRGB' /usr/include/SDL/SDL_video.h:456: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_MapRGBA' /usr/include/SDL/SDL_video.h:463: error: expected ')' before 'pixel' /usr/include/SDL/SDL_video.h:469: error: expected ')' before 'pixel' /usr/include/SDL/SDL_video.h:508: error: expected ')' before 'flags' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers or '...' before 'Uint8' /usr/include/SDL/SDL_video.h:600: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_SetClipRect' /usr/include/SDL/SDL_video.h:622: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:718: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:758: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_video.h:838: error: expected declaration specifiers or '...' before 'Uint8' In file included from /usr/include/SDL/SDL_events.h:32, from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_mouse.h:41: error: expected specifier-qualifier-list before 'Sint16' /usr/include/SDL/SDL_mouse.h:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetMouseState' /usr/include/SDL/SDL_mouse.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetRelativeMouseState' /usr/include/SDL/SDL_mouse.h:68: error: expected ')' before 'x' /usr/include/SDL/SDL_mouse.h:84: error: expected ')' before '*' token In file included from /usr/include/SDL/SDL_events.h:33, from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_joystick.h:122: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_JoystickGetAxis' /usr/include/SDL/SDL_joystick.h:140: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_JoystickGetHat' /usr/include/SDL/SDL_joystick.h:153: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_JoystickGetButton' In file included from /usr/include/SDL/SDL.h:35, from conftest.c:12: /usr/include/SDL/SDL_events.h:113: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:120: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:128: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:138: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:147: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:155: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:164: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:177: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:188: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:195: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:200: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:205: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:215: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:221: error: expected specifier-qualifier-list before 'Uint8' /usr/include/SDL/SDL_events.h:265: error: expected declaration specifiers or '...' before 'Uint32' /usr/include/SDL/SDL_events.h:328: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_EventState' In file included from /usr/include/SDL/SDL.h:40, from conftest.c:12: /usr/include/SDL/SDL_timer.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_GetTicks' /usr/include/SDL/SDL_timer.h:49: error: expected ')' before 'ms' /usr/include/SDL/SDL_timer.h:52: error: expected declaration specifiers or '...' before '*' token /usr/include/SDL/SDL_timer.h:52: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:82: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:94: error: expected declaration specifiers or '...' before '*' token /usr/include/SDL/SDL_timer.h:94: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:102: error: expected ')' before 'interval' /usr/include/SDL/SDL_timer.h:107: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_RemoveTimer' In file included from /usr/include/SDL/SDL.h:42, from conftest.c:12: /usr/include/SDL/SDL_version.h:43: error: expected specifier-qualifier-list before 'Uint8' In file included from conftest.c:12: /usr/include/SDL/SDL.h:69: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:72: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:75: error: expected ')' before 'flags' /usr/include/SDL/SDL.h:81: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SDL_WasInit' [..] The same happens building in mock for F-8/i386. I have no problem with mock for devel/i386. Help appreciated. Thanks. Bye, Andrea. From j.w.r.degoede at hhs.nl Sun Dec 23 12:20:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 23 Dec 2007 13:20:07 +0100 Subject: Broken SDL since v1.2.12-4? In-Reply-To: <1198411655.7924.10.camel@localhost.localdomain> References: <1198411655.7924.10.camel@localhost.localdomain> Message-ID: <476E5277.80509@hhs.nl> Andrea Musuruane wrote: > Hi all, > yum just updated my SDL to 1.2.12-4.fc8.i386. Since that, I am no > longer able to build any SDL dependent software. > > For example, with tecnoballz (which I was going to commit), I get the > following configure error: > > [..] > checking for SDL - version >= 0.11.0... no > *** Could not run SDL test program, checking why... > *** The test program failed to compile or link. See the file config.log > for the > *** exact error that occured. This usually means SDL was incorrectly > installed > *** or that you have moved SDL since it was installed. In the latter > case, you > *** may want to edit the sdl-config script: /usr/bin/sdl-config > [..] > > config.log shows: > > [..] > configure:4464: checking for sdl-config > configure:4482: found /usr/bin/sdl-config > configure:4495: result: /usr/bin/sdl-config > configure:4504: checking for SDL - version >= 0.11.0 > configure:4601: gcc -o conftest -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 -I/usr/include/SDL -D_GNU_SOURCE=1 > -D_REENTRANT conftest.c -lSDL -lpthread >&5 > In file included from /usr/include/SDL/SDL_stdinc.h:28, > from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:14: > /usr/include/SDL/SDL_config.h:1:3: error: invalid preprocessing > directive #Temporary > /usr/include/SDL/SDL_config.h:2:3: error: invalid preprocessing > directive #If > In file included from /usr/include/SDL/SDL_stdinc.h:28, > from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:14: > /usr/include/SDL/SDL_config.h:3: error: expected identifier or '(' > before '[' token > In file included from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:14: > /usr/include/SDL/SDL_stdinc.h:83: warning: data definition has no type > or storage class > /usr/include/SDL/SDL_stdinc.h:83: warning: type defaults to 'int' in > declaration of 'SDL_bool' > /usr/include/SDL/SDL_stdinc.h:86: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint8' > /usr/include/SDL/SDL_stdinc.h:88: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint16' > /usr/include/SDL/SDL_stdinc.h:90: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint32' > /usr/include/SDL/SDL_stdinc.h:100: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_stdinc.h:109: error: 'Uint8' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:111: error: 'Uint16' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:113: error: 'Uint32' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:115: error: size of array > 'SDL_dummy_uint64' is negative > /usr/include/SDL/SDL_stdinc.h:116: error: size of array > 'SDL_dummy_sint64' is negative > In file included from /usr/include/SDL/SDL_audio.h:30, > from /usr/include/SDL/SDL.h:30, > from conftest.c:14: > /usr/include/SDL/SDL_endian.h:65: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Swap16' > /usr/include/SDL/SDL_endian.h:98: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Swap32' > In file included from /usr/include/SDL/SDL_audio.h:31, > from /usr/include/SDL/SDL.h:30, > from conftest.c:14: > /usr/include/SDL/SDL_mutex.h:84: error: expected ')' before > 'initial_value' > /usr/include/SDL/SDL_mutex.h:106: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_mutex.h:114: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_SemValue' > /usr/include/SDL/SDL_mutex.h:154: error: expected declaration specifiers > or '...' before 'Uint32' > In file included from /usr/include/SDL/SDL_audio.h:32, > from /usr/include/SDL/SDL.h:30, > from conftest.c:14: > /usr/include/SDL/SDL_thread.h:96: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ThreadID' > /usr/include/SDL/SDL_thread.h:101: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_GetThreadID' > In file included from /usr/include/SDL/SDL_audio.h:33, > from /usr/include/SDL/SDL.h:30, > from conftest.c:14: > /usr/include/SDL/SDL_rwops.h:63: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_rwops.h:122: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadLE16' > /usr/include/SDL/SDL_rwops.h:123: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadBE16' > /usr/include/SDL/SDL_rwops.h:124: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadLE32' > /usr/include/SDL/SDL_rwops.h:125: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadBE32' > /usr/include/SDL/SDL_rwops.h:130: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_rwops.h:131: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_rwops.h:132: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_rwops.h:133: error: expected declaration specifiers > or '...' before 'Uint32' > In file included from /usr/include/SDL/SDL.h:30, > from conftest.c:14: > /usr/include/SDL/SDL_audio.h:44: error: expected > specifier-qualifier-list before 'Uint16' > /usr/include/SDL/SDL_audio.h:83: error: expected > specifier-qualifier-list before 'Uint16' > /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_audio.h:199: error: expected ')' before '*' token > /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:230: error: expected ')' before '*' token > In file included from /usr/include/SDL/SDL.h:31, > from conftest.c:14: > /usr/include/SDL/SDL_cdrom.h:62: error: expected > specifier-qualifier-list before 'Uint8' > In file included from /usr/include/SDL/SDL.h:32, > from conftest.c:14: > /usr/include/SDL/SDL_cpuinfo.h:39: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasRDTSC' > /usr/include/SDL/SDL_cpuinfo.h:43: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasMMX' > /usr/include/SDL/SDL_cpuinfo.h:47: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasMMXExt' > /usr/include/SDL/SDL_cpuinfo.h:51: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Has3DNow' > /usr/include/SDL/SDL_cpuinfo.h:55: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Has3DNowExt' > /usr/include/SDL/SDL_cpuinfo.h:59: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasSSE' > /usr/include/SDL/SDL_cpuinfo.h:63: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasSSE2' > /usr/include/SDL/SDL_cpuinfo.h:67: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasAltiVec' > In file included from /usr/include/SDL/SDL_events.h:30, > from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_active.h:49: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_GetAppState' > In file included from /usr/include/SDL/SDL_events.h:31, > from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_keyboard.h:55: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_keyboard.h:96: error: expected '=', ',', ';', 'asm' > or '__attribute__' before '*' token > In file included from /usr/include/SDL/SDL_mouse.h:30, > from /usr/include/SDL/SDL_events.h:32, > from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_video.h:45: error: expected > specifier-qualifier-list before 'Uint16' > /usr/include/SDL/SDL_video.h:49: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_video.h:64: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_video.h:89: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:150: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:184: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:240: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:276: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:287: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:348: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:395: warning: type defaults to 'int' in > declaration of 'Uint16' > /usr/include/SDL/SDL_video.h:395: error: expected ';', ',' or ')' before > '*' token > /usr/include/SDL/SDL_video.h:406: error: expected ')' before '*' token > /usr/include/SDL/SDL_video.h:449: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_MapRGB' > /usr/include/SDL/SDL_video.h:456: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_MapRGBA' > /usr/include/SDL/SDL_video.h:463: error: expected ')' before 'pixel' > /usr/include/SDL/SDL_video.h:469: error: expected ')' before 'pixel' > /usr/include/SDL/SDL_video.h:508: error: expected ')' before 'flags' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_video.h:600: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_SetClipRect' > /usr/include/SDL/SDL_video.h:622: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:718: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:758: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:838: error: expected declaration specifiers > or '...' before 'Uint8' > In file included from /usr/include/SDL/SDL_events.h:32, > from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_mouse.h:42: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_mouse.h:55: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetMouseState' > /usr/include/SDL/SDL_mouse.h:63: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetRelativeMouseState' > /usr/include/SDL/SDL_mouse.h:68: error: expected ')' before 'x' > /usr/include/SDL/SDL_mouse.h:84: error: expected ')' before '*' token > In file included from /usr/include/SDL/SDL_events.h:33, > from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_joystick.h:140: error: expected '=', ',', ';', > 'asm' or '__attribute__' before 'SDL_JoystickGetHat' > /usr/include/SDL/SDL_joystick.h:153: error: expected '=', ',', ';', > 'asm' or '__attribute__' before 'SDL_JoystickGetButton' > In file included from /usr/include/SDL/SDL.h:35, > from conftest.c:14: > /usr/include/SDL/SDL_events.h:113: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:120: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:128: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:138: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:147: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:155: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:164: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:177: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:188: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:195: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:200: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:205: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:215: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:221: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:265: error: expected declaration > specifiers or '...' before 'Uint32' > /usr/include/SDL/SDL_events.h:328: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_EventState' > In file included from /usr/include/SDL/SDL.h:40, > from conftest.c:14: > /usr/include/SDL/SDL_timer.h:46: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetTicks' > /usr/include/SDL/SDL_timer.h:49: error: expected ')' before 'ms' > /usr/include/SDL/SDL_timer.h:52: error: expected declaration specifiers > or '...' before '*' token > /usr/include/SDL/SDL_timer.h:52: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:82: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:94: error: expected declaration specifiers > or '...' before '*' token > /usr/include/SDL/SDL_timer.h:94: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:102: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:107: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_RemoveTimer' > In file included from /usr/include/SDL/SDL.h:42, > from conftest.c:14: > /usr/include/SDL/SDL_version.h:43: error: expected > specifier-qualifier-list before 'Uint8' > In file included from conftest.c:14: > /usr/include/SDL/SDL.h:69: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:72: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:75: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:81: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_WasInit' > configure:4604: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h. */ > | #define PACKAGE_NAME "tecnoballz" > | #define PACKAGE_TARNAME "tecnoballz" > | #define PACKAGE_VERSION "0.91-cvs20050828" > | #define PACKAGE_STRING "tecnoballz 0.91-cvs20050828" > | #define PACKAGE_BUGREPORT "tecnoballz at tlk.fr" > | #define PACKAGE "tecnoballz" > | #define VERSION "0.91-cvs20050828" > | /* end confdefs.h. */ > | > | #include > | #include > | #include > | #include "SDL.h" > | > | char* > | my_strdup (char *str) > | { > | char *new_str; > | > | if (str) > | { > | new_str = (char *)malloc ((strlen (str) + 1) * sizeof(char)); > | strcpy (new_str, str); > | } > | else > | new_str = NULL; > | > | return new_str; > | } > | > | int main (int argc, char *argv[]) > | { > | int major, minor, micro; > | char *tmp_version; > | > | /* This hangs on some systems (?) > | system ("touch conf.sdltest"); > | */ > | { FILE *fp = fopen("conf.sdltest", "a"); if ( fp ) fclose(fp); } > | > | /* HP/UX 9 (%@#!) writes to sscanf strings */ > | tmp_version = my_strdup("0.11.0"); > | if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, µ) != 3) { > | printf("%s, bad version string\n", "0.11.0"); > | exit(1); > | } > | > | if ((1 > major) || > | ((1 == major) && (2 > minor)) || > | ((1 == major) && (2 == minor) && (12 >= micro))) > | { > | return 0; > | } > | else > | { > | printf("\n*** 'sdl-config --version' returned %d.%d.%d, but the > minimum version\n", 1, 2, 12); > | printf("*** of SDL required is %d.%d.%d. If sdl-config is > correct, then it is\n", major, minor, micro); > | printf("*** best to upgrade to the required version.\n"); > | printf("*** If sdl-config was wrong, set the environment > variable SDL_CONFIG\n"); > | printf("*** to point to the correct copy of sdl-config, and > remove the file\n"); > | printf("*** config.cache before re-running configure\n"); > | return 1; > | } > | } > | > | > configure:4638: result: no > configure:4682: gcc -o conftest -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 -I/usr/include/SDL -D_GNU_SOURCE=1 > -D_REENTRANT conftest.c -lSDL -lpthread >&5 > In file included from /usr/include/SDL/SDL_stdinc.h:28, > from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:12: > /usr/include/SDL/SDL_config.h:1:3: error: invalid preprocessing > directive #Temporary > /usr/include/SDL/SDL_config.h:2:3: error: invalid preprocessing > directive #If > In file included from /usr/include/SDL/SDL_stdinc.h:28, > from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:12: > /usr/include/SDL/SDL_config.h:3: error: expected identifier or '(' > before '[' token > In file included from /usr/include/SDL/SDL_main.h:26, > from /usr/include/SDL/SDL.h:28, > from conftest.c:12: > /usr/include/SDL/SDL_stdinc.h:83: warning: data definition has no type > or storage class > /usr/include/SDL/SDL_stdinc.h:83: warning: type defaults to 'int' in > declaration of 'SDL_bool' > /usr/include/SDL/SDL_stdinc.h:85: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Sint8' > /usr/include/SDL/SDL_stdinc.h:86: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint8' > /usr/include/SDL/SDL_stdinc.h:87: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Sint16' > /usr/include/SDL/SDL_stdinc.h:88: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint16' > /usr/include/SDL/SDL_stdinc.h:89: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Sint32' > /usr/include/SDL/SDL_stdinc.h:90: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'Uint32' > /usr/include/SDL/SDL_stdinc.h:100: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_stdinc.h:109: error: 'Uint8' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:110: error: 'Sint8' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:111: error: 'Uint16' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:112: error: 'Sint16' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:113: error: 'Uint32' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:114: error: 'Sint32' undeclared here (not > in a function) > /usr/include/SDL/SDL_stdinc.h:115: error: size of array > 'SDL_dummy_uint64' is negative > /usr/include/SDL/SDL_stdinc.h:116: error: size of array > 'SDL_dummy_sint64' is negative > In file included from /usr/include/SDL/SDL_audio.h:30, > from /usr/include/SDL/SDL.h:30, > from conftest.c:12: > /usr/include/SDL/SDL_endian.h:65: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Swap16' > /usr/include/SDL/SDL_endian.h:98: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Swap32' > In file included from /usr/include/SDL/SDL_audio.h:31, > from /usr/include/SDL/SDL.h:30, > from conftest.c:12: > /usr/include/SDL/SDL_mutex.h:84: error: expected ')' before > 'initial_value' > /usr/include/SDL/SDL_mutex.h:106: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_mutex.h:114: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_SemValue' > /usr/include/SDL/SDL_mutex.h:154: error: expected declaration specifiers > or '...' before 'Uint32' > In file included from /usr/include/SDL/SDL_audio.h:32, > from /usr/include/SDL/SDL.h:30, > from conftest.c:12: > /usr/include/SDL/SDL_thread.h:96: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ThreadID' > /usr/include/SDL/SDL_thread.h:101: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_GetThreadID' > In file included from /usr/include/SDL/SDL_audio.h:33, > from /usr/include/SDL/SDL.h:30, > from conftest.c:12: > /usr/include/SDL/SDL_rwops.h:63: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_rwops.h:122: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadLE16' > /usr/include/SDL/SDL_rwops.h:123: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadBE16' > /usr/include/SDL/SDL_rwops.h:124: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadLE32' > /usr/include/SDL/SDL_rwops.h:125: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_ReadBE32' > /usr/include/SDL/SDL_rwops.h:130: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_rwops.h:131: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_rwops.h:132: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_rwops.h:133: error: expected declaration specifiers > or '...' before 'Uint32' > In file included from /usr/include/SDL/SDL.h:30, > from conftest.c:12: > /usr/include/SDL/SDL_audio.h:44: error: expected > specifier-qualifier-list before 'Uint16' > /usr/include/SDL/SDL_audio.h:83: error: expected > specifier-qualifier-list before 'Uint16' > /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:190: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_audio.h:199: error: expected ')' before '*' token > /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_audio.h:209: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers > or '...' before 'Uint16' > /usr/include/SDL/SDL_audio.h:210: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_audio.h:230: error: expected ')' before '*' token > In file included from /usr/include/SDL/SDL.h:31, > from conftest.c:12: > /usr/include/SDL/SDL_cdrom.h:62: error: expected > specifier-qualifier-list before 'Uint8' > In file included from /usr/include/SDL/SDL.h:32, > from conftest.c:12: > /usr/include/SDL/SDL_cpuinfo.h:39: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasRDTSC' > /usr/include/SDL/SDL_cpuinfo.h:43: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasMMX' > /usr/include/SDL/SDL_cpuinfo.h:47: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasMMXExt' > /usr/include/SDL/SDL_cpuinfo.h:51: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Has3DNow' > /usr/include/SDL/SDL_cpuinfo.h:55: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_Has3DNowExt' > /usr/include/SDL/SDL_cpuinfo.h:59: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasSSE' > /usr/include/SDL/SDL_cpuinfo.h:63: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasSSE2' > /usr/include/SDL/SDL_cpuinfo.h:67: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_HasAltiVec' > In file included from /usr/include/SDL/SDL_events.h:30, > from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_active.h:49: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_GetAppState' > In file included from /usr/include/SDL/SDL_events.h:31, > from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_keyboard.h:55: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_keyboard.h:96: error: expected '=', ',', ';', 'asm' > or '__attribute__' before '*' token > In file included from /usr/include/SDL/SDL_mouse.h:30, > from /usr/include/SDL/SDL_events.h:32, > from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_video.h:44: error: expected > specifier-qualifier-list before 'Sint16' > /usr/include/SDL/SDL_video.h:49: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_video.h:64: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_video.h:89: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:150: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:184: error: expected > specifier-qualifier-list before 'Uint32' > /usr/include/SDL/SDL_video.h:240: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:276: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:287: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:348: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Sint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Sint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:359: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:395: warning: type defaults to 'int' in > declaration of 'Uint16' > /usr/include/SDL/SDL_video.h:395: error: expected ';', ',' or ')' before > '*' token > /usr/include/SDL/SDL_video.h:406: error: expected ')' before '*' token > /usr/include/SDL/SDL_video.h:449: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_MapRGB' > /usr/include/SDL/SDL_video.h:456: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_MapRGBA' > /usr/include/SDL/SDL_video.h:463: error: expected ')' before 'pixel' > /usr/include/SDL/SDL_video.h:469: error: expected ')' before 'pixel' > /usr/include/SDL/SDL_video.h:508: error: expected ')' before 'flags' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:512: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:569: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:586: error: expected declaration specifiers > or '...' before 'Uint8' > /usr/include/SDL/SDL_video.h:600: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_SetClipRect' > /usr/include/SDL/SDL_video.h:622: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:718: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:758: error: expected declaration specifiers > or '...' before 'Uint32' > /usr/include/SDL/SDL_video.h:838: error: expected declaration specifiers > or '...' before 'Uint8' > In file included from /usr/include/SDL/SDL_events.h:32, > from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_mouse.h:41: error: expected > specifier-qualifier-list before 'Sint16' > /usr/include/SDL/SDL_mouse.h:55: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetMouseState' > /usr/include/SDL/SDL_mouse.h:63: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetRelativeMouseState' > /usr/include/SDL/SDL_mouse.h:68: error: expected ')' before 'x' > /usr/include/SDL/SDL_mouse.h:84: error: expected ')' before '*' token > In file included from /usr/include/SDL/SDL_events.h:33, > from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_joystick.h:122: error: expected '=', ',', ';', > 'asm' or '__attribute__' before 'SDL_JoystickGetAxis' > /usr/include/SDL/SDL_joystick.h:140: error: expected '=', ',', ';', > 'asm' or '__attribute__' before 'SDL_JoystickGetHat' > /usr/include/SDL/SDL_joystick.h:153: error: expected '=', ',', ';', > 'asm' or '__attribute__' before 'SDL_JoystickGetButton' > In file included from /usr/include/SDL/SDL.h:35, > from conftest.c:12: > /usr/include/SDL/SDL_events.h:113: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:120: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:128: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:138: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:147: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:155: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:164: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:177: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:188: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:195: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:200: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:205: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:215: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:221: error: expected > specifier-qualifier-list before 'Uint8' > /usr/include/SDL/SDL_events.h:265: error: expected declaration > specifiers or '...' before 'Uint32' > /usr/include/SDL/SDL_events.h:328: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_EventState' > In file included from /usr/include/SDL/SDL.h:40, > from conftest.c:12: > /usr/include/SDL/SDL_timer.h:46: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_GetTicks' > /usr/include/SDL/SDL_timer.h:49: error: expected ')' before 'ms' > /usr/include/SDL/SDL_timer.h:52: error: expected declaration specifiers > or '...' before '*' token > /usr/include/SDL/SDL_timer.h:52: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:82: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:94: error: expected declaration specifiers > or '...' before '*' token > /usr/include/SDL/SDL_timer.h:94: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:102: error: expected ')' before 'interval' > /usr/include/SDL/SDL_timer.h:107: error: expected '=', ',', ';', 'asm' > or '__attribute__' before 'SDL_RemoveTimer' > In file included from /usr/include/SDL/SDL.h:42, > from conftest.c:12: > /usr/include/SDL/SDL_version.h:43: error: expected > specifier-qualifier-list before 'Uint8' > In file included from conftest.c:12: > /usr/include/SDL/SDL.h:69: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:72: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:75: error: expected ')' before 'flags' > /usr/include/SDL/SDL.h:81: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'SDL_WasInit' > [..] > > The same happens building in mock for F-8/i386. I have no problem with > mock for devel/i386. > Yeah, Somehow one of the headers got munched during this SDL build, a new one is on its way, for now you can grab it from koji. Regards, Hans From jdieter at gmail.com Sun Dec 23 12:22:09 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 23 Dec 2007 14:22:09 +0200 Subject: Broken SDL since v1.2.12-4? In-Reply-To: <1198411655.7924.10.camel@localhost.localdomain> References: <1198411655.7924.10.camel@localhost.localdomain> Message-ID: <1198412529.4455.10.camel@jndwidescreen.lesbg.loc> On Sun, 2007-12-23 at 13:07 +0100, Andrea Musuruane wrote: > Hi all, > yum just updated my SDL to 1.2.12-4.fc8.i386. Since that, I am no > longer able to build any SDL dependent software. > > For example, with tecnoballz (which I was going to commit), I get the > following configure error: > > The same happens building in mock for F-8/i386. I have no problem with > mock for devel/i386. > > Help appreciated. > > Thanks. It's been bugzilla'd at https://bugzilla.redhat.com/show_bug.cgi?id=426564 . One of the header files has been corrupted. The maintainer hasn't replied to the bug yet, but it may have something to do with Christmas holidays. 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 jdieter at gmail.com Sun Dec 23 12:27:54 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 23 Dec 2007 14:27:54 +0200 Subject: Broken SDL since v1.2.12-4? In-Reply-To: <476E5277.80509@hhs.nl> References: <1198411655.7924.10.camel@localhost.localdomain> <476E5277.80509@hhs.nl> Message-ID: <1198412874.4455.13.camel@jndwidescreen.lesbg.loc> On Sun, 2007-12-23 at 13:20 +0100, Hans de Goede wrote: > Yeah, > > Somehow one of the headers got munched during this SDL build, a new one is on > its way, for now you can grab it from koji. > Thanks. Feel free to ignore my previous comment (about the maintainer not responding). :) 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 drago01 at gmail.com Sun Dec 23 12:39:38 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 13:39:38 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476DCB7A.4010606@gmail.com> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> Message-ID: <476E570A.1060804@gmail.com> Andrew Farris wrote: > drago01 wrote: > >> On Dec 23, 2007 1:43 AM, Chuck Anderson wrote: >> >>> On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote: >>> >>>> For me it refuses to load any site until I change >>>> "network.dns.disableIPv6" to "true" >>>> So I propose to make this the default .. >>>> >>> Works fine for me without doing that. Let's not supposedly "fix" >>> things by crippling new functionality and discouraging adoption of new >>> technology, shall we? What is the real problem here? We should be >>> focused on fixing that instead. >>> >> the problem is that it does not work with some ISP .. and thats not >> something that we can fix that easily (well or we can try to add some >> fallback logic) >> > > Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally > while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd > suggest making sure your local network configuration has IPv6 disabled and see > if that firefox now does not care whether IPv6 is not disabled. > > If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't > configure an address for the family). The application should not choose to try > and generate IPv6 traffic if it is not told you have IPv6 connectivity. > > well my ISP is connected to a wireless router and I got the configuration over dhcp from the router. There seems to be indeed a ipv6 adress assigned to the interface in question (dunno why maybe because the router does support ipv6 but the ISP does not). nevertheless if ipv6 does not work it should atleast fall back to ipv4. I know how to deal with this but I doubt that all other users affected will be able to deal with it. And a webbrowser _must_ work out of the box .. else they cannot even try to google for a solution etc. From ndbecker2 at gmail.com Sun Dec 23 13:17:37 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 23 Dec 2007 08:17:37 -0500 Subject: Wiki Migration References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> Message-ID: King InuYasha wrote: > The demo works fine in Konqueror included in Fedora 8. Are you using the > demo at http://demo.enanocms.org ? The demo at opensourcecms.com doesn't > work because they inject advert code into everything. A fix for that has > already been pushed into Mercurial once it was discovered, but it is > unknown whether or not OpenSourceCMS.com is aware of the issue. > Now I can't login to that page. It asks for a pw, but doesn't accept 'demo'. From ngompa13 at gmail.com Sun Dec 23 14:33:48 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 23 Dec 2007 08:33:48 -0600 Subject: Wiki Migration In-Reply-To: References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> Message-ID: <8278b1b0712230633x784c248bn62a301474d3464ce@mail.gmail.com> What version of Konqueror are you using? On Dec 23, 2007 7:17 AM, Neal Becker wrote: > King InuYasha wrote: > > > The demo works fine in Konqueror included in Fedora 8. Are you using the > > demo at http://demo.enanocms.org ? The demo at opensourcecms.com doesn't > > work because they inject advert code into everything. A fix for that has > > already been pushed into Mercurial once it was discovered, but it is > > unknown whether or not OpenSourceCMS.com is aware of the issue. > > > > Now I can't login to that page. It asks for a pw, but doesn't accept > 'demo'. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Sun Dec 23 14:51:33 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 23 Dec 2007 09:51:33 -0500 Subject: Fedora and lack of audio communication with the community In-Reply-To: <476DA064.50603@gmail.com> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> Message-ID: <1198421493.25746.4.camel@cutter> On Sat, 2007-12-22 at 17:40 -0600, Les Mikesell wrote: > Kevin Kofler wrote: > > Valent Turkovic gmail.com> writes: > >> first excuse me if this is the wrong mailing list. If there is > >> fedora-marketing or some similar :) mailing list please point me in > >> the right direction. > > > > There is a fedora-marketing-list indeed. > > > > But to answer your suggestion: I personally don't understand why all the fuss > > about podcasts, IMHO written plaintext is more convenient for things like that > > (easier to skim over, easier to find a section when going back to something you > > already read, easier to search automatically (fulltext search), easier to find > > in a search engine too (fulltext indexing), no need to either put headphones on > > or have everyone around listen to the podcast too whether they want it or not, > > can be consumed on a machine with no sound at all (as in some offices) and of > > course faster to download too). > > One word: commuting. Podcasts do to talk radio (or the internet > equivalent) what tivo does to television. While it is absurd to hope > that an interesting personality will be chatting on a live broadcast and > conclude at precisely the times you are trapped in your car for the > daily commute, it is quite easy to subscribe to a podcast and automate > the transfer of new content to your ipod/player. Then it is a matter of > pushing the button to pause/continue at convenient times. It's also > great if you work out regularly on a treadmill or similar device that > doesn't require your full concentration. Sometimes way a person is > saying comes across differently when you listen to an interview compared > even to reading a transcript of the same thing. I tend to prefer the > ones moderated by someone with actual broadcast experience like Leo > Laporte or fast paced ones like CNET's Buzz Out Load. Podcasts are useless to the deaf and Hard of Hearing. If you want to put a podcast up, fine. if you don't have a transcript of it you're excluding that portion of the population, entirely. There is currently software to read text in a voice for the blind, we have nothing to convert speech to text. that's why we shouldn't do podcasts. -sv From jkeating at redhat.com Sun Dec 23 15:06:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Dec 2007 10:06:10 -0500 Subject: Fedora and lack of audio communication with the community In-Reply-To: <1198421493.25746.4.camel@cutter> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> <1198421493.25746.4.camel@cutter> Message-ID: <20071223100610.3b9069f4@redhat.com> On Sun, 23 Dec 2007 09:51:33 -0500 seth vidal wrote: > that's why we shouldn't do podcasts. Or we should be responsible about our podcasts. I'm perfectly happy if somebody wants to interview me for a podcast, so long as they post a written transcript 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 subhodip at fedoraproject.org Sun Dec 23 15:11:58 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sun, 23 Dec 2007 20:41:58 +0530 Subject: what with mock ?? In-Reply-To: <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> Message-ID: <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> This is also a problem i am facing with kernel-devel-2.6.23.8-63.fc8.i686. -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From subhodip at fedoraproject.org Sun Dec 23 15:23:06 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sun, 23 Dec 2007 20:53:06 +0530 Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> Message-ID: <539333cb0712230723p7ec62a21h692ab070465a4bdf@mail.gmail.com> K3b is the most popular cd burning atleast here . and people keep on asking for it as it is not available since F7 . +1 from also . -------- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From subhodip at fedoraproject.org Sun Dec 23 15:26:30 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sun, 23 Dec 2007 20:56:30 +0530 Subject: what with mock ?? In-Reply-To: <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> Message-ID: <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> pirut show only mock-0.8.17 listed -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From ndbecker2 at gmail.com Sun Dec 23 15:07:17 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 23 Dec 2007 10:07:17 -0500 Subject: Wiki Migration References: <4762E5F5.4010206@redhat.com> <76e72f800712202141x2b7d2510kd482117e1fa9e1a4@mail.gmail.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> <8278b1b0712230633x784c248bn62a301474d3464ce@mail.gmail.com> Message-ID: King InuYasha wrote: > What version of Konqueror are you using? > > On Dec 23, 2007 7:17 AM, Neal Becker wrote: > >> King InuYasha wrote: >> >> > The demo works fine in Konqueror included in Fedora 8. Are you using >> > the demo at http://demo.enanocms.org ? The demo at opensourcecms.com >> > doesn't work because they inject advert code into everything. A fix for >> > that has already been pushed into Mercurial once it was discovered, but >> > it is unknown whether or not OpenSourceCMS.com is aware of the issue. >> > >> >> Now I can't login to that page. It asks for a pw, but doesn't accept >> 'demo'. >> OK, it's working now. From lesmikesell at gmail.com Sun Dec 23 15:45:32 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 23 Dec 2007 09:45:32 -0600 Subject: Fedora and lack of audio communication with the community In-Reply-To: <1198421493.25746.4.camel@cutter> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> <1198421493.25746.4.camel@cutter> Message-ID: <476E829C.109@gmail.com> seth vidal wrote: > On Sat, 2007-12-22 at 17:40 -0600, Les Mikesell wrote: >> Kevin Kofler wrote: >>> Valent Turkovic gmail.com> writes: >>>> first excuse me if this is the wrong mailing list. If there is >>>> fedora-marketing or some similar :) mailing list please point me in >>>> the right direction. >>> There is a fedora-marketing-list indeed. >>> >>> But to answer your suggestion: I personally don't understand why all the fuss >>> about podcasts, IMHO written plaintext is more convenient for things like that >>> (easier to skim over, easier to find a section when going back to something you >>> already read, easier to search automatically (fulltext search), easier to find >>> in a search engine too (fulltext indexing), no need to either put headphones on >>> or have everyone around listen to the podcast too whether they want it or not, >>> can be consumed on a machine with no sound at all (as in some offices) and of >>> course faster to download too). >> One word: commuting. Podcasts do to talk radio (or the internet >> equivalent) what tivo does to television. While it is absurd to hope >> that an interesting personality will be chatting on a live broadcast and >> conclude at precisely the times you are trapped in your car for the >> daily commute, it is quite easy to subscribe to a podcast and automate >> the transfer of new content to your ipod/player. Then it is a matter of >> pushing the button to pause/continue at convenient times. It's also >> great if you work out regularly on a treadmill or similar device that >> doesn't require your full concentration. Sometimes way a person is >> saying comes across differently when you listen to an interview compared >> even to reading a transcript of the same thing. I tend to prefer the >> ones moderated by someone with actual broadcast experience like Leo >> Laporte or fast paced ones like CNET's Buzz Out Load. > > > Podcasts are useless to the deaf and Hard of Hearing. If you want to put > a podcast up, fine. if you don't have a transcript of it you're > excluding that portion of the population, entirely. There is currently > software to read text in a voice for the blind, we have nothing to > convert speech to text. > > that's why we shouldn't do podcasts. Are you against radio as well? Some podcasts are just recordings of radio sessions that were broadcast live. And most of the technical ones are just people talking about things that are available in print anyway. -- Les Mikesell lesmikesell at gmail.com From ngompa13 at gmail.com Sun Dec 23 16:32:04 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 23 Dec 2007 10:32:04 -0600 Subject: Wiki Migration In-Reply-To: References: <4762E5F5.4010206@redhat.com> <476BC6D5.4070802@redhat.com> <1198248240.7443.31.camel@study.mwiriadi.id.au> <476BD28C.8040804@redhat.com> <1198252268.7443.46.camel@study.mwiriadi.id.au> <476BE074.4020703@redhat.com> <8278b1b0712210816l22daba22p5d6a18381441b1ee@mail.gmail.com> <8278b1b0712230633x784c248bn62a301474d3464ce@mail.gmail.com> Message-ID: <8278b1b0712230832s2b13dcc3iadb42443fe2b027f@mail.gmail.com> Great. On Dec 23, 2007 9:07 AM, Neal Becker wrote: > King InuYasha wrote: > > > What version of Konqueror are you using? > > > > On Dec 23, 2007 7:17 AM, Neal Becker wrote: > > > >> King InuYasha wrote: > >> > >> > The demo works fine in Konqueror included in Fedora 8. Are you using > >> > the demo at http://demo.enanocms.org ? The demo at opensourcecms.com > >> > doesn't work because they inject advert code into everything. A fix > for > >> > that has already been pushed into Mercurial once it was discovered, > but > >> > it is unknown whether or not OpenSourceCMS.com is aware of the issue. > >> > > >> > >> Now I can't login to that page. It asks for a pw, but doesn't accept > >> 'demo'. > >> > > OK, it's working now. > > -- > 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 drago01 at gmail.com Sun Dec 23 16:51:03 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 17:51:03 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> Message-ID: On Dec 22, 2007 9:43 PM, Valent Turkovic wrote: > On 12/20/07, Eric Mesa wrote: > > I also use K3B. In comparison all of the Gnome burners are crap. (And I > > primarily use Gnome) > > > > > > On Dec 20, 2007 9:13 AM, Marc Wiriadisastra wrote: > > > > > > > > > On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > > > > > > > It has been brought to my attention > > > > > > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/ > > ) that K3b is > > > > no longer available on the DVD images (since the Core-Extras merge). As > > far as > > > > I can tell, this is because it is marked only as "optional" and not > > "default" > > > > in the sound-and-video group? As K3b is probably the best Free CD/DVD > > burning > > > > program around, the burning tool of choice of most KDE users and even > > several > > > > GNOME users, I think it would be great if this could be put back onto > > the DVD > > > > images in F9. Can this be added to the pungi kickstart config? > > > > > > > > Kevin Kofler > > > > > > > +1 and I run Gnome > > +100 :) > > I asked for including K3b on Fedora Live CD and got chewed for it! > Then I asked at least for Brassero and the answer was also no :( > > The reasoning was that there is already burning app on Gnome, the > nautils gnome burning monstrocity :( > > Please put k3b or brassero on Fedora Live CD, please. > we are talking about the install DVD no the livecd . for this I vote +1 too. As for the (non kde) livecd its not even an option. (space!!!!!!) From sundaram at fedoraproject.org Sun Dec 23 16:43:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 23 Dec 2007 22:13:54 +0530 Subject: Package Review Process wiki page and Fedora Update System In-Reply-To: References: Message-ID: <476E904A.3020507@fedoraproject.org> Michel Salim wrote: > Hi all, > > I've been noticing that on several occasions, new packagers would get > their packages approved, and then not submit the package to Fedora > Update System. There's thus a delay before the package is available on > stable releases. > > It just occured to me to check the Package Review Process page on the > wiki today, and it turns out that it does not mention Bodhi at all. > Should this be added? It should be. Feel free to mention it. > If so, should new packages be submitted as stable or testing? My > personal opinion is stable for any distributions tested by the > packager and reviewer, and testing for other distributions (with the > caveat that a package for any distribution can't go stable before a > newer distribution) I agree with this. Rahul From makghosh at gmail.com Sun Dec 23 16:56:55 2007 From: makghosh at gmail.com (Arindam Ghosh) Date: Sun, 23 Dec 2007 22:26:55 +0530 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: Message-ID: <8990327d0712230856h71112361h74c8f9397bd90aba@mail.gmail.com> K3B needs to brought back to the DVD, better if it starts with F9. Its the most reliable burning software available.... +1 from me :) On Dec 20, 2007 4:32 PM, Kevin Kofler wrote: > It has been brought to my attention > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/) that K3b is > no longer available on the DVD images (since the Core-Extras merge). As far as > I can tell, this is because it is marked only as "optional" and not "default" > in the sound-and-video group? As K3b is probably the best Free CD/DVD burning > program around, the burning tool of choice of most KDE users and even several > GNOME users, I think it would be great if this could be put back onto the DVD > images in F9. Can this be added to the pungi kickstart config? > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > cheers Arindam -- GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From makghosh at gmail.com Sun Dec 23 17:02:04 2007 From: makghosh at gmail.com (Arindam Ghosh) Date: Sun, 23 Dec 2007 22:32:04 +0530 Subject: what with mock ?? In-Reply-To: <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> Message-ID: <8990327d0712230902j6b14bc71k6ff94fbfd7a29f8a@mail.gmail.com> Hi On Dec 23, 2007 8:56 PM, subhodip biswas wrote: > pirut show only mock-0.8.17 listed In this case you should prolly' try enabling the fedora-development repository. It's gotta have the updated builds of 'mock'. cheers Arindam -- GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From choeger at cs.tu-berlin.de Sun Dec 23 17:58:27 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 23 Dec 2007 18:58:27 +0100 Subject: need advise: tomcat5 selinux policy Message-ID: <1198432707.3143.4.camel@choeger4> Hi, I am currently developing a selinux sample policy for a university project. I took example.te and example.fc as a base. Now I've got the problem that tomcat5 calls java to run a webservice which runs under the java_t domain. Can I use a transition rule to force it running under e.g. tomcat5_javawebbapp_t? regards christoph From kevin.kofler at chello.at Sun Dec 23 17:32:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 23 Dec 2007 17:32:53 +0000 (UTC) Subject: what with mock ?? References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> <8990327d0712230902j6b14bc71k6ff94fbfd7a29f8a@mail.gmail.com> Message-ID: Arindam Ghosh gmail.com> writes: > In this case you should prolly' try enabling the fedora-development > repository. It's gotta have the updated builds of 'mock'. NO! If he was running Rawhide, he'd already have that enabled. If you're not running Rawhide, then enabling the development repository is a very bad idea, as it'll effectively upgrade you to Rawhide. The problem here is simply that some mirrors are out of sync. Kevin Kofler From kevin.kofler at chello.at Sun Dec 23 17:49:12 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 23 Dec 2007 17:49:12 +0000 (UTC) Subject: Firefox 3 Beta 2 in Rawhide References: <476A2656.5060704@redhat.com> Message-ID: drago01 gmail.com> writes: > For me it refuses to load any site until I change > "network.dns.disableIPv6" to "true" > So I propose to make this the default .. You can't be serious... Trying IPv4 first would make sense, but disabling IPv6 altogether? Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Sun Dec 23 18:46:36 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 23 Dec 2007 19:46:36 +0100 Subject: gtkspell update Message-ID: <20071223194636.42eca982.mschwendt.tmp0701.nospam@arcor.de> I send out a warning about problems with the gtkspell update in rawhide, because according to the changelog it's only a minor update (with a jump from .fc8 to .fc9, though): %changelog * Thu Dec 20 2007 Matthew Barnes - 2.0.11-5.fc9 - Add patch for RH bug #245888 (use Enchant). * Wed Oct 10 2007 Matthew Barnes - 2.0.11-4.fc8 - Rebuild However, (and I have not examined it any further yet) a build of sylpheed, which worked fine on Dec 17th, now breaks like this: [...] gcc -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 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/kerberos/include -I/usr/include/gtkspell-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -o sylpheed main.o mainwindow.o folderview.o summaryview.o messageview.o headerview.o textview.o imageview.o mimeview.o query_search.o message_search.o colorlabel.o action.o compose.o gtkshruler.o menu.o stock_pixmap.o prefs_ui.o prefs_common_dialog.o prefs_filter.o prefs_filter_edit.o prefs_account_dialog.o prefs_folder_item.o prefs_display_items.o prefs_display_header.o prefs_customheader.o prefs_summary_column.o prefs_template.o prefs_actions.o prefs_search_folder.o prefs_toolbar.o account_dialog.o template.o addressbook.o addr_compl.o addritem.o addrcache.o addrbook.o addrindex.o mgutils.o vcard.o ldif.o importldif.o importcsv.o jpilot.o syldap.o editbook.o editgroup.o editaddress.o editvcard.o editjpilot.o editldap.o editldap_basedn.o addressadd.o filesel.o foldersel.o statusbar.o logwindow.o sourcewindow.o manage_window.o undo.o alertpanel.o inputdialog.o progressdialog.o subscribedialog.o about.o setup.o gtkutils.o send_message.o inc.o import.o export.o rfc2015.o passphrase.o select-keys.o sigstatus.o simple-gettext.o manual.o eggtrayicon.o trayicon.o printing.o sslmanager.o quote_fmt_lex.o quote_fmt_parse.o sylpheed-marshal.o -pthread -lgpgme -lresolv -llber -lpthread -lldap -lgthread-2.0 -lrt ../libsylph/.libs/libsylph.a -L/usr/kerberos/lib -lnsl -lcompface -lssl -lcrypto -lz -lgtkspell -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 compose.o: In function `compose_set_spell_lang_menu': /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5331: undefined reference to `new_aspell_config' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5332: undefined reference to `get_aspell_dict_info_list' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5333: undefined reference to `delete_aspell_config' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5335: undefined reference to `aspell_dict_info_list_elements' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference to `aspell_dict_info_enumeration_next' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference to `aspell_dict_info_enumeration_next' /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5342: undefined reference to `delete_aspell_dict_info_enumeration' collect2: ld returned 1 exit status From lordmorgul at gmail.com Sun Dec 23 18:51:58 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 23 Dec 2007 10:51:58 -0800 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476E570A.1060804@gmail.com> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> Message-ID: <476EAE4E.2060400@gmail.com> drago01 wrote: > Andrew Farris wrote: >> drago01 wrote: >> >>> On Dec 23, 2007 1:43 AM, Chuck Anderson wrote: >>> the problem is that it does not work with some ISP .. and thats not >>> something that we can fix that easily (well or we can try to add some >>> fallback logic) >>> >> >> Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address >> locally >> while your ISP won't respond properly to IPv6 -> IPv4 nat >> translation? I'd >> suggest making sure your local network configuration has IPv6 disabled >> and see >> if that firefox now does not care whether IPv6 is not disabled. >> >> If your ISP misbehaves, try not letting IPv6 traffic out of your >> machine (don't >> configure an address for the family). The application should not >> choose to try >> and generate IPv6 traffic if it is not told you have IPv6 connectivity. >> >> > well my ISP is connected to a wireless router and I got the > configuration over dhcp from the router. There seems to be indeed a ipv6 > adress assigned to the interface in question (dunno why maybe because > the router does support ipv6 but the ISP does not). > nevertheless if ipv6 does not work it should atleast fall back to ipv4. > I know how to deal with this but I doubt that all other users affected > will be able to deal with it. And a webbrowser _must_ work out of the > box .. else they cannot even try to google for a solution etc. I agree that the primary browser *should just work*. But I do not think the right path is to go and disable IPv6 entirely by default (in a hidden option)... the longer this type of ad hoc 'fix' for ISPs that are not yet making the conversion the longer the entire internet will suffer with it. The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option. We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From drago01 at gmail.com Sun Dec 23 19:02:36 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 20:02:36 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> Message-ID: On Dec 23, 2007 6:49 PM, Kevin Kofler wrote: > > drago01 gmail.com> writes: > > For me it refuses to load any site until I change > > "network.dns.disableIPv6" to "true" > > So I propose to make this the default .. > > You can't be serious... > Trying IPv4 first would make sense, but disabling IPv6 altogether? disabling it seems to be too much .. but should atleast fallback to ipv4 when v6 does not work. From makghosh at gmail.com Sun Dec 23 19:06:51 2007 From: makghosh at gmail.com (Arindam Ghosh) Date: Mon, 24 Dec 2007 00:36:51 +0530 Subject: what with mock ?? In-Reply-To: References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> <8990327d0712230902j6b14bc71k6ff94fbfd7a29f8a@mail.gmail.com> Message-ID: <8990327d0712231106t31fb3690k8b9ee9ebc3281ca0@mail.gmail.com> On Dec 23, 2007 11:02 PM, Kevin Kofler wrote: > NO! If he was running Rawhide, he'd already have that enabled. If you're not > running Rawhide, then enabling the development repository is a very bad idea, > as it'll effectively upgrade you to Rawhide. Yeah! that is not a good idea anways...so simply pirut needs to re-synced. :) But just installing fedora-packager won't get the entire system upgraded to Rawhide. Actually, i suggested a temporary enabling, better to use yum from command-line, # yum --enablerepo=development groupinstall fedora-packager > The problem here is simply that some mirrors are out of sync. i agree cheers Arindam -- GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From myfedora at richip.dhs.org Sun Dec 23 19:19:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 23 Dec 2007 12:19:26 -0700 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476E25B5.9050603@redhat.com> References: <476A2656.5060704@redhat.com> <20071222164214.GE30935@asus.config> <476E25B5.9050603@redhat.com> Message-ID: <1198437566.21925.12.camel@localhost6.localdomain6> On Sun, 2007-12-23 at 10:09 +0100, Martin Stransky wrote: > Adam Huffman wrote: > > I have installed it on F8 and it seems to have brought back the annoying > > behaviour of moving the Firefox window when opening a link. Is this > > Fedora-specific? > > > > Please check the generic upstream version > (http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-2-now-available-for-download/) I was going to post about this, too (FF3 window popping up in the virtual desktop that the user is in around the time a link is clicked), but assumed that it had always been the behavior of the upstream version of FF (including ver. 2) and that we were just applying patches to it in Fedora to adopt a different behavior. So that isn't the case? -- Richi Plana From frank-buettner at gmx.net Sun Dec 23 19:28:33 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 23 Dec 2007 20:28:33 +0100 Subject: Filezilla for EPEL Message-ID: <476EB6E1.5090109@gmx.net> Hello, can filezilla be released for EPEL? Thanks, and an marry Christmas.:) -------------- 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 choeger at cs.tu-berlin.de Sun Dec 23 19:29:13 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 23 Dec 2007 20:29:13 +0100 Subject: need advise: tomcat5 selinux policy In-Reply-To: <1198432707.3143.4.camel@choeger4> References: <1198432707.3143.4.camel@choeger4> Message-ID: <1198438153.3143.6.camel@choeger4> Am Sonntag, den 23.12.2007, 18:58 +0100 schrieb Christoph H?ger: > Hi, > > I am currently developing a selinux sample policy for a university > project. I took example.te and example.fc as a base. > Now I've got the problem that tomcat5 calls java to run a webservice > which runs under the java_t domain. Can I use a transition rule to force > it running under e.g. tomcat5_javawebbapp_t? > > regards > > christoph > I just saw, that I forgot to mention that the example policy shall secure tomcat. From myfedora at richip.dhs.org Sun Dec 23 19:28:37 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 23 Dec 2007 12:28:37 -0700 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476EAE4E.2060400@gmail.com> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> Message-ID: <1198438117.21925.19.camel@localhost6.localdomain6> On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote: > The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails > (and yes I know that is more work). In the meantime if it has an option to > 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't > think disabling it is a good option. > > We still probably should not be enabling the IPv6 address unless requested by > the users (for which there is a very obvious UI option already right in the > network configuration), but that is a broader discussion that has happened a few > times before. A better fix (and one that other subsystems could use) is a program that detects whether IPv6 will be a problem for the user and set a flag somewhere global that programs can check or scripts can recognize and thus set the defaults for programs like FF to enable or disable IPv6. Cascade effect from a global config to a minor. After all, if IPv6 isn't enabled in the Network layer, then applications shouldn't either. It's an ugly solution for an ugly situation. As for not enabling IPv6 by default, you'll find by going back through fedora-devel archives that you'll find just as many IPv6 proponents for the sake of enabling new technologies as you'll find anti-IPv6 for the sake of security/not-installing-unneeded-functionality/etc. Can o' worms for you. -- Richi Plana From valent.turkovic at gmail.com Sun Dec 23 19:55:25 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 23 Dec 2007 20:55:25 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> Message-ID: <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> On 12/23/07, drago01 wrote: > On Dec 22, 2007 9:43 PM, Valent Turkovic wrote: > > On 12/20/07, Eric Mesa wrote: > > > I also use K3B. In comparison all of the Gnome burners are crap. (And I > > > primarily use Gnome) > > > > > > > > > On Dec 20, 2007 9:13 AM, Marc Wiriadisastra wrote: > > > > > > > > > > > > On Thu, 2007-12-20 at 11:02 +0000, Kevin Kofler wrote: > > > > > > > > > It has been brought to my attention > > > > > > > > (http://dot.kde.org/1197759365/1198030918/1198084280/1198100165/ > > > ) that K3b is > > > > > no longer available on the DVD images (since the Core-Extras merge). As > > > far as > > > > > I can tell, this is because it is marked only as "optional" and not > > > "default" > > > > > in the sound-and-video group? As K3b is probably the best Free CD/DVD > > > burning > > > > > program around, the burning tool of choice of most KDE users and even > > > several > > > > > GNOME users, I think it would be great if this could be put back onto > > > the DVD > > > > > images in F9. Can this be added to the pungi kickstart config? > > > > > > > > > > Kevin Kofler > > > > > > > > > +1 and I run Gnome > > > > +100 :) > > > > I asked for including K3b on Fedora Live CD and got chewed for it! > > Then I asked at least for Brassero and the answer was also no :( > > > > The reasoning was that there is already burning app on Gnome, the > > nautils gnome burning monstrocity :( > > > > Please put k3b or brassero on Fedora Live CD, please. > > > > we are talking about the install DVD no the livecd . > for this I vote +1 too. > As for the (non kde) livecd its not even an option. (space!!!!!!) But brassero is gnome app... I know that kde apps can't fit on gnome live cd. -- 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 drago01 at gmail.com Sun Dec 23 20:00:53 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 21:00:53 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198438117.21925.19.camel@localhost6.localdomain6> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> <1198438117.21925.19.camel@localhost6.localdomain6> Message-ID: On Dec 23, 2007 8:28 PM, Richi Plana wrote: > On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote: > > The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails > > (and yes I know that is more work). In the meantime if it has an option to > > 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't > > think disabling it is a good option. > > > > We still probably should not be enabling the IPv6 address unless requested by > > the users (for which there is a very obvious UI option already right in the > > network configuration), but that is a broader discussion that has happened a few > > times before. > > A better fix (and one that other subsystems could use) is a program that > detects whether IPv6 will be a problem for the user and set a flag > somewhere global that programs can check or scripts can recognize and > thus set the defaults for programs like FF to enable or disable IPv6. > Cascade effect from a global config to a minor. After all, if IPv6 isn't > enabled in the Network layer, then applications shouldn't either. > > It's an ugly solution for an ugly situation. > > As for not enabling IPv6 by default, you'll find by going back through > fedora-devel archives that you'll find just as many IPv6 proponents for > the sake of enabling new technologies as you'll find anti-IPv6 for the > sake of security/not-installing-unneeded-functionality/etc. Can o' worms > for you. I have no problem with ipv6 enabled by default as long as ipv4 only networks still work whit out requiring the user to change a hidden option. (as it did until now). From sundaram at fedoraproject.org Sun Dec 23 19:52:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Dec 2007 01:22:53 +0530 Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> Message-ID: <476EBC95.5050707@fedoraproject.org> Valent Turkovic wrote:) > > But brassero is gnome app... I know that kde apps can't fit on gnome live cd. Actually there isn't any space left in either the KDE or GNOME live images regardless of whether it is a KDE app or not. With multi-lib, they don't even fit a CD for x86_64 architecture. You would have to remove existing apps or find a way to split them up and remove sub packages if you need more space. Rahul From drago01 at gmail.com Sun Dec 23 20:03:05 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 21:03:05 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> <1198438117.21925.19.camel@localhost6.localdomain6> Message-ID: On Dec 23, 2007 9:00 PM, drago01 wrote: > > On Dec 23, 2007 8:28 PM, Richi Plana wrote: > > On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote: > > > The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails > > > (and yes I know that is more work). In the meantime if it has an option to > > > 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't > > > think disabling it is a good option. > > > > > > We still probably should not be enabling the IPv6 address unless requested by > > > the users (for which there is a very obvious UI option already right in the > > > network configuration), but that is a broader discussion that has happened a few > > > times before. > > > > A better fix (and one that other subsystems could use) is a program that > > detects whether IPv6 will be a problem for the user and set a flag > > somewhere global that programs can check or scripts can recognize and > > thus set the defaults for programs like FF to enable or disable IPv6. > > Cascade effect from a global config to a minor. After all, if IPv6 isn't > > enabled in the Network layer, then applications shouldn't either. > > > > It's an ugly solution for an ugly situation. > > > > As for not enabling IPv6 by default, you'll find by going back through > > fedora-devel archives that you'll find just as many IPv6 proponents for > > the sake of enabling new technologies as you'll find anti-IPv6 for the > > sake of security/not-installing-unneeded-functionality/etc. Can o' worms > > for you. > > I have no problem with ipv6 enabled by default as long as ipv4 only > networks still work whit out requiring the user to change a hidden > option. (as it did until now). > one thing that I noticed: ipv6 is NOT disabled in firefox 2 but it still works for me. So this is a regression in firefox 3's ipv6/ipv4 handling. From sundaram at fedoraproject.org Sun Dec 23 19:55:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Dec 2007 01:25:04 +0530 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> <1198438117.21925.19.camel@localhost6.localdomain6> Message-ID: <476EBD18.5010307@fedoraproject.org> drago01 wrote: > I have no problem with ipv6 enabled by default as long as ipv4 only > networks still work whit out requiring the user to change a hidden > option. (as it did until now). File a bug report in upstream bugzilla. Rahul From berrange at redhat.com Sun Dec 23 21:17:17 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 23 Dec 2007 21:17:17 +0000 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <1198438117.21925.19.camel@localhost6.localdomain6> References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> <1198438117.21925.19.camel@localhost6.localdomain6> Message-ID: <20071223211717.GA24823@redhat.com> On Sun, Dec 23, 2007 at 12:28:37PM -0700, Richi Plana wrote: > On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote: > > The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails > > (and yes I know that is more work). In the meantime if it has an option to > > 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't > > think disabling it is a good option. > > > > We still probably should not be enabling the IPv6 address unless requested by > > the users (for which there is a very obvious UI option already right in the > > network configuration), but that is a broader discussion that has happened a few > > times before. > > A better fix (and one that other subsystems could use) is a program that > detects whether IPv6 will be a problem for the user and set a flag > somewhere global that programs can check or scripts can recognize and > thus set the defaults for programs like FF to enable or disable IPv6. > Cascade effect from a global config to a minor. After all, if IPv6 isn't > enabled in the Network layer, then applications shouldn't either. > > It's an ugly solution for an ugly situation. > > As for not enabling IPv6 by default, you'll find by going back through > fedora-devel archives that you'll find just as many IPv6 proponents for > the sake of enabling new technologies as you'll find anti-IPv6 for the > sake of security/not-installing-unneeded-functionality/etc. Can o' worms > for you. There is no technical reason why we should have to choose between enabling and disabling IPv6 in firefox. If it correctly follows the RFC 3484 for DNS resolution then it would 'just work'. Applications which are correctly written will use 'getaddrinfo' to resolve names. This will automatically decide whether to return IPv4 addrs, or IPv6 addrs or both, and will sort them in the order most likely to succeed. If you have only link-local IPv6 addresses (which all Fedora installs do by default) then it will *not* give you back IPv6 addrs since you can't reach them. Likewise if you have a site-local IPv6 address, it will not give you back IPv6 addrs that are out on the internet because they would not be routable. There's all sorts of rules on prioritization, but the effect is IPv4 & IPv6 will always be enable in the DNS lookup and apps should 'just work' whatever interface address config they have. http://people.redhat.com/drepper/userapi-ipv6.html http://www.rfc-editor.org/rfc/rfc3484.txt 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 valent.turkovic at gmail.com Sun Dec 23 21:24:44 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 23 Dec 2007 22:24:44 +0100 Subject: Fedora and lack of audio communication with the community In-Reply-To: <1198421493.25746.4.camel@cutter> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> <1198421493.25746.4.camel@cutter> Message-ID: <64b14b300712231324y2cce5754y9d001a0b890da516@mail.gmail.com> On 12/23/07, seth vidal wrote: > > On Sat, 2007-12-22 at 17:40 -0600, Les Mikesell wrote: > > Kevin Kofler wrote: > > > Valent Turkovic gmail.com> writes: > > >> first excuse me if this is the wrong mailing list. If there is > > >> fedora-marketing or some similar :) mailing list please point me in > > >> the right direction. > > > > > > There is a fedora-marketing-list indeed. > > > > > > But to answer your suggestion: I personally don't understand why all the fuss > > > about podcasts, IMHO written plaintext is more convenient for things like that > > > (easier to skim over, easier to find a section when going back to something you > > > already read, easier to search automatically (fulltext search), easier to find > > > in a search engine too (fulltext indexing), no need to either put headphones on > > > or have everyone around listen to the podcast too whether they want it or not, > > > can be consumed on a machine with no sound at all (as in some offices) and of > > > course faster to download too). > > > > One word: commuting. Podcasts do to talk radio (or the internet > > equivalent) what tivo does to television. While it is absurd to hope > > that an interesting personality will be chatting on a live broadcast and > > conclude at precisely the times you are trapped in your car for the > > daily commute, it is quite easy to subscribe to a podcast and automate > > the transfer of new content to your ipod/player. Then it is a matter of > > pushing the button to pause/continue at convenient times. It's also > > great if you work out regularly on a treadmill or similar device that > > doesn't require your full concentration. Sometimes way a person is > > saying comes across differently when you listen to an interview compared > > even to reading a transcript of the same thing. I tend to prefer the > > ones moderated by someone with actual broadcast experience like Leo > > Laporte or fast paced ones like CNET's Buzz Out Load. > > > Podcasts are useless to the deaf and Hard of Hearing. If you want to put > a podcast up, fine. if you don't have a transcript of it you're > excluding that portion of the population, entirely. There is currently > software to read text in a voice for the blind, we have nothing to > convert speech to text. > > that's why we shouldn't do podcasts. > > -sv Why do you (fedora) do video without sign language translation? Fedora and linux in general is far, far, far from usable for blind persons... and for disabled also, voice recognition is almost non existent... There are lots of people who can't read and listening to computer voice reading some text is far worse from live talk shows... Not doing podcasts is a nonsense to me. You could exlude every medium for some reason... and we should stop everything and do nothing, that would be best :) Valent. -- 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 sundaram at fedoraproject.org Sun Dec 23 21:23:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Dec 2007 02:53:07 +0530 Subject: Fedora and lack of audio communication with the community In-Reply-To: <64b14b300712231324y2cce5754y9d001a0b890da516@mail.gmail.com> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> <1198421493.25746.4.camel@cutter> <64b14b300712231324y2cce5754y9d001a0b890da516@mail.gmail.com> Message-ID: <476ED1BB.2030409@fedoraproject.org> Valent Turkovic wrote: > Why do you (fedora) do video without sign language translation? > Fedora and linux in general is far, far, far from usable for blind > persons... and for disabled also, voice recognition is almost non > existent... Not quite. Here is a review from a blind user. http://blogs.sun.com/korn/entry/a_view_of_fedora_as Rahul From kwizart at gmail.com Sun Dec 23 21:54:31 2007 From: kwizart at gmail.com (KH KH) Date: Sun, 23 Dec 2007 22:54:31 +0100 Subject: Filezilla for EPEL In-Reply-To: <476EB6E1.5090109@gmx.net> References: <476EB6E1.5090109@gmx.net> Message-ID: 2007/12/23, Frank B?ttner : > Hello, > can filezilla be released for EPEL? Hello No, unless the requested BuildRequirement can be provided. (needs wxGTK 2.8.x) Actually even rawhide cannot provides the necessary BuildRequirement for the last FileZilla. (3.0.4 - needs wxGTK 2.8.6) so I've backported some patches so we can build the last 3.0.2.1 (needs wxGTK 2.8.3) with theses additional patches... As soon as it will be possible, I will request a EPEL-5 branch for FileZilla. But i would say, it does not make sense for now. Alternatively, it could be possible to build it with a statically compiled wxGTK... I will check further next week... Nicolas (kwizart ) > Thanks, > and an marry Christmas.:) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From icon at fedoraproject.org Sun Dec 23 21:56:39 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 23 Dec 2007 16:56:39 -0500 Subject: License change: diction (GPLv2+ -> GPLv3+) Message-ID: Note, that diction went from GPLv2+ to GPLv3+. "repoquery --whatrequires diction" gives me nothing, so I'm guessing that this change doesn't have any adverse effects. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Sun Dec 23 21:54:58 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 23 Dec 2007 22:54:58 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <476EBC95.5050707@fedoraproject.org> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> Message-ID: <476ED932.2090601@poolshark.org> Rahul Sundaram wrote: > With multi-lib, > they don't even fit a CD for x86_64 architecture. Hmm, why would we provide multi-lib on a live CD ? From dan at danny.cz Sun Dec 23 22:13:58 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 23 Dec 2007 23:13:58 +0100 Subject: Filezilla for EPEL In-Reply-To: References: <476EB6E1.5090109@gmx.net> Message-ID: <1198448038.3226.8.camel@eagle.danny.cz> KH KH p??e v Ne 23. 12. 2007 v 22:54 +0100: > 2007/12/23, Frank B?ttner : > > Hello, > > can filezilla be released for EPEL? > Hello > No, unless the requested BuildRequirement can be provided. (needs wxGTK 2.8.x) > Actually even rawhide cannot provides the necessary BuildRequirement > for the last FileZilla. (3.0.4 - needs wxGTK 2.8.6) so I've backported > some patches so we can build the last 3.0.2.1 (needs wxGTK 2.8.3) with > theses additional patches... > > As soon as it will be possible, I will request a EPEL-5 branch for > FileZilla. But i would say, it does not make sense for now. > Alternatively, it could be possible to build it with a statically > compiled wxGTK... > > I will check further next week... We are working on the inclusion of wxGTK into EPEL-4. I will be responsible for EPEL and Matthew for Fedora. So stay tuned :-) Dan From kevin.kofler at chello.at Sun Dec 23 23:26:14 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 23 Dec 2007 23:26:14 +0000 (UTC) Subject: gtkspell update References: <20071223194636.42eca982.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > * Thu Dec 20 2007 Matthew Barnes redhat.com> - 2.0.11-5.fc9 > - Add patch for RH bug #245888 (use Enchant). This says what it says: gtkspell is now using enchant instead of aspell. For the rationale, see: http://fedoraproject.org/wiki/Releases/FeatureDictionary > compose.o: In function `compose_set_spell_lang_menu': > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5331: undefined reference to `new_aspell_config' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5332: undefined reference to `get_aspell_dict_info_list' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5333: undefined reference to `delete_aspell_config' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5335: undefined reference to `aspell_dict_info_list_elements' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference to `aspell_dict_info_enumeration_next' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference to `aspell_dict_info_enumeration_next' > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5342: undefined reference to `delete_aspell_dict_info_enumeration' And this is Sylpheed trying to use aspell-related functions directly, so of course this doesn't work anymore. If Sylpheed really must use APIs of the underlying spellchecker instead of the gtkspell abstraction, it'll have to be patched to use enchant too. (Technically, those linker errors could probably be fixed by linking in aspell directly, but that'll not solve the actual problem because Sylpheed would then try to read the list of languages from aspell while gtkspell is actually using enchant.) Kevin Kofler From triad at df.lth.se Sun Dec 23 23:43:47 2007 From: triad at df.lth.se (Linus Walleij) Date: Mon, 24 Dec 2007 00:43:47 +0100 (CET) Subject: how is pulseaudio supposed to work? In-Reply-To: <20071219163804.GG28769@tango.0pointer.de> References: <20071218151210.2542f875@redhat.com> <1198010295.11811.27.camel@rousalka.dyndns.org> <20071218211312.GG3360@tango.0pointer.de> <20071218215443.GA97953@dspnet.fr.eu.org> <20071219095432.GL9741@tango.0pointer.de> <20071219104448.GA80218@dspnet.fr.eu.org> <20071219110744.GA16151@tango.0pointer.de> <20071219142245.GB2526@free.fr> <20071219153727.GD28769@tango.0pointer.de> <20071219160634.GE2526@free.fr> <20071219163804.GG28769@tango.0pointer.de> Message-ID: On Wed, 19 Dec 2007, Lennart Poettering wrote: > What we really want is some kind of init-like babysitter as the > session manager. (...) > I try to push Scott Remnant with his InitKit into that direction. (...) > While the > dependency trees are certainly much simpler for GNOME sessions than > for system bootup it is basically the same problem, so it would be > great to handle both the same way by the same code. Sounds like you're advocating InitKit to build upon init[ng] being "init[ng] for sessions". And it intuitively strikes me as a good idea. With the percieved slowness in session start discussed in other threads, the parallelizing nature of especially initng could be put to good work here. (Or I misunderstood the details entirely.) Linus From bruno at wolff.to Sun Dec 23 23:54:46 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 23 Dec 2007 17:54:46 -0600 Subject: Fedora 8 review In-Reply-To: <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> Message-ID: <20071223235446.GA32319@wolff.to> On Fri, Dec 21, 2007 at 13:08:41 -0700, Stephen John Smoogen wrote: > On Dec 21, 2007 12:54 PM, Jeff Spaleta wrote: > > > I hereby make this a personal challenge to every single laypress > > reviewer out there. Stop sensationalizing problems, and start helping > > your readers appreciate the value of participating in open development > > by being role models on how to interact with developers to file > > issues. You can't participate like this for other software, stop > > squandering the opportunity to help users to see the opportunity to > > have an impact on the software they are using. > > > > But.. but.. but... you are going to completely make sensational press > not a money maker. If John Dvorak, ESR, etc can't stand around yelling > about how something sucks because it didnt fit their little world > view.. how are they going to sell ads, books, or t-shirts? I don't think ESR belongs in this thread. He actually does contribute to open source projects (e.g. recently he has done a lot of work for Wesnoth). From jkeating at redhat.com Mon Dec 24 00:47:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Dec 2007 19:47:19 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <476ED932.2090601@poolshark.org> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> Message-ID: <20071223194719.24292e38@redhat.com> On Sun, 23 Dec 2007 22:54:58 +0100 Denis Leroy wrote: > Hmm, why would we provide multi-lib on a live CD ? Because Live images are installable. -- 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 lkundrak at redhat.com Mon Dec 24 03:30:08 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 24 Dec 2007 04:30:08 +0100 Subject: Moonshine -> Werewolf -> ? Werewolf is a , is a In-Reply-To: <4767F34D.2090905@redhat.com> References: <20071218072709.6c5afb2a@hansolo.jdub.homelinux.org> <65514.63.85.68.164.1197984751.squirrel@mail.jcomserv.net> <4767F34D.2090905@redhat.com> Message-ID: <1198467008.9210.2.camel@localhost.localdomain> On Tue, 2007-12-18 at 11:20 -0500, Michael DeHaan wrote: > * Dentist. Werewolves scare kids. Dentists scare kids. (substitute > something else that scares kids). Hah! This one would definitely get my vote! -- Lubomir Kundrak (Red Hat Security Response Team) From braden at endoframe.com Mon Dec 24 05:40:30 2007 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 24 Dec 2007 00:40:30 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476E216B.1040209@redhat.com> References: <476A2656.5060704@redhat.com> <1198298613.3557.32.camel@hinge.endoframe.net> <476E216B.1040209@redhat.com> Message-ID: <476F464E.8080509@endoframe.com> Martin Stransky wrote: > Braden McDaniel wrote: >> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote: >> >> [snip] >> >>> If you're a package maintainer and your package already uses xulrunner, >>> please rebuild it against the new rawhide version. Xulrunner directory >>> has been changed and many gecko packages (if not all) are linked with >>> --rpath linker directive. As long as rpath is used you have to rebuild >>> gecko-libs based packages after each xulrunner change so please consider >>> to remove it. Gecko libraries are registered system wide by >>> /etc/ld.so.conf.d and rpath should not be necessary in rawhide. >> >> But isn't it the case that the libraries in question do not have >> soversions? >> >> If the rpath is eliminated, how do we know when things really *do* need >> to break? > > gecko-libs 1.9 exports only frozen interfaces so ideally we don't need > to rebuild any package unless we move to a completely new gecko (firefox > 4 ;-)) I don't find that rationale particularly confidence-inspiring. (Since when did software development proceed "ideally"? ;-) Are we sure there are no external symbols accessible from public headers that aren't considered "frozen"? Or are we just sure that blessed interfaces are frozen? I don't like the idea of playing without a net here. soversions are how we track backward compatibility; software that doesn't follow conventions *should* be handled with the kind of caution that is reflected in (for example) an rpath. It's a pain in the ass because it breaks a lot. But it breaks *predictably*. I'm sure I'm as unhappy with the rebuilds as anyone; but I *like* determinism *a lot*. Do we have any statements of intent from upstream regarding these issues? A commitment to change library names when frozen interfaces change, perhaps? -- Braden McDaniel e-mail: Jabber: From subhodip at fedoraproject.org Mon Dec 24 06:09:07 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Mon, 24 Dec 2007 11:39:07 +0530 Subject: what with mock ?? In-Reply-To: <8990327d0712231106t31fb3690k8b9ee9ebc3281ca0@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> <8990327d0712230902j6b14bc71k6ff94fbfd7a29f8a@mail.gmail.com> <8990327d0712231106t31fb3690k8b9ee9ebc3281ca0@mail.gmail.com> Message-ID: <539333cb0712232209y65e03534v43b59f952613bda6@mail.gmail.com> i am not running rawhide .. F8 . Fedora-packager needs mock 0.8.17 while @debarshi some mirror have mock 0.8.18 . pirut does not show that nor does yum. Enabling development repo does not help . > The problem here is simply that some mirrors are out of sync. is anyone taking care of that ? -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From makghosh at gmail.com Mon Dec 24 06:27:03 2007 From: makghosh at gmail.com (Arindam Ghosh) Date: Mon, 24 Dec 2007 11:57:03 +0530 Subject: what with mock ?? In-Reply-To: <539333cb0712232209y65e03534v43b59f952613bda6@mail.gmail.com> References: <539333cb0712230037t32cba8b2x283a4a93e6859120@mail.gmail.com> <3170f42f0712230224g6d3a31f0j50b9b5e6f952d46d@mail.gmail.com> <539333cb0712230711m5ff6adfakd6475ede34acecd4@mail.gmail.com> <539333cb0712230726i7411dd3cl5deaf3ee97a048cb@mail.gmail.com> <8990327d0712230902j6b14bc71k6ff94fbfd7a29f8a@mail.gmail.com> <8990327d0712231106t31fb3690k8b9ee9ebc3281ca0@mail.gmail.com> <539333cb0712232209y65e03534v43b59f952613bda6@mail.gmail.com> Message-ID: <8990327d0712232227v1b7f524bm63ae18a4dce6b699@mail.gmail.com> Have you tried to re-sync yum/pirut I mean try, # yum clean all This will clear all your old mirrorlists. and then try to install fedora-packager I seem to already have mock ==================== [joy at desktop ~]$ rpm -q mock mock-0.8.18-1.fc8 ==================== As for the mirrors, who haven't synced the latest version of mock, i think that will be done shortly... On Dec 24, 2007 11:39 AM, subhodip biswas wrote: > i am not running rawhide .. F8 . Fedora-packager needs mock 0.8.17 while > @debarshi some mirror have mock 0.8.18 . > > pirut does not show that nor does yum. Enabling development repo does > not help . > > > The problem here is simply that some mirrors are out of sync. > > is anyone taking care of that ? > > -- > Regards > Subhodip Biswas > > GPG key : FAEA34AB > Server : pgp.mit.edu > http://subhodipbiswas.wordpress.com > http:/www.fedoraproject.org/wiki/SubhodipBiswas > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > cheers Arindam -- GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From denis at poolshark.org Mon Dec 24 07:39:11 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 24 Dec 2007 08:39:11 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476E2500.8000205@redhat.com> References: <476A2656.5060704@redhat.com> <476D9D59.30001@poolshark.org> <476E2500.8000205@redhat.com> Message-ID: <476F621F.8030903@poolshark.org> Martin Stransky wrote: > Denis Leroy wrote: >> Since i maintain galeon, i got word from an upstream developer that >> xulrunner is still not exactly in a nice state to work with. To quote >> him: "I'm holding off on this until mozilla sorts out the microb >> problem. Apparently a good chunk of the brokenness is due to a bunch >> of unreviewed microb (the n800 browser) patches being committed. They >> claim they are going to back them out. Hopefully after that, [galeon] >> won't be so crippled.". > >> I know almost nothing about mozilla/xulrunner upstream development, >> but I have to ask: it's not just them (the packages that depend on >> firefox) that have to be ready for xulrunner, will xulrunner also be >> ready for them ? :-) (i.e. with enough time for maintainers/upstream >> to port/debug ?) > > I hope this will be fixed before the final firefox 3 release. If you > have any serious problem please file a bug at bugzilla.mozilla.org (or > bugzilla.redhat.com and I'll move it upstream). > > Things are still fresh and any feedback is highly appreciated. > >> If it comes to that, I hope we can debate whether it should not be >> xulrunner that gets dropped and firefox-devel restored (assuming >> that's even possible). > > We are not going to ship two firefox versions (2 and 3). Xulrunner-devel > is generally a firefox3-devel package, there isn't any difference and I > believe all developers will be able to transfer their packages to > Firefox 3 (or xulrunner in our distro). Ah i see, so the porting problems stem from the transition to firefox 3 (gecko 1.9), not so much from the the xulrunner packaging transition. That makes sense, thanks. Finally had a chance to try galeon on rawhide (tough to run rawhide on vmware currently), unfortunately it segfaults on startup. Maybe we should create a firefox/mozilla/xulrunner SIG, to bring together the people that are comfortable around mozilla code ? The SIG page could track the various porting efforts to gecko 1.9. From valent.turkovic at gmail.com Mon Dec 24 08:31:04 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 24 Dec 2007 09:31:04 +0100 Subject: Fedora 8 review In-Reply-To: <476C2300.2020704@fedoraproject.org> References: <64b14b300712210648g6adca64re22a1e1c569dce5d@mail.gmail.com> <476BD268.1050009@hhs.nl> <16de708d0712211114s7c7c350cj624be9115323f4d0@mail.gmail.com> <604aa7910712211121x3b8c8ff3h1e88190d5c91c98@mail.gmail.com> <16de708d0712211125v27e7a795p579fd3b51980564c@mail.gmail.com> <604aa7910712211154s6d985265s71b77ab4bae26708@mail.gmail.com> <80d7e4090712211208h6be04684h873191fe37166e03@mail.gmail.com> <604aa7910712211219i2f418b8ar561d2a47633bf984@mail.gmail.com> <476C22EE.3030807@ncsu.edu> <476C2300.2020704@fedoraproject.org> Message-ID: <476F6E48.6020300@gmail.com> Rahul Sundaram wrote: > Casey Dahlin wrote: >> Jeff Spaleta wrote: >>> On Dec 21, 2007 11:08 AM, Stephen John Smoogen >>> wrote: >>> >>>> But.. but.. but... you are going to completely make sensational press >>>> not a money maker. If John Dvorak, ESR, etc can't stand around yelling >>>> about how something sucks because it didnt fit their little world >>>> view.. how are they going to sell ads, books, or t-shirts? >>>> >>> >>> Yell all you want, just reference the corresponding tickets next to >>> the rant. >>> >>> -jef >>> >>> >> Does this all mean we aren't going to attempt to find and fix these >> problems? > > How do you expect anyone to fix the problems without even knowing what > the problems are? Mails asking for more details went unanswered BTW. > > Rahul > I forwarded you Bryans email in which he says they didn't get any emails from you... Valent. From buildsys at redhat.com Mon Dec 24 11:43:55 2007 From: buildsys at redhat.com (Build System) Date: Mon, 24 Dec 2007 06:43:55 -0500 Subject: rawhide report: 20071224 changes Message-ID: <200712241143.lBOBhtLx015997@porkchop.devel.redhat.com> New package fmt-ptrn A simple template system New package jabbim Jabber client for mere mortals New package perl-Algorithm-CheckDigits Perl extension to generate and test check digits New package photoml An XML DTD and tools for describing photographic metadata Removed package kalgebra Updated Packages: Miro-1.0-4.fc9 -------------- * Sun Dec 23 2007 Alex Lancaster 1.0-4 - Add support for python eggs for F9+ * Sun Dec 23 2007 Alex Lancaster 1.0-3 - Re-enable gecko-libs 1.9, as 1.8.1.10 has now gone away as a BR. - Add first-cut patch from Martin Stransky from #393521 that attempts to patch Miro to work against xulrunner. Likely incomplete. akode-2.0.2-3.fc9 ----------------- * Sun Dec 23 2007 Rex Dieter 2.0.2-3 - fix flac113 support * Sun Dec 23 2007 Rex Dieter 2.0.2-2 - fix multilib conflicts (#340591) * Sun Dec 23 2007 Rex Dieter 2.0.2-1 - akode-2.0.2 atanks-2.7-1.fc9 ---------------- * Sun Dec 23 2007 Konstantin Ryabitsev - 2.7-1 - Upstream 2.7 booty-0.94-1.fc9 ---------------- * Sun Dec 23 2007 Bill Nottingham - 0.94-1 - fix up for more anaconda changes (#426562) claws-mail-3.2.0-2.fc9 ---------------------- * Sun Dec 23 2007 Andreas Bierfert - 3.2.0-2 - bump control-center-1:2.21.4-2.fc9 ----------------------------- * Mon Dec 24 2007 Matthias Clasen - 2.21.4-2 - Rebuild nautilus extensions against new nautilus diction-1.11-1.fc9 ------------------ * Sun Dec 23 2007 Konstantin Ryabitsev - 1.11-1 - Upstream 1.11 (#423901) - Update license version to GPLv3+ - Update source links emacs-auctex-11.84-5.fc9 ------------------------ * Sun Dec 23 2007 Jonathan G. Underwood - 11.84-5 - Enable building of separate tex-preview package - Remove a few residual tetex references evince-2.21.1-2.fc9 ------------------- * Sun Dec 23 2007 Matthias Clasen - 2.21.1-2 - Build nautilus extension against nautilus 2.21 file-roller-2.20.2-2.fc9 ------------------------ * Sun Dec 23 2007 Matthias Clasen - 2.20.2-2 - Rebuild nautilus extension against nautilus 2.21 gmpc-0.15.5.0-1.fc9 ------------------- * Sun Dec 23 2007 Adrian Reber - 0.15.5.0-1 - updated to 0.15.5.0 - this should fix #242226 - added six more plugins (wikipedia, random-playlist, mserver, libnotify, favorites, extraplaylist) - added BR libnotify-devel for libnotify plugin gurlchecker-0.10.1-5.fc9 ------------------------ * Sun Dec 23 2007 Arindam Ghosh - 0.10.1-5 - Updated clamav-lib as a build requires jd-1.9.8-0.5.rc071223.fc9 ------------------------- * Sun Dec 23 2007 Mamoru Tasaka - 1.9.8-0.5.rc071223 - 1.9.8 rc 071223 * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 * Mon Dec 10 2007 Mamoru Tasaka - 1.9.8-0.3.beta071210 - 1.9.8 beta 071210 libmpd-0.15.0-1.fc9 ------------------- * Sun Dec 23 2007 Adrian Reber - 0.15.0-1 - update to 0.15.0 - added BR glib2-devel nautilus-2.21.1-2.fc9 --------------------- * Sun Dec 23 2007 Matthias Clasen - 2.21.1-2 - Fix extensiondir * Fri Dec 21 2007 Matthias Clasen - 2.21.1-1 - Upodate to 2.21.1 * Wed Dec 19 2007 - Bastien Nocera - 2.20.0-7 - Update audio preview patch to check for aliases (#381401) njam-1.25-7.fc9 --------------- * Fri Aug 31 2007 Hans de Goede 1.25-7 - Fix Source0 URL plplot-5.8.0-5.fc9 ------------------ * Sun Dec 23 2007 - Orion Poplawski - 5.8.0-5 - Rebuild for octave 3.0 poedit-1.3.9-1.fc9 ------------------ * Sun Dec 23 2007 Konstantin Ryabitsev - 1.3.9-1 - Upstream 1.3.9 - Make sure all docs are utf-8 ppl-0.9-17.fc9 -------------- * Sun Dec 23 2007 Roberto Bagnara 0.9-17 - The SWI-Prolog `pl' package is temporarily not available on the ppc64 architecture: temporarily disabled `ppl-swiprolog' and `ppl-swiprolog-static' on that architecture. quake3-1.34-0.6.rc4.fc9 ----------------------- * Sun Dec 23 2007 Hans de Goede 1.34-0.6.rc4 - Update urbanterror autodlrc file to refer to version 4.1 (was 4.0) * Sun Dec 23 2007 Hans de Goede 1.34-0.5.rc4 - Split of the demo launcher into a quake3-demo package, so that when for example openarena requires quake3 for the engine people don't automatically get the demo launcher installed - Add installer / launcher for Urban Terror in an urbanterror subpackage (bz 385771) - Add installer / launcher for World of Padman in a worldofpadman subpackage scim-bridge-0.4.14-1.fc9 ------------------------ * Sun Dec 23 2007 Huang Peng - 0.4.14-1 - Update to 0.4.14. tecnoballz-0.92-1.fc9 --------------------- * Sat Dec 22 2007 Andrea Musuruane 0.92-1 - updated to v0.92 - license changed to GPLv3+ - changed description - dropped French man page because it is outdated - added SDL_image-devel to BR - added a new patch by Hans de Goede to drop setgid privileges when not needed - dropped no longer needed patches Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071212-4.fc9.i386 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071212-4.fc9.x86_64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071212-4.fc9.ppc requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-4.fc9.ppc64 requires octave(api) = 0:api-v31 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From dan at danny.cz Mon Dec 24 12:21:24 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 24 Dec 2007 13:21:24 +0100 Subject: Filezilla for EPEL In-Reply-To: <1198448038.3226.8.camel@eagle.danny.cz> References: <476EB6E1.5090109@gmx.net> <1198448038.3226.8.camel@eagle.danny.cz> Message-ID: <1198498884.3238.6.camel@eagle.danny.cz> Dan Hor?k p??e v Ne 23. 12. 2007 v 23:13 +0100: > KH KH p??e v Ne 23. 12. 2007 v 22:54 +0100: > > 2007/12/23, Frank B?ttner : > > > Hello, > > > can filezilla be released for EPEL? > > Hello > > No, unless the requested BuildRequirement can be provided. (needs wxGTK 2.8.x) > > Actually even rawhide cannot provides the necessary BuildRequirement > > for the last FileZilla. (3.0.4 - needs wxGTK 2.8.6) so I've backported > > some patches so we can build the last 3.0.2.1 (needs wxGTK 2.8.3) with > > theses additional patches... > > > > As soon as it will be possible, I will request a EPEL-5 branch for > > FileZilla. But i would say, it does not make sense for now. > > Alternatively, it could be possible to build it with a statically > > compiled wxGTK... > > > > I will check further next week... > > We are working on the inclusion of wxGTK into EPEL-4. I will be > responsible for EPEL and Matthew for Fedora. So stay tuned :-) wxGTK 2.8.4 was just built for EPEL-4 and is available on the build system, tested with a rebuild of codeblocks Dan From frank-buettner at gmx.net Mon Dec 24 13:26:31 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 24 Dec 2007 14:26:31 +0100 Subject: Filezilla for EPEL In-Reply-To: <1198498884.3238.6.camel@eagle.danny.cz> References: <476EB6E1.5090109@gmx.net> <1198448038.3226.8.camel@eagle.danny.cz> <1198498884.3238.6.camel@eagle.danny.cz> Message-ID: <476FB387.5000501@gmx.net> Thanks, and happy 24th.:) -------------- 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 kwizart at gmail.com Mon Dec 24 14:35:15 2007 From: kwizart at gmail.com (KH KH) Date: Mon, 24 Dec 2007 15:35:15 +0100 Subject: Filezilla for EPEL In-Reply-To: <1198498884.3238.6.camel@eagle.danny.cz> References: <476EB6E1.5090109@gmx.net> <1198448038.3226.8.camel@eagle.danny.cz> <1198498884.3238.6.camel@eagle.danny.cz> Message-ID: 2007/12/24, Dan Hor?k : > > Dan Hor?k p??e v Ne 23. 12. 2007 v 23:13 +0100: > > KH KH p??e v Ne 23. 12. 2007 v 22:54 +0100: > > > 2007/12/23, Frank B?ttner : > > > > Hello, > > > > can filezilla be released for EPEL? > > > Hello > > > No, unless the requested BuildRequirement can be provided. (needs wxGTK 2.8.x) > > > Actually even rawhide cannot provides the necessary BuildRequirement > > > for the last FileZilla. (3.0.4 - needs wxGTK 2.8.6) so I've backported > > > some patches so we can build the last 3.0.2.1 (needs wxGTK 2.8.3) with > > > theses additional patches... > > > > > > As soon as it will be possible, I will request a EPEL-5 branch for > > > FileZilla. But i would say, it does not make sense for now. > > > Alternatively, it could be possible to build it with a statically > > > compiled wxGTK... > > > > > > I will check further next week... > > > > We are working on the inclusion of wxGTK into EPEL-4. I will be > > responsible for EPEL and Matthew for Fedora. So stay tuned :-) > > wxGTK 2.8.4 was just built for EPEL-4 and is available on the build > system, tested with a rebuild of codeblocks Ok, so what about EPEL-5 ? I didn't checked the wxGTK version available here. Anyway i will request branches for EL-4 and EL-5 then ... I will probably backport others patches and do quick testing... Then maybe it will be avaible in a week or two... Can we have wxGTK updated for rawhide or are we waiting for something else ? Nicolas (kwizart) > > Dan > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dan at danny.cz Mon Dec 24 15:33:02 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 24 Dec 2007 16:33:02 +0100 Subject: Filezilla for EPEL In-Reply-To: References: <476EB6E1.5090109@gmx.net> <1198448038.3226.8.camel@eagle.danny.cz> <1198498884.3238.6.camel@eagle.danny.cz> Message-ID: <1198510382.3238.12.camel@eagle.danny.cz> KH KH p??e v Po 24. 12. 2007 v 15:35 +0100: > 2007/12/24, Dan Hor?k : > > > > Dan Hor?k p??e v Ne 23. 12. 2007 v 23:13 +0100: > > > KH KH p??e v Ne 23. 12. 2007 v 22:54 +0100: > > > > 2007/12/23, Frank B?ttner : > > > > > Hello, > > > > > can filezilla be released for EPEL? > > > > Hello > > > > No, unless the requested BuildRequirement can be provided. (needs wxGTK 2.8.x) > > > > Actually even rawhide cannot provides the necessary BuildRequirement > > > > for the last FileZilla. (3.0.4 - needs wxGTK 2.8.6) so I've backported > > > > some patches so we can build the last 3.0.2.1 (needs wxGTK 2.8.3) with > > > > theses additional patches... > > > > > > > > As soon as it will be possible, I will request a EPEL-5 branch for > > > > FileZilla. But i would say, it does not make sense for now. > > > > Alternatively, it could be possible to build it with a statically > > > > compiled wxGTK... > > > > > > > > I will check further next week... > > > > > > We are working on the inclusion of wxGTK into EPEL-4. I will be > > > responsible for EPEL and Matthew for Fedora. So stay tuned :-) > > > > wxGTK 2.8.4 was just built for EPEL-4 and is available on the build > > system, tested with a rebuild of codeblocks > Ok, so what about EPEL-5 ? I didn't checked the wxGTK version available here. > Anyway i will request branches for EL-4 and EL-5 then ... wxGTK already exists in EPEL-5 > I will probably backport others patches and do quick testing... Then > maybe it will be avaible in a week or two... > > Can we have wxGTK updated for rawhide or are we waiting for something else ? I could prepare the update during the next few days. Dan From myfedora at richip.dhs.org Mon Dec 24 16:54:08 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 24 Dec 2007 09:54:08 -0700 Subject: Security Policy for Applications/Packages Message-ID: <1198515248.29224.5.camel@localhost6.localdomain6> Hi, What's Fedora's policy for applications that need certain security policies? What I mean is, if an application needs SELinux policy entries or firewall entries, what does Fedora recommend people involved to do? Am I right in assuming that packagers are the one to execute security requests from the system? Is there an API or a program one can execute to apply for security clearances? Config files that should be dropped somewhere where an administrator can approve or disapprove via some GUI interface pop-up or even email? -- Richi Plana From mail at robertoragusa.it Mon Dec 24 17:39:50 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 24 Dec 2007 18:39:50 +0100 Subject: how is pulseaudio supposed to work? In-Reply-To: <20071218182629.GC28630@tango.0pointer.de> References: <1197573808.2917.13.camel@metroid.rdu.redhat.com> <1197576068.10057.6.camel@metroid.rdu.redhat.com> <20071216153013.3358dda9@alkaid.a.lan> <1197823564.29354.25.camel@localhost6.localdomain6> <20071217234804.GE3559@tango.0pointer.de> <1197969643.3361.0.camel@s1.crocom.com.pl> <20071218182629.GC28630@tango.0pointer.de> Message-ID: <476FEEE6.2070908@robertoragusa.it> Lennart Poettering wrote: [snipped reasons about having PA as a session daemon] > Admittedly there are a couple of drawbacks of PA being a session > daemon. One being that it is very difficult to play an event sound > while switching VTs on FUS. And sharing sound cards between multiple > active sessions is difficult too. But I think these disadvantages do > not outweigh the advantages of the per-session design, far from > that. Technical reasons against system-wide mode apart, I realize that if a daemon grabs the hardware in an exclusive way, but there are reasonable use cases were many users want simultaneous access to the hardware, maybe the daemon should be able to grant access to those users by acting as an multiplexer in some way (well, maybe mixer more than multiplexer). Imagine this use case. - There is a desktop session running, with moderate use of audio (beeps, desktop sound effects, flash from a web site). - Someone else in my room wants to play some mp3; so it logins from another machine via ssh into the system to run mpg123. The fact that some beeps could be mixed into the songs is not an issue. Now, the default PA configuration denies this, as the second user (via ssh) is not the active session. But, it is possible to grant permission to the second user. I heard about cookie sharing; my self-discovered method is to chmod 777 -R /tmp/pulse-myusername. The sounds are now correctly mixed together, right? Now, suppose the desktop session is going to be closed, but the "remote" user still wants his music playing. Closing the session will bring down the daemon, right? It looks like there is no configuration to cope with this scenario. But a system wide daemon would manage this use case well. Having in mind the strict desktop integration which can only be achieved with the session based approach (I'm quoting you), I simply wonder: why can't PA be a client of itself? Why not have a system-wide PA *AND* one or more session-wide PAs? I think that a PA hierarchy gives a lot of flexibility. For example, in the Ctrl-Alt-F7, Ctrl-Alt-F8 use case described in another mail, you could have the system-wide PA serving the two session-wide PAs. Each of the session-wide could decide if "mute sound when this session is switched out", but the system-wide PA could also "ignore sound from any child PA" or "lower volume to 10%" when the administrator runs a specific command (imagine something triggered by, for example, an ISDN event of a phone ringing) and a firewall watching script could beep on specific events and so on. Considerations? Best regards. -- Roberto Ragusa mail at robertoragusa.it From myfedora at richip.dhs.org Mon Dec 24 17:41:44 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 24 Dec 2007 10:41:44 -0700 Subject: bug-buddy API Message-ID: <1198518104.29224.17.camel@localhost6.localdomain6> Is there an API interface to bug-buddy that would allow my app to bring it up and pre-populate it with app-provided information? I'd like to start writing apps with more checks and tests (asserts, etc.) and would like an easy way for that information to get home to me (the developer). It's easy to put in assert()s but most are only useful for local testing. Before starting to write a subsystem that would ask the user for confirmation before emailing me, I'm wondering if bug-buddy could be coerced to do it. There's something mentioned about gnome_segv (is that some gnome function that I pass to signal(2)?), but I want bug-buddy to come up outside of SIGSEGVs. Likely as a call from an exception handler so I wouldn't have to halt or abort program execution. The reason I'm thinking of doing things this way is 1) I'm training myself to write tests first & often and 2) that recent discussion on the "Fedora 8 Review" thread got me thinking that the only way I can get users to report bugs (if not actually do search and find tickets) is to make it easy for them to communicate the information to me. -- Richi Plana From berrange at redhat.com Mon Dec 24 17:56:57 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 24 Dec 2007 17:56:57 +0000 Subject: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <200712241051.lBOAp97R005241@releng1.fedora.phx.redhat.com> References: <200712241051.lBOAp97R005241@releng1.fedora.phx.redhat.com> Message-ID: <20071224175657.GA8016@redhat.com> Any suggestions on how best to deal with the following problem.... On Mon, Dec 24, 2007 at 03:51:09AM -0700, buildsys at fedoraproject.org wrote: > perl-Test-AutoBuild has broken dependencies in the development tree: > On ppc64: > perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 > Please resolve this as soon as possible. perl-Test-AutoBuild is the module in CVS, it generates perl-Test-AutoBuild main RPM containing most of the app, and then a number of sub-RPMs - one per SCM system supported. The whole app is a 'noarch' since it is pure Perl and not architecture dependant. Unfortunately it looks like the 'darcs' SCM system is not available[1] on PPC causing me to get spammed nightly about this broken dep. To be honest this isn't really a problem that'll hit any users - since the darcs dependancy is only in the sub-RPM, users can simply not install perl-Test-AutoBuild-darcs on the PPC platforms. I can't do any '%if %{arch}' conditional stuff in the RPM since this is a noarch package, and I don't want to make the package arch-dependant just to get rid of the darcs package on PPC since there is nothing broken here that will hit users. I really just want to make this nightly spam STFU. Is there any way to block a noarch sub-RPM from the PPC repos ? Dan. [1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246051 -- |=- 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 caillon at redhat.com Mon Dec 24 19:05:59 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 24 Dec 2007 20:05:59 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476D9D59.30001@poolshark.org> References: <476A2656.5060704@redhat.com> <476D9D59.30001@poolshark.org> Message-ID: <47700317.7050804@redhat.com> On 12/23/2007 12:27 AM, Denis Leroy wrote: > I know almost nothing about mozilla/xulrunner upstream development, but > I have to ask: it's not just them (the packages that depend on firefox) > that have to be ready for xulrunner, will xulrunner also be ready for > them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?) As a maintainer of gecko-dependent packages, you're on the hook for determining this. The code is still beta. If it isn't ready for your application(s) to make use of it, you should make sure bugs get filed. With either Mozilla or your package's upstream(s) or both. This is sort of the whole purpose of sticking XULRunner in now... so we can find any showstopper bugs and get them fixed. From caillon at redhat.com Mon Dec 24 19:09:40 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 24 Dec 2007 20:09:40 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071222164214.GE30935@asus.config> References: <476A2656.5060704@redhat.com> <20071222164214.GE30935@asus.config> Message-ID: <477003F4.4020404@redhat.com> On 12/22/2007 05:42 PM, Adam Huffman wrote: > I have installed it on F8 and it seems to have brought back the annoying > behaviour of moving the Firefox window when opening a link. Is this > Fedora-specific? This is a metacity bug[1]. walters added a patch to our rawhide metacity package, which ought to be fixed in metacity-2.21.5-2.fc9. [1] http://bugzilla.gnome.org/show_bug.cgi?id=482354 From caillon at redhat.com Mon Dec 24 19:14:04 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 24 Dec 2007 20:14:04 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: References: <476A2656.5060704@redhat.com> <20071223004359.GF28987@angus.ind.WPI.EDU> <476DCB7A.4010606@gmail.com> <476E570A.1060804@gmail.com> <476EAE4E.2060400@gmail.com> <1198438117.21925.19.camel@localhost6.localdomain6> Message-ID: <477004FC.6050704@redhat.com> On 12/23/2007 09:00 PM, drago01 wrote: > I have no problem with ipv6 enabled by default as long as ipv4 only > networks still work whit out requiring the user to change a hidden > option. (as it did until now). So if you are having problems, file a bug at https://bugzilla.mozilla.org/ From mschwendt.tmp0701.nospam at arcor.de Mon Dec 24 22:24:18 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 24 Dec 2007 23:24:18 +0100 Subject: gtkspell update In-Reply-To: References: <20071223194636.42eca982.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20071224232418.10917697.mschwendt.tmp0701.nospam@arcor.de> On Sun, 23 Dec 2007 23:26:14 +0000 (UTC), Kevin Kofler wrote: > This says what it says: gtkspell is now using enchant instead of aspell. For > the rationale, see: > http://fedoraproject.org/wiki/Releases/FeatureDictionary > > > compose.o: In function `compose_set_spell_lang_menu': > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5331: undefined reference > to `new_aspell_config' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5332: undefined reference > to `get_aspell_dict_info_list' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5333: undefined reference > to `delete_aspell_config' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5335: undefined reference > to `aspell_dict_info_list_elements' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference > to `aspell_dict_info_enumeration_next' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5336: undefined reference > to `aspell_dict_info_enumeration_next' > > /builddir/build/BUILD/sylpheed-2.4.8/src/compose.c:5342: undefined reference > to `delete_aspell_dict_info_enumeration' > > And this is Sylpheed trying to use aspell-related functions directly, so of > course this doesn't work anymore. If Sylpheed really must use APIs of the > underlying spellchecker instead of the gtkspell abstraction, GtkSpell does not offer an interface that could be used to retrieve the list of available dictionaries. > it'll have to be patched to use enchant too. Which is what I've done as a fix/work-around. > (Technically, those linker errors could probably be > fixed by linking in aspell directly, but that'll not solve the actual problem > because Sylpheed would then try to read the list of languages from aspell while > gtkspell is actually using enchant.) Yes, that's not an option. From kevin.kofler at chello.at Mon Dec 24 22:55:32 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Dec 2007 22:55:32 +0000 (UTC) Subject: gtkspell update References: <20071223194636.42eca982.mschwendt.tmp0701.nospam@arcor.de> <20071224232418.10917697.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > GtkSpell does not offer an interface that could be used to retrieve the list > of available dictionaries. Ugh, what a broken API! :-/ > > it'll have to be patched to use enchant too. > > Which is what I've done as a fix/work-around. Good work! Kevin Kofler From fedora at leemhuis.info Tue Dec 25 11:00:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Dec 2007 12:00:32 +0100 Subject: EPEL report week 51 2007 Message-ID: <4770E2D0.2080703@leemhuis.info> = Weekly EPEL Summary = Week 51/2007 == Most important happenings == * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00101.html EPEL4 builders now use RHEL 4.6] * alpine now in EPEL == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00130.html perl modules in EPEL] == Meeting == === Next Meeting === 20080201 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === Attendees: * [:MikeMcGrath:mmcgrath] * [:KevinFenzi:nirik] * [:MichaelStahnke:stahnma] Topics: * RHEL MetaData | stahnma | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData * stahnma> I have been working on a something that spits out requires/provides/filelisting etc for each rpm . I am actually surprised repoview doesn't have something like that * stuff will be hosted on fedorapeople * No ETA; stahnma> "I was hoping to have it done today, but that didn't happen ; maybe next coupel weeks. Holidays screw up schedules " * KojiAndBodhiForEpel * mmcgrath> the wheels are in motion to try to get funding for an intern but nothing concrete yet. * RHEL 5.1 (and 4.6) for the builders * thats done now, right? * how to do it next time still under discussion * nirik> | another issue related here: updates for builders? would it be hard to get them to pull updates into the buildroot ? * mmcgrath> | If we decide thats what we want to do we'll also have to figure out a way to do it. Right now going from RHEL5 -> 5.1 involved me downloading the DVD's, copying RPM's over and running createrepo. * more on the list * update http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies * nirik> | I updated the page... if everyone could look and correct/add/modify, feel free. * Free discussion * anything planned on EPEL at FUDcon? Maybe a EPEL meeting at fudcon... perhaps a 'Fedora maintainers intro to EPEL' ? * stahnma> | also, it's great to see so many new packages in EPEL lately * nirik> | I am still working on getting munin in... need some more perl deps. Will probibly start on Xfce over the holidays too. == Stats == === General === Number of EPEL Contributors: 161 We welcome 6 new contributors: bellet bojan deji jbowes key pwouters === EPEL 5 === Number of source packages: 923 Number of binary packages: 1702 There are 31 new Packages: * acpitool | Command line ACPI client * alpine | UW Alpine mail user agent * asa | Convert Fortran carriage control characters * BibTool | A Tool for manipulating BibTeX data bases * bitmap | Bitmap editor and converter utilities for the X Window System * cppunit | C++ unit testing framework * docbook2X | Convert docbook into man and Texinfo * elektra | A key/value pair database to store software configurations * esmtp | User configurable relay-only Mail Transfer Agent (MTA) * gparted | Gnome Partition Editor * mISDN | Userspace part of Modular ISDN stack * monotone | A free, distributed version control system * nautilus-actions | Nautilus extension for customizing the context menu * netbsd-iscsi | User-space implementation of iSCSI target from NetBSD project * perl-HTTP-Server-Simple | Very simple standalone HTTP daemon * perl-IO-Tty | Perl interface to pseudo tty's * perl-IPC-Run | Perl module for interacting with child processes * perl-Locale-Maketext-Fuzzy | Maketext from already interpolated strings * perl-Log-Dispatch | Dispatches messages to one or more outputs * perl-Mail-Sender | Module for sending mails with attachments through an SMTP server * perl-Mail-Sendmail | Simple platform independent mailer for Perl * perl-Module-ScanDeps | Recursively scan Perl code for dependencies * perl-PAR-Dist | Toolkit for creating and manipulating Perl PAR distributions * perl-Text-Aspell | Perl interface to the GNU Aspell library * pyflakes | A Lint-like tool for Python * python-ctypes | Advanced Foreign Function Interface for Python * python-openid | Python OpenID libraries * python-pycurl | A Python interface to libcurl * trousers | Implementation of the TCG's Software Stack v1.2 Specification * viewvc | Browser interface for CVS and SVN version control repositories * xbae | Motif matrix, caption and text input widgets === EPEL 4 === Number of source packages: 534 Number of binary packages: 1035 There are 29 new Packages: * acpitool | Command line ACPI client * alpine | UW Alpine mail user agent * asa | Convert Fortran carriage control characters * BibTool | A Tool for manipulating BibTeX data bases * cernlib | General purpose CERN library * cppunit | C++ unit testing framework * docbook2X | Convert docbook into man and Texinfo * esmtp | User configurable relay-only Mail Transfer Agent (MTA) * ganglia | Ganglia Distributed Monitoring System * libesmtp | SMTP client library * pcapdiff | Compares packet captures, detects forged, dropped or mangled packets * perl-Archive-Tar | A module for Perl manipulation of .tar files * perl-Archive-Zip | Perl library for accessing Zip archives * perl-Compress-Zlib | Interface to zlib compression library * perl-IO-String | Emulate file interface for in-core strings * perl-IO-Tty | Perl interface to pseudo tty's * perl-IO-Zlib | IO:: style interface to Compress::Zlib * perl-IPC-Run | Perl module for interacting with child processes * perl-Locale-Maketext-Fuzzy | Maketext from already interpolated strings * perl-Mail-Sender | Module for sending mails with attachments through an SMTP server * perl-Mail-Sendmail | Simple platform independent mailer for Perl * perl-Module-Build | Perl module for building and installing Perl modules * perl-PAR-Dist | Toolkit for creating and manipulating Perl PAR distributions * pyflakes | A Lint-like tool for Python * python-genshi | Toolkit for stream-based generation of output for the web * python-openid | Python OpenID libraries * python-protocols | Open Protocols and Component Adaptation for Python * viewvc | Browser interface for CVS and SVN version control repositories * xbae | Motif matrix, caption and text input widgets ---- ["CategoryEPELReports"] From buildsys at redhat.com Tue Dec 25 11:40:26 2007 From: buildsys at redhat.com (Build System) Date: Tue, 25 Dec 2007 06:40:26 -0500 Subject: rawhide report: 20071225 changes Message-ID: <200712251140.lBPBeQLu023908@porkchop.devel.redhat.com> New package perl-Config-Simple Simple configuration file class New package perl-Test-YAML-Meta Validation of the META.yml file in a distribution New package starplot-gliese3 Stellar data set for use by the StarPlot tool Updated Packages: aspell-gu-0.03-1.fc9 -------------------- aspell-hi-0.02-1.fc9 -------------------- bochs-2.3.6-1.fc9 ----------------- * Mon Dec 24 2007 Hans de Goede 2.3.6-1 - New upstream release 2.3.6 cheese-0.3.0-1.fc9 ------------------ deluge-0.5.7.95-1.fc9 --------------------- * Mon Dec 24 2007 Mamoru Tasaka - 0.5.7.95-1 - Update to new upstream release candidate (0.5.8 RC1) - Completely suppress updates notification (bug 299601, 426642) egoboo-2.7.5-3.fc9 ------------------ * Mon Dec 24 2007 Hans de Goede 2.7.5-3 - Second attempt at fixing compilation on big endian archs like powerpc * Mon Dec 24 2007 Hans de Goede 2.7.5-2 - Fix compilation on big endian archs like powerpc * Sun Dec 23 2007 Hans de Goede 2.7.5-1 - New upstream release 2.7.5 egoboo-data-2.7.5-1.fc9 ----------------------- gallery2-2.2.4-1.fc9 -------------------- * Mon Dec 24 2007 Lubomir Kundrak 2.2.4-1 - A christmas present -- critical security update to 2.2.4 kdegames3-3.5.8-3.fc9 --------------------- * Mon Dec 24 2007 Kevin Kofler - 3.5.8-3 - remove crystalsvg icons which conflict with kdeartwork (F9+) (#426694) kdewebdev-6:3.5.8-5.fc9 ----------------------- * Mon Dec 24 2007 Kevin Kofler - 6:3.5.8-5 - remove crystalsvg icon which conflicts with kdeartwork (F9+) (#426694) nautilus-flac-converter-0.0.2-10.fc9 ------------------------------------ * Mon Dec 24 2007 Brian Pepple - 0.0.2-10 - Rebuild for change to nautilus extension api change. - Add patch to use new nautilus extension directory. nautilus-image-converter-0.2.1-2.fc9 ------------------------------------ * Mon Dec 24 2007 Brian Pepple - 0.2.1-2 - Rebuild for change to nautilus extension api change. - Add patch to use new nautilus extension directory. selinux-policy-3.2.5-5.fc9 -------------------------- * Mon Dec 24 2007 Dan Walsh 3.2.5-6 - Fix role transition fro unconfined_r to system_r when running rpm * Fri Dec 21 2007 Dan Walsh 3.2.5-5 - Fixes for xguest sylpheed-2.4.8-1 ---------------- * Sun Dec 23 2007 Michael Schwendt - 2.4.8-1 - Patch spell-checking support. Retrieve list of dictionaries from Enchant instead of Aspell, because GtkSpell no longer uses Aspell. - BR enchant-devel - Update to 2.4.8 (accumulated bug-fixes). tinyerp-4.2.1-1.fc9 ------------------- * Mon Dec 24 2007 Dan Horak 4.2.1-1 - update to upstream version 4.2.1 tkimg-1.3-0.6.20071018svn.fc9 ----------------------------- * Mon Dec 24 2007 Sergio Pascual 1.3-0.6.20071018svn - Static 'stub' library included in devel subpackage - Rebuild to fix bug #426683 wpa_supplicant-1:0.5.7-20.fc9 ----------------------------- * Mon Dec 24 2007 Dan Williams - 0.5.7-20 - Fix LSB initscript header to ensure 'messagebus' is started first (rh #244029) * Thu Dec 06 2007 Dan Williams - 1:0.5.7-19 - Fix two leaks when signalling state and scan results (rh #408141) - Add logrotate config file (rh #404181) - Add new LSB initscript header to initscript with correct deps (rh #244029) - Move other runtime arguments to /etc/sysconfig/wpa_supplicant - Start after messagebus service (rh #385191) - Fix initscript 'condrestart' command (rh #217281) xulrunner-1.9-0.beta2.4.fc9 --------------------------- * Mon Dec 24 2007 Christopher Aillon 1.9-0.beta2.4 - Don't Provide webclient (xulrunner is not itself a webclient) - Don't Obsolete old firefox, only firefox-devel - Kill legacy obsoletes (phoenix, etc) that were never in rawhide Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071212-4.fc9.i386 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071212-4.fc9.x86_64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071212-4.fc9.ppc requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-4.fc9.ppc64 requires octave(api) = 0:api-v31 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From nphilipp at redhat.com Tue Dec 25 17:34:52 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 25 Dec 2007 18:34:52 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071223194719.24292e38@redhat.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> Message-ID: <1198604092.6197.18.camel@gibraltar.str.redhat.com> On Sun, 2007-12-23 at 19:47 -0500, Jesse Keating wrote: > On Sun, 23 Dec 2007 22:54:58 +0100 > Denis Leroy wrote: > > > Hmm, why would we provide multi-lib on a live CD ? > > Because Live images are installable. Secondary arch packages can be installed after the initial installation just fine (whether from Live media or via anaconda). Having these on Live media shouldn't be necessary unless we ship secondary arch only software (like wine) on the medium. We should have means to enable multilib if so desired rather than having it on Live media where it's not strictly needed. Merry Christmas by the way :-). 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 zboszor at freemail.hu Tue Dec 25 19:48:52 2007 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Tue, 25 Dec 2007 20:48:52 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <20071220085009.1f5afdb5@redhat.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> Message-ID: <47715EA4.1010406@freemail.hu> Jesse Keating ?rta: > On Thu, 20 Dec 2007 14:23:43 +0100 > Ralf Ertzinger wrote: > > >> Java-Applets that work with icedtea >> (even in Firefox 2). >> > > Huh. Every java applet I've come across has worked in IcedTea. > Head in the sand, ostrich? :-) Please try this link, a gaming site: http://jojatek.hu/indexold.html At the left column you will find single-person games. I tried some, none worked. Try e.g. REX at the end of the page, both i386 and x86_64 Firefox/IcedTea shows "Applet not initialized" after loading the applet. Sun Java 1.6u3 works for the FF2/i386. Best regards, Zolt?n B?sz?rm?nyi From jkeating at redhat.com Tue Dec 25 21:01:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 25 Dec 2007 16:01:38 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198604092.6197.18.camel@gibraltar.str.redhat.com> References: <1198160022.3142.0.camel@localhost.localdomain> <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> Message-ID: <20071225160138.11cda072@redhat.com> On Tue, 25 Dec 2007 18:34:52 +0100 Nils Philippsen wrote: > Secondary arch packages can be installed after the initial > installation just fine (whether from Live media or via anaconda). > Having these on Live media shouldn't be necessary unless we ship > secondary arch only software (like wine) on the medium. We should > have means to enable multilib if so desired rather than having it on > Live media where it's not strictly needed. > > Merry Christmas by the way :-). Which sounds great until you take one of the oft stated goals of multilib, which is non-rpm software just works out of the box, which is why we install multilib by default when installing from traditional media, and why the experience is not changed when you install from live media. -- 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 Dec 25 21:27:13 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Dec 2007 12:27:13 -0900 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <47715EA4.1010406@freemail.hu> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <47715EA4.1010406@freemail.hu> Message-ID: <604aa7910712251327o78831cb6yc4ea378b1a595198@mail.gmail.com> On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi wrote: > Please try this link, a gaming site: http://jojatek.hu/indexold.html do you have to register to play them? I don't understand the language, so it's difficult to know how to get to the games, just clicking on the title takes me to what looks like a registration page. In contrast, the free non-registation games I've tried listed at http://www.java.com/en/games/ are working in IcedTea. http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a great 5 minute time waster. -jef From zboszor at freemail.hu Tue Dec 25 22:28:40 2007 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Tue, 25 Dec 2007 23:28:40 +0100 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <604aa7910712251327o78831cb6yc4ea378b1a595198@mail.gmail.com> References: <476A2656.5060704@redhat.com> <20071220105326.13c9eb3e@dhcp03.addix.net> <476A3CC8.4070908@olen.net> <20071220112255.5a79fc1e@dhcp03.addix.net> <1198156677.4120.0.camel@scrappy.miketc.com> <20071220142343.5c190ea8@dhcp03.addix.net> <20071220085009.1f5afdb5@redhat.com> <47715EA4.1010406@freemail.hu> <604aa7910712251327o78831cb6yc4ea378b1a595198@mail.gmail.com> Message-ID: <47718418.3040607@freemail.hu> Jeff Spaleta ?rta: > On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi wrote: > >> Please try this link, a gaming site: http://jojatek.hu/indexold.html >> > > do you have to register to play them? I don't understand the language, > so it's difficult to know > how to get to the games, just clicking on the title takes me to what > looks like a registration page. > The button with the text "Bel?p?s pr?baj?t?kra" should give you the game without registering. It's something like "Enter for a trial game". Registering has the advantage of keeping your own high scores, etc. > In contrast, the free non-registation games I've tried listed at > http://www.java.com/en/games/ > are working in IcedTea. > > http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a > great 5 minute time waster. > > -jef > > From bernie at codewiz.org Wed Dec 26 01:28:48 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 25 Dec 2007 20:28:48 -0500 Subject: Koji build fails with weird "/bin/hostname not found" error Message-ID: <4771AE50.3040400@codewiz.org> Any idea why this build would fail? http://koji.fedoraproject.org/koji/taskinfo?taskID=309982 All I did was: koji build --scratch --arch-override=ppc dist-f9 'cvs://cvs.fedoraproject.org/cvs/pkgs?epiphany/devel#epiphany-2_21_4-1_fc9' ---cut--- ENTER do("bash -l -c 'rpmbuild -bs --target ppc --nodeps //builddir/build/SPECS/epiphany.spec'", '/var/lib/mock/dist-f9-build-98149-12971/root/', 0, True, 0, , 425, 425, 'ppc', logger=) run cmd timeout(0): bash -l -c 'rpmbuild -bs --target ppc --nodeps //builddir/build/SPECS/epiphany.spec' /etc/profile: line 38: /bin/hostname: No such file or directory warning: Could not canonicalize hostname: ppc4.fedora.phx.redhat.com Building target platforms: ppc Building for target ppc Wrote: /builddir/build/SRPMS/epiphany-2.21.4-1.fc9.src.rpm LEAVE do --> ---cut--- -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From mtasaka at ioa.s.u-tokyo.ac.jp Wed Dec 26 01:39:15 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 26 Dec 2007 10:39:15 +0900 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <4771AE50.3040400@codewiz.org> References: <4771AE50.3040400@codewiz.org> Message-ID: <4771B0C3.208@ioa.s.u-tokyo.ac.jp> Bernardo Innocenti wrote, at 12/26/2007 10:28 AM +9:00: > Any idea why this build would fail? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=309982 Please check root.log. Ref: http://www.redhat.com/archives/rhl-devel-list/2007-December/msg01273.html Regards, Mamoru From bernie at codewiz.org Wed Dec 26 02:23:27 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 25 Dec 2007 21:23:27 -0500 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <4771AE50.3040400@codewiz.org> References: <4771AE50.3040400@codewiz.org> Message-ID: <4771BB1F.2020907@codewiz.org> Bernardo Innocenti wrote: > Any idea why this build would fail? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=309982 This one is even more puzzling: http://koji.fedoraproject.org/koji/taskinfo?taskID=310030 Fails in dist-olpc2, but without printing errors in the build log. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From dennis at ausil.us Wed Dec 26 02:25:30 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 25 Dec 2007 20:25:30 -0600 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <4771AE50.3040400@codewiz.org> References: <4771AE50.3040400@codewiz.org> Message-ID: <200712252025.30970.dennis@ausil.us> On Tuesday 25 December 2007, Bernardo Innocenti wrote: > Any idea why this build would fail? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=309982 > > All I did was: > koji build --scratch --arch-override=ppc dist-f9 > 'cvs://cvs.fedoraproject.org/cvs/pkgs?epiphany/devel#epiphany-2_21_4-1_fc9' > > ---cut--- > ENTER do("bash -l -c 'rpmbuild -bs --target ppc --nodeps > //builddir/build/SPECS/epiphany.spec'", > '/var/lib/mock/dist-f9-build-98149-12971/root/', 0, True, 0, > , 425, 425, 'ppc', > logger=) run cmd > timeout(0): bash -l -c 'rpmbuild -bs --target ppc --nodeps > //builddir/build/SPECS/epiphany.spec' /etc/profile: line 38: /bin/hostname: > No such file or directory > warning: Could not canonicalize hostname: ppc4.fedora.phx.redhat.com > Building target platforms: ppc > Building for target ppc > Wrote: /builddir/build/SRPMS/epiphany-2.21.4-1.fc9.src.rpm > LEAVE do --> > ---cut--- have a look in the root.log http://koji.fedoraproject.org/koji/getfile?taskID=309982&name=root.log DEBUG util.py:260: No Package Found for gecko-devel = 1.8.1.10 Dennis From dennis at ausil.us Wed Dec 26 02:28:25 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 25 Dec 2007 20:28:25 -0600 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <4771BB1F.2020907@codewiz.org> References: <4771AE50.3040400@codewiz.org> <4771BB1F.2020907@codewiz.org> Message-ID: <200712252028.25845.dennis@ausil.us> On Tuesday 25 December 2007, Bernardo Innocenti wrote: > Bernardo Innocenti wrote: > > Any idea why this build would fail? > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=309982 > > This one is even more puzzling: > http://koji.fedoraproject.org/koji/taskinfo?taskID=310030 > > Fails in dist-olpc2, but without printing errors in the build > log. Actually its less puzzling http://koji.fedoraproject.org/koji/getfile?taskID=310030&name=root.log DEBUG util.py:260: No Package Found for popt-devel popt-devel does not exist in F-7 it was introduced in F-8 you need to BR popt not popt-devel Dennis From bernie at codewiz.org Wed Dec 26 02:40:22 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 25 Dec 2007 21:40:22 -0500 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <200712252028.25845.dennis@ausil.us> References: <4771AE50.3040400@codewiz.org> <4771BB1F.2020907@codewiz.org> <200712252028.25845.dennis@ausil.us> Message-ID: <4771BF16.9060701@codewiz.org> Dennis Gilmore wrote: > Actually its less puzzling > http://koji.fedoraproject.org/koji/getfile?taskID=310030&name=root.log > DEBUG util.py:260: No Package Found for popt-devel > > popt-devel does not exist in F-7 it was introduced in F-8 > > you need to BR popt not popt-devel Ah, I see. Thank you! In both these case, I was confused by the fact that a build.log was present even though there were errors in root.log. Has this always been the normal behavior? I was under the impression it worked differently just a couple of weeks ago. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From jkeating at redhat.com Wed Dec 26 04:07:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 25 Dec 2007 23:07:46 -0500 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <4771BF16.9060701@codewiz.org> References: <4771AE50.3040400@codewiz.org> <4771BB1F.2020907@codewiz.org> <200712252028.25845.dennis@ausil.us> <4771BF16.9060701@codewiz.org> Message-ID: <20071225230746.45d5602c@redhat.com> On Tue, 25 Dec 2007 21:40:22 -0500 Bernardo Innocenti wrote: > Has this always been the normal behavior? Not exactly. > I was under the > impression it worked differently just a couple of weeks ago. It was. A couple of weeks ago a much older mock / koji set was used on the builders. We would actually lose logging output as mock would overwrite certain log files during the build process. Now however that isn't happening. One of the changes is that everything is logged. The order is like so: buildroot init -> root.log srpm reconstruction to pick up arch specific BuildReqs -> build.log (since rpmbuild is used) BuildDeps install -> root.log finished rpm builds -> build.log It can be somewhat confusing, but using the mock exit codes can help. I'll be shortly working on some changes to koji so that the mock exit codes are translated into meaningful messages such as "error installing builddeps" or "error initing buildroot" or "error building package". These will be much better clues as to what log file holds the failure. -- 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 bernie at codewiz.org Wed Dec 26 04:39:25 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 25 Dec 2007 23:39:25 -0500 Subject: Koji build fails with weird "/bin/hostname not found" error In-Reply-To: <20071225230746.45d5602c@redhat.com> References: <4771AE50.3040400@codewiz.org> <4771BB1F.2020907@codewiz.org> <200712252028.25845.dennis@ausil.us> <4771BF16.9060701@codewiz.org> <20071225230746.45d5602c@redhat.com> Message-ID: <4771DAFD.4050400@codewiz.org> Jesse Keating wrote: > It was. > [...] Thank you a lot for the very detailed explanation :) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From andy at smile.org.ua Wed Dec 26 07:47:13 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 26 Dec 2007 09:47:13 +0200 Subject: Are links in the koji's info message still broken? Message-ID: <20071226074713.GG29292@serv.smile.org.ua> Hi! I try to build klamav for fc8. Build was failed. But I have received the info message with following: ... Task Type: buildArch (klamav-0.41.1-9.fc8.src.rpm, x86_64) logs: http://koji.fedoraproject.org/packages/klamav/0.41.1/9.fc8/data/logs/x86_64/build.log ... That is really absent link! What is wrong? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From subhodip at fedoraproject.org Wed Dec 26 09:15:29 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Wed, 26 Dec 2007 14:45:29 +0530 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071225160138.11cda072@redhat.com> References: <582715960712200707y2b365744o64bb851a7309c87f@mail.gmail.com> <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> Message-ID: <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> K3b though popular , may bear some space constraints in live cd 's . But I think it can be bought back to DVD's as it was in Fedora core 6 and previous ... because of its popularity. -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From subhodip at fedoraproject.org Wed Dec 26 09:34:19 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Wed, 26 Dec 2007 15:04:19 +0530 Subject: fedora cert Message-ID: <539333cb0712260134t3cb7d6e6r1febd47ea8e2cf4c@mail.gmail.com> hi ! i have changed my hard disk because the previous one gave away . How should i use the keys and certificate and CLA . Will coping them to my present home directory do ?? -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From j.w.r.degoede at hhs.nl Wed Dec 26 09:57:12 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Dec 2007 10:57:12 +0100 Subject: fedora cert In-Reply-To: <539333cb0712260134t3cb7d6e6r1febd47ea8e2cf4c@mail.gmail.com> References: <539333cb0712260134t3cb7d6e6r1febd47ea8e2cf4c@mail.gmail.com> Message-ID: <47722578.2020201@hhs.nl> subhodip biswas wrote: > hi ! > i have changed my hard disk because the previous one gave away . How > should i use the keys and certificate and CLA . Will coping them to my > present home directory do ?? > Yes, copying them to your present home dir should do. Regards, Hans From mschwendt.tmp0701.nospam at arcor.de Wed Dec 26 10:26:18 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 26 Dec 2007 11:26:18 +0100 Subject: Are links in the koji's info message still broken? In-Reply-To: <20071226074713.GG29292@serv.smile.org.ua> References: <20071226074713.GG29292@serv.smile.org.ua> Message-ID: <20071226112618.27f36781.mschwendt.tmp0701.nospam@arcor.de> On Wed, 26 Dec 2007 09:47:13 +0200, Andy Shevchenko wrote: > Hi! > > I try to build klamav for fc8. Build was failed. > But I have received the info message with following: > ... > Task Type: buildArch (klamav-0.41.1-9.fc8.src.rpm, x86_64) > logs: > http://koji.fedoraproject.org/packages/klamav/0.41.1/9.fc8/data/logs/x86_64/build.log > ... > > That is really absent link! What is wrong? https://fedorahosted.org/koji/ticket/71 Display the task link at the bottom instead, and load the logs from there. From buildsys at redhat.com Wed Dec 26 11:24:50 2007 From: buildsys at redhat.com (Build System) Date: Wed, 26 Dec 2007 06:24:50 -0500 Subject: rawhide report: 20071226 changes Message-ID: <200712261124.lBQBOoFI000587@porkchop.devel.redhat.com> New package mt-daapd An iTunes-compatible media server New package perl-Math-BaseCnv Fast functions to CoNVert between number Bases Updated Packages: amsn-0.97-1.fc9 --------------- * Mon Dec 24 2007 Sander Hoentjen - 0.97-1 - Update to 0.97 * Wed Nov 21 2007 Sander Hoentjen - 0.96-11 - Fix undefined tcl_version * Sun Nov 11 2007 Sander Hoentjen - 0.96-10 - change htmlview to xdg-open (bug #365381) - use alsa by default for playing sounds - undo rev 8 and 9 changes until it is supported compiz-fusion-0.6.0-8.fc9 ------------------------- * Tue Dec 25 2007 Adel Gadllah 0.6.0-8 - Fix fullscreen for flash windows when legacy fullscreen is enabled. emacs-auctex-11.84-6.fc9 ------------------------ * Tue Dec 25 2007 Jonathan G. Underwood - 11.84-6 - Add Obsolotes and Provides for tetex-preview to tex-preview (#426758) flasm-1.62-3.fc9 ---------------- * Tue Dec 25 2007 Patrice Dumas 1.62-3 - minor cleanups kdebase-6:3.97.0-5.fc9 ---------------------- * Tue Dec 25 2007 Kevin Kofler 3.97.0-5 - Obsoletes: dolphin, d3lphin, Provides: dolphin (F9+) * Fri Dec 14 2007 Rex Dieter 3.97.0-4 - Obsoletes: -extras (f9+) * Wed Dec 12 2007 Kevin Kofler 3.97.0-3 - rebuild for changed _kde4_includedir kdegames-6:3.97.0-3.fc9 ----------------------- * Tue Dec 25 2007 Kevin Kofler 3.97.0-3 - move libkdegames.so to %{_libdir}/kde4/devel and patch search order (#426730) * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 mfiler2-4.0.5a-1.fc9 -------------------- * Wed Dec 26 2007 Mamoru Tasaka - 4.0.5a-1 - 4.0.5a wmx-6pl1-17.fc9 --------------- * Tue Dec 25 2007 Gabriel Somlo 6pl1-17 - changed build config option to use default X cursor fonts wpa_supplicant-1:0.5.7-21.fc9 ----------------------------- * Tue Dec 25 2007 Dan Williams - 0.5.7-21 - Backport 'frequency' option for Ad-Hoc network configs xorg-x11-docs-1.3-2.fc9 ----------------------- * Tue Dec 25 2007 Adam Jackson 1.3-2 - Install PDF instead of gzipped PostScript. - Move everything to /usr/share/doc to be more like other doc packages. - Add 'registry' to the doc set. Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 octave-forge - 20071212-4.fc9.i386 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) octave-forge - 20071212-4.fc9.x86_64 requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo octave-forge - 20071212-4.fc9.ppc requires octave(api) = 0:api-v31 php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-4.fc9.ppc64 requires octave(api) = 0:api-v31 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From richardfearn at gmail.com Wed Dec 26 11:52:05 2007 From: richardfearn at gmail.com (Richard Fearn) Date: Wed, 26 Dec 2007 11:52:05 +0000 Subject: Guidelines for packaging documentation containing PHP scripts Message-ID: <212718d80712260352w306e0c8pac8d1306c4957aff@mail.gmail.com> Hi everyone, I posted a message on the fedora-packaging list last week regarding packaging php-pdb, a library for manipulating Palm OS databases: https://www.redhat.com/archives/fedora-packaging/2007-December/msg00025.html Nobody's replied to that message yet, so I wondered if anyone on this list could offer any advice. php-pdb comes with documentation in the form of PHP scripts (including examples using php-pdb itself), and these need to be accessed through Apache. I wondered: * whether I should convert the documentation to plain HTML; * if it's OK to remove a .tar.gz containing a patched version of the library intended for use with another application (it doesn't seem appropriate for the php-pdb package); * whether it's OK to remove references to a sample app (which would also need to be served by Apache) - and leave the .tar.gz of the sample app in the doc files. Are there any other packages where the documentation comes as PHP scripts designed to be served through Apache? If anyone could point me at any examples I'd be grateful. I looked at the packaging guidelines for PHP but couldn't see anything relevant to executable documentation. Thanks, Richard Fearn From dragonauta.x at gmail.com Wed Dec 26 13:00:52 2007 From: dragonauta.x at gmail.com (dragonauta x) Date: Wed, 26 Dec 2007 10:00:52 -0300 Subject: moto4lin Message-ID: Sorry for bother you! I really appreciate your time. I've been using FC5, FC6 and Fedora7 and I've found that the moto4lin has a little bug (the same in all three distro). The Greek 'Sho' letter (?) between A and C drives letter that makes innaccessible other drives in the phone. (In statusbar appears /a?/c) I've contacted the author and he suggested me to use SVN (trunk) version. I've installed that and works. Can we replace the actual moto4lin rpm with the SVN one? should I build an rpm from the svn version? Thank you! Diego Rucci -- .:: www.preguntaslinux.org :: moderador ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Wed Dec 26 13:48:20 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 26 Dec 2007 13:48:20 +0000 Subject: moto4lin In-Reply-To: References: Message-ID: <645d17210712260548h4ac269bj7c593be5482bf95d@mail.gmail.com> On 26/12/2007, dragonauta x wrote: > Sorry for bother you! > I really appreciate your time. > > I've been using FC5, FC6 and Fedora7 and I've found that the moto4lin has a > little bug (the same in all three distro). > The Greek 'Sho' letter (?) between A and C drives letter that makes > innaccessible other drives in the phone. (In statusbar appears /a?/c) > I've contacted the author and he suggested me to use SVN (trunk) version. > I've installed that and works. > > Can we replace the actual moto4lin rpm with the SVN one? These requests are better off being placed in bugzilla: http://bugzilla.redhat.com. I imagine the package maintainer would be sympathetic to your request, given it fixes a real world bug. From choeger at cs.tu-berlin.de Wed Dec 26 17:09:29 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 26 Dec 2007 18:09:29 +0100 Subject: SELinux macro broken? Message-ID: <1198688969.14312.2.camel@choeger4> Hi, when I tried to build a custom SELinux module, this strange behavior occured: when I used: libs_read_lib_files(tomcat5_t) I got "read" denied source: tomcat5_t target: lib_t but using require { type lib_t; type tomcat5_t; class file read; } allow tomcat5_t lib_t:file read; worked fine. Although this should essentially be the same in my understanding. Any explanations for that? regards christoph From the.masch at gmail.com Wed Dec 26 18:31:12 2007 From: the.masch at gmail.com (masch) Date: Wed, 26 Dec 2007 13:31:12 -0500 Subject: Update wine Message-ID: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> Hi! Do you have some notice for Wine Update? Salu2... From dragonauta.x at gmail.com Wed Dec 26 22:44:23 2007 From: dragonauta.x at gmail.com (dragonauta x) Date: Wed, 26 Dec 2007 19:44:23 -0300 Subject: moto4lin Message-ID: >> Sorry for bother you! >> I really appreciate your time. >> >> I've been using FC5, FC6 and Fedora7 and I've found that the moto4lin has a >> little bug (the same in all three distro). >> The Greek 'Sho' letter (?) between A and C drives letter that makes >> innaccessible other drives in the phone. (In statusbar appears /a?/c) >> I've contacted the author and he suggested me to use SVN (trunk) version. >> I've installed that and works. >> >> Can we replace the actual moto4lin rpm with the SVN one? > >These requests are better off being placed in bugzilla: > http://bugzilla.redhat.com. I imagine the package maintainer would be >sympathetic to your request, given it fixes a real world bug. Thanks Jonathan, I did reported in bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=426667 and they told me to contact the author... so the author told to use the svn version... In Argentina we say: "nobody holds hot potatos" Seems like nobody wants to solve this... Anyone who knows were should I post this? thanks again for your invaluable time -- .:: www.preguntaslinux.org :: moderador ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.sourada at seznam.cz Wed Dec 26 22:57:04 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 26 Dec 2007 23:57:04 +0100 Subject: moto4lin In-Reply-To: References: Message-ID: <1198709824.10877.3.camel@pc-notebook> On Wed, 2007-12-26 at 23:44 +0100, dragonauta x wrote: > Thanks Jonathan, I did reported in bugzilla > https://bugzilla.redhat.com/show_bug.cgi?id=426667 > and they told me to contact the author... so > the author told to use the svn version... > > In Argentina we say: "nobody holds hot potatos" > Seems like nobody wants to solve this... > Anyone who knows were should I post this? > > thanks again for your invaluable time > -- > .:: www.preguntaslinux.org :: moderador ::. > -- Hi, I think you should say in the report in bugzilla that you contacted the author and he that he suggested using svn version and that you tried it and it work and suggest in the bug to either backport some patches from the svn version (if anyone is able to track which changes in code fixes the behaviour) or upgrading to svn snapshot completely. 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 andreas.bierfert at lowlatency.de Wed Dec 26 23:19:03 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 27 Dec 2007 00:19:03 +0100 Subject: Update wine In-Reply-To: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> Message-ID: <20071227001903.4cafd812@alkaid.a.lan> On Wed, 26 Dec 2007 13:31:12 -0500 masch wrote: > Hi! > Do you have some notice for Wine Update? > > Salu2... Take a look here: http://fedoraproject.org/wiki/AndreasBierfert/Wine. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From the.masch at gmail.com Thu Dec 27 04:01:15 2007 From: the.masch at gmail.com (masch) Date: Wed, 26 Dec 2007 23:01:15 -0500 Subject: Update wine In-Reply-To: <20071227001903.4cafd812@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> Message-ID: <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> .Yes, I have 0.9.49, but the latest version is 0.9.51 with many fixes. Do you know when will be ready? Salu2... On Dec 26, 2007 6:19 PM, Andreas Bierfert wrote: > > On Wed, 26 Dec 2007 13:31:12 -0500 > masch wrote: > > > Hi! > > Do you have some notice for Wine Update? > > > > Salu2... > > Take a look here: http://fedoraproject.org/wiki/AndreasBierfert/Wine. > > > - Andreas > -- > Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB > andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted > phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From Matt_Domsch at dell.com Thu Dec 27 04:58:48 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 26 Dec 2007 22:58:48 -0600 Subject: Fedora and lack of audio communication with the community In-Reply-To: <1198421493.25746.4.camel@cutter> References: <64b14b300712221307q6596884cpa57134bf6f74fd89@mail.gmail.com> <476DA064.50603@gmail.com> <1198421493.25746.4.camel@cutter> Message-ID: <20071227045848.GA16852@auslistsprd01.us.dell.com> > Podcasts are useless to the deaf and Hard of Hearing. If you want to put > a podcast up, fine. if you don't have a transcript of it you're > excluding that portion of the population, entirely. There is currently > software to read text in a voice for the blind, we have nothing to > convert speech to text. I managed a (very low listenership) podcast for a year. It's a good bit of work, but I wouldn't discourage someone wanting to do it. In my postings, I had the good fortune that my audio content was being read nearly verbatim from a printed sheet, and I had the content of the printed sheet to include in the ID3 tags (MP3s) and comment tags (OGGs). My limited audience probably never even noticed this "feature" of their downloaded file, but it was trivial to add. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From subhodip at fedoraproject.org Thu Dec 27 06:34:36 2007 From: subhodip at fedoraproject.org (subhodip biswas) Date: Thu, 27 Dec 2007 12:04:36 +0530 Subject: fedora cert In-Reply-To: <47722578.2020201@hhs.nl> References: <539333cb0712260134t3cb7d6e6r1febd47ea8e2cf4c@mail.gmail.com> <47722578.2020201@hhs.nl> Message-ID: <539333cb0712262234sfe4f9b7s6c4d7ef217a34cbe@mail.gmail.com> thanx for the help ... it worked -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From andreas.bierfert at lowlatency.de Thu Dec 27 09:21:06 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 27 Dec 2007 10:21:06 +0100 Subject: Update wine In-Reply-To: <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> Message-ID: <20071227102106.1a9da15a@alkaid.a.lan> On Wed, 26 Dec 2007 23:01:15 -0500 masch wrote: > .Yes, I have 0.9.49, but the latest version is 0.9.51 with many fixes. > Do you know when will be ready? As you can see I have build .51 on December 17th. If you really need it go and grep it from the koji link. .51 will be released for F-{7,8} when I had time to fix some package bugs which will hopefully be in the next days. Regards, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Thu Dec 27 10:36:37 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 27 Dec 2007 11:36:37 +0100 Subject: Heads up: new sysprof package without binary kernel module Message-ID: As you surely know, all the (two...) binaries kernel modules we used to ship were removed from rawhide. As a result, the sysprof package can't work due to the missing kernel module. I investigated the possibility of including the needed module in the kernel: http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/802 but it seems it's not going to happen (at least, not soon enough...) so here is my B plan... I prepared a sysprof update with the following modifications: 1. provide a subpackage with the kernel module sources 2. let this package obsolete kmod-sysprof 3. provide a build procedure for the kernel module 4. patch the main sysprof application to help the user understanding what is going on The scratch build for this package is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=310956 I will greatly appreciate comments, suggestions, test results, whatever you feel relevant for bringing this in a acceptable state before F9 Cheers Gianluca From lkundrak at redhat.com Thu Dec 27 10:58:20 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 27 Dec 2007 11:58:20 +0100 Subject: Heads up: new sysprof package without binary kernel module In-Reply-To: References: Message-ID: <1198753100.8312.2.camel@localhost.localdomain> Hi, On Thu, 2007-12-27 at 11:36 +0100, Gianluca Sforna wrote: > As you surely know, all the (two...) binaries kernel modules we used > to ship were removed from rawhide. > As a result, the sysprof package can't work due to the missing kernel module. > > I investigated the possibility of including the needed module in the kernel: > > http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/802 > > but it seems it's not going to happen (at least, not soon enough...) > so here is my B plan... > > I prepared a sysprof update with the following modifications: > > 1. provide a subpackage with the kernel module sources > 2. let this package obsolete kmod-sysprof > 3. provide a build procedure for the kernel module > 4. patch the main sysprof application to help the user understanding > what is going on Please don't do this. What would be an advantage of this approach compared to shipping a binary module? The solution that seems most logical for me is to remove the sysprof package from Fedora altogether, and it will surely find some love in Livna and RPMFusion. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Thu Dec 27 10:58:20 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 27 Dec 2007 11:58:20 +0100 Subject: Heads up: new sysprof package without binary kernel module In-Reply-To: References: Message-ID: <1198753100.8312.2.camel@localhost.localdomain> Hi, On Thu, 2007-12-27 at 11:36 +0100, Gianluca Sforna wrote: > As you surely know, all the (two...) binaries kernel modules we used > to ship were removed from rawhide. > As a result, the sysprof package can't work due to the missing kernel module. > > I investigated the possibility of including the needed module in the kernel: > > http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/802 > > but it seems it's not going to happen (at least, not soon enough...) > so here is my B plan... > > I prepared a sysprof update with the following modifications: > > 1. provide a subpackage with the kernel module sources > 2. let this package obsolete kmod-sysprof > 3. provide a build procedure for the kernel module > 4. patch the main sysprof application to help the user understanding > what is going on Please don't do this. What would be an advantage of this approach compared to shipping a binary module? The solution that seems most logical for me is to remove the sysprof package from Fedora altogether, and it will surely find some love in Livna and RPMFusion. -- Lubomir Kundrak (Red Hat Security Response Team) From buildsys at redhat.com Thu Dec 27 11:55:35 2007 From: buildsys at redhat.com (Build System) Date: Thu, 27 Dec 2007 06:55:35 -0500 Subject: rawhide report: 20071227 changes Message-ID: <200712271155.lBRBtZ8D016728@porkchop.devel.redhat.com> New package perl-Getopt-GUI-Long A wrapper around Getopt::Long to provide a GUI to applications New package starplot-yale5 Stellar data set for use by the StarPlot tool Removed package marble Removed package d3lphin Updated Packages: freeciv-2.1.2-1.fc9 ------------------- * Tue Dec 25 2007 Brian Pepple - 2.1.2-1 - Update to 2.1.2. gajim-0.11.4-1.fc9 ------------------ * Wed Dec 26 2007 Mat??j Cepl 0.11.4-1 - New upstream release. jd-1.9.8-0.5.svn1674.fc9 ------------------------ * Thu Dec 27 2007 Mamoru Tasaka - 1.9.8-0.5.svn1674 - svn 1674 * Sun Dec 23 2007 Mamoru Tasaka - 1.9.8-0.5.rc071223 - 1.9.8 rc 071223 * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 libHX-1.10.2-1.fc9 ------------------ libdockapp-0.6.1-5.fc9 ---------------------- * Thu Dec 27 2007 Patrice Dumas 0.6.1-5 - minor cleanups mfiler2-4.0.5b-1.fc9 -------------------- * Wed Dec 26 2007 Mamoru Tasaka - 4.0.5b-1 - 4.0.5b * Thu Dec 20 2007 Mamoru Tasaka - 4.0.1-1 - 4.0.1 * Wed Dec 19 2007 Mamoru Tasaka - 4.0.0e-1 - 4.0.0e nautilus-sendto-0.12-6.fc9 -------------------------- * Wed Dec 26 2007 Matthias Clasen - 0.12-6 - Install the nautilus exension in the right spot octave-forge-20071212-5.fc9 --------------------------- * Wed Dec 26 2007 Quentin Spencer 20071212-5 - Rebuild for octave 3.0.0. Remove edit.m because it's now in octave. oniguruma-5.9.1-1.fc9 --------------------- pinot-0.81-3.fc9 ---------------- * Thu Dec 27 2007 Adel Gadllah 0.81-3 - Rebuild against xapian 1.0.5 python-kaa-base-0.2.0-1.fc9 --------------------------- * Wed Dec 26 2007 kwizart < kwizart at gmail.com > - 0.2.0-1 - Update to 0.2.0 python-kaa-imlib2-0.2.2-1.fc9 ----------------------------- * Wed Dec 26 2007 kwizart < kwizart at gmail.com > - 0.2.2-1 - Update to 0.2.2 python-kaa-metadata-0.7.1-1.fc9 ------------------------------- * Wed Dec 26 2007 kwizart < kwizart at gmail.com > - 0.7.1-1 - Update to 0.7.1 system-config-language-1.2.15-1.fc9 ----------------------------------- * Wed Dec 26 2007 Lingning Zhang - 1.2.15-1 - fix bug294561. * Tue Nov 27 2007 Parag Nemade - 1.2.14-2 - Merge review SPEC cleanup rh#226461 xapian-bindings-1.0.5-1.fc9 --------------------------- * Thu Dec 27 2007 Adel Gadllah 1.0.5-1 - Update to 1.0.5 xapian-core-1.0.5-1.fc9 ----------------------- * Thu Dec 27 2007 Adel Gadllah 1.0.5-1 - Update to 1.0.5 Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.i386 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.x86_64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bmpx-extension - 0.40.13-6.fc9.ppc requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bmpx-extension - 0.40.13-6.fc9.ppc64 requires firefox = 0:2.0.0.10 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From gilboad at gmail.com Thu Dec 27 13:27:50 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 27 Dec 2007 15:27:50 +0200 Subject: Update wine In-Reply-To: <20071227102106.1a9da15a@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> Message-ID: <1198762070.4830.3.camel@gilboa-work-dev.localdomain> On Thu, 2007-12-27 at 10:21 +0100, Andreas Bierfert wrote: > On Wed, 26 Dec 2007 23:01:15 -0500 > masch wrote: > > > .Yes, I have 0.9.49, but the latest version is 0.9.51 with many fixes. > > Do you know when will be ready? > > As you can see I have build .51 on December 17th. If you really need it go and > grep it from the koji link. .51 will be released for F-{7,8} when I had time to > fix some package bugs which will hopefully be in the next days. > > Regards, > Andreas Andreas, Can you post the koji link? I can only find the .49 build. Thanks, - Gilboa [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=24773 From andreas.bierfert at lowlatency.de Thu Dec 27 14:06:42 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 27 Dec 2007 15:06:42 +0100 Subject: Update wine In-Reply-To: <1198762070.4830.3.camel@gilboa-work-dev.localdomain> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> Message-ID: <20071227150642.30e79230@alkaid.a.lan> On Thu, 27 Dec 2007 15:27:50 +0200 Gilboa Davara wrote: > Can you post the koji link? > I can only find the .49 build. [1] as stated on the wiki [2]. Regards, Andreas [1] - http://koji.fedoraproject.org/koji/taskinfo?taskID=297430 [2] - http://fedoraproject.org/wiki/AndreasBierfert/Wine -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Thu Dec 27 14:09:43 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 27 Dec 2007 16:09:43 +0200 Subject: Update wine In-Reply-To: <20071227150642.30e79230@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> Message-ID: <1198764583.4830.5.camel@gilboa-work-dev.localdomain> On Thu, 2007-12-27 at 15:06 +0100, Andreas Bierfert wrote: > On Thu, 27 Dec 2007 15:27:50 +0200 > Gilboa Davara wrote: > > > Can you post the koji link? > > I can only find the .49 build. > > [1] as stated on the wiki [2]. > > Regards, > Andreas > > [1] - http://koji.fedoraproject.org/koji/taskinfo?taskID=297430 > [2] - http://fedoraproject.org/wiki/AndreasBierfert/Wine > -- Thanks. Must have missed it. - Gilboa From gilboad at gmail.com Thu Dec 27 14:15:40 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 27 Dec 2007 16:15:40 +0200 Subject: Update wine (koji download is broken) In-Reply-To: <1198764583.4830.5.camel@gilboa-work-dev.localdomain> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <1198764583.4830.5.camel@gilboa-work-dev.localdomain> Message-ID: <1198764940.4830.7.camel@gilboa-work-dev.localdomain> On Thu, 2007-12-27 at 16:09 +0200, Gilboa Davara wrote: > On Thu, 2007-12-27 at 15:06 +0100, Andreas Bierfert wrote: > > On Thu, 27 Dec 2007 15:27:50 +0200 > > Gilboa Davara wrote: > > > > > Can you post the koji link? > > > I can only find the .49 build. > > > > [1] as stated on the wiki [2]. > > > > Regards, > > Andreas > > > > [1] - http://koji.fedoraproject.org/koji/taskinfo?taskID=297430 > > [2] - http://fedoraproject.org/wiki/AndreasBierfert/Wine > > -- > > Thanks. > Must have missed it. > > - Gilboa P.S. Koji error's out when I try to download the RPMs. I'll try again later and open up a BZ# if it continues to error out. - Gilboa From mtasaka at ioa.s.u-tokyo.ac.jp Thu Dec 27 14:30:05 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 27 Dec 2007 23:30:05 +0900 Subject: Update wine In-Reply-To: <20071227150642.30e79230@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> Message-ID: <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> Andreas Bierfert wrote, at 12/27/2007 11:06 PM +9:00: > On Thu, 27 Dec 2007 15:27:50 +0200 > Gilboa Davara wrote: > >> Can you post the koji link? >> I can only find the .49 build. > > [1] as stated on the wiki [2]. > > Regards, > Andreas > > [1] - http://koji.fedoraproject.org/koji/taskinfo?taskID=297430 > [2] - http://fedoraproject.org/wiki/AndreasBierfert/Wine > Well, no. scratch build results are deleted automatically from koji repo after one week or so is passed. Information for task 297328 Created Mon, 17 Dec 2007 12:03:42 MST Completed Mon, 17 Dec 2007 13:15:54 MST Regards, Mamoru From the.masch at gmail.com Thu Dec 27 16:25:14 2007 From: the.masch at gmail.com (masch) Date: Thu, 27 Dec 2007 11:25:14 -0500 Subject: Update wine In-Reply-To: <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> Message-ID: <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> How can i get that version? Salu2... On Dec 27, 2007 9:30 AM, Mamoru Tasaka wrote: > Andreas Bierfert wrote, at 12/27/2007 11:06 PM +9:00: > > On Thu, 27 Dec 2007 15:27:50 +0200 > > Gilboa Davara wrote: > > > >> Can you post the koji link? > >> I can only find the .49 build. > > > > [1] as stated on the wiki [2]. > > > > Regards, > > Andreas > > > > [1] - http://koji.fedoraproject.org/koji/taskinfo?taskID=297430 > > [2] - http://fedoraproject.org/wiki/AndreasBierfert/Wine > > > > Well, no. scratch build results are deleted automatically from > koji repo after one week or so is passed. > > Information for task 297328 > Created Mon, 17 Dec 2007 12:03:42 MST > Completed Mon, 17 Dec 2007 13:15:54 MST > > Regards, > Mamoru > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pertusus at free.fr Thu Dec 27 18:49:29 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 27 Dec 2007 19:49:29 +0100 Subject: kernels won't boot In-Reply-To: <200712220828.48202.sgrubb@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> Message-ID: <20071227184929.GA2568@free.fr> On Sat, Dec 22, 2007 at 08:28:48AM -0500, Steve Grubb wrote: > On Saturday 22 December 2007 07:16:32 Build System wrote: > > Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other > people running into this? I see the same. The following don't work: kernel-2.6.24-0.107.rc5.git3.fc9 kernel-2.6.24-0.123.rc6.fc9 kernel-2.6.24-0.81.rc4.git7.fc9 works, and most kernels before this one didn't worked. My computer is a dell latitude d505. -- Pat From lkundrak at redhat.com Thu Dec 27 20:47:57 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 27 Dec 2007 21:47:57 +0100 Subject: Update wine In-Reply-To: <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> Message-ID: <1198788477.8312.16.camel@localhost.localdomain> On Thu, 2007-12-27 at 11:25 -0500, masch wrote: > How can i get that version? > Salu2... You can compile it yourself on your machine (preferably in mock), or do a build in koji, possibly a scratch one. -- Lubomir Kundrak (Red Hat Security Response Team) From andreas.bierfert at lowlatency.de Thu Dec 27 20:51:15 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 27 Dec 2007 21:51:15 +0100 Subject: Update wine In-Reply-To: <1198788477.8312.16.camel@localhost.localdomain> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> Message-ID: <20071227215115.274bc3a8@alkaid.a.lan> On Thu, 27 Dec 2007 21:47:57 +0100 Lubomir Kundrak wrote: > You can compile it yourself on your machine (preferably in mock), or do > a build in koji, possibly a scratch one. I will push a updates-testing build later. -Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyle at mcmartin.ca Fri Dec 28 01:55:49 2007 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 27 Dec 2007 20:55:49 -0500 Subject: Fwd: Package: kernel-2.6.24-0.128.rc6.git4.fc9 Tag: dist-f9 Status: failed Built by: kyle Message-ID: <20071228015549.GB9347@fattire.cabal.ca> Anyone have any idea why this keeps failing for me? The NVR seems to be different for each attempt in koji. cheers, Kyle ----- Forwarded message from Koji Build System ----- From: Koji Build System Subject: Package: kernel-2.6.24-0.128.rc6.git4.fc9 Tag: dist-f9 Status: failed Built by: kyle Date: Thu, 27 Dec 2007 18:33:22 -0700 Message-Id: <200712280133.lBS1XM7I002519 at bastion.fedora.phx.redhat.com> Package: kernel-2.6.24-0.128.rc6.git4.fc9 Tag: dist-f9 Status: failed Built by: kyle ID: 29212 Started: Thu, 27 Dec 2007 14:30:00 MST Finished: Thu, 27 Dec 2007 18:32:44 MST Changelog: * Thu Dec 27 2007 Kyle McMartin - 2.6.24-rc6-git4 * Wed Dec 26 2007 Kyle McMartin - 2.6.24-rc6-git3 * Mon Dec 24 2007 Dave Jones - Anaconda should be fixed now, so disable SYSFS_DEPRECATED again. kernel-2.6.24-0.128.rc6.git4.fc9 (29212) failed on ppc4.fedora.phx.redhat.com (noarch): pg.DatabaseError: error 'ERROR: duplicate key violates unique constraint "rpminfo_unique_nvra" ' in 'INSERT INTO rpminfo (name,version,release,epoch, build_id,arch,buildtime,buildroot_id, size,payloadhash) VALUES ('kernel','2.6.24','0.128.rc6.git4.fc9',NULL, 29212,'ppc',1198793324,98490, 19457961,'a6b63564d2f1ac8231b24b6cffb0e5b3') ' SRPMS: kernel-2.6.24-0.128.rc6.git4.fc9.src.rpm Failed tasks: ------------- Task 311572 on ppc4.fedora.phx.redhat.com Task Type: build (dist-f9, devel:kernel-2_6_24-0_128_rc6_git4_fc9) From giallu at gmail.com Fri Dec 28 07:37:19 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 28 Dec 2007 08:37:19 +0100 Subject: Heads up: new sysprof package without binary kernel module In-Reply-To: <1198753100.8312.2.camel@localhost.localdomain> References: <1198753100.8312.2.camel@localhost.localdomain> Message-ID: On Dec 27, 2007 11:58 AM, Lubomir Kundrak wrote: > > 1. provide a subpackage with the kernel module sources > > 2. let this package obsolete kmod-sysprof > > 3. provide a build procedure for the kernel module > > 4. patch the main sysprof application to help the user understanding > > what is going on > > Please don't do this. What would be an advantage of this approach > compared to shipping a binary module? The solution that seems most > logical for me is to remove the sysprof package from Fedora altogether, > and it will surely find some love in Livna and RPMFusion. > The main advantage of this approach is actually that I can avoid moving the package between repos... I hope to get some more (different?) views on the topic Thanks a lot Gianluca From andreas.bierfert at lowlatency.de Fri Dec 28 10:06:21 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 28 Dec 2007 11:06:21 +0100 Subject: Update wine In-Reply-To: <20071227215115.274bc3a8@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> <20071227215115.274bc3a8@alkaid.a.lan> Message-ID: <20071228110621.78daa14e@alkaid.a.lan> On Thu, 27 Dec 2007 21:51:15 +0100 Andreas Bierfert wrote: > I will push a updates-testing build later. Build [1] is completed and should hit F8 updates-testing with the next push. Regards, Andreas [1] - http://koji.fedoraproject.org/koji/buildinfo?buildID=29237 -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Dec 28 10:20:40 2007 From: opensource at till.name (Till Maas) Date: Fri, 28 Dec 2007 11:20:40 +0100 Subject: Heads up: new sysprof package without binary kernel module In-Reply-To: References: <1198753100.8312.2.camel@localhost.localdomain> Message-ID: <200712281120.45996.opensource@till.name> On Fr Dezember 28 2007, Gianluca Sforna wrote: > The main advantage of this approach is actually that I can avoid > moving the package between repos... > > I hope to get some more (different?) views on the topic Fesco decided that kernel modules are not allowed in Fedora 9 and later, regardless on how they are packaged. Therefore moving the package to another repository is the only option. :-/ 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 dragonauta.x at gmail.com Fri Dec 28 11:05:56 2007 From: dragonauta.x at gmail.com (dragonauta x) Date: Fri, 28 Dec 2007 08:05:56 -0300 Subject: moto4lin, I give up. Message-ID: I give up... (to resume: moto4lin doesn't work well with +2 drives, but SVN version does) This is what I got on bugzilla: "I'm sorry, but this is still an upstream issue. The fact that the upstream author has a patch that fixes this problem but is not releasing it in an official release does not make this a packaging issues, IMHO. It is my position that bugs like this need to be fixed by an upstream release, particularly in cases like this. Because upstream fixes help all distributions, and Fedora, effectively, forking it does not. I don't believe it is Fedora's place to be tracking svn. Does the upstream maintainer have a good reason for not having a real release that fixes this? If someone from fedora-devel thinks this should be tracking SVN, they should re-open this and take assignment on the bug." Thanks anyway. -- .:: www.preguntaslinux.org :: moderador ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Fri Dec 28 11:36:43 2007 From: buildsys at redhat.com (Build System) Date: Fri, 28 Dec 2007 06:36:43 -0500 Subject: rawhide report: 20071228 changes Message-ID: <200712281136.lBSBahqZ026272@porkchop.devel.redhat.com> New package nightfall Nightfall is an astronomy application for emulation of eclipsing stars Updated Packages: Zim-0.23-1.fc9 -------------- * Thu Nov 22 2007 Chris Weyl 0.23-1 - update to 0.23 audit-1.6.3-1.fc9 ----------------- * Thu Dec 27 2007 Steve Grubb 1.6.3-1 - Add kernel release string to DEAMON_START events - Fix keep_logs when num_logs option disabled (#325561) - Fix auparse to handle node fields for syscall records - Update system-config-audit to version 0.4.5 (Miloslav Trmac) - Add keyword week-ago to aureport & ausearch start/end times - Fix audit log permissions on rotate. If group is root 0400, otherwise 0440 - Add RACF zos remote audispd plugin (Klaus Kiwi) - Add event queue overflow action to audispd * Mon Oct 01 2007 Steve Grubb 1.6.2-2 - Don't retry if the rt queue is full. * 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 bind-32:9.5.0-23.b1.fc9 ----------------------- * Thu Dec 27 2007 Adam Tkac 32:9.5.0-23.b1 - fixed initscript wait loop (#426382) - removed dependency on policycoreutils and libselinux (#426515) bmpx-0.40.13-7.fc9 ------------------ * Fri Dec 28 2007 Alexander Kahl - 0.40.13-7 - removed firefox extension until ff 3.0 reaches stable compiz-fusion-0.6.0-10.fc9 -------------------------- * Thu Dec 27 2007 Adel Gadllah 0.6.0-10 - Plug small memory leak * Thu Dec 27 2007 Adel Gadllah 0.6.0-9 - Don't break legacy apps that want to unfullscreen themselves * Tue Dec 25 2007 Adel Gadllah 0.6.0-8 - Fix fullscreen for flash windows when legacy fullscreen is enabled. fontmatrix-0.3.0-3.r270.fc9 --------------------------- * Thu Dec 27 2007 Parag - 0.3.0-3.r270 - update to svn revision 270 glibc-2.7.90-2 -------------- * Thu Dec 27 2007 Jakub Jelinek 2.7.90-2 - update to trunk - nsswitch fix (#425768) - temporarily enable assert checking gnomesword-2.3.2-1.fc9 ---------------------- * Fri Dec 28 2007 Deji Akingunola - 2.3.2-1 - Update to 2.3.2 hwbrowser-0.41-1.fc9 -------------------- * Thu Dec 27 2007 Nils Philippsen - 0.41-1 - rename sr at Latn to sr at latin (#426587) im-chooser-0.5.5-1.fc9 ---------------------- * Thu Dec 27 2007 Akira TAGOH - 0.5.5-1 - New upstream release. - Rename sr at Latn to sr at latin. (#426540) kvm-58-2.fc9 ------------ * Thu Dec 27 2007 Jeremy Katz - 58-2 - Fix up defaults patch to apply * Thu Dec 27 2007 Jeremy Katz - 58-1 - Update to kvm-58 libsx-2.05-14.fc9 ----------------- * Thu Dec 27 2007 Patrice Dumas 2.05-14 - remove static lib * Thu Dec 27 2007 Patrice Dumas 2.05-13 - keep timestamps maxima-5.14.0-2.fc9 ------------------- * Thu Dec 27 2007 Rex Dieter 5.14.0-2 - respin (sbcl) nautilus-search-tool-0.2.2-2.fc9 -------------------------------- * Thu Dec 27 2007 Paul W. Frields - 0.2.2-2 - Put extension in the proper directory (#426831) ooo2txt-0.0.6-3.fc9 ------------------- pam_ssh-1.92-7.fc9 ------------------ * Thu Dec 27 2007 Patrice Dumas 1.92-7 - keep timestamps perl-File-DesktopEntry-0.04-5.fc9 --------------------------------- * Thu Dec 27 2007 Patrice Dumas 0.04-5 - update to 0.04 perl-IPC-Run3-0.040-1.fc9 ------------------------- * Fri Dec 28 2007 Ralf Cors??pius 0.040-1 - Upstream update. - chmod -x files from source tarball. perl-Locale-Maketext-Lexicon-0.65-1.fc9 --------------------------------------- * Fri Dec 28 2007 Ralf Cors??pius - 0.65-1 - Upstream update. perl-POE-Component-SimpleDBI-1.18-1.fc9 --------------------------------------- * Thu Dec 27 2007 Chris Weyl 1.18-1 - update to 1.18 pirut-1.3.29-1.fc9 ------------------ * Thu Dec 27 2007 Jeremy Katz - 1.3.29-1 - Don't show 0 updates (#417901) - Fix a typo in cdinstaller - Fake out plugins to think there's a command line to avoid bugs like #421961 - Translation updates for el, sk and gu - Allow update/removal of a single package with single.py (#426102) ruby-1.8.6.111-4.fc9 -------------------- * Fri Dec 28 2007 Akira TAGOH - 1.8.6.111-4 - Clean up again. * Fri Dec 21 2007 Akira TAGOH - 1.8.6.111-3 - Clean up the spec file. - Remove ruby-man-1.4.6 stuff. this is entirely the out-dated document. this could be replaced by ri. - Disable the static library building. * Tue Dec 04 2007 Release Engineering - 1.8.6.111-2 - Rebuild for openssl bump rxvt-unicode-8.9-1.fc9 ---------------------- * Thu Dec 27 2007 Andreas Bierfert - 8.9-1 - version upgrade sbcl-1.0.13-1.fc9 ----------------- * Thu Dec 27 2007 Rex Dieter 1.0.13-1 - sbcl-1.0.13 scim-python-0.1.8-1.fc9 ----------------------- * Fri Dec 28 2007 Huang Peng - 0.1.8-1 - Update to 0.1.8. system-config-date-1.9.18-1.fc9 ------------------------------- * Thu Dec 27 2007 Nils Philippsen - 1.9.18-1 - rename sr at Latn to sr at latin (#426591) system-config-nfs-1.3.34-1.fc9 ------------------------------ * Thu Dec 27 2007 Nils Philippsen - 1.3.34-1 - rename sr at Latn to sr at latin (#426589) * Wed Dec 05 2007 Nils Philippsen - overwrite *.pot and *.po files only on real changes system-config-samba-1.2.59-1.fc9 -------------------------------- * Thu Dec 27 2007 Nils Philippsen - 1.2.59-1 - rename sr at Latn to sr at latin (#426588) * Wed Dec 05 2007 Nils Philippsen - overwrite *.pot and *.po files only on real changes system-config-services-0.9.18-1.fc9 ----------------------------------- * Thu Dec 27 2007 Nils Philippsen - 0.9.18-1 - rename sr at Latn to sr at latin (#426590) * Wed Dec 05 2007 Nils Philippsen - overwrite *.pot and *.po files only on real changes system-config-users-1.2.74-1.fc9 -------------------------------- * Thu Dec 27 2007 Nils Philippsen - 1.2.74-1 - rename sr at Latn to sr at latin (#426592) * Mon Dec 10 2007 Nils Philippsen - allow setting but not creating of home directories when creating a user (#416421) * Wed Dec 05 2007 Nils Philippsen - overwrite *.pot and *.po files only on real changes Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 php-imap - 5.2.5-3.i386 requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) php-imap - 5.2.5-3.x86_64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo php-imap - 5.2.5-3.ppc requires libc-client.so.2006 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-imap - 5.2.5-3.ppc64 requires libc-client.so.2006()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From andreas.bierfert at lowlatency.de Fri Dec 28 11:45:38 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 28 Dec 2007 12:45:38 +0100 Subject: Heads up: opensync upgrade Message-ID: <20071228124538.54e5f081@alkaid.a.lan> Hallo everyone, coming up for rawhide is an opensync upgrade to 0.35. This means that all opensync plugins will need an upgrade and all applications depending on opensync need a rebuild because of a soname bump from .0 to .1. 0.35 still is a testing release on the road to 0.40 which should be released sometime soon. As 0.40 will include many changes (including a new build environment using cmake) I would like to give it as much testing as possible. There is one important change: There currently is no gui tool to do the synchronization (not that multisync really worked anway). The gui for now is deprecated. The command line tool msynctool however has been developed further. Because of this I have decided to finally split out msynctool from the multisync package. Msynctool has been part of the multisync package for historical reasons but should not be in there anymore. The split review bug can be found here (#426915). There are also some additional plugins for which I have put up review bugs in case anyone is interested: o google-calendar (#426911) o moto (#426912) o opie (#426913) o vformat (#426914) If there are problems let me know. Best Regards, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Fri Dec 28 11:52:37 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Dec 2007 11:52:37 +0000 Subject: moto4lin, I give up. In-Reply-To: References: Message-ID: <18292.58245.440406.888498@zebedee.pink> dragonauta x writes: > I give up... > (to resume: moto4lin doesn't work well with +2 drives, but SVN version does) > This is what I got on bugzilla: > "I'm sorry, but this is still an upstream issue. The fact that the upstream > author has a patch that fixes this problem but is not releasing it in an > official release does not make this a packaging issues, IMHO. > > It is my position that bugs like this need to be fixed by an upstream > release, > particularly in cases like this. Because upstream fixes help all > distributions, > and Fedora, effectively, forking it does not. > > I don't believe it is Fedora's place to be tracking svn. Does the upstream > maintainer have a good reason for not having a real release that fixes this? > > If someone from fedora-devel thinks this should be tracking SVN, they should > re-open this and take assignment on the bug." > > Thanks anyway. I don't get it. Where's the problem? Upstream refuses to produce an update? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From drago01 at gmail.com Fri Dec 28 12:12:04 2007 From: drago01 at gmail.com (drago01) Date: Fri, 28 Dec 2007 13:12:04 +0100 Subject: Update wine In-Reply-To: <20071228110621.78daa14e@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> <20071227215115.274bc3a8@alkaid.a.lan> <20071228110621.78daa14e@alkaid.a.lan> Message-ID: <4774E814.2080305@gmail.com> Andreas Bierfert wrote: > On Thu, 27 Dec 2007 21:51:15 +0100 > Andreas Bierfert wrote: > > >> I will push a updates-testing build later. >> > > Build [1] is completed and should hit F8 updates-testing with the next push. > > Regards, > > Andreas > > [1] - http://koji.fedoraproject.org/koji/buildinfo?buildID=29237 > > Notes about the pulseaudio fix: 1) does not work on x86_64 see: https://bugzilla.redhat.com/show_bug.cgi?id=426882 2) not a real issue but please pass -n Wine to the padsp call so that PA volumemanager does not show "oss emulation ..." From fedora at leemhuis.info Fri Dec 28 12:26:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Dec 2007 13:26:23 +0100 Subject: Heads up: new sysprof package without binary kernel module In-Reply-To: <200712281120.45996.opensource@till.name> References: <1198753100.8312.2.camel@localhost.localdomain> <200712281120.45996.opensource@till.name> Message-ID: <4774EB6F.8040104@leemhuis.info> On 28.12.2007 11:20, Till Maas wrote: > On Fr Dezember 28 2007, Gianluca Sforna wrote: > >> The main advantage of this approach is actually that I can avoid >> moving the package between repos... >> I hope to get some more (different?) views on the topic > Fesco decided that kernel modules are not allowed in Fedora 9 and later, > regardless on how they are packaged. Therefore moving the package to another > repository is the only option. :-/ Not the only, but the best one IMHO. As it was reviewed in Fedora we can just import it to Livna without an additional review. I also take care of rebuilding all kmods for newly released kernel, so that easier for you as well. >From Livna it will be moved to RPM Fusion once it starts (e.g. when I find time to finally complete setting up FAS for look-aside cache authentification; if anybody wants to help and knows about the Fedora infrastructure more then I do, is a better sysadmin then I am (I'm a bad sysadmin -- I earn my money with different things) then drop me a line). CU thl From andreas.bierfert at lowlatency.de Fri Dec 28 12:30:44 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 28 Dec 2007 13:30:44 +0100 Subject: Update wine In-Reply-To: <4774E814.2080305@gmail.com> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> <20071227215115.274bc3a8@alkaid.a.lan> <20071228110621.78daa14e@alkaid.a.lan> <4774E814.2080305@gmail.com> Message-ID: <20071228133044.4b3b6963@alkaid.a.lan> On Fri, 28 Dec 2007 13:12:04 +0100 drago01 wrote: > Notes about the pulseaudio fix: > 1) does not work on x86_64 see: > https://bugzilla.redhat.com/show_bug.cgi?id=426882 I have added this as a blocker... > 2) not a real issue but please pass -n Wine to the padsp call so that PA > volumemanager does not show "oss emulation ..." Will be added in the next build. Thanks, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- 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 Fri Dec 28 14:25:08 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 28 Dec 2007 09:25:08 -0500 Subject: xulrunner, Miro on f8 Message-ID: After installing firefox-3.0-0.beta2.3.fc9.x86_64 along with deps (xulrunner), I just tried installing Miro-1.0-4.fc9.x86. Any ideas on this? miro /usr/lib64/xulrunner-1.9pre Traceback (most recent call last): File "/usr/bin/miro.real", line 123, in startapp() File "/usr/bin/miro.real", line 58, in startapp import singleclick File "/usr/lib64/python2.5/site-packages/miro/singleclick.py", line 36, in import app File "/usr/lib64/python2.5/site-packages/miro/app.py", line 610, in import frontend File "/usr/lib64/python2.5/site-packages/miro/frontend.py", line 50, in import MozillaBrowser ImportError: /usr/lib64/xulrunner-sdk-1.9pre/lib/libxul.so: undefined symbol: g_assertion_message From nphilipp at redhat.com Fri Dec 28 15:10:07 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 28 Dec 2007 16:10:07 +0100 Subject: moto4lin, I give up. In-Reply-To: <18292.58245.440406.888498@zebedee.pink> References: <18292.58245.440406.888498@zebedee.pink> Message-ID: <1198854607.10926.16.camel@gibraltar.str.redhat.com> On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote: > I don't get it. Where's the problem? Upstream refuses to produce an > update? Upstream seems reluctant to release new versions, the last one is from March 2005. I can't tell if they refuse to do it or simply haven't been asked, though. IMO, the Fedora package maintainer should at least investigate if backporting the fix is feasible. 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 ivazqueznet at gmail.com Fri Dec 28 16:23:58 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 28 Dec 2007 11:23:58 -0500 Subject: moto4lin, I give up. In-Reply-To: <1198854607.10926.16.camel@gibraltar.str.redhat.com> References: <18292.58245.440406.888498@zebedee.pink> <1198854607.10926.16.camel@gibraltar.str.redhat.com> Message-ID: <1198859038.19106.6.camel@ignacio.lan> On Fri, 2007-12-28 at 16:10 +0100, Nils Philippsen wrote: > On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote: > > > I don't get it. Where's the problem? Upstream refuses to produce an > > update? > > Upstream seems reluctant to release new versions, the last one is from > March 2005. A failure to release an update in almost 3 years is usually the result of one of three things: 1) The software is finally stable and doesn't need frequent updates. 2) The maintainer has no faith in the software in general. 3) The maintainer doesn't actually want (or is pathologically unable) to maintain the software. Since the first obviously isn't true, one of the latter two must be. In my mind both of those cases are valid reasons for eventually orphaning the package if the situation doesn't improve. -- 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 Dec 28 17:17:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 28 Dec 2007 10:17:16 -0700 Subject: moto4lin, I give up. In-Reply-To: <18292.58245.440406.888498@zebedee.pink> References: <18292.58245.440406.888498@zebedee.pink> Message-ID: <1198862236.5905.8.camel@localhost6.localdomain6> On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote: > dragonauta x writes: > > I give up... > > (to resume: moto4lin doesn't work well with +2 drives, but SVN version does) > > This is what I got on bugzilla: > > "I'm sorry, but this is still an upstream issue. The fact that the upstream > > author has a patch that fixes this problem but is not releasing it in an > > official release does not make this a packaging issues, IMHO. > > > > It is my position that bugs like this need to be fixed by an upstream > > release, > > particularly in cases like this. Because upstream fixes help all > > distributions, > > and Fedora, effectively, forking it does not. > > > > I don't believe it is Fedora's place to be tracking svn. Does the upstream > > maintainer have a good reason for not having a real release that fixes this? > > > > If someone from fedora-devel thinks this should be tracking SVN, they should > > re-open this and take assignment on the bug." > > > > Thanks anyway. > > I don't get it. Where's the problem? Upstream refuses to produce an > update? Please don't oversimplify the issue. Just because upstream refuses, for whatever reason, to come up with a release doesn't mean packagers should refuse to package up a copy from VCS, particularly if it's been made reproducible. Upstream has their own agenda and packagers carry a bigger responsibility to the PACKAGE'S USERS. If the packager doesn't want to do the extra work, then say so, and hopefully a comaintainer will package it. But don't refuse it on principle. The fact remains that there is a fix and upstream isn't making it difficult at all to package. So why drag one's feet? If this were a trivial patch (cosmetic), I'd understand the reluctance. But bugs which break normal functionality I consider pretty up there. -- Richi Plana From mail at robertoragusa.it Fri Dec 28 17:27:22 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Fri, 28 Dec 2007 18:27:22 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <1196890738.17277.22.camel@localhost.localdomain> References: <20071203093903.GA5087@evileye.atkac.englab.brq.redhat.com> <20071203104518.00e1ac88@dhcp03.addix.net> <20071203100027.GA18645@evileye.atkac.englab.brq.redhat.com> <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> Message-ID: <477531FA.1000202@robertoragusa.it> Simo Sorce wrote: > The chaching nameserver is definitely the way to go imo. > It also would make it possible to do many other things like querying a > different name server based on the request. > > For example I'd like to query my corporate domain server (over the vpn) > buy only for domain names that end in my.corp.com and use my ISP for > anything else. I currently use some ad-hoc scripts to obtain this behavior, that is, don't query the corp server for generic queries. When manually launching them, some bind configs are modified and named restarted (/etc/resolv.conf always goes to 127.0.0.1). But there is another problem which I'm not able to solve easily: if you try to resolve www.google.com and you have "search my.corp.com" in /etc/resolv.conf, a query for www.google.com.my.corp.com will be tried first. The only solution I know is to use "www.google.com.", with a final dot, but that would mean changing every domain in every config (including rewiring my brain to always append an extra dot :-) ). It's a pity the rules are this way; the opposite would be a lot better (www.google.com ignores suffixes, but, e.g. www.google.com. gets the prefix expansion). What about simply reverting the attempts order, instead? First try it naked, then with suffixes. Would that violate some RFC or something? Best regards. -- Roberto Ragusa mail at robertoragusa.it From valent.turkovic at gmail.com Fri Dec 28 17:59:41 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 18:59:41 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> Message-ID: <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> On 12/26/07, subhodip biswas wrote: > K3b though popular , may bear some space constraints in live cd 's . > But I think it can be bought back to DVD's as it was in Fedora core 6 > and previous ... because of its popularity. > -- > Regards > Subhodip Biswas > Please consider this for Fedora 9 Live CD: https://bugzilla.redhat.com/show_bug.cgi?id=315151 -- 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 valent.turkovic at gmail.com Fri Dec 28 18:00:31 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 19:00:31 +0100 Subject: Consider this for Fedora 9 Live CD Message-ID: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> https://bugzilla.redhat.com/show_bug.cgi?id=315151 Please consider this for Fedora 9 Live CD... Valent. -- 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 johnp at redhat.com Fri Dec 28 18:05:28 2007 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 28 Dec 2007 13:05:28 -0500 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> Message-ID: <1198865128.7175.4.camel@localhost.localdomain> On Fri, 2007-12-28 at 19:00 +0100, Valent Turkovic wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > Please consider this for Fedora 9 Live CD... > > Valent. > > -- > 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 While I agree this is useful it is something that should be filed upstream and fixed in nautilus-cd-burner. It would be pretty easy to implement. -- John (J5) Palmieri From alan at clueserver.org Fri Dec 28 18:05:11 2007 From: alan at clueserver.org (Alan) Date: Fri, 28 Dec 2007 10:05:11 -0800 (PST) Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> Message-ID: <37808.198.182.193.170.1198865111.squirrel@clueserver.org> > On 12/26/07, subhodip biswas wrote: >> K3b though popular , may bear some space constraints in live cd 's . >> But I think it can be bought back to DVD's as it was in Fedora core 6 >> and previous ... because of its popularity. >> -- >> Regards >> Subhodip Biswas >> > Please consider this for Fedora 9 Live CD: > https://bugzilla.redhat.com/show_bug.cgi?id=315151 My only concern with adding K3B is all the KDE dependencies it drags along with it. I like the program a lot, but how much added baggage does it add? I wish that the Gnome CD burning software worked as easily and as well as K3B, but I have yet to find one that does. (They all seem to be horribly designed from a UI to me.) From valent.turkovic at gmail.com Fri Dec 28 18:09:59 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 19:09:59 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <37808.198.182.193.170.1198865111.squirrel@clueserver.org> References: <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> Message-ID: <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> On 12/28/07, Alan wrote: > > On 12/26/07, subhodip biswas wrote: > >> K3b though popular , may bear some space constraints in live cd 's . > >> But I think it can be bought back to DVD's as it was in Fedora core 6 > >> and previous ... because of its popularity. > >> -- > >> Regards > >> Subhodip Biswas > >> > > Please consider this for Fedora 9 Live CD: > > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > My only concern with adding K3B is all the KDE dependencies it drags along > with it. I like the program a lot, but how much added baggage does it > add? > > I wish that the Gnome CD burning software worked as easily and as well as > K3B, but I have yet to find one that does. (They all seem to be horribly > designed from a UI to me.) What is wrong with Brasero UI? I find it very similar UI vise when comparing it to k3b, still I like k3b more because it just works better for me. Do you have some concrete UI issues with Brasero? Have you talked with some Brasero devels regarding those issues? Valent. -- 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 valent.turkovic at gmail.com Fri Dec 28 18:12:45 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 19:12:45 +0100 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <1198865128.7175.4.camel@localhost.localdomain> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> <1198865128.7175.4.camel@localhost.localdomain> Message-ID: <64b14b300712281012j3548675aida4af4c196364946@mail.gmail.com> On 12/28/07, John (J5) Palmieri wrote: > > On Fri, 2007-12-28 at 19:00 +0100, Valent Turkovic wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > > > Please consider this for Fedora 9 Live CD... > > > > Valent. > > > > -- > > 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 > > While I agree this is useful it is something that should be filed > upstream and fixed in nautilus-cd-burner. It would be pretty easy to > implement. Well at least until upstream doesn't fix this issue there isn't a reason why fedora users should "suffer" because of that, is it? Please also consider this RFE which can be easily fixed, but still in F8 it is not: https://bugzilla.redhat.com/show_bug.cgi?id=315141 -- 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 alan at clueserver.org Fri Dec 28 18:13:09 2007 From: alan at clueserver.org (Alan) Date: Fri, 28 Dec 2007 10:13:09 -0800 (PST) Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> References: <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> Message-ID: <34209.12.172.32.236.1198865589.squirrel@clueserver.org> > On 12/28/07, Alan wrote: >> > On 12/26/07, subhodip biswas wrote: >> >> K3b though popular , may bear some space constraints in live cd 's . >> >> But I think it can be bought back to DVD's as it was in Fedora core 6 >> >> and previous ... because of its popularity. >> >> -- >> >> Regards >> >> Subhodip Biswas >> >> >> > Please consider this for Fedora 9 Live CD: >> > https://bugzilla.redhat.com/show_bug.cgi?id=315151 >> >> My only concern with adding K3B is all the KDE dependencies it drags >> along >> with it. I like the program a lot, but how much added baggage does it >> add? >> >> I wish that the Gnome CD burning software worked as easily and as well >> as >> K3B, but I have yet to find one that does. (They all seem to be >> horribly >> designed from a UI to me.) > > What is wrong with Brasero UI? I find it very similar UI vise when > comparing it to k3b, still I like k3b more because it just works > better for me. > > Do you have some concrete UI issues with Brasero? Have you talked with > some Brasero devels regarding those issues? I have not tried that one. I guess at some point after starting to use K3B I stopped looking at newer apps. I was thinking of whatever Nero ripped off to base their Linux version off of. Ghod that is ugly. From drago01 at gmail.com Fri Dec 28 18:13:49 2007 From: drago01 at gmail.com (drago01) Date: Fri, 28 Dec 2007 19:13:49 +0100 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <1198865128.7175.4.camel@localhost.localdomain> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> <1198865128.7175.4.camel@localhost.localdomain> Message-ID: On Dec 28, 2007 7:05 PM, John (J5) Palmieri wrote: > > On Fri, 2007-12-28 at 19:00 +0100, Valent Turkovic wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > > > Please consider this for Fedora 9 Live CD... > > > > Valent. > > > > -- > > 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 > > While I agree this is useful it is something that should be filed > upstream and fixed in nautilus-cd-burner. It would be pretty easy to > implement. thats already possible .. mount a cd/dvd and right click on it. From johnp at redhat.com Fri Dec 28 18:15:27 2007 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 28 Dec 2007 13:15:27 -0500 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <1198865128.7175.4.camel@localhost.localdomain> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> <1198865128.7175.4.camel@localhost.localdomain> Message-ID: <1198865727.7175.11.camel@localhost.localdomain> On Fri, 2007-12-28 at 13:05 -0500, John (J5) Palmieri wrote: > On Fri, 2007-12-28 at 19:00 +0100, Valent Turkovic wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > > > Please consider this for Fedora 9 Live CD... > > > > Valent. > > > > -- > > 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 > > While I agree this is useful it is something that should be filed > upstream and fixed in nautilus-cd-burner. It would be pretty easy to > implement. Actually looking at it it is already implemented. Just pop in the CD or DVD and right click on the icon. There is an option to copy the disk. If you select teh same DVD drive it is in it will create the iso and then ask you to pop in a DVD-R. If you are asking to be able to do this on a live image that has not been installed to a hard drive then you are pretty much out of luck unless you boot up with the mode where the whole system is loaded into memory. -- John (J5) Palmieri From aph at redhat.com Fri Dec 28 18:19:52 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Dec 2007 18:19:52 +0000 Subject: moto4lin, I give up. In-Reply-To: <1198862236.5905.8.camel@localhost6.localdomain6> References: <18292.58245.440406.888498@zebedee.pink> <1198862236.5905.8.camel@localhost6.localdomain6> Message-ID: <18293.15944.694755.303391@zebedee.pink> Richi Plana writes: > On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote: > > dragonauta x writes: > > > I give up... > > > (to resume: moto4lin doesn't work well with +2 drives, but SVN > > > version does) > > > This is what I got on bugzilla: > > > "I'm sorry, but this is still an upstream issue. The fact > > > that the upstream author has a patch that fixes this problem > > > but is not releasing it in an official release does not make > > > this a packaging issues, IMHO. > > > > > > It is my position that bugs like this need to be fixed by an > > > upstream release, particularly in cases like this. Because > > > upstream fixes help all distributions, and Fedora, > > > effectively, forking it does not. > > > > > > I don't believe it is Fedora's place to be tracking svn. Does > > > the upstream maintainer have a good reason for not having a > > > real release that fixes this? > > > > > > If someone from fedora-devel thinks this should be tracking > > > SVN, they should re-open this and take assignment on the bug." > > > > > > Thanks anyway. > > > > I don't get it. Where's the problem? Upstream refuses to > > produce an update? > > Please don't oversimplify the issue. Just because upstream refuses, for > whatever reason, to come up with a release doesn't mean packagers should > refuse to package up a copy from VCS, particularly if it's been made > reproducible. I dunno. That sounds like a very good reason to me. Otherwise Fedora would have to maintain a fork, which really isn't a good plan. It isn't the job of a Fedora packager to maintain a fork. If it's really so important to get this fixed, it needs to be fixed across all distros. If there hasn't been a release for three years, the package needs to be orphaned or someone who cares needs to start maintaining a fork that can become the new upstream. > Upstream has their own agenda and packagers carry a bigger > responsibility to the PACKAGE'S USERS. If the packager doesn't want > to do the extra work, then say so, and hopefully a comaintainer > will package it. But don't refuse it on principle. > The fact remains that there is a fix and upstream isn't making it > difficult at all to package. So why drag one's feet? If this were a > trivial patch (cosmetic), I'd understand the reluctance. But bugs > which break normal functionality I consider pretty up there. I think we need to know why upstream is not packaging this fix in an official release. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From christoph.wickert at nurfuerspam.de Fri Dec 28 18:19:35 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 28 Dec 2007 19:19:35 +0100 Subject: Broken deps in the stable release are not acceptable Message-ID: <1198865975.3293.41.camel@wicktop.localdomain> Raleigh, we have a problem... python-gammu, which is required by wammu, prevents users from updating to the latest gammu release for several days now. It has already been reported in Bugzilla, see https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more interesting - https://bugzilla.redhat.com/show_bug.cgi?id=425831 This leads me to some questions: 1. Why is # 425831 still in status "New"? It has been reported on Dec 16th and the maintainer already responded to it. 2. What's so difficult to coordinate 2 (3 with wammu) dependent packages? All are owned by the same packager. IMO this should be done in one single update in bodhi. 3. Do we need better training for our maintainers or more documentation in the wiki? The broken deps already appeared in EPEL before they were in F8, so the maintainer should have known that he's breaking something when he did the gammu update in Fedora. 4. When was the testing done? gammu-1.17.0-1.fc8 was built on Dec. 22 11:22:28 MST [1] and hit the updates repo on Dec. 23 22:50:08 [2]. This is less than 36 hours for testing. 5. Why has gammu been pushed directly to updates and not to updates-testing? According to the changelog it was not a security update. Note that I don't want to blame a single person here. I think this is just an example that we really NEED to think about how to avoid such situations in the future? I know there are people on vacation these days, but there are enough people that offered help. Unfortunately they are not allowed to by the ACLs. Any thoughts? Christoph [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966 [2] https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743 From nphilipp at redhat.com Fri Dec 28 18:34:43 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 28 Dec 2007 19:34:43 +0100 Subject: moto4lin, I give up. In-Reply-To: <18293.15944.694755.303391@zebedee.pink> References: <18292.58245.440406.888498@zebedee.pink> <1198862236.5905.8.camel@localhost6.localdomain6> <18293.15944.694755.303391@zebedee.pink> Message-ID: <1198866883.10926.18.camel@gibraltar.str.redhat.com> On Fri, 2007-12-28 at 18:19 +0000, Andrew Haley wrote: > I think we need to know why upstream is not packaging this fix in an > official release. And I think it's probably the package maintainers job to find this out ;-). 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 lesmikesell at gmail.com Fri Dec 28 18:43:46 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 28 Dec 2007 12:43:46 -0600 Subject: moto4lin, I give up. In-Reply-To: <18293.15944.694755.303391@zebedee.pink> References: <18292.58245.440406.888498@zebedee.pink> <1198862236.5905.8.camel@localhost6.localdomain6> <18293.15944.694755.303391@zebedee.pink> Message-ID: <477543E2.2030200@gmail.com> Andrew Haley wrote: > > Please don't oversimplify the issue. Just because upstream refuses, for > > whatever reason, to come up with a release doesn't mean packagers should > > refuse to package up a copy from VCS, particularly if it's been made > > reproducible. > > I dunno. That sounds like a very good reason to me. Otherwise Fedora > would have to maintain a fork, which really isn't a good plan. It > isn't the job of a Fedora packager to maintain a fork. > > If it's really so important to get this fixed, it needs to be fixed > across all distros. If there hasn't been a release for three years, > the package needs to be orphaned or someone who cares needs to start > maintaining a fork that can become the new upstream. Why would upstream's existing sourceforge svn trunk be considered a new fork? -- Les Mikesell lesmikesell at gmail.com From skvidal at fedoraproject.org Fri Dec 28 19:07:29 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 28 Dec 2007 14:07:29 -0500 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198865975.3293.41.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> Message-ID: <1198868849.2079.1.camel@cutter> On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote: > Raleigh, we have a problem... > > python-gammu, which is required by wammu, prevents users from updating > to the latest gammu release for several days now. It has already been > reported in Bugzilla, see > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more > interesting - > https://bugzilla.redhat.com/show_bug.cgi?id=425831 > > This leads me to some questions: > > 1. Why is # 425831 still in status "New"? It has been reported on > Dec 16th and the maintainer already responded to it. It's the holidays and people are doing non-fedora things? I mean it's from dec 16th to the 28th. It's 12 days, I grant you, but if the person(s) is(are) in college then there's a good chance they may be away from their normal work habits or network connections. -sv From laxathom at fedoraproject.org Fri Dec 28 19:25:13 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 28 Dec 2007 15:25:13 -0400 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198865975.3293.41.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> Message-ID: <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> 2007/12/28, Christoph Wickert : > > Raleigh, we have a problem... > > python-gammu, which is required by wammu, prevents users from updating > to the latest gammu release for several days now. It has already been > reported in Bugzilla, see > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more > interesting - > https://bugzilla.redhat.com/show_bug.cgi?id=425831 I fallen on an broken deps on kernel-xen-devel during the update of my F-8 release, why don't talk about too ? Its not the first time we have this kind of trouble. I Agree this should not happen but, ask first why there is a broken deps on some packages and why this happen. This leads me to some questions: > > 1. Why is # 425831 still in status "New"? It has been reported on > Dec 16th and the maintainer already responded to it. > 2. What's so difficult to coordinate 2 (3 with wammu) dependent > packages? All are owned by the same packager. IMO this should be > done in one single update in bodhi. It's not difficult, it's not my first update of gammu collection/dependence package, and it's not the first time a upadte depended release. 3. Do we need better training for our maintainers or more > documentation in the wiki? The broken deps already appeared in > EPEL before they were in F8, so the maintainer should have known > that he's breaking something when he did the gammu update in > Fedora. I think we should set up and automate or web_api to request repo tag for package we wanted to build against fresh released one to build other into koji/mock from repo 4. When was the testing done? gammu-1.17.0-1.fc8 was built on Dec. > 22 11:22:28 MST [1] and hit the updates repo on Dec. 23 22:50:08 > [2]. This is less than 36 hours for testing. For that, we could make a bodhi policy. Cause no rules say all package Must go to testing-update before move to stable one. 5. Why has gammu been pushed directly to updates and not to > updates-testing? According to the changelog it was not a > security update. Why does only security update should go to stable ? Note that I don't want to blame a single person here. I think this is > just an example that we really NEED to think about how to avoid such > situations in the future? I know there are people on vacation these > days, but there are enough people that offered help. Unfortunately they > are not allowed to by the ACLs. I'm not here to blame anyone too but this thread should up many time ago. on differente pacakge that broken yum udpate in the past, not only this one. Any thoughts? > Christoph > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966 > [2] https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743 > > > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmadams at hiwaay.net Fri Dec 28 19:29:27 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 28 Dec 2007 13:29:27 -0600 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <477531FA.1000202@robertoragusa.it> References: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <477531FA.1000202@robertoragusa.it> Message-ID: <20071228192927.GA1196734@hiwaay.net> Once upon a time, Roberto Ragusa said: > But there is another problem which I'm not able to solve easily: > if you try to resolve www.google.com and you have > "search my.corp.com" in /etc/resolv.conf, a query for > www.google.com.my.corp.com will be tried first. > The only solution I know is to use "www.google.com.", > with a final dot, but that would mean changing every domain > in every config (including rewiring my brain to always > append an extra dot :-) ). That would be a bug according to the documentation. If at least 1 (by default) dot appears, the initial query is supposed to be the absolute query. See the man pages for resolv.conf and resolver. I don't see the same behvior (it works the documented way for me). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From berrange at redhat.com Fri Dec 28 19:34:13 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 28 Dec 2007 19:34:13 +0000 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> Message-ID: <20071228193413.GC17600@redhat.com> On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote: > 2007/12/28, Christoph Wickert : > > > > Raleigh, we have a problem... > > > > python-gammu, which is required by wammu, prevents users from updating > > to the latest gammu release for several days now. It has already been > > reported in Bugzilla, see > > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more > > interesting - > > https://bugzilla.redhat.com/show_bug.cgi?id=425831 > > > I fallen on an broken deps on kernel-xen-devel during the update of my F-8 > release, why don't talk about too ? > Its not the first time we have this kind of trouble. This is the first time I've heard about broken deps with kernel-xen-devel - if I'd known I would have ensured it got fixed. Please file a BZ if you hit this kind of problem because if no one reports it it'll never get fixed. > I Agree this should not happen but, ask first why there is a broken deps on > some packages and why this happen. It is no great mystery. People are fallible & make packaging mistakes sometimes. The various automated scripts for sanity checking Fedora repos don't always catch every broken thing because they too are written by people who are fallible. People testing new releases are the final sanity check & we rely on them to report the problems they find in BZ otherwise they lie may undiscovered by the package maintainer forever... 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 johnp at redhat.com Fri Dec 28 19:42:42 2007 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 28 Dec 2007 14:42:42 -0500 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <64b14b300712281012j3548675aida4af4c196364946@mail.gmail.com> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> <1198865128.7175.4.camel@localhost.localdomain> <64b14b300712281012j3548675aida4af4c196364946@mail.gmail.com> Message-ID: <1198870962.7175.20.camel@localhost.localdomain> On Fri, 2007-12-28 at 19:12 +0100, Valent Turkovic wrote: > On 12/28/07, John (J5) Palmieri wrote: > > > > On Fri, 2007-12-28 at 19:00 +0100, Valent Turkovic wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > > > > > > Please consider this for Fedora 9 Live CD... > > > > > > Valent. > > > > > > -- > > > 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 > > > > While I agree this is useful it is something that should be filed > > upstream and fixed in nautilus-cd-burner. It would be pretty easy to > > implement. > > Well at least until upstream doesn't fix this issue there isn't a > reason why fedora users should "suffer" because of that, is it? That is not how things work. Red Hat Fedora only has a subset of upstream developers. In some projects we may be the main developers and others we may have no developers at all. If the bug (like the one you filed bellow) has to do with integrating functionality in upstream releases into Fedora then it is best to file in Fedora. In fact Fedora is a good first place to file things. However if the functionality is something that would benefit from a larger developer base looking at it, we will recommend you file it upstream as given the amount of work Fedora developers have they might not have time to get to it. > Please also consider this RFE which can be easily fixed, but still in > F8 it is not: > https://bugzilla.redhat.com/show_bug.cgi?id=315141 I looked at this and wrote a comment. The gist of it is that this functionality exists and is easy to turn on but is turned off by default, most likely for good reasons. -- John (J5) Palmieri From lkundrak at redhat.com Fri Dec 28 20:06:10 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 28 Dec 2007 21:06:10 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198865975.3293.41.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> Message-ID: <1198872370.8312.41.camel@localhost.localdomain> On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote: > Raleigh, we have a problem... > > python-gammu, which is required by wammu, prevents users from updating > to the latest gammu release for several days now. What strikes me here is that we don't have a tooling that would avoid this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that won't let a package out if it causes a dependency to be unsatisfiable or it itself have an unmet dependency. -- Lubomir Kundrak (Red Hat Security Response Team) From rdieter at math.unl.edu Sat Dec 29 02:01:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Dec 2007 20:01:44 -0600 Subject: Putting K3b back onto the DVDs? References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> Message-ID: Alan wrote: > My only concern with adding K3B is all the KDE dependencies it drags along > with it. I like the program a lot, but how much added baggage does it > add? (At least for non-size-constrained spins, like the DVD one at issue here) Who gives a crap. Use the best tool for the job, who cares which toolkit it uses? -- Rex From jkeating at redhat.com Fri Dec 28 20:11:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Dec 2007 15:11:54 -0500 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198872370.8312.41.camel@localhost.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> <1198872370.8312.41.camel@localhost.localdomain> Message-ID: <20071228151154.5c1bce2f@redhat.com> On Fri, 28 Dec 2007 21:06:10 +0100 Lubomir Kundrak wrote: > What strikes me here is that we don't have a tooling that would avoid > this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that > won't let a package out if it causes a dependency to be unsatisfiable > or it itself have an unmet dependency. The problem continues to be the time it takes to calculate that, particularly when you have to generate multilib sets to ensure you don't break anything in the multilib set. Luke has been working off and on on doing depchecking at some points of a bodhi push cycle, but it's a tough problem to solve. -- 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 Dec 28 20:13:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Dec 2007 15:13:31 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> Message-ID: <20071228151331.6af2f7fb@redhat.com> On Fri, 28 Dec 2007 20:01:44 -0600 Rex Dieter wrote: > Use the best tool for the job, who cares which toolkit it uses? I care when it looks like ass compared to the other apps I have open, doesn't use my font settings, doesn't use the same file selector, etc, etc, 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 ivazqueznet at gmail.com Fri Dec 28 20:18:07 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 28 Dec 2007 15:18:07 -0500 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198872370.8312.41.camel@localhost.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> <1198872370.8312.41.camel@localhost.localdomain> Message-ID: <1198873087.19106.9.camel@ignacio.lan> On Fri, 2007-12-28 at 21:06 +0100, Lubomir Kundrak wrote: > On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote: > > Raleigh, we have a problem... > > > > python-gammu, which is required by wammu, prevents users from updating > > to the latest gammu release for several days now. > > What strikes me here is that we don't have a tooling that would avoid > this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that > won't let a package out if it causes a dependency to be unsatisfiable or > it itself have an unmet dependency. The high-level architecture is in place. All it needs is someone familiar with bodhi and repodata to write the code. https://fedorahosted.org/bodhi/ticket/79 -- 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 fedora at leemhuis.info Fri Dec 28 20:23:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Dec 2007 21:23:45 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <20071228193413.GC17600@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <20071228193413.GC17600@redhat.com> Message-ID: <47755B51.60106@leemhuis.info> On 28.12.2007 20:34, Daniel P. Berrange wrote: > On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote: >> 2007/12/28, Christoph Wickert : >>> Raleigh, we have a problem... >>> >>> python-gammu, which is required by wammu, prevents users from updating >>> to the latest gammu release for several days now. It has already been >>> reported in Bugzilla, see >>> https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more >>> interesting - >>> https://bugzilla.redhat.com/show_bug.cgi?id=425831 Well, the EPEL report (the second one) has not much in common with the Fedora report. Just coincidence afaics. >> I Agree this should not happen but, ask first why there is a broken deps on >> some packages and why this happen. > It is no great mystery. People are fallible & make packaging mistakes sometimes. Agreed, but... > The various automated scripts for sanity checking Fedora repos don't always > catch every broken thing because they too are written by people who are fallible. ...there are afaik no scripts that would have detected such a problem, and that's not good (tm), lead to this specific problem and IMHO should be fixed. A simple diff between the old and the new provides send to the gammu owner my mail might have told him "hmm, maybe other packages depend on that .so file; I should check this with repoquery before I push this to stable"; that might have helped to solve the problem in time. The second big problem: why wasn't this reported earlier? Does nobody use updates-testing? Or did non of the updates-testing users report the problem? Part of this problem maybe: where is the best place to report such issue these days: bodhi comment or bug entry in bugzilla? Cu knurd From jkeating at redhat.com Fri Dec 28 20:22:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Dec 2007 15:22:48 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071228151331.6af2f7fb@redhat.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: <20071228152248.70ebe64b@redhat.com> On Fri, 28 Dec 2007 15:13:31 -0500 Jesse Keating wrote: > I care when it looks like ass compared to the other apps I have open, > doesn't use my font settings, doesn't use the same file selector, etc, > etc, etc... (this coming from somebody who for years used gnome + kmail and often times k3b, but now uses claws-mail and nautilus (and sometimes brasero)) -- 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 vpivaini at cs.helsinki.fi Fri Dec 28 20:48:19 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Fri, 28 Dec 2007 22:48:19 +0200 Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking) Message-ID: <200712282248.21314.vpivaini@cs.helsinki.fi> Hi, I hope this is the correct list for this kind of questions, also sorry for the lengthy mail... Voikko is a free software spellchecker and hyphenator for the Finnish language . Voikko actually works quite well, I'd say it's the best free software has to offer currently in the field of Finnish spell checking. I've taken an interest in packaging Voikko, it's dependencies and the applications based on it that are released by the Voikko project. Libvoikko and it's dependencies malaga and suomi-malaga (packaged as malaga-suomi-voikko) are already in Fedora. The next application to package is tmispell-voikko, but as packaging is quite new to me, I've found this one a bit more difficult than some of the previous packages. The main problem is this: the package provides a binary /usr/bin/tmispell, which is intended to be "a transparent wrapper around Ispell", so that it does the spell checking by itself if you call it with Finnish and calls ispell otherwise. The README says that tmispell should be installed to /usr/bin/ispell and the real ispell executable should be moved to e.g. /usr/bin/ispell.real. Then the location of the real ispell should be set in the configuration file of tmispell-voikko. In Fedora /usr/bin/ispell is provided by the aspell package and I assume it's not good packaging to move around files that belong to other packages. But placing tmispell to /usr/bin/ispell is apparently the only way KDE (and possibly other ispell compatible programs) can use tmispell. The Voikko main maintainer had this suggestion: as /usr/bin/ispell in Fedora is a script, we could place tmispell to /usr/bin/tmispell and modify the ispell script to call tmispell when Finnish is used. What do you think? If we do this, it'll probably be rawhide-only stuff? Even if I can't place tmispell to /usr/bin/ispell or edit the ispell script in F-7 and F-8, I still think it would be nice to have tmispell "as such" in these releases as well. At least tmispell could be used as a CLI frontend to libvoikko, even if programs like KDE can't see it. Enchant people please note: the tmispell-voikko package also provides a Voikko plugin for Enchant, which I've named enchant-voikko. The plugin will probably be in the next stable enchant release as well, but I believe it won't hurt to package it separately until that's released. This would hopefully add support for Finnish spell checking in rawhide's KDE4, among others, I haven't had a chance to test it, though. I haven't yet made a review request for this package, I thought it would be better to discuss these issues first on the list instead of giving them to a single reviewer to solve. The spec file is at The SRPM is at I'll also post the spec file here for easier comments. I'm awaiting your feedback :) Name: tmispell-voikko Version: 0.6.3 Release: 0.1%{?dist} Summary: An Ispell compatible front-end for spell-checking modules Group: System Environment/Libraries License: GPLv2+ URL: http://voikko.sourceforge.net/ Source0: http://downloads.sourceforge.net/voikko/%{name}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: libvoikko-devel ncurses-devel gettext pkgconfig glib2-devel enchant-devel %description Tmispell is an Ispell compatible front-end for spell-checking modules. To do the actual spell-checking for Finnish language it uses the spell-checking system Voikko. # FIXME: /usr/bin/ispell should be a symlink to /usr/bin/tmispell and the real # ispell should be renamed to e.g. /usr/bin/ispell.real for KDE etc. to work. # The other option would be to modify /usr/bin/ispell to call # /usr/bin/tmispell when it's called with Finnish. If neither of these can be # done, it's worth it to have /usr/bin/tmispell as a command line client for # Voikko. %package -n enchant-voikko Summary: Voikko spellchecker support for Enchant Group: Development/Libraries %description -n enchant-voikko Voikko spellchecker support for Enchant. %prep %setup -q %build %configure --disable-static make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p" find $RPM_BUILD_ROOT -name '*.la' -exec rm -f {} ';' # Install the configuration file sed -i -e 's/ispell.real/ispell/' tmispell.conf.example install -Dpm 0644 tmispell.conf.example $RPM_BUILD_ROOT%{_sysconfdir}/tmispell.conf # Fake Finnish dictionary for ispell clients. These won't actually work for # KDE etc. unless the binary is in /usr/bin/ispell. These are always installed # into %{_prefix}/lib/ispell/ even though it's an rpmlint error because my # testing shows that KDE recognizes them from there but not from /usr/share. install -dm 755 %{buildroot}%{_prefix}/lib/ispell touch %{buildroot}%{_prefix}/lib/ispell/suomi.{hash,aff} %find_lang %{name} %clean rm -rf $RPM_BUILD_ROOT %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %files -f %{name}.lang %defattr(-,root,root,-) %doc ChangeLog NEWS README README.fi %config(noreplace) %{_sysconfdir}/tmispell.conf %{_mandir}/man1/tmispell* %{_mandir}/man5/tmispell* %{_bindir}/tmispell %{_prefix}/lib/ispell %files -n enchant-voikko %{_libdir}/enchant/libenchant_voikko*.so.* %{_libdir}/enchant/libenchant_voikko.so %changelog * Mon Nov 26 2007 Ville-Pekka Vainio - 0.6.3-0.1 - Initial package -- Ville-Pekka Vainio From alan at clueserver.org Fri Dec 28 20:56:29 2007 From: alan at clueserver.org (Alan) Date: Fri, 28 Dec 2007 12:56:29 -0800 (PST) Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> Message-ID: <30471.12.172.32.236.1198875389.squirrel@clueserver.org> > Alan wrote: > >> My only concern with adding K3B is all the KDE dependencies it drags >> along >> with it. I like the program a lot, but how much added baggage does it >> add? > > (At least for non-size-constrained spins, like the DVD one at issue here) > > Who gives a crap. > > Use the best tool for the job, who cares which toolkit it uses? If space is a limitation, you *do* give a crap. There have been other solutions proposed that solve the problem in Gnome without having to use a KDE app, so the situation is moot anyways. From limb at jcomserv.net Fri Dec 28 21:16:03 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 28 Dec 2007 15:16:03 -0600 (CST) Subject: moto4lin, I give up. In-Reply-To: <1198859038.19106.6.camel@ignacio.lan> References: <18292.58245.440406.888498@zebedee.pink> <1198854607.10926.16.camel@gibraltar.str.redhat.com> <1198859038.19106.6.camel@ignacio.lan> Message-ID: <9642.63.85.68.164.1198876563.squirrel@mail.jcomserv.net> > On Fri, 2007-12-28 at 16:10 +0100, Nils Philippsen wrote: >> On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote: >> >> > I don't get it. Where's the problem? Upstream refuses to produce an >> > update? >> >> Upstream seems reluctant to release new versions, the last one is from >> March 2005. > > A failure to release an update in almost 3 years is usually the result > of one of three things: > > 1) The software is finally stable and doesn't need frequent updates. > 2) The maintainer has no faith in the software in general. > 3) The maintainer doesn't actually want (or is pathologically unable) to > maintain the software. > > Since the first obviously isn't true, one of the latter two must be. In > my mind both of those cases are valid reasons for eventually orphaning > the package if the situation doesn't improve. I for one see no reason why a well-tested SVN version can't be packaged. See gnubg. The stable release is defined as a particular SVN version, not a particular tarball. Some upstreams, like xmoto's for example, will provide you the SVN version numbers to allow you to take two check outs and create your own patches. I did this for xmoto 0.3.3, so we could fix a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of functionality. > -- > Ignacio Vazquez-Abrams > > PLEASE don't CC me; I'm already subscribed > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From Lam at Lam.pl Fri Dec 28 21:38:47 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 28 Dec 2007 22:38:47 +0100 Subject: moto4lin, I give up. In-Reply-To: <9642.63.85.68.164.1198876563.squirrel@mail.jcomserv.net> References: <18292.58245.440406.888498@zebedee.pink> <1198854607.10926.16.camel@gibraltar.str.redhat.com> <1198859038.19106.6.camel@ignacio.lan> <9642.63.85.68.164.1198876563.squirrel@mail.jcomserv.net> Message-ID: <20071228223847.7b434f72@pensja.lam.pl> Dnia 2007-12-28, o godz. 15:16:03 "Jon Ciesla" napisa?(a): > Some upstreams, like xmoto's for example, will > provide you the SVN version numbers to allow you to take two check outs > and create your own patches. I did this for xmoto 0.3.3, so we could fix > a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of > functionality. Now imagine you have 100 bugs, there's never going to be 0.3.4 and 0.4 or 1.0 is going to come out in 2011. Even with an upstream giving you commit numbers, you'll end up either: - having 100 patches, half of them not SVN patches (but merged from a few dependant commits), - really forking and releasing your own tarball (not a packager's business), - releasing a snapshot and dealing with its new bugs, which could end up causing more trouble for the users and you. With one simple (one small patch published by upstream) bug and active upstream development of a "stable" branch, there's no problem. Moto4lin could be different, however. If its maintainers don't want to deal with patching it or releasing snapshots, they do it for a reason. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From limb at jcomserv.net Fri Dec 28 21:45:48 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 28 Dec 2007 15:45:48 -0600 (CST) Subject: moto4lin, I give up. In-Reply-To: <20071228223847.7b434f72@pensja.lam.pl> References: <18292.58245.440406.888498@zebedee.pink> <1198854607.10926.16.camel@gibraltar.str.redhat.com> <1198859038.19106.6.camel@ignacio.lan> <9642.63.85.68.164.1198876563.squirrel@mail.jcomserv.net> <20071228223847.7b434f72@pensja.lam.pl> Message-ID: <32094.63.85.68.164.1198878348.squirrel@mail.jcomserv.net> > Dnia 2007-12-28, o godz. 15:16:03 "Jon Ciesla" > napisa??(a): > >> Some upstreams, like xmoto's for example, will >> provide you the SVN version numbers to allow you to take two check outs >> and create your own patches. I did this for xmoto 0.3.3, so we could >> fix >> a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of >> functionality. > Now imagine you have 100 bugs, there's never going to be 0.3.4 and 0.4 or > 1.0 > is going to come out in 2011. Even with an upstream giving you commit > numbers, > you'll end up either: > - having 100 patches, half of them not SVN patches (but merged from a few > dependant commits), > - really forking and releasing your own tarball (not a packager's > business), > - releasing a snapshot and dealing with its new bugs, which could end up > causing more trouble for the users and you. > > With one simple (one small patch published by upstream) bug and active > upstream development of a "stable" branch, there's no problem. Moto4lin > could > be different, however. If its maintainers don't want to deal with patching > it > or releasing snapshots, they do it for a reason. Agreed, with this case it was two showstopper bugs, and they were still working on a few new features for the next release, so it made sense. It may or may not work here, but it's worth looking into. Even with dependant commits, svn diff x:y could be a big help. > Lam > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From mail at robertoragusa.it Fri Dec 28 22:01:29 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Fri, 28 Dec 2007 23:01:29 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071228192927.GA1196734@hiwaay.net> References: <20071203173704.GA10615@evileye.atkac.englab.brq.redhat.com> <1196704588.21151.10.camel@localhost.localdomain> <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <477531FA.1000202@robertoragusa.it> <20071228192927.GA1196734@hiwaay.net> Message-ID: <47757239.20307@robertoragusa.it> Chris Adams wrote: > Once upon a time, Roberto Ragusa said: >> But there is another problem which I'm not able to solve easily: >> if you try to resolve www.google.com and you have >> "search my.corp.com" in /etc/resolv.conf, a query for >> www.google.com.my.corp.com will be tried first. >> The only solution I know is to use "www.google.com.", >> with a final dot, but that would mean changing every domain >> in every config (including rewiring my brain to always >> append an extra dot :-) ). > > That would be a bug according to the documentation. If at least 1 (by > default) dot appears, the initial query is supposed to be the absolute > query. See the man pages for resolv.conf and resolver. I don't see the > same behvior (it works the documented way for me). Hmm, I was sure to have often seen this stuff in wireshark logs. Done some tests, with following results. If you have a dot at the end, it's an absolute query and nothing else. If you don't have a dot at the end and you are below ndots threshold, suffixed queries and nothing else. If you don't have a dot at the end and you are at/above ndots threshold, absolute query and (on failure) then suffixed queries. So, you're right in correcting me: in normal conditions the resolver is not leaking info about the domain I visit to my.corp.com DNS servers. But it indeed happens when I mistype www.google.xom for www.google.com, as it attempts www.google.xom.my.corp.com. It would be nice to have a hard ndots option: "only try suffixes if less than ndots dots" Rethinking about it... ndots currently can avoid the absolute query. No way to avoid the suffixed queries. What about having two options: - mindotsforabsolute (a.k.a. ndots, default 1) - maxdotsforsuffixed (new option to avoid suffixed queries, default infinite, but in my case I'd like to put a 0 here) What is the right place to propose that as an enhancement? Best regards. -- Roberto Ragusa mail at robertoragusa.it From cmadams at hiwaay.net Fri Dec 28 22:12:06 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 28 Dec 2007 16:12:06 -0600 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <47757239.20307@robertoragusa.it> References: <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <477531FA.1000202@robertoragusa.it> <20071228192927.GA1196734@hiwaay.net> <47757239.20307@robertoragusa.it> Message-ID: <20071228221206.GE931347@hiwaay.net> Once upon a time, Roberto Ragusa said: > Rethinking about it... > ndots currently can avoid the absolute query. > No way to avoid the suffixed queries. I think: $ export RES_DEFNAMES=0 will do it (see man resolver). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Fri Dec 28 20:48:04 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Dec 2007 20:48:04 +0000 (UTC) Subject: Broken deps in the stable release are not acceptable References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <20071228193413.GC17600@redhat.com> <47755B51.60106@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > The second big problem: why wasn't this reported earlier? Does nobody > use updates-testing? Or did non of the updates-testing users report the > problem? Because the update never went to testing, it was pushed directly to stable. Kevin Kofler From kevin.kofler at chello.at Fri Dec 28 21:13:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Dec 2007 21:13:44 +0000 (UTC) Subject: Broken deps in the stable release are not acceptable References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> Message-ID: Xavier Lamien fedoraproject.org> writes: > Why does only security update? should go to stable ? It's not a hard rule, but normally updates which aren't security fixes or critical bugfixes should go to testing first so problems like this one can be caught. Kevin Kofler From rdieter at math.unl.edu Sat Dec 29 03:56:59 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Dec 2007 21:56:59 -0600 Subject: Putting K3b back onto the DVDs? References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: Jesse Keating wrote: > On Fri, 28 Dec 2007 20:01:44 -0600 > Rex Dieter wrote: > >> Use the best tool for the job, who cares which toolkit it uses? > > I care when it looks like ass compared to the other apps I have open, > doesn't use my font settings, doesn't use the same file selector, etc, > etc, etc... Tangential issue, more about toolkit integration issues... (yes, it could be better). Otherwise we're left with limiting the DVD content and/or default apps to gnome/gtk-only ones, which I'd hope wasn't the intent of your comment. -- Rex From andreas.bierfert at lowlatency.de Fri Dec 28 22:58:03 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 28 Dec 2007 23:58:03 +0100 Subject: Update wine In-Reply-To: <20071228133044.4b3b6963@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227001903.4cafd812@alkaid.a.lan> <93d66b780712262001y1f1b30xe023f4768c66a656@mail.gmail.com> <20071227102106.1a9da15a@alkaid.a.lan> <1198762070.4830.3.camel@gilboa-work-dev.localdomain> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> <20071227215115.274bc3a8@alkaid.a.lan> <20071228110621.78daa14e@alkaid.a.lan> <4774E814.2080305@gmail.com> <20071228133044.4b3b6963@alkaid.a.lan> Message-ID: <20071228235803.36fe912f@alkaid.a.lan> On Fri, 28 Dec 2007 13:30:44 +0100 Andreas Bierfert wrote: > Will be added in the next build. 0.9.52 has been build and should hit updates-testing soon. Regards, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mail at robertoragusa.it Fri Dec 28 23:41:38 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sat, 29 Dec 2007 00:41:38 +0100 Subject: BIND will completely drop D-BUS dynamic forwarders table support In-Reply-To: <20071228221206.GE931347@hiwaay.net> References: <20071204132031.GA3250@traged.englab.brq.redhat.com> <475602B4.9020109@tmus.dk> <20071205095817.46be4d87@dhcp03.addix.net> <1196863948.4124.8.camel@space-ghost.verbum.private> <20071205172630.GB10961@nostromo.devel.redhat.com> <1196888695.2963.12.camel@space-ghost.verbum.private> <1196890738.17277.22.camel@localhost.localdomain> <477531FA.1000202@robertoragusa.it> <20071228192927.GA1196734@hiwaay.net> <47757239.20307@robertoragusa.it> <20071228221206.GE931347@hiwaay.net> Message-ID: <477589B2.40905@robertoragusa.it> Chris Adams wrote: > Once upon a time, Roberto Ragusa said: >> Rethinking about it... >> ndots currently can avoid the absolute query. >> No way to avoid the suffixed queries. > > I think: > > $ export RES_DEFNAMES=0 > > will do it (see man resolver). This would always disable defnames when no dot is present. Thanks for the hint, but it's not what I'm looking for. On the contrary, I want to disable defnames when dots are present. Apparently impossible to achieve. Best regards. -- Roberto Ragusa mail at robertoragusa.it From kevin.kofler at chello.at Fri Dec 28 22:51:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Dec 2007 22:51:41 +0000 (UTC) Subject: moto4lin, I give up. References: Message-ID: dragonauta x gmail.com> writes: > This is what I got on bugzilla:"I'm sorry, but this is still an upstream > issue. ?The fact that the upstream author has a patch that fixes this problem > but is not releasing it in anofficial release does not make this a packaging > issues, IMHO. IMHO it does. Maintainers: In a situation like this, if there's a patch from upstream, please apply it! If upstream only provides the fix in the form of a commit to SVN trunk, first try applying the diff from SVN to the release, sometimes it just works. If it doesn't apply, you have 3 options: 1. Try asking upstream (nicely) for a backport which applies to the stable release. Keep in mind though that the upstream author(s) might be very busy and do(es) not necessarily have the time to do backports. 2. Backport the patch yourself. This is often fairly easy. 3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real release for ages, this may well be the best option, however be careful, as the snapshot may also include regressions. It is usually a good idea to run the idea by upstream first, as for one they are likely to know about any regressions in the snapshots, and secondly, unfortunately some uncooperative upstreams may also get upset and hostile if you package snapshots (whereas others will even ask you to do just that, also depending on the state the code in SVN is in, thus the importance of asking). If you have a ready-to-apply patch or if you use options 1 or 2, please don't patch the source tarball directly, use Patch0 (or Patch1, ...). If you use option 3, make your SVN checkout the new Source0. > It is my position that bugs like this need to be fixed by an upstream > release, particularly in cases like this. ?Because upstream fixes help all > distributions,and Fedora, effectively, forking it does not. First of all: It isn't "forking" to backport a patch which is already in the upstream SVN trunk. It's even less "forking" to package something straight from the SVN trunk. Secondly: Other distros will eventually get the fix because it's already in SVN trunk, so it will be in the next release. And if they want it first, they can backport it, just as you can. Notwithstanding all the above: It would of course be better for all distros, including Fedora, if there was a new stable release with the fix. However, as I said above, upstream may be too busy to do backports, and unwilling to release from the current state of the SVN trunk for reasons unrelated to the fix (regressions etc.). So sometimes, backporting is really the only option. > I don't believe it is Fedora's place to be tracking svn. Then backport the fix. If it doesn't apply to the stable version and you can't get it to apply, let us see the BZ report and the fix and I'm sure one of us will be able to help you. > Does the upstream maintainer have a good reason for not having a real release > that fixes this? You have to ask this question to upstream themselves. :-) Kevin Kofler From triad at df.lth.se Fri Dec 28 23:59:05 2007 From: triad at df.lth.se (Linus Walleij) Date: Sat, 29 Dec 2007 00:59:05 +0100 (CET) Subject: /dev/null is permission 400 in rawhide Message-ID: This problem came in today: bash-3.2$ ls -al /dev/null cr-------- 1 root root 1, 3 28 dec 21.32 /dev/null Anyone else hit by it and knows the reason for? (Nothing much else than rootshell works, manual chmod to the rescue.) I suspect the glibc update, but I have actually no idea what update caused this. Linus From rdieter at math.unl.edu Sat Dec 29 03:55:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Dec 2007 21:55:50 -0600 Subject: Putting K3b back onto the DVDs? References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <30471.12.172.32.236.1198875389.squirrel@clueserver.org> Message-ID: Alan wrote: >> (At least for non-size-constrained spins, like the DVD one at issue here) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Who gives a crap. >> >> Use the best tool for the job, who cares which toolkit it uses? > > If space is a limitation, you *do* give a crap. See above. > There have been other solutions proposed that solve the problem in Gnome > without having to use a KDE app, so the situation is moot anyways. We're not talking about the Gnome/desktop spin here, but the DVD install-set. -- Rex From darrellpf at gmail.com Sat Dec 29 00:05:05 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 28 Dec 2007 16:05:05 -0800 Subject: /dev/null is permission 400 in rawhide In-Reply-To: References: Message-ID: On Dec 28, 2007 3:59 PM, Linus Walleij wrote: > This problem came in today: > > bash-3.2$ ls -al /dev/null > cr-------- 1 root root 1, 3 28 dec 21.32 /dev/null > > Anyone else hit by it and knows the reason for? (Nothing much else > than rootshell works, manual chmod to the rescue.) > > I suspect the glibc update, but I have actually no idea what update caused > this. Same problem here this morning. I only noticed it when Thunderbird wouldn't start for me. Same solution too. It wasn't the glibc update because I didn't install it. I usually wait a couple of days on that one just to be safe. I looked at the last couple of days of package updates (there haven't been many with the holidays) but I didn't see any other obvious candidates. darrell From mitr at volny.cz Sat Dec 29 00:10:28 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 29 Dec 2007 01:10:28 +0100 Subject: /dev/null is permission 400 in rawhide In-Reply-To: References: Message-ID: <47759074.9080606@volny.cz> Hello, Linus Walleij napsal(a): > This problem came in today: > > bash-3.2$ ls -al /dev/null > cr-------- 1 root root 1, 3 28 dec 21.32 /dev/null This is #426934. Eric Paris found the problem, I'm building an updated audit package right now. Mirek From kevin.kofler at chello.at Fri Dec 28 22:56:32 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Dec 2007 22:56:32 +0000 (UTC) Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking) References: <200712282248.21314.vpivaini@cs.helsinki.fi> Message-ID: Ville-Pekka Vainio cs.helsinki.fi> writes: > Enchant people please note: the tmispell-voikko package also provides a > Voikko plugin for Enchant, which I've named enchant-voikko. The plugin will > probably be in the next stable enchant release as well, but I believe it > won't hurt to package it separately until that's released. This would > hopefully add support for Finnish spell checking in rawhide's KDE4, among > others, I haven't had a chance to test it, though. And in KSpell2 in Rawhide's KDE 3. :-) http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs3/devel/kdelibs-3.5.8-kspell2-enchant.patch?rev=1.1&view=markup > In Fedora /usr/bin/ispell is provided by the aspell package and I assume it's > not good packaging to move around files that belong to other packages. But > placing tmispell to /usr/bin/ispell is apparently the only way KDE (and > possibly other ispell compatible programs) can use tmispell. For the legacy KSpell interface which uses command-line spellcheckers, we could just add support for tmispell like I added support for hunspell: http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs3/devel/kdelibs-3.5.8-kspell-hunspell.patch?rev=1.1&view=markup As you can see from the above patch, it isn't that hard to patch in support for an additional executable Kevin Kofler From kevin.kofler at chello.at Sat Dec 29 00:04:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Dec 2007 00:04:42 +0000 (UTC) Subject: Putting K3b back onto the DVDs? References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <30471.12.172.32.236.1198875389.squirrel@clueserver.org> Message-ID: Alan clueserver.org> writes: > If space is a limitation, you *do* give a crap. But there's plenty of space left on the DVD! Remember I'm not talking about the GNOME live CD (nor about the KDE live CD which already includes it). > There have been other solutions proposed that solve the problem in Gnome > without having to use a KDE app, so the situation is moot anyways. No, it's not moot! The DVD also contains KDE, and it is the only "supported" way to upgrade a previous Fedora installation, so not having K3b on the DVD is bad for KDE users (and for GNOME users who are using K3b anyway). Kevin Kofler From christoph.wickert at nurfuerspam.de Sat Dec 29 00:55:08 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 29 Dec 2007 01:55:08 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> Message-ID: <1198889708.3293.86.camel@wicktop.localdomain> Am Freitag, den 28.12.2007, 15:25 -0400 schrieb Xavier Lamien: > > > 2007/12/28, Christoph Wickert : > Raleigh, we have a problem... > > python-gammu, which is required by wammu, prevents users from > updating > to the latest gammu release for several days now. It has > already been > reported in Bugzilla, see > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even > more > interesting - > https://bugzilla.redhat.com/show_bug.cgi?id=425831 > > > I fallen on an broken deps on kernel-xen-devel during the update of my > F-8 release, why don't talk about too ? Because I never was affected by this one and did not even hear of it before. IMHO a devel package is not that important as an application. Most users could simply remove the package without loosing functionality, this is different with wammu. BTW: Are you talking about an upgrade from F7 to F8 or about an update during the release? > Its not the first time we have this kind of trouble. Yes, and this is the reason why I wrote my mail. We NEED to look for ways that this CANNOT happen, because it really is a showstopper that frightens people to use Fedora. At least I have heard people complaining about this over and over again, for example at fedoraforum.de > > I Agree this should not happen but, ask first why there is a broken > deps on some packages and why this happen. I guess most of the time it happens because of a lack of communication and coordination. But if all packages are owned by the same person this reason IMO is not valid. > > This leads me to some questions: > > 1. Why is # 425831 still in status "New"? It has been > reported on Dec 16th and the maintainer already responded to > it. > 2. What's so difficult to coordinate 2 (3 with wammu) > dependent packages? All are owned by the same packager. IMO > this should be done in one single update in bodhi. > > It's not difficult, it's not my first update of gammu > collection/dependence package, and it's not the first time a upadte > depended release. Then you should have known what happens... ;) Once again: I'm not here to blame someone. > > 3. Do we need better training for our maintainers or > more > documentation in the wiki? The broken deps already > appeared in EPEL before they were in F8, so the maintainer > should have known that he's breaking something when he did the > gammu update in Fedora. > > I think we should set up and automate or web_api to request repo tag > for package we wanted to build against fresh released one > to build other into koji/mock from repo I agree that the current situation is not optimal for the packagers because the required packages have to be added to buildroot manually by rel-eng. But AFAIK we do have the possibility of chain-builds now. > > 4. When was the testing done? gammu-1.17.0-1.fc8 was > built on Dec. 22 11:22:28 MST [1] and hit the updates repo on > Dec. 23 22:50:08 [2]. This is less than 36 hours for testing. > > For that, we could make a bodhi policy. Cause no rules say all package > Must go to testing-update before move to stable one. You are right. I thought we already had policy for that but the wiki says: "If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead." IMO this is wrong, it should only be allowed for security updates. > > 5. Why has gammu been pushed directly to updates and not > to > updates-testing? According to the changelog it was not > a > security update. > > Why does only security update should go to stable ? Because problems like this case most likely would have been realized in testing before they annoy a large number of users. Pushing updates directly to stable renders updates-testing useless. > > Note that I don't want to blame a single person here. I think > this is just an example that we really NEED to think about how > to avoid such situations in the future? I know there are > people on vacation these days, but there are enough people > that offered help. Unfortunately they are not allowed to by > the ACLs. > > I'm not here to blame anyone too but this thread should up many time > ago. on differente pacakge that broken yum udpate in the past, not > only this one. Let's not talk about the past, let's talk about how to avoid this in the future. There are several ways we could try to accomplish this: Some are more strict policies, others are more technical, but most important I think we should get rid of the "don't touch other peoples packages"-attitude. If someone fixed that within one or two days I wouldn't have written my previous mail. Christoph > > > > Any thoughts? > Christoph > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966 > [2] > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743 > From christoph.wickert at nurfuerspam.de Sat Dec 29 00:56:06 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 29 Dec 2007 01:56:06 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <47755B51.60106@leemhuis.info> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <20071228193413.GC17600@redhat.com> <47755B51.60106@leemhuis.info> Message-ID: <1198889766.3293.88.camel@wicktop.localdomain> Am Freitag, den 28.12.2007, 21:23 +0100 schrieb Thorsten Leemhuis: > On 28.12.2007 20:34, Daniel P. Berrange wrote: > > On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote: > >> 2007/12/28, Christoph Wickert : > >>> Raleigh, we have a problem... > >>> > >>> python-gammu, which is required by wammu, prevents users from updating > >>> to the latest gammu release for several days now. It has already been > >>> reported in Bugzilla, see > >>> https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more > >>> interesting - > >>> https://bugzilla.redhat.com/show_bug.cgi?id=425831 > > Well, the EPEL report (the second one) has not much in common with the > Fedora report. Just coincidence afaics. You are correct, I did not look carefully enough. But IMO it's the same problem, no matter if it is libGammu.so.1 or libGammu.so.2. > >> I Agree this should not happen but, ask first why there is a broken deps on > >> some packages and why this happen. > > It is no great mystery. People are fallible & make packaging mistakes sometimes. > > Agreed, but... > > > The various automated scripts for sanity checking Fedora repos don't always > > catch every broken thing because they too are written by people who are fallible. > > ...there are afaik no scripts that would have detected such a problem, > and that's not good (tm), lead to this specific problem and IMHO should > be fixed. A simple diff between the old and the new provides send to the > gammu owner my mail might have told him "hmm, maybe other packages > depend on that .so file; I should check this with repoquery before I > push this to stable"; that might have helped to solve the problem in time. > > The second big problem: why wasn't this reported earlier? Does nobody > use updates-testing? Or did non of the updates-testing users report the > problem? As Kevin and me already wrote this update went directly to stable > Part of this problem maybe: where is the best place to report > such issue these days: bodhi comment or bug entry in bugzilla? Not sure what is better, but in this case there has been both: two comments in bodhi and two comments in the bugzilla bugs. > > Cu > knurd > Christoph From kevin.kofler at chello.at Sat Dec 29 00:26:20 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Dec 2007 00:26:20 +0000 (UTC) Subject: Putting K3b back onto the DVDs? References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > I care when it looks like ass compared to the other apps I have open, That's what Bluecurve is for. ;-) We'd love having a Nodoka theme available for KDE too, but we're fairly busy already, so there isn't one yet. (We just didn't have the time to work on one.) Thus Bluecurve (and Quarticurve for Qt 4) is the best we can offer for a unified look. I also disagree with the assertion that Plastik "looks like ass". ;-) It just looks different (and that's the main problem we have to solve, I think moving away from Bluecurve was a mistake). > doesn't use my font settings, I agree our community (especially the upstream projects) needs to work on not having to set up everything twice though. (But setting the fonts the same way in both environments is possible, of course.) > doesn't use the same file selector That's because it uses a better one. ;-) More seriously, there are solutions being worked on for the standard dialog (especially file selector) issue at freedesktop.org and elsewhere, unfortunately nothing which got widespread adoption yet. :-( But surely having to write every single application twice, once with each toolkit, is not the real solution! Kevin Kofler (comaintaining KDE as well as the GTK+-based XChat and using XChat on KDE all the time) PS: All this is not a reason not to offer K3b as an option on the DVD. I'm not asking for it to be installed by default, just to be there! From christoph.wickert at nurfuerspam.de Sat Dec 29 00:58:08 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 29 Dec 2007 01:58:08 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198868849.2079.1.camel@cutter> References: <1198865975.3293.41.camel@wicktop.localdomain> <1198868849.2079.1.camel@cutter> Message-ID: <1198889888.3293.91.camel@wicktop.localdomain> Am Freitag, den 28.12.2007, 14:07 -0500 schrieb seth vidal: > On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote: > > Raleigh, we have a problem... > > > > python-gammu, which is required by wammu, prevents users from updating > > to the latest gammu release for several days now. It has already been > > reported in Bugzilla, see > > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more > > interesting - > > https://bugzilla.redhat.com/show_bug.cgi?id=425831 > > > > This leads me to some questions: > > > > 1. Why is # 425831 still in status "New"? It has been reported on > > Dec 16th and the maintainer already responded to it. > > It's the holidays and people are doing non-fedora things? > > I mean it's from dec 16th to the 28th. It's 12 days, I grant you, but if > the person(s) is(are) in college then there's a good chance they may be > away from their normal work habits or network connections. That's why I wrote "I know there are people on vacation these days", but IMO a packager should change a bug's status to assigned if he knows about the problem and he promised to fix it. If someone is 'offline' for a while, other people should be allowed to touch his packages. > > -sv Christoph From kevin.kofler at chello.at Sat Dec 29 01:09:06 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Dec 2007 01:09:06 +0000 (UTC) Subject: Broken deps in the stable release are not acceptable References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> Message-ID: Christoph Wickert nurfuerspam.de> writes: > You are right. I thought we already had policy for that but the wiki > says: > "If you feel that community testing is unnecessary for your update, you > can choose to push it straight to the stable fedora-updates repository > instead." > > IMO this is wrong, it should only be allowed for security updates. It should also stay allowed for critical regression fixes at the very least. Unfortunately, sometimes updates slip through testing despite causing serious issues. For example, an SDL update caused _any_ build against SDL-devel to fail (because SDL-config.h was corrupted by a trivial typo in the specfile which was missed during testing). We really want the fix to such regressions to go to stable as quickly as possible, not to have to go to testing first. In this case though, there wasn't really any reason to bypass testing, was there? Kevin Kofler From christoph.wickert at nurfuerspam.de Sat Dec 29 01:27:53 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 29 Dec 2007 02:27:53 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> Message-ID: <1198891673.3293.97.camel@wicktop.localdomain> Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler: > Christoph Wickert nurfuerspam.de> writes: > > You are right. I thought we already had policy for that but the wiki > > says: > > "If you feel that community testing is unnecessary for your update, you > > can choose to push it straight to the stable fedora-updates repository > > instead." > > > > IMO this is wrong, it should only be allowed for security updates. > > It should also stay allowed for critical regression fixes at the very least. > Unfortunately, sometimes updates slip through testing despite causing serious > issues. For example, an SDL update caused _any_ build against SDL-devel to fail > (because SDL-config.h was corrupted by a trivial typo in the specfile which was > missed during testing). We really want the fix to such regressions to go to > stable as quickly as possible, not to have to go to testing first. I completely agree with you. Maybe we could say that updates are allowed to bypass testing if they fix a) serious bugs b) bugs marked as "urgent" c) broken deps For c) I think only plain rebuilds should be allowed. If the broken deps are fixed by updating to a newer version the new package should be tested again, at least for one or two days. Christoph From sundaram at fedoraproject.org Sat Dec 29 01:32:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Dec 2007 07:02:13 +0530 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198891673.3293.97.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> Message-ID: <4775A39D.4000307@fedoraproject.org> Christoph Wickert wrote: > Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler: >> Christoph Wickert nurfuerspam.de> writes: >>> You are right. I thought we already had policy for that but the wiki >>> says: >>> "If you feel that community testing is unnecessary for your update, you >>> can choose to push it straight to the stable fedora-updates repository >>> instead." >>> >>> IMO this is wrong, it should only be allowed for security updates. >> It should also stay allowed for critical regression fixes at the very least. >> Unfortunately, sometimes updates slip through testing despite causing serious >> issues. For example, an SDL update caused _any_ build against SDL-devel to fail >> (because SDL-config.h was corrupted by a trivial typo in the specfile which was >> missed during testing). We really want the fix to such regressions to go to >> stable as quickly as possible, not to have to go to testing first. > > I completely agree with you. Maybe we could say that updates are allowed > to bypass testing if they fix > a) serious bugs > b) bugs marked as "urgent" > c) broken deps b) isn't a good criteria since anybody can mark any bug as urgent. If the priority field in bugzilla is restricted to package maintainers and triagers, I would agree with you. Rahul From berrange at redhat.com Sat Dec 29 01:48:35 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 29 Dec 2007 01:48:35 +0000 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198891673.3293.97.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> Message-ID: <20071229014835.GB27783@redhat.com> On Sat, Dec 29, 2007 at 02:27:53AM +0100, Christoph Wickert wrote: > > Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler: > > Christoph Wickert nurfuerspam.de> writes: > > > You are right. I thought we already had policy for that but the wiki > > > says: > > > "If you feel that community testing is unnecessary for your update, you > > > can choose to push it straight to the stable fedora-updates repository > > > instead." > > > > > > IMO this is wrong, it should only be allowed for security updates. > > > > It should also stay allowed for critical regression fixes at the very least. > > Unfortunately, sometimes updates slip through testing despite causing serious > > issues. For example, an SDL update caused _any_ build against SDL-devel to fail > > (because SDL-config.h was corrupted by a trivial typo in the specfile which was > > missed during testing). We really want the fix to such regressions to go to > > stable as quickly as possible, not to have to go to testing first. > > I completely agree with you. Maybe we could say that updates are allowed > to bypass testing if they fix > a) serious bugs > b) bugs marked as "urgent" > c) broken deps > > For c) I think only plain rebuilds should be allowed. If the broken deps > are fixed by updating to a newer version the new package should be > tested again, at least for one or two days. For fixing broken deps its reasonable to bypassing testing, since the assuption is the current package is already un-installable. Bugs marked 'urgent' is a complete waste of time - everyone thinks their own bug is urgent / important. If someone enters a BZ and marks it urgent I'll typically put it at the bottom of my TODO list because it usually isn't urgent at all ;-P Similarly 'serious bug' is kind of hard to define as a formal policy - you need to enumerate a reasonable set of scenarios which are considered serious. 'broken deps' is one good example of a serious bug. 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 drago01 at gmail.com Sat Dec 29 01:53:26 2007 From: drago01 at gmail.com (drago01) Date: Sat, 29 Dec 2007 02:53:26 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <20071229014835.GB27783@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <20071229014835.GB27783@redhat.com> Message-ID: On Dec 29, 2007 2:48 AM, Daniel P. Berrange wrote: > For fixing broken deps its reasonable to bypassing testing, since the > assuption is the current package is already un-installable. Bugs marked > 'urgent' is a complete waste of time - everyone thinks their own bug > is urgent / important. If someone enters a BZ and marks it urgent I'll > typically put it at the bottom of my TODO list because it usually isn't > urgent at all ;-P Similarly 'serious bug' is kind of hard to define as > a formal policy - you need to enumerate a reasonable set of scenarios > which are considered serious. 'broken deps' is one good example of a > serious bug. data corruption, app is "unuseable" ... etc. but I think the best solution is "trust the maintainer" .. he should be able to judge if the update is urgent or not ... if not he should not be a maintainer at all. From sundaram at fedoraproject.org Sat Dec 29 01:46:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Dec 2007 07:16:37 +0530 Subject: Broken deps in the stable release are not acceptable In-Reply-To: References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <20071229014835.GB27783@redhat.com> Message-ID: <4775A6FD.9030203@fedoraproject.org> drago01 wrote: > On Dec 29, 2007 2:48 AM, Daniel P. Berrange wrote: > >> For fixing broken deps its reasonable to bypassing testing, since the >> assuption is the current package is already un-installable. Bugs marked >> 'urgent' is a complete waste of time - everyone thinks their own bug >> is urgent / important. If someone enters a BZ and marks it urgent I'll >> typically put it at the bottom of my TODO list because it usually isn't >> urgent at all ;-P Similarly 'serious bug' is kind of hard to define as >> a formal policy - you need to enumerate a reasonable set of scenarios >> which are considered serious. 'broken deps' is one good example of a >> serious bug. > > data corruption, app is "unuseable" ... etc. > > but I think the best solution is "trust the maintainer" .. he should > be able to judge if the update is urgent or not ... if not he should > not be a maintainer at all. It is still useful to give a set of usual scenarios where the bug is considered urgent as guidance for maintainers in need of it. Rahul From jkeating at redhat.com Sat Dec 29 03:17:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Dec 2007 22:17:27 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: <20071228221727.64df7bf1@redhat.com> On Sat, 29 Dec 2007 00:26:20 +0000 (UTC) Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > I care when it looks like ass compared to the other apps I have > > open, > > That's what Bluecurve is for. ;-) Except I don't like bluecurve as much anymore (: > > We'd love having a Nodoka theme available for KDE too, but we're > fairly busy already, so there isn't one yet. (We just didn't have the > time to work on one.) Thus Bluecurve (and Quarticurve for Qt 4) is > the best we can offer for a unified look. > > I also disagree with the assertion that Plastik "looks like ass". ;-) > It just looks different (and that's the main problem we have to > solve, I think moving away from Bluecurve was a mistake). The "look like ass" wasn't that Plastik looks bad, it just doesn't match, therefor it makes the entire experience look like ass because it's mismatched. > > > doesn't use my font settings, > > I agree our community (especially the upstream projects) needs to > work on not having to set up everything twice though. (But setting > the fonts the same way in both environments is possible, of course.) > > > doesn't use the same file selector > > That's because it uses a better one. ;-) > > More seriously, there are solutions being worked on for the standard > dialog (especially file selector) issue at freedesktop.org and > elsewhere, unfortunately nothing which got widespread adoption > yet. :-( > > But surely having to write every single application twice, once with > each toolkit, is not the real solution! > > Kevin Kofler (comaintaining KDE as well as the GTK+-based > XChat and using XChat on KDE all the time) > > PS: All this is not a reason not to offer K3b as an option on the > DVD. I'm not asking for it to be installed by default, just to be > there! I'm not disagreeing with offering it on the DVD, in fact, I thought it was due to comps settings. If it isn't set in comps, I'll add it to the manifest so that it'll be there optionally. -- 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 Dec 29 03:18:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Dec 2007 22:18:02 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: <20071228221802.425b35bb@redhat.com> On Fri, 28 Dec 2007 21:56:59 -0600 Rex Dieter wrote: > Otherwise we're left with limiting the DVD content and/or default > apps to gnome/gtk-only ones, which I'd hope wasn't the intent of your > comment. Nope, I was just explaining why I personally don't wish to use k3b anymore on my gnome desktop. -- 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 Sat Dec 29 06:59:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 29 Dec 2007 07:59:17 +0100 Subject: moto4lin, I give up. In-Reply-To: References: Message-ID: <4775F045.60504@hhs.nl> Kevin Kofler wrote: > dragonauta x gmail.com> writes: >> This is what I got on bugzilla:"I'm sorry, but this is still an upstream >> issue. The fact that the upstream author has a patch that fixes this problem >> but is not releasing it in anofficial release does not make this a packaging >> issues, IMHO. > > IMHO it does. Maintainers: In a situation like this, if there's a patch from > upstream, please apply it! > > If upstream only provides the fix in the form of a commit to SVN trunk, first > try applying the diff from SVN to the release, sometimes it just works. If it > doesn't apply, you have 3 options: > 1. Try asking upstream (nicely) for a backport which applies to the stable > release. Keep in mind though that the upstream author(s) might be very busy and > do(es) not necessarily have the time to do backports. > 2. Backport the patch yourself. This is often fairly easy. > 3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real > release for ages, this may well be the best option, however be careful, as the > snapshot may also include regressions. It is usually a good idea to run the > idea by upstream first, as for one they are likely to know about any > regressions in the snapshots, and secondly, unfortunately some uncooperative > upstreams may also get upset and hostile if you package snapshots (whereas > others will even ask you to do just that, also depending on the state the code > in SVN is in, thus the importance of asking). > > If you have a ready-to-apply patch or if you use options 1 or 2, please don't > patch the source tarball directly, use Patch0 (or Patch1, ...). If you use > option 3, make your SVN checkout the new Source0. > You forgot 4) Ask on this list if there is anyone who is willing to backport upstream's fix for you. >> It is my position that bugs like this need to be fixed by an upstream >> release, particularly in cases like this. Because upstream fixes help all >> distributions,and Fedora, effectively, forking it does not. > > First of all: It isn't "forking" to backport a patch which is already in the > upstream SVN trunk. It's even less "forking" to package something straight from > the SVN trunk. > > Secondly: Other distros will eventually get the fix because it's already in SVN > trunk, so it will be in the next release. And if they want it first, they can > backport it, just as you can. > > Notwithstanding all the above: It would of course be better for all distros, > including Fedora, if there was a new stable release with the fix. However, as I > said above, upstream may be too busy to do backports, and unwilling to release > from the current state of the SVN trunk for reasons unrelated to the fix > (regressions etc.). So sometimes, backporting is really the only option. > >> I don't believe it is Fedora's place to be tracking svn. > > Then backport the fix. > > If it doesn't apply to the stable version and you can't get it to apply, let us > see the BZ report and the fix and I'm sure one of us will be able to help you. > Ah yes, thats what I meant with option 4. Regards, Hans From alexl at users.sourceforge.net Sat Dec 29 07:43:25 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 29 Dec 2007 00:43:25 -0700 Subject: xulrunner, Miro on f8 In-Reply-To: (Neal Becker's message of "Fri\, 28 Dec 2007 09\:25\:08 -0500") References: Message-ID: >>>>> "NB" == Neal Becker writes: NB> After installing firefox-3.0-0.beta2.3.fc9.x86_64 along with deps NB> (xulrunner), I just tried installing Miro-1.0-4.fc9.x86. NB> Any ideas on this? I assume you meant F-9 (rawhide), not F-8 (the subject line). If so, then it's because the patch I applied from: https://bugzilla.redhat.com/show_bug.cgi?id=393521 only allows Miro to compile, but unfortunately doesn't allow it to actually run. The problem is that Miro doesn't really yet work with xulrunner. (Note that getting packages to work against xulrunner is now mandatory because firefox-devel has since been dropped from rawhide). I was only able to test that Miro *compiled* against xulrunner, not that it actually *runs*q, because I don't currently run a rawhide box myself, so I'm glad that somebody has. Please add your feedback and comments to that bug above. Martin Stransky (who did the patch), did say the patch I applied was a "minimal" patch, and did not necessary say it would work. :-/ I've since filed a bug with upstream: http://bugzilla.pculture.org/show_bug.cgi?id=9370 to see if they can fix it properly, but no response as yet. (I've also raised the issue on #miro on freenode, but more people bothering them on mailing lists or IRC would probably help get attention to the issue). NB> miro /usr/lib64/xulrunner-1.9pre Traceback (most recent call NB> last): File "/usr/bin/miro.real", line 123, in startapp() NB> File "/usr/bin/miro.real", line 58, in startapp import singleclick NB> File "/usr/lib64/python2.5/site-packages/miro/singleclick.py", NB> line 36, in import app File NB> "/usr/lib64/python2.5/site-packages/miro/app.py", line 610, in NB> import frontend File NB> "/usr/lib64/python2.5/site-packages/miro/frontend.py", line 50, in NB> import MozillaBrowser ImportError: NB> /usr/lib64/xulrunner-sdk-1.9pre/lib/libxul.so: undefined symbol: NB> g_assertion_message Various issues related to packages that depend on xulrunner are tracked here: http://fedoraproject.org/wiki/Releases/FeatureXULRunner Alex From pertusus at free.fr Sat Dec 29 08:40:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 29 Dec 2007 09:40:46 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <1198889708.3293.86.camel@wicktop.localdomain> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> Message-ID: <20071229084046.GA5534@free.fr> On Sat, Dec 29, 2007 at 01:55:08AM +0100, Christoph Wickert wrote: > > > > For that, we could make a bodhi policy. Cause no rules say all package > > Must go to testing-update before move to stable one. > > You are right. I thought we already had policy for that but the wiki > says: > "If you feel that community testing is unnecessary for your update, you > can choose to push it straight to the stable fedora-updates repository > instead." > > IMO this is wrong, it should only be allowed for security updates. I disagree. In my case nobody ever noticed the regressions in testing even for my packages that are widely used. And for the packages that correspond with a niche of users, of course I never got any feedback in bodhi. Given that it seems that there isn't a lot of people using testing it seems to me that for niche software it would be better to go straight to stable. -- Pat From j.w.r.degoede at hhs.nl Sat Dec 29 08:54:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 29 Dec 2007 09:54:33 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <20071229084046.GA5534@free.fr> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <20071229084046.GA5534@free.fr> Message-ID: <47760B49.7050305@hhs.nl> Patrice Dumas wrote: > On Sat, Dec 29, 2007 at 01:55:08AM +0100, Christoph Wickert wrote: >>> For that, we could make a bodhi policy. Cause no rules say all package >>> Must go to testing-update before move to stable one. >> You are right. I thought we already had policy for that but the wiki >> says: >> "If you feel that community testing is unnecessary for your update, you >> can choose to push it straight to the stable fedora-updates repository >> instead." >> >> IMO this is wrong, it should only be allowed for security updates. > > I disagree. In my case nobody ever noticed the regressions in testing > even for my packages that are widely used. And for the packages that > correspond with a niche of users, of course I never got any feedback > in bodhi. > > Given that it seems that there isn't a lot of people using testing it > seems to me that for niche software it would be better to go straight to > stable. > +1 Not to mention updates which aren't updates but new packages. Regards, Hans From vpivaini at cs.helsinki.fi Sat Dec 29 10:28:11 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 29 Dec 2007 12:28:11 +0200 Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking ) In-Reply-To: References: <200712282248.21314.vpivaini@cs.helsinki.fi> Message-ID: <200712291228.11586.vpivaini@cs.helsinki.fi> Kevin Kofler kirjoitti: > For the legacy KSpell interface which uses command-line spellcheckers, we > could just add support for tmispell like I added support for hunspell: > http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs3/devel/kdelibs-3.5.8-kspe >ll-hunspell.patch?rev=1.1&view=markup As you can see from the above patch, > it isn't that hard to patch in support for an additional executable OK, this sounds good. What should I do with the fake dictionary files then, see . Basically the README says to do "touch /usr/lib/ispell/suomi.{hash,aff}" to fake ispell compatible programs to see that there is Finnish spell checking available. If I add these files, the current KDE in F-8 will see them and show Finnish as an ispell language, but of course it won't work, if /usr/bin/ispell is not a link to /usr/bin/tmispell. Could you hack rawhide's KSpell so that it would see if tmispell is available and then offer Finnish spell checking, without any fake dictionary files? If this was possible, then I could package tmispell similarly for all branches, basically as a command line application without any dictionary hacks. -- Ville-Pekka Vainio From buildsys at redhat.com Sat Dec 29 11:56:39 2007 From: buildsys at redhat.com (Build System) Date: Sat, 29 Dec 2007 06:56:39 -0500 Subject: rawhide report: 20071229 changes Message-ID: <200712291156.lBTBud6N001653@porkchop.devel.redhat.com> New package libopensync-plugin-google-calendar Google Calendar plugin for libopensync New package libopensync-plugin-moto Plugin for syncing with Motorola phones via libopensync New package libopensync-plugin-opie Synchronisation with the Opie handheld environment New package libopensync-plugin-vformat Vformat plugin for libopensync New package perl-Module-CPANTS-Analyse Generate Kwalitee ratings for a distribution New package perl-XML-Generator-DBI Generate SAX events from SQL queries New package perl-XML-Handler-YAWriter Yet another Perl SAX XML Writer New package perl-XML-Tidy Tidy indenting of XML documents New package python-httplib2 A comprehensive HTTP client library New package quesoglc The OpenGL Character Renderer New package scanmem Simple interactive debugging utility Updated Packages: KoboDeluxe-0.5.1-1.fc9 ---------------------- * Fri Dec 28 2007 Hans de Goede 0.5.1-1 - New upstream release 0.5.1 asterisk-1.4.16.2-1.fc9 ----------------------- * Fri Dec 28 2007 Jeffrey C. Ollie - 1.4.16.2-1 - Update to 1.4.16.2 audit-1.6.3-2.fc9 ----------------- * Sat Dec 29 2007 Miloslav Trma?? - 1.6.3-2 - Don't fchmod() /dev/null to mode 0400 (#426934) beagle-0.3.2-1.fc9 ------------------ * Fri Dec 28 2007 Matthias Clasen - 0.3.2-1 - Update to 0.3.2 bugzilla-3.0.2-6.fc9 -------------------- * Fri Dec 28 2007 John Berninger - 3.0.2-6 - Add cron.daily, cron.whine to payload list * Fri Dec 28 2007 John Berninger - 3.0.2-5 - Typo in spec file, rebuild * Fri Dec 28 2007 John Berninger - 3.0.2-3 - bz 426465 - don't enable cron jobs so cron doesn't complain about an unconfigured installation deluge-0.5.7.98-1.fc9 --------------------- * Sat Dec 29 2007 Mamoru Tasaka - 0.5.7.98-1 - Update to new upstream release candidate (0.5.8 RC2) dwdiff-1.3-1.fc9 ---------------- * Fri Dec 28 2007 Jakub Hrozek 1.3-1 - New upstream eclipse-setools-3.3.2.3-1.fc9 ----------------------------- * Fri Dec 28 2007 Dave Sugar - 3.3.2.3-1 - add error output of loading of setools-libs-java fails - update version * Thu Dec 06 2007 Dave Sugar - 3.3.2-2 - remove explicit vendor setting * Wed Dec 05 2007 Dave Sugar - 3.3.2-1 - public release update version to 3.3.2-1 eclipse-slide-1.3.6-2.fc9 ------------------------- * Fri Dec 28 2007 Dave Sugar - 1.3.6-2 - plugin version in feature was not correct. * Fri Dec 28 2007 Dave Sugar - 1.3.6-1 - minor bug fixing - import dialoag added glpi-0.70-2.fc9 --------------- * Fri Dec 28 2007 Remi Collet - 0.70-2 - Changeset 6190 gnochm-0.9.11-1.fc9 ------------------- * Fri Dec 28 2007 Patrice Dumas 0.9.11-1 - update to 0.9.11 gnofract4d-3.7-1.fc9 -------------------- * Fri Dec 28 2007 Stewart Adam - 3.7-1 - Update to 3.7 - Drop obsolete patches gnome-mag-0.15.0-1.fc9 ---------------------- * Fri Dec 28 2007 Matthias Clasen - 0.15.0-1 - Update to 0.15.0 gtkspell-2.0.11-6.fc9 --------------------- * Fri Dec 28 2007 Matthew Barnes - 2.0.11-6.fc9 - Remove aspell dependency from devel subpackage. iotop-0.1-3.fc9 --------------- * Fri Dec 28 2007 Adel Gadllah 0.1-3 - Fix build issue jabbim-0.3-0.55.20071228svn.fc9 ------------------------------- * Fri Dec 28 2007 Michal Schmidt - 0.3-0.55.20071228svn - Upstream SVN revision 1635. * Fri Dec 28 2007 Michal Schmidt - 0.3-0.54.20071228svn - Upstream SVN revision 1633. jd-1.9.8-1.fc9 -------------- * Fri Dec 28 2007 Mamoru Tasaka - 1.9.8-1 - 1.9.8 * Sun Dec 23 2007 Mamoru Tasaka - 1.9.8-0.5.rc071223 - 1.9.8 rc 071223 * Tue Dec 18 2007 Mamoru Tasaka - 1.9.8-0.4,beta071218 - 1.9.8 beta 071218 kdepim-6:3.5.8-13.svn20071204.ent.fc9 ------------------------------------- * Fri Dec 28 2007 Kevin Kofler 6:3.5.8-13.20071204.ent - rebuild for new libopensync libbonobo-2.20.3-1.fc9 ---------------------- * Fri Dec 28 2007 Matthias Clasen - 2.20.3-1 - Update to 2.20.3 libkdcraw-0.1.3-1.fc9 --------------------- * Fri Dec 28 2007 Marcin Garski 0.1.3-1 - Update to 0.1.3 libnemesi-0.6.4-0.1.rc2.fc9 --------------------------- * Fri Dec 28 2007 Dominik Mierzejewski 0.6.4-0.1.rc2 - update to 0.6.4-rc2 - fixes multiple buffer overflow vulnerabilities (bug #426905) - kill rpaths libopenraw-0.0.3-1.fc9 ---------------------- * Fri Dec 28 2007 Trond Danielsen - 0.0.3-1 - New upstream version. - Updated license tag. - Fixed rpath error. libopensync-0.35-2.fc9 ---------------------- * Fri Dec 28 2007 Andreas Bierfert - 0.35-2 - use cmake macro * Thu Dec 27 2007 Andreas Bierfert - 0.35-1 - version upgrade * Sun Oct 21 2007 Andreas Bierfert - 0.33-1 - version upgrade libopensync-plugin-evolution2-0.35-2.fc9 ---------------------------------------- * Fri Dec 28 2007 Andreas Bierfert 0.35-2 - use cmake macro * Thu Dec 27 2007 Andreas Bierfert 0.35-1 - version upgrade - remove -devel subpackage libopensync-plugin-file-0.35-2.fc9 ---------------------------------- * Fri Dec 28 2007 Andreas Bierfert 0.35-2 - use cmake macro * Thu Dec 27 2007 Andreas Bierfert 0.35-1 - version upgrade libopensync-plugin-gnokii-0.35-1.fc9 ------------------------------------ * Fri Dec 28 2007 Andreas Bierfert - 0.35-1 - version upgrade libopensync-plugin-gpe-0.35-2.fc9 --------------------------------- * Sat Dec 29 2007 Andreas Bierfert 0.35-2 - use cmake macro * Thu Dec 27 2007 Andreas Bierfert 0.35-1 - version upgrade libopensync-plugin-irmc-0.35-2.fc9 ---------------------------------- * Sat Dec 29 2007 Andreas Bierfert 0.35-2 - use cmake macro * Fri Dec 28 2007 Andreas Bierfert 0.35-1 - version upgrade libopensync-plugin-kdepim-0.35-1.fc9 ------------------------------------ * Sat Dec 29 2007 Andreas Bierfert - 0.35-1 - version upgrade * Thu Sep 27 2007 Oliver Falk 0.22-3 - Add patch to support finding qt 3.3 in /usr/lib/qt-3.3 libopensync-plugin-palm-0.35-2.fc9 ---------------------------------- * Sat Dec 29 2007 Andreas Bierfert 0.35-2 - use cmake macro * Fri Dec 28 2007 Andreas Bierfert 0.35-1 - version upgrade libopensync-plugin-python-0.35-2.fc9 ------------------------------------ * Sat Dec 29 2007 Andreas Bierfert 0.35-2 - use cmake macro * Fri Dec 28 2007 Andreas Bierfert 0.35-1 - version upgrade libopensync-plugin-syncml-0.35-1.fc9 ------------------------------------ * Fri Dec 28 2007 Andreas Bierfert - 0.35-1 - version upgrade linuxdcpp-1.0.1-1.fc9 --------------------- * Fri Dec 28 2007 Marcin Garski 1.0.1-1 - Update to 1.0.1 m17n-contrib-1.1.4-1.fc9 ------------------------ * Fri Dec 28 2007 Parag Nemade -1.1.4-1.fc9 - Update to new upstream release 1.1.4 - Added missing tbl2mim.awk as Source1 m17n-db-1.5.0-1.fc9 ------------------- * Fri Dec 28 2007 Parag Nemade -1.5.0-1.fc9 - Update to new upstream release 1.5.0 m17n-lib-1.5.0-1.fc9 -------------------- * Fri Dec 28 2007 Parag Nemade -1.5.0-1.fc9 - Update to new upstream release 1.5.0 - Added missing internal-flt.h file as Source1 munin-1.2.5-4.fc9 ----------------- * Wed Dec 26 2007 Kevin Fenzi - 1.2.5-4 - Add patch to fix ampersand and degrees in plugins (fixes #376441) nautilus-sendto-0.12-7.fc9 -------------------------- * Fri Dec 28 2007 Adel Gadllah - 0.12-7 - Fix icq file transfers with pidgin RH #408511 perl-Exception-Class-1.23-4.fc9 ------------------------------- * Sat Dec 29 2007 Ralf Cors??pius 1.23-4 - BR: perl(Test::More) (BZ 419631). - Adjust License-tag. perl-Module-Pluggable-3.60-2.fc9 -------------------------------- * Sat Dec 29 2007 Ralf Corsepius - 3.60-2 - Adjust License-tag. - Fix perms on sources. - BR: perl(Test::More) (BZ 419631). perl-Parse-CPAN-Packages-2.26-5.fc9 ----------------------------------- * Sat Dec 29 2007 Ralf Cors??pius - 2.26-5 - Adjust License-tag. - Add BR: perl(Test::More) (BZ 419631). php-5.2.5-4 ----------- * Fri Dec 28 2007 Joe Orton 5.2.5-4 - rebuild for libc-client bump * Wed Dec 05 2007 Release Engineering - 5.2.5-3 - Rebuild for openssl bump * Wed Dec 05 2007 Joe Orton 5.2.5-2 - update to 5.2.5 php-magickwand-1.0.5-1.fc9 -------------------------- * Fri Dec 28 2007 Robert Scheck 1.0.5-1 - Upgrade to 1.0.5 (#229401) * Fri Dec 28 2007 Robert Scheck 1.0.1-1 - Upgrade to 1.0.1 (#394961) * Fri Dec 28 2007 Robert Scheck 0.1.9-1 - Upgrade to 0.1.9 php-pear-Net-Ping-2.4.3-1.fc9 ----------------------------- * Fri Dec 28 2007 Remi Collet 2.4.3-1 - update to 2.4.3 ruby-RMagick-2.0.0-3.fc9 ------------------------ * Fri Dec 28 2007 Mamoru Tasaka - 2.0.0-3 - 2.0.0 - Workaround for ruby site bug related to static archive removal. scribus-1.3.4-3.fc9 ------------------- * Fri Dec 28 2007 Andreas Bierfert - 1.3.4-3 - fix inclusion of python scripts as proposed by Todd Zullinger (#312091) - fix desktop file * Thu Aug 23 2007 Andreas Bierfert - 1.3.4-2 - rebuild for buildid - new license tag setroubleshoot-2.0.0-3.fc9 -------------------------- * Fri Dec 28 2007 - 2.0.0-3 - clear the previous database, it's not compatible with v2.0 * Fri Dec 28 2007 - 2.0.0-2 - fix requires for plugins * Fri Dec 28 2007 - 2.0.0-1 - prepare for v2 test release - Completed most work for version 2 of setroubleshoot, prepare for test release - import Dan's changes from the mainline primarily allow_postfix_local_write_mail_spool plugin - escape html, fix siginfo.format_html(), siginfo.format_text() - add async-error signal - change identity to just username - make sure set_filter user validation works and reports error in browser - fix generation of line numbers and host when connected to audispd - add permissive notification, resolves bug #231334: Wording doesn't change for permissive mode - get the uid,gid when a client connects to the server - set_filter now verifies the filter is owned by the user, - resolves bug #288261: setroubleshoot lack of user authentication - remove filter options which weren't being used - change '@' in audit data hostname to '.' - remove restart dialog resolves bug #321171: sealert's dialog after update is higly confusing - fix rpc xml arg - fix handling of host value - tweak what fields are in signature - move data items which had been in 'avc' object into siginfo - clean up siginfo format - large parts of new audit data pipeline working, checkpoint - fix duplicate xml nodes when generating xml tree - audit event can now be xml serialized - switch from using int's for audit record types to strings - avoid conversion headaches and possibilty of not being able to convert a new unknown type - add logic to allow XmlSerialize to be subclassed and init_from_xml_node to be overridden - add support to xml serialize classes AuditEventID, AuditEvent, AuditRecord - use metaclass for xml class init - start adding xml support to audit data classes - Use metaclass to wrap class init - move xml serialization code from signature.py to xml_serialize.py - simplify aspect of the serialization code - add unstructured xml mapping, each xml element name has its content mapped to obj.name - modify xml serialization to be driven by xml contents - general clean up - checkpoint conversion of serialization to use metaclasses - clean up class/data specifications for XmlSerializable - add support for client rpc testing - add changelog entry - add SubProcess class to setroubleshootd in preparation to - run daemon as subprocess so we can gather results and compare them to the expected data we sent - rewrite all plugins to use new v2 audit data - add SubProcess class to setroubleshootd in preparation to run daemon as subprocess so we can gather results and compare them to the expected data we sent - add new test support: add config section 'test', add boolean 'analyze' to config test section, add class TestPluginReportReceiver which is installed if test.analyze is True, it prints analysis report. In test_setroubleshootd send AUDIT_EOE to assure sequential event processing so analysis results have same ordering as events that are sent by test_setroubleshootd - alert signatures now include host information, alerts will be grouped by host setroubleshoot-plugins-2.0.0-1.fc9 ---------------------------------- * Fri Dec 28 2007 - 2.0.0-1 - prepare for v2 test release tetex-elsevier-0.1.20071024-1.fc9 --------------------------------- * Fri Dec 28 2007 Patrice Dumas 0.1.20071024-1 - update to the new version - correct urls - build the manuals varnish-1.1.2-4.fc9 ------------------- * Fri Dec 28 2007 Ingvar Hagelund - 1.1.2-4 - Build for fedora update * Fri Dec 28 2007 Ingvar Hagelund - 1.1.2-2 - Added missing changelog items * Thu Dec 20 2007 Stig Sandbeck Mathisen - 1.1.2-1 - Bumped the version number to 1.1.2. - Addeed build dependency on libxslt wine-0.9.52-2.fc9 ----------------- * Sat Dec 29 2007 Andreas Bierfert - 0.9.52-2 - fix menu bug (#393641) * Fri Dec 28 2007 Andreas Bierfert - 0.9.52-1 - version upgrade * Fri Dec 28 2007 Andreas Bierfert - 0.9.51-3 - add -n Wine to pulseaudio workaround - try to fix menu bug #393641 wmix-3.1-2.fc9 -------------- xorg-x11-drv-radeonhd-1.1.0-0.2.20071228git.fc9 ----------------------------------------------- * Fri Dec 28 2007 Hans Ulrich Niedermann - 1.1.0-0.2.20071228git - New snapshot (upstream commit fcf15c8facb7c2c1a4a2513f3f84537f3f35c6a1): - (Some?) RV670 support - c036b819: Only report unknown cards IF they have issues. - b9277bfc: Check for loaded fglrx kernel module. - 765f5972: Man page describes all RandR properties - 2b3928c6: Fix "messed up colours" issues after suspend/resume - ... Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.i386 requires libgtkembedmoz.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.x86_64 requires libgtkembedmoz.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc requires libgtkembedmoz.so xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 ruby-gtkmozembed - 0.16.0-19.fc9.ppc64 requires libgtkembedmoz.so()(64bit) From david at lovesunix.net Sat Dec 29 11:59:48 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 29 Dec 2007 12:59:48 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> Message-ID: <1198929588.31425.5.camel@localhost.localdomain> Em S?b, 2007-12-29 ?s 00:26 +0000, Kevin Kofler escreveu: > Jesse Keating redhat.com> writes: > > I care when it looks like ass compared to the other apps I have open, > > That's what Bluecurve is for. ;-) No amount of theming will make a KDE app look, act or behave like a native GNOME app (or vice virsa). Though it does make things more tolerable. Personally when it comes to burning I favor integrating it in the places where I really want that functionality as I have a hard time seeing how aside historically being burdened as such this is functionality that requires or is best utilized as a seperate task. Burning a music cd should be in Banshee, photo cds in f-spot and so on. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From mschwendt.tmp0701.nospam at arcor.de Sat Dec 29 13:56:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 29 Dec 2007 14:56:39 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> Message-ID: <20071229145639.a7518447.mschwendt.tmp0701.nospam@arcor.de> On Sat, 29 Dec 2007 01:09:06 +0000 (UTC), Kevin Kofler wrote: > Christoph Wickert nurfuerspam.de> writes: > > You are right. I thought we already had policy for that but the wiki > > says: > > "If you feel that community testing is unnecessary for your update, you > > can choose to push it straight to the stable fedora-updates repository > > instead." > > > > IMO this is wrong, it should only be allowed for security updates. > > It should also stay allowed for critical regression fixes at the very least. > Unfortunately, sometimes updates slip through testing despite causing serious > issues. For example, an SDL update caused _any_ build against SDL-devel to fail > (because SDL-config.h was corrupted by a trivial typo in the specfile which was > missed during testing). Wow! That's one brilliant way to phrase it. Not. ;) It didn't "slip through testing" as you call it. It wasn't tested at all. Neither "in testing" nor "before pushing it into testing". From jkeating at redhat.com Sat Dec 29 14:39:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Dec 2007 09:39:48 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198929588.31425.5.camel@localhost.localdomain> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> Message-ID: <20071229093948.4ad26f1e@redhat.com> On Sat, 29 Dec 2007 12:59:48 +0100 David Nielsen wrote: > Personally when it comes to burning I favor integrating it in the > places where I really want that functionality as I have a hard time > seeing how aside historically being burdened as such this is > functionality that requires or is best utilized as a seperate task. > Burning a music cd should be in Banshee, photo cds in f-spot and so > on. I completely agree, it's just that I find these apps lacking. Banshee often gets the length of my music files wrong so it will refuse to let me burn an audio CD I know is of the right size. Brasero doesn't seem to have this problem, neither does K3b. That's the only thing I find myself using these tools for anymore, making audio CDs from my various music 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: From caillon at redhat.com Sat Dec 29 14:51:40 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 29 Dec 2007 15:51:40 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <4775A39D.4000307@fedoraproject.org> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> Message-ID: <47765EFC.1030409@redhat.com> On 12/29/2007 02:32 AM, Rahul Sundaram wrote: > Christoph Wickert wrote: >> I completely agree with you. Maybe we could say that updates are allowed >> to bypass testing if they fix >> a) serious bugs >> b) bugs marked as "urgent" >> c) broken deps > > b) isn't a good criteria since anybody can mark any bug as urgent. If > the priority field in bugzilla is restricted to package maintainers and > triagers, I would agree with you. The same maintainer who marks "push right to stable" can tweak the field before they submit the update and you won't have solved anything. From frank-buettner at gmx.net Sat Dec 29 15:17:26 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 29 Dec 2007 16:17:26 +0100 Subject: Asterisk and EPEL Message-ID: <47766506.4020007@gmx.net> Hello, how looks it about asterisk at the EPEL repo? -------------- 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 sundaram at fedoraproject.org Sat Dec 29 15:17:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Dec 2007 20:47:05 +0530 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <47765EFC.1030409@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> Message-ID: <477664F1.8080403@fedoraproject.org> Christopher Aillon wrote: > On 12/29/2007 02:32 AM, Rahul Sundaram wrote: >> Christoph Wickert wrote: >>> I completely agree with you. Maybe we could say that updates are allowed >>> to bypass testing if they fix >>> a) serious bugs >>> b) bugs marked as "urgent" >>> c) broken deps >> >> b) isn't a good criteria since anybody can mark any bug as urgent. If >> the priority field in bugzilla is restricted to package maintainers >> and triagers, I would agree with you. > > The same maintainer who marks "push right to stable" can tweak the field > before they submit the update and you won't have solved anything. Even if it had a strict set of rules and maintainers are going to abuse the system, they can mark any update as a critical security update and push it through too but then it is much more easier to point out who is responsible compared to users just marking a random bug as a high priority one. At any rate, I think we should just disable the priority field or limit it's access if we want to rely on it for anything at all. Rahul From martin at marquesminen.com.ar Sat Dec 29 16:06:34 2007 From: martin at marquesminen.com.ar (Martin Marques) Date: Sat, 29 Dec 2007 13:06:34 -0300 Subject: New tzdata Message-ID: <4776708A.9050004@marquesminen.com.ar> Will there be a new tzdata available as tonight, and by a new law, we will have a daylight hour change in Argentina? Debian has already made the changes: http://packages.debian.org/changelogs/pool/main/t/tzdata/current/changelog.html From sgrubb at redhat.com Sat Dec 29 16:14:20 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 29 Dec 2007 11:14:20 -0500 Subject: /dev/null is permission 400 in rawhide In-Reply-To: References: Message-ID: <200712291114.21046.sgrubb@redhat.com> On Friday 28 December 2007 06:59:05 pm Linus Walleij wrote: > Anyone else hit by it and knows the reason for? (Nothing much else > than rootshell works, manual chmod to the rescue.) > > I suspect the glibc update, but I have actually no idea what update caused > this. As others said this was the audit package (oopsie). A new one was built with a temporary fix and was pushed out in today's rawhide. A new package was just built with the permanent fix just a few minutes ago. You can try the newest one here: http://koji.fedoraproject.org/koji/buildinfo?buildID=29400 -Steve From david at lovesunix.net Sat Dec 29 16:39:37 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 29 Dec 2007 17:39:37 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071229093948.4ad26f1e@redhat.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> Message-ID: <1198946377.838.1.camel@localhost.localdomain> Em S?b, 2007-12-29 ?s 09:39 -0500, Jesse Keating escreveu: > On Sat, 29 Dec 2007 12:59:48 +0100 > David Nielsen wrote: > > > Personally when it comes to burning I favor integrating it in the > > places where I really want that functionality as I have a hard time > > seeing how aside historically being burdened as such this is > > functionality that requires or is best utilized as a seperate task. > > Burning a music cd should be in Banshee, photo cds in f-spot and so > > on. > > I completely agree, it's just that I find these apps lacking. Banshee > often gets the length of my music files wrong so it will refuse to let > me burn an audio CD I know is of the right size. Brasero doesn't seem > to have this problem, neither does K3b. That's the only thing I find > myself using these tools for anymore, making audio CDs from my various > music files. I assume that you have filed bugs for these issues? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From jkeating at redhat.com Sat Dec 29 17:11:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Dec 2007 12:11:24 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198946377.838.1.camel@localhost.localdomain> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> Message-ID: <20071229121124.42c79600@redhat.com> On Sat, 29 Dec 2007 17:39:37 +0100 David Nielsen wrote: > I assume that you have filed bugs for these issues? Not recently, I only recently discovered this, and I wasn't sure if it was bad mp3 encoding or not. I need to recreate the files and see if it continues. -- 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 caillon at redhat.com Sat Dec 29 17:43:54 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 29 Dec 2007 18:43:54 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <477664F1.8080403@fedoraproject.org> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> <477664F1.8080403@fedoraproject.org> Message-ID: <4776875A.1000908@redhat.com> On 12/29/2007 04:17 PM, Rahul Sundaram wrote: > Christopher Aillon wrote: >> On 12/29/2007 02:32 AM, Rahul Sundaram wrote: >>> Christoph Wickert wrote: >>>> I completely agree with you. Maybe we could say that updates are >>>> allowed >>>> to bypass testing if they fix >>>> a) serious bugs >>>> b) bugs marked as "urgent" >>>> c) broken deps >>> >>> b) isn't a good criteria since anybody can mark any bug as urgent. If >>> the priority field in bugzilla is restricted to package maintainers >>> and triagers, I would agree with you. >> >> The same maintainer who marks "push right to stable" can tweak the >> field before they submit the update and you won't have solved anything. > > Even if it had a strict set of rules and maintainers are going to abuse > the system, Hey dude, I wasn't the one agreeing with a set of rules, that was you. I'm just saying it's unwise to agree with a set of rules that can still be worked around easily. > they can mark any update as a critical security update and > push it through too but then it is much more easier to point out who is > responsible compared to users just marking a random bug as a high > priority one. I just noticed that nobody sent out a FESCo Meeting Summary for 2007-09-27[1]. There, we approved http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft so the Fedora Security Response team would have to approve it before it gets released as a security advisory. [1] At least there's a log at http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html Nobody's implemented that yet, though... Luke? This would be quite nice to get done... :-) From sundaram at fedoraproject.org Sat Dec 29 17:39:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Dec 2007 23:09:25 +0530 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <4776875A.1000908@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> <477664F1.8080403@fedoraproject.org> <4776875A.1000908@redhat.com> Message-ID: <4776864D.4020606@fedoraproject.org> Christopher Aillon wrote: > Hey dude, I wasn't the one agreeing with a set of rules, that was you. > I'm just saying it's unwise to agree with a set of rules that can still > be worked around easily. We are talking about related but different issues. I am talking about guidelines to support maintainers looking for guidance on maintaining their packages and not to prevent maintainers from abusing the system. I would atleast initially trust maintainers to just not do that. Rahul From david at lovesunix.net Sat Dec 29 17:57:25 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 29 Dec 2007 18:57:25 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071229121124.42c79600@redhat.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> <20071229121124.42c79600@redhat.com> Message-ID: <1198951045.838.6.camel@localhost.localdomain> Em S?b, 2007-12-29 ?s 12:11 -0500, Jesse Keating escreveu: > On Sat, 29 Dec 2007 17:39:37 +0100 > David Nielsen wrote: > > > I assume that you have filed bugs for these issues? > > Not recently, I only recently discovered this, and I wasn't sure if it > was bad mp3 encoding or not. I need to recreate the files and see if > it continues. Most likely it's because the mp3s are variable bitrate, that tends to really mess up duration estimates (the joys of jerryrigging mp3s to support technology they were not intended originally - fun fun fun). But please do cc me on the bug once you file them, I have never seen this problem but then again most of my music is in FLAC or constant bitrate mp3s in the form of podcasts. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From kevin.kofler at chello.at Sat Dec 29 19:04:45 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Dec 2007 19:04:45 +0000 (UTC) Subject: New tzdata References: <4776708A.9050004@marquesminen.com.ar> Message-ID: Martin Marques marquesminen.com.ar> writes: > Will there be a new tzdata available as tonight, and by a new law, we > will have a daylight hour change in Argentina? WTF!? Are they crazy? They announce a DST change with only 3 (!!!) days notice, when most of the world is on holidays?! How are they expecting software to get updated in time? :-/ Kevin Kofler From kevin.kofler at chello.at Sat Dec 29 19:09:24 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Dec 2007 19:09:24 +0000 (UTC) Subject: New tzdata References: <4776708A.9050004@marquesminen.com.ar> Message-ID: Martin Marques marquesminen.com.ar> writes: > Will there be a new tzdata available as tonight, and by a new law, we > will have a daylight hour change in Argentina? Probably not, as there isn't even a bug report filed in Bugzilla yet. Please file one! Kevin Kofler From valent.turkovic at gmail.com Sat Dec 29 19:43:59 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 29 Dec 2007 20:43:59 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198951045.838.6.camel@localhost.localdomain> References: <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> <20071229121124.42c79600@redhat.com> <1198951045.838.6.camel@localhost.localdomain> Message-ID: <64b14b300712291143h23f080c4pb2d6b958ecc95e92@mail.gmail.com> On 12/29/07, David Nielsen wrote: > > Em S?b, 2007-12-29 ?s 12:11 -0500, Jesse Keating escreveu: > > On Sat, 29 Dec 2007 17:39:37 +0100 > > David Nielsen wrote: > > > > > I assume that you have filed bugs for these issues? > > > > Not recently, I only recently discovered this, and I wasn't sure if it > > was bad mp3 encoding or not. I need to recreate the files and see if > > it continues. > > Most likely it's because the mp3s are variable bitrate, that tends to > really mess up duration estimates (the joys of jerryrigging mp3s to > support technology they were not intended originally - fun fun fun). > > But please do cc me on the bug once you file them, I have never seen > this problem but then again most of my music is in FLAC or constant > bitrate mp3s in the form of podcasts. > > - David I belive I posted a bug regarding this issue ages ago and it still isn't fixed: https://bugzilla.redhat.com/show_bug.cgi?id=227483 Valent. -- 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 valent.turkovic at gmail.com Sat Dec 29 19:43:59 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 29 Dec 2007 20:43:59 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198951045.838.6.camel@localhost.localdomain> References: <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> <20071229121124.42c79600@redhat.com> <1198951045.838.6.camel@localhost.localdomain> Message-ID: <64b14b300712291143h23f080c4pb2d6b958ecc95e92@mail.gmail.com> On 12/29/07, David Nielsen wrote: > > Em S?b, 2007-12-29 ?s 12:11 -0500, Jesse Keating escreveu: > > On Sat, 29 Dec 2007 17:39:37 +0100 > > David Nielsen wrote: > > > > > I assume that you have filed bugs for these issues? > > > > Not recently, I only recently discovered this, and I wasn't sure if it > > was bad mp3 encoding or not. I need to recreate the files and see if > > it continues. > > Most likely it's because the mp3s are variable bitrate, that tends to > really mess up duration estimates (the joys of jerryrigging mp3s to > support technology they were not intended originally - fun fun fun). > > But please do cc me on the bug once you file them, I have never seen > this problem but then again most of my music is in FLAC or constant > bitrate mp3s in the form of podcasts. > > - David I belive I posted a bug regarding this issue ages ago and it still isn't fixed: https://bugzilla.redhat.com/show_bug.cgi?id=227483 Valent. -- 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 fedora at camperquake.de Sat Dec 29 19:54:00 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 29 Dec 2007 20:54:00 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <64b14b300712291143h23f080c4pb2d6b958ecc95e92@mail.gmail.com> References: <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> <20071229121124.42c79600@redhat.com> <1198951045.838.6.camel@localhost.localdomain> <64b14b300712291143h23f080c4pb2d6b958ecc95e92@mail.gmail.com> Message-ID: <20071229205400.14a035e7@lain.camperquake.de> Hi. On Sat, 29 Dec 2007 20:43:59 +0100, Valent Turkovic wrote > I belive I posted a bug regarding this issue ages ago and it still > isn't fixed: https://bugzilla.redhat.com/show_bug.cgi?id=227483 Without having looked at the file referenced in this bug: there are MP3 files for which the real length is impossible to determine without decoding the whole file. From laxathom at fedoraproject.org Sat Dec 29 20:14:29 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 29 Dec 2007 21:14:29 +0100 Subject: Wrong tag in EL-5 branch (?) Message-ID: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> Hello, When tried to make tag EL-5 branch, i fallen on this following error : ---------------------------------------------------------------------------------------------- [SmootherFrOgZ at lxtbuild EL-5]$ make tag cvs tag -c g-wrap-1_9_9-5_fc9 ERROR: The tag g-wrap-1_9_9-5_fc9 is already applied on a different branch ERROR: You can not forcibly move tags between branches ---------------------------------------------------------------------------------------------- I had to proceed as follow to fix this : HEAD_BRANCH=EL-5 make tag If someone else could perform an make tag action to check this, it'd be great. Thx, -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Sat Dec 29 20:40:32 2007 From: opensource at till.name (Till Maas) Date: Sat, 29 Dec 2007 21:40:32 +0100 Subject: Wrong tag in EL-5 branch (?) In-Reply-To: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> References: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> Message-ID: <200712292140.40755.opensource@till.name> On Sa Dezember 29 2007, Xavier Lamien wrote: > If someone else could perform an make tag action to check this, it'd be > great. The user notting deleted the file "branch", I guess by accident: http://cvs.fedoraproject.org/viewcvs/rpms/g-wrap/EL-5/?hideattic=0 You need to create it with: echo EL-5 >> branch in the EL-5 subdir. Otherwise the Makefile does not know which branch it is in. 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 Sat Dec 29 20:45:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 29 Dec 2007 21:45:33 +0100 Subject: Wrong tag in EL-5 branch (?) In-Reply-To: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> References: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> Message-ID: <20071229214533.4b4d8078.mschwendt.tmp0701.nospam@arcor.de> On Sat, 29 Dec 2007 21:14:29 +0100, Xavier Lamien wrote: > Hello, > > When tried to make tag EL-5 branch, i fallen on this following error : > ---------------------------------------------------------------------------------------------- > [SmootherFrOgZ at lxtbuild EL-5]$ make tag > cvs tag -c g-wrap-1_9_9-5_fc9 > ERROR: The tag g-wrap-1_9_9-5_fc9 is already applied on a different branch > ERROR: You can not forcibly move tags between branches > ---------------------------------------------------------------------------------------------- > > I had to proceed as follow to fix this : > HEAD_BRANCH=EL-5 make tag > > If someone else could perform an make tag action to check this, it'd be > great. Undelete the "branch" file. Put "EL-5" in it. Compare with your EL-4 branch if you are unsure. I could help, but ACLs are in place. From bpepple at fedoraproject.org Sat Dec 29 20:43:37 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 29 Dec 2007 15:43:37 -0500 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <4776875A.1000908@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> <477664F1.8080403@fedoraproject.org> <4776875A.1000908@redhat.com> Message-ID: <1198961017.16206.1.camel@kennedy> On Sat, 2007-12-29 at 18:43 +0100, Christopher Aillon wrote: > I just noticed that nobody sent out a FESCo Meeting Summary for > 2007-09-27[1]. There, we approved > http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft > so the Fedora Security Response team would have to approve it before it > gets released as a security advisory. > > [1] At least there's a log at > http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html Also, a meeting summary: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070927 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 laxathom at fedoraproject.org Sat Dec 29 21:18:16 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 29 Dec 2007 22:18:16 +0100 Subject: Wrong tag in EL-5 branch (?) In-Reply-To: <200712292140.40755.opensource@till.name> References: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> <200712292140.40755.opensource@till.name> Message-ID: <62bc09df0712291318l4f338c69p208fdcefb8b255e3@mail.gmail.com> 2007/12/29, Till Maas : > > On Sa Dezember 29 2007, Xavier Lamien wrote: > > > If someone else could perform an make tag action to check this, it'd be > > great. > > The user notting deleted the file "branch", I guess by accident: > http://cvs.fedoraproject.org/viewcvs/rpms/g-wrap/EL-5/?hideattic=0 > > You need to create it with: > echo EL-5 >> branch > in the EL-5 subdir. Otherwise the Makefile does not know which branch it > is > in. I could see that the Makefile.common's looking for file branch and if it doesn't find it set $HEAD_BRANCH to devel branch as default branch. It wouldn't be more simple to print an error message instead of set it to devel if this file is missing ? Regards, > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Sat Dec 29 22:58:57 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 29 Dec 2007 23:58:57 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071229205400.14a035e7@lain.camperquake.de> References: <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198946377.838.1.camel@localhost.localdomain> <20071229121124.42c79600@redhat.com> <1198951045.838.6.camel@localhost.localdomain> <64b14b300712291143h23f080c4pb2d6b958ecc95e92@mail.gmail.com> <20071229205400.14a035e7@lain.camperquake.de> Message-ID: <64b14b300712291458j16f5166apd10b5e8fdaabca43@mail.gmail.com> On 12/29/07, Ralf Ertzinger wrote: > Hi. > > On Sat, 29 Dec 2007 20:43:59 +0100, Valent Turkovic wrote > > > I belive I posted a bug regarding this issue ages ago and it still > > isn't fixed: https://bugzilla.redhat.com/show_bug.cgi?id=227483 > > Without having looked at the file referenced in this bug: there are > MP3 files for which the real length is impossible to determine without > decoding the whole file. My experience is that some players work almost perfectly with VBR and constant rate files (audacious for example) while other have problems (amarok which uses tablib). Valent. -- 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 valent.turkovic at gmail.com Sat Dec 29 23:01:13 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 30 Dec 2007 00:01:13 +0100 Subject: better usability - choice which icons are on the desktop Message-ID: <64b14b300712291501p499dbd03la49358d56887cbce@mail.gmail.com> Hi, I posted a RFE: https://bugzilla.redhat.com/show_bug.cgi?id=426907 I would appreciate any comments and other suggestions. 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 the.masch at gmail.com Sat Dec 29 23:03:35 2007 From: the.masch at gmail.com (masch) Date: Sat, 29 Dec 2007 18:03:35 -0500 Subject: Update wine In-Reply-To: <20071228235803.36fe912f@alkaid.a.lan> References: <93d66b780712261031g4377a96dob70016b515aa85ac@mail.gmail.com> <20071227150642.30e79230@alkaid.a.lan> <4773B6ED.9030404@ioa.s.u-tokyo.ac.jp> <93d66b780712270825i2e23e00wcbba6fe7697cc2d4@mail.gmail.com> <1198788477.8312.16.camel@localhost.localdomain> <20071227215115.274bc3a8@alkaid.a.lan> <20071228110621.78daa14e@alkaid.a.lan> <4774E814.2080305@gmail.com> <20071228133044.4b3b6963@alkaid.a.lan> <20071228235803.36fe912f@alkaid.a.lan> Message-ID: <93d66b780712291503q461eb1cfy2184a3cca93ce68e@mail.gmail.com> Great!! Thanks so much!!! Salu2.. On Dec 28, 2007 5:58 PM, Andreas Bierfert wrote: > On Fri, 28 Dec 2007 13:30:44 +0100 > Andreas Bierfert wrote: > > > Will be added in the next build. > > 0.9.52 has been build and should hit updates-testing soon. > > Regards, > > Andreas > > -- > Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB > andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted > phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mike at miketc.com Sat Dec 29 23:16:01 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 29 Dec 2007 17:16:01 -0600 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071229093948.4ad26f1e@redhat.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> Message-ID: <1198970161.4502.1.camel@scrappy.miketc.com> On Sat, 2007-12-29 at 09:39 -0500, Jesse Keating wrote: > I completely agree, it's just that I find these apps lacking. Banshee > often gets the length of my music files wrong so it will refuse to let > me burn an audio CD I know is of the right size. Brasero doesn't seem > to have this problem, neither does K3b. That's the only thing I find > myself using these tools for anymore, making audio CDs from my various > music files. For my own satisfaction/curiosity, what exactly do you use for at least copying/burning CD/DVD and/or burning an image? I used to use xcdroast but have been using k3b for a while. Didn't know there was another app (nautilus does this in a way?). -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From jkeating at redhat.com Sat Dec 29 23:24:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Dec 2007 18:24:35 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198970161.4502.1.camel@scrappy.miketc.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198970161.4502.1.camel@scrappy.miketc.com> Message-ID: <20071229182435.760e0b2f@redhat.com> On Sat, 29 Dec 2007 17:16:01 -0600 Mike Chambers wrote: > For my own satisfaction/curiosity, what exactly do you use for at > least copying/burning CD/DVD and/or burning an image? I used to use > xcdroast but have been using k3b for a while. > > Didn't know there was another app (nautilus does this in a way?). I use nautilus. Right click on an iso and select "Write to disc". Or right click on the CD icon and select "Copy Disc...". Go to Places -> CD/DVD Creator to give you a nautilus window to drag files into, with a menu item to burn them. I even burn over NFS this way, hand mounting the NFS and browsing to it in Nautilus to the isos directory. I'm told that support for doing this over nautilus mounted nfs/smb/etc will be coming soon. -- 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 andreas.bierfert at lowlatency.de Sat Dec 29 23:31:28 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 30 Dec 2007 00:31:28 +0100 Subject: Wrong tag in EL-5 branch (?) In-Reply-To: <62bc09df0712291318l4f338c69p208fdcefb8b255e3@mail.gmail.com> References: <62bc09df0712291214x14108323x23c6f53da9d34a3a@mail.gmail.com> <200712292140.40755.opensource@till.name> <62bc09df0712291318l4f338c69p208fdcefb8b255e3@mail.gmail.com> Message-ID: <20071230003128.50f57455@alkaid.a.lan> On Sat, 29 Dec 2007 22:18:16 +0100 "Xavier Lamien" wrote: > It wouldn't be more simple to print an error message instead of set it to > devel if this file is missing ? Not really since devel does not have branch files since it is not branched. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sun Dec 30 00:48:16 2007 From: drago01 at gmail.com (drago01) Date: Sun, 30 Dec 2007 01:48:16 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20071229182435.760e0b2f@redhat.com> References: <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <20071229093948.4ad26f1e@redhat.com> <1198970161.4502.1.camel@scrappy.miketc.com> <20071229182435.760e0b2f@redhat.com> Message-ID: On Dec 30, 2007 12:24 AM, Jesse Keating wrote: > On Sat, 29 Dec 2007 17:16:01 -0600 > Mike Chambers wrote: > > > For my own satisfaction/curiosity, what exactly do you use for at > > least copying/burning CD/DVD and/or burning an image? I used to use > > xcdroast but have been using k3b for a while. > > > > Didn't know there was another app (nautilus does this in a way?). > > I use nautilus. Right click on an iso and select "Write to disc". Or > right click on the CD icon and select "Copy Disc...". > > Go to Places -> CD/DVD Creator to give you a nautilus window to drag > files into, with a menu item to burn them. > > I even burn over NFS this way, hand mounting the NFS and browsing to it > in Nautilus to the isos directory. I'm told that support for doing > this over nautilus mounted nfs/smb/etc will be coming soon. yes with gvfs this should be possible because this locations are mounted via fuse an therefor can be accessed by any application (including nautilus-cd-burner and its backends) From caillon at redhat.com Sun Dec 30 04:07:58 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 30 Dec 2007 05:07:58 +0100 Subject: better usability - choice which icons are on the desktop In-Reply-To: <64b14b300712291501p499dbd03la49358d56887cbce@mail.gmail.com> References: <64b14b300712291501p499dbd03la49358d56887cbce@mail.gmail.com> Message-ID: <4777199E.90203@redhat.com> On 12/30/2007 12:01 AM, Valent Turkovic wrote: > Hi, > I posted a RFE: > https://bugzilla.redhat.com/show_bug.cgi?id= > > I would appreciate any comments and other suggestions. Suggestion: don't follow up bugs by posting links to a mailing list asking for discussion on the bug. Bugzilla doesn't do threading, so it's inherently harder for the maintainer to follow the bug now. In general, if you are looking for usability feedback, do a usability study in a usability lab. If you are looking for public opinion, ask a mailing list, set up a poll, or blog somewhere. If you are looking for a maintainer to make a decision, file a bug. From ville.skytta at iki.fi Sun Dec 30 10:48:25 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 30 Dec 2007 12:48:25 +0200 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions Message-ID: <200712301248.31541.ville.skytta@iki.fi> Hello, Related to Jesse's "I care when it looks like ass compared to the other apps I have open" message in the recent K3b thread: Getting GNOME apps to look decent in KDE sessions is somewhat painful currently. Not only does one need to configure their settings in the GNOME control center (which I can understand and live with even though it's suboptimal), but that is not enough. No settings persist accross session unless one gets something to start gnome-settings-daemon. Without gnome-settings-daemon running, many GNOME apps display broken/missing icons, and do not honor the settings I've configured in GNOME control center (eg. font sizes, themes). For examples of broken icons log in to a fresh KDE session, and open GNOME control center itself (the initial view shows lots of broken icons) or the nm-applet context menus. For examples of my font size being ignored, any GNOME app seems to do. Where should this be fixed? Shouldn't GNOME apps that use settings governed by the daemon get the daemon running if needed? Can't GNOME apps be made to look semi decent (eg. no broken icons) without the daemon running? What if gnome-settings-daemon isn't even installed? Should KDE start gnome-settings-daemon when a session starts? This is on F8. I've traditionally "fixed" this locally by installing a ~/.kde/Autostart/gnome-settings-daemon -> /usr/libexec/gnome-settings-daemon symlink but I think this deserves a real fix somewhere so that things just work. From hughsient at gmail.com Sun Dec 30 11:03:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 30 Dec 2007 11:03:19 +0000 Subject: Difficulties testing the new nouveau driver Message-ID: <1199012599.17626.13.camel@hughsie-laptop> As some of you may know I've been packaging and testing nouveau (the free NVIDIA 3D driver) for some time. The current way the driver is packaged is making things very difficult to properly test on fedora: * The xf86-video-nv-2.1.5.tar.bz2 and nouveau-gitID.tar.gz are included in the xorg-x11-drv-nv-2.1.5 srpm. * This srpm spits out xorg-x11-drv-nv-2.1.5 and xorg-x11-drv-nouveau-2.1.5 rpm files when built. This poses me problems as: * I can't easily keep the original nv rpm intact when building the new nouveau * The upstream version of nouveau ddx is 1.2.0, and the rpm version is 2.1.5 * I can't uninstall the xorg-x11-drv-nv driver to test nouveau from source without nuking the nv driver too. I understand that one day the nouveau ddx will replace the nv ddx, but this can be accomplished with standard rpm obsoletes rather than shipping the nouveau source in the nv srpm. For me, I think the proper way of doing this would be to: * Have a nouveau srpm *and* a nv srpm - they are different codebases and have different version numbers * Somehow fix the brokenness that has lead to the version number xorg-x11-drv-nouveau-2.1.5 being installed when actually installed was xorg-x11-drv-nouveau-1.2.0 Ideas welcome. Richard. From colin at colina.demon.co.uk Sun Dec 30 11:04:23 2007 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun, 30 Dec 2007 11:04:23 +0000 Subject: Gobo Message-ID: I am interested in packaging Gobo for Fedora. Gobo (http://www.gobosoft.com) is a set of Eiffel class libraries, and includes a fast Eiffel compiler (on Linux, it uses gcc as a backend and also for bootstrapping itself). The license is MIT. What steps would I need to take to get this accepted? -- Colin Adams Preston Lancashire From mrmazda at ij.net Sun Dec 30 11:12:24 2007 From: mrmazda at ij.net (Felix Miata) Date: Sun, 30 Dec 2007 06:12:24 -0500 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions In-Reply-To: <200712301248.31541.ville.skytta@iki.fi> References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: <47777D18.5000808@ij.net> On 2007/12/30 12:48 (GMT+0200) Ville Skytt? apparently typed: > Where should this be fixed? Other distros in KControl right below "Fonts" have a selection "GTK Styles and Fonts". PITA that it doesn't. Dunno why F8 doesn't have it, unless it's a Fedora way to try to coerce KDE users into using Gnome. -- Jesus Christ, the reason for the season. Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From drago01 at gmail.com Sun Dec 30 11:14:56 2007 From: drago01 at gmail.com (drago01) Date: Sun, 30 Dec 2007 12:14:56 +0100 Subject: Difficulties testing the new nouveau driver In-Reply-To: <1199012599.17626.13.camel@hughsie-laptop> References: <1199012599.17626.13.camel@hughsie-laptop> Message-ID: <47777DB0.20502@gmail.com> Richard Hughes wrote: > As some of you may know I've been packaging and testing nouveau (the > free NVIDIA 3D driver) for some time. The current way the driver is > packaged is making things very difficult to properly test on fedora: > > * The xf86-video-nv-2.1.5.tar.bz2 and nouveau-gitID.tar.gz are included > in the xorg-x11-drv-nv-2.1.5 srpm. > * This srpm spits out xorg-x11-drv-nv-2.1.5 and > xorg-x11-drv-nouveau-2.1.5 rpm files when built. > > This poses me problems as: > > * I can't easily keep the original nv rpm intact when building the new > nouveau > * The upstream version of nouveau ddx is 1.2.0, and the rpm version is > 2.1.5 > * I can't uninstall the xorg-x11-drv-nv driver to test nouveau from > source without nuking the nv driver too. > > I understand that one day the nouveau ddx will replace the nv ddx, but > this can be accomplished with standard rpm obsoletes rather than > shipping the nouveau source in the nv srpm. For me, I think the proper > way of doing this would be to: > > * Have a nouveau srpm *and* a nv srpm - they are different codebases and > have different version numbers > +1 I see no reason why they should be in the same srpm. From andreas.bierfert at lowlatency.de Sun Dec 30 11:15:10 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 30 Dec 2007 12:15:10 +0100 Subject: Difficulties testing the new nouveau driver In-Reply-To: <1199012599.17626.13.camel@hughsie-laptop> References: <1199012599.17626.13.camel@hughsie-laptop> Message-ID: <20071230121510.3396e632@alkaid.a.lan> On Sun, 30 Dec 2007 11:03:19 +0000 Richard Hughes wrote: > * Have a nouveau srpm *and* a nv srpm - they are different codebases and > have different version numbers > * Somehow fix the brokenness that has lead to the version number > xorg-x11-drv-nouveau-2.1.5 being installed when actually installed was > xorg-x11-drv-nouveau-1.2.0 This seems like the right thing to do. To resolve the version problems you probably have to bump the epoch on nouveau and imho this situation is a valid reason to do so. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Dec 30 11:16:25 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 30 Dec 2007 20:16:25 +0900 Subject: Gobo In-Reply-To: References: Message-ID: <47777E09.5020202@ioa.s.u-tokyo.ac.jp> Colin Paul Adams wrote, at 12/30/2007 08:04 PM +9:00: > I am interested in packaging Gobo for Fedora. > > Gobo (http://www.gobosoft.com) is a set of Eiffel class libraries, and > includes a fast Eiffel compiler (on Linux, it uses gcc as a backend > and also for bootstrapping itself). > > The license is MIT. > > What steps would I need to take to get this accepted? Please check http://fedoraproject.org/wiki/PackageMaintainers/Join to import softwares into Fedora. Regards, Mamoru From drago01 at gmail.com Sun Dec 30 11:23:17 2007 From: drago01 at gmail.com (drago01) Date: Sun, 30 Dec 2007 12:23:17 +0100 Subject: Gobo In-Reply-To: References: Message-ID: <47777FA5.2020301@gmail.com> Colin Paul Adams wrote: > I am interested in packaging Gobo for Fedora. > > Gobo (http://www.gobosoft.com) is a set of Eiffel class libraries, and > includes a fast Eiffel compiler (on Linux, it uses gcc as a backend > and also for bootstrapping itself). > > The license is MIT. > > What steps would I need to take to get this accepted? > http://fedoraproject.org/wiki/PackageMaintainers/Join From buildsys at redhat.com Sun Dec 30 11:40:41 2007 From: buildsys at redhat.com (Build System) Date: Sun, 30 Dec 2007 06:40:41 -0500 Subject: rawhide report: 20071230 changes Message-ID: <200712301140.lBUBefBk012810@porkchop.devel.redhat.com> Updated Packages: audacious-1.4.5-1.fc9 --------------------- * Sat Dec 29 2007 Ralf Ertzinger 1.4.5-1 - Update to 1.4.5 * Mon Dec 03 2007 Ralf Ertzinger 1.4.4-1 - Update to 1.4.4 * Sat Dec 01 2007 Ralf Ertzinger 1.4.2-3 - Add patch to fix streams sometimes being left open - Obsolete: audacious-docklet audacious-plugins-1.4.3-1.fc9 ----------------------------- * Sat Dec 29 2007 Ralf Ertzinger 1.4.3-1 - Update to 1.4.3 audit-1.6.4-1.fc9 ----------------- * Sat Dec 29 2007 Steve Grubb 1.6.4-1 - fchmod of log file was on wrong variable (#426934) - Allow use of errno strings for exit codes in audit rules avrdude-5.5-1.fc9 ----------------- * Sat Dec 29 2007 Trond Danielsen - 5.5-1 - New upstream version - Fixed minor rpmlint warning. chess-1.0-11.fc9 ---------------- * Sat Dec 29 2007 Hans de Goede 1.0-11 - Rebuild for new ogre ecl-0.9j-1.fc9 -------------- * Sat Dec 29 2007 Gerard Milmeister - 0.9j-1 - new release 0.9j * Mon Aug 28 2006 Gerard Milmeister - 0.9i-3 - Rebuild for FE6 * Sun Jul 23 2006 Gerard Milmeister - 0.9i-2 - release number fix g-wrap-1.9.9-5.fc9 ------------------ * Sat Dec 29 2007 Xavier Lamien - 1.9.9-5 - Fixed bug #341471. gallery2-2.2.4-2.fc9 -------------------- * Sat Dec 29 2007 John Berninger 0.3.2-7 - Fix dhcpd lease directory ghex-2.21.4-1.1 --------------- * Sat Dec 29 2007 Thorsten Leemhuis - 2.21.4-1 - Update to 2.21.4 - Pass --disable-static to configure - remove obsolete rm -rf RPM_BUILD_ROOT/var/scrollkeeper from install section glpi-0.70-3.fc9 --------------- * Sat Dec 29 2007 Remi Collet - 0.70-3 - Changeset 6191 + 6194 + 6196 iso-codes-1.7-1.fc9 ------------------- * Sat Dec 29 2007 Christopher Aillon 1.7-1 - Update to 1.7 jabbim-0.3-0.57.20071230svn.fc9 ------------------------------- * Sun Dec 30 2007 Michal Schmidt - 0.3-0.57.20071230svn - Upstream SVN revision 1651. - more fixes in status messages, groupchat invitations, DNS resolving. * Sat Dec 29 2007 Michal Schmidt - 0.3-0.56.20071229svn - Upstream SVN revision 1637. - fixes setting of status. ndesk-dbus-glib-0.4.1-2.fc9 --------------------------- * Sat Dec 29 2007 David Nielsen - 0.4.1-2 - -devel now requires ndesk-dbus-devel ogre-1.4.6-1.fc9 ---------------- * Sat Dec 29 2007 Hans de Goede 1.4.6-1 - New upstream release 1.4.6 - Warning as always with a new upstream ogre release this breaks the ABI and changes the soname! ruby-gnome2-0.16.0-23.fc9 ------------------------- * Sun Dec 30 2007 Mamoru Tasaka 0.16.0-23 - Revert the wrong patch against src/lib/gtkmozembed.rb * Sun Dec 30 2007 Mamoru Tasaka 0.16.0-22 - Update xulrunner patch (#402591) - Some misc fix for maybe glib2 >= 2.15.0 - Workarround for #226381 c11 * Fri Dec 28 2007 Alex Lancaster 0.16.0-21 - Add xulrunner patch from bugzilla #402591 - Rebuild against gecko-lib 1.9 (xulrunner) scribes-0.3.3.1-1.fc9 --------------------- * Sat Dec 29 2007 Peter Gordon - 0.3.3.1-1 - Update to new upstream release (0.3.3.1). tibetan-machine-uni-fonts-1.901-1.fc9 ------------------------------------- varnish-1.1.2-5.fc9 ------------------- * Sat Dec 29 2007 Ingvar Hagelund - 1.1.2-5 - Added missing configuration examples - Corrected the license to "BSD" xfce4-notes-plugin-1.6.1-1.fc9 ------------------------------ * Sat Dec 29 2007 Christoph Wickert - 1.6.1-1 - Update to 1.6.1 - BR Thunar-devel for new file system monitoring feature xfce4-timer-plugin-0.6-2.fc9 ---------------------------- * Sat Dec 29 2007 Christoph Wickert - 0.6-2 - Bump release due to tag collision * Sat Dec 29 2007 Christoph Wickert - 0.6-1 - Update to 0.6 xtide-2.9.5-2.fc9 ----------------- * Sun Dec 30 2007 Mamoru Tasaka - 2.9.5-2 - Update harmonics data to 20071228 Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 nx - 2.1.0-22.fc7.i386 requires libcrypto.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) nx - 2.1.0-22.fc7.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan From kevin.kofler at chello.at Sun Dec 30 13:00:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 30 Dec 2007 13:00:38 +0000 (UTC) Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > Where should this be fixed? Shouldn't GNOME apps that use settings governed > by the daemon get the daemon running if needed? Can't GNOME apps be made to > look semi decent (eg. no broken icons) without the daemon running? What if > gnome-settings-daemon isn't even installed? Should KDE start > gnome-settings-daemon when a session starts? I guess we should be checking if gnome-settings-daemon is installed and running it if it is, in an autostart script in kdebase(-workspace) or kde-settings. But I'll discuss this with the other KDE SIG folks. Kevin Kofler From kevin.kofler at chello.at Sun Dec 30 13:03:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 30 Dec 2007 13:03:25 +0000 (UTC) Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> <47777D18.5000808@ij.net> Message-ID: Felix Miata ij.net> writes: > Other distros in KControl right below "Fonts" have a selection "GTK Styles > and Fonts". PITA that it doesn't. Dunno why F8 doesn't have it, unless it's a AFAIK, this KControl module is provided by the gtk-qt-engine, and works independently of whether you actually use that as your GTK+ theme or not. So install our gtk-qt-engine theme to get it. > Fedora way to try to coerce KDE users into using Gnome. Nobody is trying to coerce you into using GNOME. :-) Kevin Kofler From kevin.kofler at chello.at Sun Dec 30 13:11:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 30 Dec 2007 13:11:03 +0000 (UTC) Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> <47777D18.5000808@ij.net> Message-ID: Oops, I wrote: > install our gtk-qt-engine theme to get it. I actually meant "install our gtk-qt-engine _package_". The theme itself isn't Fedora's work, of course. ;-) Kevin Kofler From rdieter at math.unl.edu Sun Dec 30 13:25:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Dec 2007 07:25:23 -0600 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: Kevin Kofler wrote: > Ville Skytt? iki.fi> writes: >> Where should this be fixed? Shouldn't GNOME apps that use settings >> governed >> by the daemon get the daemon running if needed? Can't GNOME apps be made >> to >> look semi decent (eg. no broken icons) without the daemon running? What >> if >> gnome-settings-daemon isn't even installed? Should KDE start >> gnome-settings-daemon when a session starts? > > I guess we should be checking if gnome-settings-daemon is installed and > running it if it is, in an autostart script in kdebase(-workspace) or > kde-settings. But I'll discuss this with the other KDE SIG folks. IMO, this isn't a "kde"-specific problem per-se, this same issue will arise using any desktop != gnome. To me, begs the question, why don't gnome apps "just work" when launched outside of a gnome environment? -- Rex From kevin.kofler at chello.at Sun Dec 30 13:54:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 30 Dec 2007 13:54:38 +0000 (UTC) Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: Rex Dieter math.unl.edu> writes: > IMO, this isn't a "kde"-specific problem per-se, this same issue will arise > using any desktop != gnome. To me, begs the question, why don't gnome > apps "just work" when launched outside of a gnome environment? That's a good question to ask. KDE apps can autolaunch all the daemons they need to run, why can't GNOME apps do the same? Kevin Kofler From ville.skytta at iki.fi Sun Dec 30 14:45:13 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 30 Dec 2007 16:45:13 +0200 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions In-Reply-To: References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: <200712301645.15378.ville.skytta@iki.fi> On Sunday 30 December 2007, Rex Dieter wrote: > Kevin Kofler wrote: > > Ville Skytt? iki.fi> writes: > >> Where should this be fixed? Shouldn't GNOME apps that use settings > >> governed > >> by the daemon get the daemon running if needed? Can't GNOME apps be > >> made to > >> look semi decent (eg. no broken icons) without the daemon running? What > >> if > >> gnome-settings-daemon isn't even installed? Should KDE start > >> gnome-settings-daemon when a session starts? > > > > I guess we should be checking if gnome-settings-daemon is installed and > > running it if it is, in an autostart script in kdebase(-workspace) or > > kde-settings. But I'll discuss this with the other KDE SIG folks. > > IMO, this isn't a "kde"-specific problem per-se, this same issue will arise > using any desktop != gnome. To me, begs the question, why don't gnome > apps "just work" when launched outside of a gnome environment? Right, that would be preferable. (I actually asked that question in a bunch of different forms in my initial mail.) But without knowing anything about whether it's considered a "feature" or if it's hard to fix or not, I think launching the daemon in $DE session startup scripts would be an acceptable and easy enough temporary fix until there's a better solution. Interestingly enough, some apps seem to launch the daemon if it's not already running. For example clicking some (but not all) buttons in gnome-control-center do it. That doesn't happen with the majority (or any?) of other GNOME/GTK apps I regularly use though. From ville.skytta at iki.fi Sun Dec 30 15:21:07 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 30 Dec 2007 17:21:07 +0200 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions In-Reply-To: References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: <200712301721.09417.ville.skytta@iki.fi> On Sunday 30 December 2007, Kevin Kofler wrote: > Oops, I wrote: > > install our gtk-qt-engine theme to get it. > > I actually meant "install our gtk-qt-engine _package_". Ok, that looks useful, but helps only for a subset of the issues. For example, it doesn't help with broken gnome-control-center icons. Even so, I think having it installed by default in KDE setups could be an improvement (no new deps caused as at least zenity which is there by default already pulls in gtk stuff). comps-f9 patch attached. On the other hand, a running gnome-settings-daemon appears to override gtk-qt-engine's settings so that they have no effect. So if there's going to be a change so that KDE will launch gnome-settings-daemon at session startup, there doesn't seem to be point in having gtk-qt-engine installed by default any more. -------------- next part -------------- A non-text attachment was scrubbed... Name: comps-f9.patch Type: text/x-diff Size: 1158 bytes Desc: not available URL: From lsof at nodata.co.uk Sun Dec 30 18:05:56 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 30 Dec 2007 19:05:56 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> Message-ID: <1199037956.5463.18.camel@sb-home> Am Montag, den 17.12.2007, 01:57 +0000 schrieb Jonathan Underwood: > On 16/12/2007, Stewart Adam wrote: > > As well, I've got 29 applications listed under 'System Tools'. I > > understand that not everyone does because it obviously depends on which > > packages you have installed, but many entries do similar tasks > > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > > saved by putting them into a submenu. > > Related to this is something that is currently driving me utterly > crazy with F-8 (not sure if this has changed in rawhide) - why do we > have > > Application->System Tools and > System->Preferences->System and > System->Administration. > > Most users will not understand the distinction (if indeed there even > is one). This is in pretty bad need of being rationalised. +1 From lsof at nodata.co.uk Sun Dec 30 18:09:20 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 30 Dec 2007 19:09:20 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> Message-ID: <1199038160.5463.22.camel@sb-home> Am Sonntag, den 16.12.2007, 13:36 -0900 schrieb Jeff Spaleta: > On Dec 16, 2007 10:50 AM, Stewart Adam wrote: > > As well, I've got 29 applications listed under 'System Tools'. I > > understand that not everyone does because it obviously depends on which > > packages you have installed, but many entries do similar tasks > > (Terminal, Konsole, Konsole Super User Mode). A lot of space could be > > saved by putting them into a submenu. > > submenus... by default for all usage cases? I don't think this makes > any sense at all. Good point. But why must a user choose a category in order to find an application? Surely a menu is only useful if the user doesn't know what the application is called. Surely an app can be in multiple categories? I'm not a fan of hunting through menus. It makes no sense to me that my (Evolution) address book is under the "Internet" menu, but my calendar is under "Office". Perhaps we should look for a different approach. From loupgaroublond at gmail.com Sun Dec 30 19:52:07 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 30 Dec 2007 14:52:07 -0500 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1199038160.5463.22.camel@sb-home> References: <1197834610.32070.47.camel@Diffingo.localdomain> <604aa7910712161436u18aceacek89faaac3f7c20c0c@mail.gmail.com> <1199038160.5463.22.camel@sb-home> Message-ID: <7f692fec0712301152t765470falf3489d68bc89b41a@mail.gmail.com> On Dec 30, 2007 1:09 PM, nodata wrote: > Good point. But why must a user choose a category in order to find an > application? Surely a menu is only useful if the user doesn't know what > the application is called. Surely an app can be in multiple categories? > > I'm not a fan of hunting through menus. It makes no sense to me that my > (Evolution) address book is under the "Internet" menu, but my calendar > is under "Office". > > Perhaps we should look for a different approach. You probably want some kind of task oriented tag system, instead of just using categories. Your address book, email, and browser all belong to the Internet task. Your address book, email, and address book all belong to the PIM task. Your calendar/todo system, word processor, and spreadsheet all belong to the Office/Workflow task. Of course, the system isn't set up for it nearly as well as it is for just pigeonholing everything into single categories, so I just put my most frequently used apps on a bar on the side of my desktop, and touch the menu system rarely. Alot of the desktops, except for Gnome and OS X seem to focus on monitoring which apps get clicked on the most, and try to provide this for you automagically. They fail, because rather than making things easy, they put a bunch of frequently used items in unpredictable spaces, forcing the user to hesitate when trying to do what he/she does the most often. Of course we probably need some good usability studies, and I'm sure Microsoft has enough money invested in their POS start menu that says users like having their commonly used programs shift position regularly. A task oriented desktop has been my (increasingly devalued) 0.02 USD for the past year and half though. -Yaakov From triad at df.lth.se Sun Dec 30 21:35:17 2007 From: triad at df.lth.se (Linus Walleij) Date: Sun, 30 Dec 2007 22:35:17 +0100 (CET) Subject: Opinions welcome: Restructuring the system menus In-Reply-To: <1199037956.5463.18.camel@sb-home> References: <1197834610.32070.47.camel@Diffingo.localdomain> <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> <1199037956.5463.18.camel@sb-home> Message-ID: I put my EUR 0.01 into bug 249204 on the system menu inputs: https://bugzilla.redhat.com/show_bug.cgi?id=249204 Linus From mclasen at redhat.com Mon Dec 31 01:02:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 30 Dec 2007 20:02:37 -0500 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions In-Reply-To: References: <200712301248.31541.ville.skytta@iki.fi> Message-ID: <1199062957.4326.2.camel@localhost.localdomain> On Sun, 2007-12-30 at 13:00 +0000, Kevin Kofler wrote: > Ville Skytt? iki.fi> writes: > > Where should this be fixed? Shouldn't GNOME apps that use settings governed > > by the daemon get the daemon running if needed? Can't GNOME apps be made to > > look semi decent (eg. no broken icons) without the daemon running? What if > > gnome-settings-daemon isn't even installed? Should KDE start > > gnome-settings-daemon when a session starts? > > I guess we should be checking if gnome-settings-daemon is installed and running > it if it is, in an autostart script in kdebase(-workspace) or kde-settings. But > I'll discuss this with the other KDE SIG folks. > What should rather happen is that kde should run an xsettings manager that maps kde settings to xsettings where it makes sense. That will let you use kde tools to configure gtk applications, at least for basic things that are covered by xsettings. I thought there was an xsettings manager for kde somewhere. Does the Fedora KDE include that ? From rdieter at math.unl.edu Mon Dec 31 02:43:25 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Dec 2007 20:43:25 -0600 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> <1199062957.4326.2.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > I thought there was an xsettings > manager for kde somewhere. Does the Fedora KDE include that ? Not that I'm aware, but I'd love to be wrong here. -- Rex From rdieter at math.unl.edu Mon Dec 31 03:58:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Dec 2007 21:58:16 -0600 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> <1199062957.4326.2.camel@localhost.localdomain> Message-ID: Rex Dieter wrote: > Matthias Clasen wrote: > >> I thought there was an xsettings >> manager for kde somewhere. Does the Fedora KDE include that ? > > Not that I'm aware, but I'd love to be wrong here. Did some digging, looks like Mandriva includes a home-brew package named xsettings-kde, and it looks like it could serve nicely. (and why oh why was this never upstreamed...) -- Rex From dmc.fedora at filteredperception.org Mon Dec 31 00:37:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 30 Dec 2007 18:37:25 -0600 Subject: gripe/question: /etc/sysconfig/system-config-firewall??? Message-ID: <477839C5.6040200@filteredperception.org> Anybody care to explain to me the logic of the file /etc/sysconfig/system-config-firewall which makes my kickstart and/or lokkit invocations not be respected? I.e. port 22 remains open even if I do lokkit --enabled (or just firewall --enabled in kickstart) It seems like if anything lokkit should be writing this file, not reading one installed by an rpm. But maybe I just need a clue. ??? -dmc From dmc.fedora at filteredperception.org Mon Dec 31 01:10:44 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 30 Dec 2007 19:10:44 -0600 Subject: gripe/question: /etc/sysconfig/system-config-firewall??? In-Reply-To: <477839C5.6040200@filteredperception.org> References: <477839C5.6040200@filteredperception.org> Message-ID: <47784194.3060002@filteredperception.org> Douglas McClendon wrote: > Anybody care to explain to me the logic of the file > > /etc/sysconfig/system-config-firewall > > which makes my kickstart and/or lokkit invocations not be respected? > > I.e. port 22 remains open even if I do > > lokkit --enabled > > (or just firewall --enabled in kickstart) > > It seems like if anything lokkit should be writing this file, not > reading one installed by an rpm. But maybe I just need a clue. ??? Bahh, I still need a clue, but I'm suspecting now that something did write to that file and it doesn't have 22 in it as installed. But having seen but not read the thread here about packages opening up ports in the firewall rules, I did do rpm -q --scripts openssh-server and didn't see IT doing anything that would write to that file. clue please...??? Basic issue: I do a kickstart install with firewall --enabled NOT firewall --enabled --port=22:tcp and I still see port 22 open, and the only clue I've found is that if I delete the contents of /etc/sysconfig/system-config-firewall, then I can actually get 22 closed via 'lokkit --enabled' which seems to be the appropriate way. (though it seems like it should work without having to muck with the sysconfig file) -dmc From buildsys at redhat.com Mon Dec 31 11:56:56 2007 From: buildsys at redhat.com (Build System) Date: Mon, 31 Dec 2007 06:56:56 -0500 Subject: rawhide report: 20071231 changes Message-ID: <200712311156.lBVBuudc016463@porkchop.devel.redhat.com> New package gpar2 GUI for verifying and repairing PAR and PAR2 recovery sets New package gwave GPLed Analog Waveform Viewing Environment New package libpar2 Library for performing comman tasks related to PAR recovery sets Removed package kdmtheme Updated Packages: alltray-0.70-1.fc9 ------------------ * Sun Dec 30 2007 Denis Leroy - 0.70-1 - Update to upstream 0.70 aspell-mr-0.10-3.fc9 -------------------- audacious-plugins-1.4.3.1-1.fc9 ------------------------------- * Sat Dec 29 2007 Ralf Ertzinger 1.4.3.1-1 - Update to 1.4.3.1 audit-1.6.4-3.fc9 ----------------- * Sun Dec 30 2007 Steve Grubb 1.6.4-3 - Allow 0600 file perms for audit logs bash-completion-20060301-8.fc9 ------------------------------ * Mon Dec 31 2007 Ville Skytt?? - 20060301-8 - Associate VDR recording files with media players. - Update mock completion. brasero-0.7.0-1.fc9 ------------------- * Sun Dec 30 2007 Denis Leroy - 0.7.0-1 - Update to upstream 0.7.0, updated BRs - Forward-ported open() permission patch compiz-fusion-0.6.0-11.fc9 -------------------------- * Sun Dec 30 2007 Adel Gadllah 0.6.0-11 - Fix stupid typo in the patch * Thu Dec 27 2007 Adel Gadllah 0.6.0-10 - Plug small memory leak * Thu Dec 27 2007 Adel Gadllah 0.6.0-9 - Don't break legacy apps that want to unfullscreen themselves devhelp-0.16.1-5.fc9 -------------------- * Mon Dec 31 2007 Jeremy Katz - 0.16.1-5 - Rebuild against newer xulrunner gnome-packagekit-0.1.5-2.fc9 ---------------------------- * Sun Dec 30 2007 Christopher Aillon - 0.1.5-2 - Fix the build * Fri Dec 21 2007 Robin Norwood - 0.1.5-1 - Update to latest upstream version: 0.1.5 hyperestraier-1.4.13-1.fc9 -------------------------- * Sun Dec 30 2007 Mamoru Tasaka - 1.4.13-1 - 1.4.13 kde-filesystem-4-5.fc9 ---------------------- * Sun Dec 30 2007 Rex Dieter 4-5 - +%_datadir/autostart, %_kde4_datadir/autostart kdebase-workspace-3.97.0-5.fc9 ------------------------------ * Mon Dec 31 2007 Kevin Kofler - 3.97.0-5 - fix createGtkrc to set tooltip colors also for GTK+ 2.12+ * Sun Dec 30 2007 Kevin Kofler 3.97.0-4 - Obsoletes: kdmtheme kdebase3-3.5.8-27.fc9 --------------------- * Mon Dec 31 2007 Kevin Kofler - 3.5.8-27 - fix createGtkrc to set tooltip colors also for GTK+ 2.12+ * Fri Dec 21 2007 Luk???? Tinkl - 3.5.8-26 - fix kded crash on logout (#426459) * Tue Dec 18 2007 Lukas Tinkl - 3.5.8-25 - fix Firefox detection in Klipper (#377171) libburn-0.4.0-1.fc9 ------------------- * Thu Dec 13 2007 Denis Leroy - 0.4.0-1 - Update to 0.4.0 libupnp-1.6.3-2.fc9 ------------------- * Sun Dec 30 2007 Eric Tanguy - 1.6.3-2 - Spec file cleanup * Sun Dec 30 2007 Eric Tanguy - 1.6.3-1 - Update to version 1.6.3 m17n-contrib-1.1.5-1.fc9 ------------------------ * Mon Dec 31 2007 Parag Nemade -1.1.5-1.fc9 - Update to new upstream release 1.1.5 nx-2.1.0-24.fc9 --------------- * Sun Dec 09 2007 Alex Lancaster - 2.1.0-24 - Rebuild for new openssl soname bump * Fri Sep 21 2007 Lubomir Kundrak - 2.1.0-23 - Fix Source addresses (#248533) perl-DateTime-Set-0.25-5.fc9 ---------------------------- * Sun Dec 30 2007 Ralf Cors??pius - 0.25-5 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-IO-All-0.38-2.fc9 ---------------------- * Mon Dec 31 2007 Ralf Cors??pius 0.38-2 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-Log-Message-0.01-4.fc9 --------------------------- * Sun Dec 30 2007 Ralf Cors??pius - 0.01-4 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). * Wed Apr 18 2007 Steven Pritchard 0.01-3 - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. * Sat Sep 16 2006 Steven Pritchard 0.01-2 - Fix find option order. perl-Log-Message-Simple-0.02-2.fc9 ---------------------------------- * Sun Dec 30 2007 Ralf Cors??pius - 0.02-2 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-Module-Install-0.67-2.fc9 ------------------------------ * Sun Dec 30 2007 Ralf Cors??pius - 0.67-2 - BR: perl(Test::More), perl(CPAN) (BZ 419631). - Remove TEST_POD (Unused). - Add AUTOMATED_TESTING. - BR: perl(Test::Pod) for AUTOMATED_TESTING. - Adjust License-tag. perl-Module-Loaded-0.01-4.fc9 ----------------------------- * Sun Dec 30 2007 Ralf Cors??pius - 0.01-4 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-Package-Constants-0.01-4.fc9 --------------------------------- * Sun Dec 30 2007 Ralf Cors??pius 0.01-4 - BR: perl(Test::More) (BZ 419631). - Adjust License-tag. perl-Params-Check-0.26-2.fc9 ---------------------------- * Mon Dec 31 2007 Ralf Cors??pius 0.26-2 - BR: perl(Test::More) (BZ 419631). - Adjust License-tag. perl-Test-Portability-Files-0.05-5.fc9 -------------------------------------- * Sun Dec 30 2007 Ralf Cors??pius - 0.05-5 - BR: perl(Test::More). - BR: perl(Test::Pod), perl(Test::Pod::Coverage). - Adjust License-tag. pm-utils-0.99.4-7.fc9 --------------------- * Sun Dec 30 2007 Till Maas - 0.99.4-7 - fix some bugs (RH #302401) popt-1.13-1.fc9 --------------- * Sun Dec 30 2007 Robert Scheck 1.13-1 - Upgrade to 1.13 (#290531, #332201, #425803) - Solved multilib problems at doxygen generated files (#342921) q-7.10-1.fc9 ------------ * Sun Dec 30 2007 Gerard Milmeister - 7.10-1 - new release 7.10 selinux-policy-3.2.5-6.fc9 -------------------------- unixODBC-2.2.12-5.fc9 --------------------- * Sun Dec 30 2007 Tom Lane 2.2.12-5 - Add missing BuildRequires for flex. Resolves: #427063 warzone2100-2.0.10-1.fc9 ------------------------ * Sun Dec 30 2007 Karol Trzcionka - 2.0.10-1 - Update to v2.0.10 wordpress-2.3.2-1.fc9 --------------------- * Sun Dec 30 2007 Adrian Reber - 2.3.2-1 - updated to 2.3.2 (bz 426431, Draft Information Disclosure) yelp-2.21.1-3.fc9 ----------------- * Sun Dec 30 2007 Jeremy Katz - 2.21.1-3 - Rebuild for new xulrunner Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.i386 requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.i386 requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.i386 requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.x86_64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-alsa - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-capi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-jabber - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-javascript - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ldap - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-misdn - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libssl.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires libcrypto.so.6 callweaver-mysql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-odbc - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-ogi - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires libldap-2.3.so.0 callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc requires liblber-2.3.so.0 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-alsa - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-bluetooth - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-capi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-jabber - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-javascript - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ldap - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-misdn - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libcrypto.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires libssl.so.6()(64bit) callweaver-mysql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-odbc - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-ogi - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-postgresql - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires libldap-2.3.so.0()(64bit) callweaver-zaptel - 1.2-0.3.rc4.20070822.ppc64 requires liblber-2.3.so.0()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan From nphilipp at redhat.com Mon Dec 31 12:02:44 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 31 Dec 2007 13:02:44 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1198929588.31425.5.camel@localhost.localdomain> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> Message-ID: <1199102564.8488.64.camel@gibraltar.str.redhat.com> On Sat, 2007-12-29 at 12:59 +0100, David Nielsen wrote: > Personally when it comes to burning I favor integrating it in the places > where I really want that functionality as I have a hard time seeing how > aside historically being burdened as such this is functionality that > requires or is best utilized as a seperate task. Burning a music cd > should be in Banshee, photo cds in f-spot and so on. And authoring a CD (think of mixed mode CDs, or if you want/need to tweak settings, or exact copies of audio CDs so they later still work with cddb and don't annoy you with gaps between live tracks ;-)) should be done in an authoring program (that's how I see k3b nowadays). 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 Mon Dec 31 12:40:31 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 31 Dec 2007 13:40:31 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> <1199037956.5463.18.camel@sb-home> Message-ID: <1199104831.8488.69.camel@gibraltar.str.redhat.com> On Sun, 2007-12-30 at 22:35 +0100, Linus Walleij wrote: > I put my EUR 0.01 into bug 249204 on the system menu inputs: > https://bugzilla.redhat.com/show_bug.cgi?id=249204 This bug is not about the system menu, but system-config-services. Some of your suggestions were not about system-config-services either, you should file them against more appropriate components ;-). 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 Mon Dec 31 12:40:31 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 31 Dec 2007 13:40:31 +0100 Subject: Opinions welcome: Restructuring the system menus In-Reply-To: References: <1197834610.32070.47.camel@Diffingo.localdomain> <645d17210712161757p113dce95q18dc1992c4ef6627@mail.gmail.com> <1199037956.5463.18.camel@sb-home> Message-ID: <1199104831.8488.69.camel@gibraltar.str.redhat.com> On Sun, 2007-12-30 at 22:35 +0100, Linus Walleij wrote: > I put my EUR 0.01 into bug 249204 on the system menu inputs: > https://bugzilla.redhat.com/show_bug.cgi?id=249204 This bug is not about the system menu, but system-config-services. Some of your suggestions were not about system-config-services either, you should file them against more appropriate components ;-). 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 kanarip at kanarip.com Mon Dec 31 14:27:30 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 31 Dec 2007 15:27:30 +0100 Subject: gripe/question: /etc/sysconfig/system-config-firewall??? In-Reply-To: <47784194.3060002@filteredperception.org> References: <477839C5.6040200@filteredperception.org> <47784194.3060002@filteredperception.org> Message-ID: <4778FC52.3040501@kanarip.com> Douglas McClendon wrote: > Douglas McClendon wrote: >> Anybody care to explain to me the logic of the file >> >> /etc/sysconfig/system-config-firewall >> >> which makes my kickstart and/or lokkit invocations not be respected? >> >> I.e. port 22 remains open even if I do >> >> lokkit --enabled >> >> (or just firewall --enabled in kickstart) >> >> It seems like if anything lokkit should be writing this file, not >> reading one installed by an rpm. But maybe I just need a clue. ??? > > Bahh, I still need a clue, but I'm suspecting now that something did > write to that file and it doesn't have 22 in it as installed. But > having seen but not read the thread here about packages opening up ports > in the firewall rules, I did do rpm -q --scripts openssh-server and > didn't see IT doing anything that would write to that file. clue > please...??? > > Basic issue: I do a kickstart install with > > firewall --enabled > > NOT > > firewall --enabled --port=22:tcp > > and I still see port 22 open, and the only clue I've found is that if I > delete the contents of /etc/sysconfig/system-config-firewall, then I can > actually get 22 closed via 'lokkit --enabled' which seems to be the > appropriate way. (though it seems like it should work without having to > muck with the sysconfig file) > I'm not sure how /etc/sysconfig/system-config-firewall is /actually/ related to iptables (or -the service- /etc/sysconfig/iptables if you will), other then providing a set of defaults for the s-c-f application itself (firstboot uses it too maybe?). I agree with you though firewall --enabled should lock down the box, and not have a sneaky --port=22:tcp, but I don't know how (other then %post) and I don't know if it's related to /etc/sysconfig/s-c-f Just my $0.02 Kind regards, Jeroen van Meeuwen -kanarip From fedora at leemhuis.info Mon Dec 31 15:30:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 31 Dec 2007 16:30:01 +0100 Subject: Asterisk and EPEL In-Reply-To: <47766506.4020007@gmx.net> References: <47766506.4020007@gmx.net> Message-ID: <47790AF9.6020603@leemhuis.info> On 29.12.2007 16:17, Frank B?ttner wrote: > how looks it about asterisk at the EPEL repo? There was a thread discussing this on the epel-devel-list some days ago: https://www.redhat.com/archives/epel-devel-list/2007-December/msg00120.html CU knurd From martin at marquesminen.com.ar Mon Dec 31 15:58:57 2007 From: martin at marquesminen.com.ar (Martin Marques) Date: Mon, 31 Dec 2007 12:58:57 -0300 Subject: New tzdata In-Reply-To: References: <4776708A.9050004@marquesminen.com.ar> Message-ID: <477911C1.10402@marquesminen.com.ar> Kevin Kofler escribi?: > Martin Marques marquesminen.com.ar> writes: >> Will there be a new tzdata available as tonight, and by a new law, we >> will have a daylight hour change in Argentina? > > WTF!? Are they crazy? They announce a DST change with only 3 (!!!) days notice, > when most of the world is on holidays?! How are they expecting software to get > updated in time? :-/ Don't even mention it. The worst part is that we are already ahead in 1 hour, and now we are 2 hours in the atlantic. :-( The citizens are very happy with the change, especially the ones closer to Chile which have sun light until 10pm. From louisg00 at bellsouth.net Mon Dec 31 16:12:06 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Mon, 31 Dec 2007 11:12:06 -0500 Subject: kernel build failed last few times Message-ID: <1199117526.3056.2.camel@sonlaptop> Koji shows that kernel build failed for the last few times. Anyone looking into this? From fedora at leemhuis.info Mon Dec 31 16:30:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 31 Dec 2007 17:30:50 +0100 Subject: EPEL report week 52 2007 Message-ID: <4779193A.5010901@leemhuis.info> = Weekly EPEL Summary = Week 52/2007 == Most important happenings == * Some problems on the builders; for more details see [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00193.html this mail] * lots of new packages this week; much thx to Patrice Dumas, who made a lot of them available in EPEL == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2007-December/msg00152.html BUG: clamav packages badly broken] == Meeting == === Next Meeting === 20080201 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === There was non scheduled. == Stats == === General === Number of EPEL Contributors: 165 We welcome 4 new contributors: alexl danken jcarlson jdieter === EPEL 5 === Number of source packages: 944 Number of binary packages: 1733 There are 21 new Packages: * flasm | Flash bytecode assembler disassembler * gnochm | CHM file viewer * hspell | A Hebrew spell checker * kchmviewer | CHM viewer with KDE support * libdockapp | DockApp Development Standard Library * libnc-dap | The NetCDF interface to DAP-2 from OPeNDAP * libsx | Simple X library * ooo2txt | Convert OpenOffice documents to simple text * pam_ssh | PAM module for use with SSH keys and ssh-agent * perl-File-BaseDir | Use the freedesktop basedir spec * perl-File-DesktopEntry | Object to handle .desktop files * perl-File-NFSLock | Perl module to do NFS (or not) locking * perl-Heap | Perl extension for keeping data partially sorted * perl-LWP-Authen-Wsse | Library for enabling X-WSSE authentication in LWP * perl-Statistics-Descriptive | Perl module of basic descriptive statistical functions * perl-Text-CHM | Perl extension for handling MS Compiled HtmlHelp Files * perl-Text-Unidecode | US-ASCII transliterations of Unicode text * pwgen | Automatic password generation * python-alsa | Python binding for the ALSA library * python-chm | Python package for CHM files handling * tetex-elsevier | Elsevier LaTeX style files and documentation === EPEL 4 === Number of source packages: 558 Number of binary packages: 1075 There are 24 new Packages: * codeblocks | An open source, cross platform, free C++ IDE * flasm | Flash bytecode assembler disassembler * kchmviewer | CHM viewer with KDE support * libdockapp | DockApp Development Standard Library * libnc-dap | The NetCDF interface to DAP-2 from OPeNDAP * libsx | Simple X library * ooo2txt | Convert OpenOffice documents to simple text * pam_ssh | PAM module for use with SSH keys and ssh-agent * perl-Devel-Symdump | A Perl module for inspecting Perl's symbol table * perl-File-BaseDir | Use the freedesktop basedir spec * perl-File-NFSLock | Perl module to do NFS (or not) locking * perl-Heap | Perl extension for keeping data partially sorted * perl-LWP-Authen-Wsse | Library for enabling X-WSSE authentication in LWP * perl-Parse-Yapp | Perl extension for generating and using LALR parsers * perl-Pod-Coverage | Checks if the documentation of a module is comprehensive * perl-Statistics-Descriptive | Perl module of basic descriptive statistical functions * perl-Test-Builder-Tester | Test runner for Test::Builder testsuites * perl-Test-Pod-Coverage | Check for pod coverage in your distribution * perl-Test-Pod | Perl module for checking for POD errors in files * perl-Text-CHM | Perl extension for handling MS Compiled HtmlHelp Files * perl-Text-Unidecode | US-ASCII transliterations of Unicode text * pwgen | Automatic password generation * python-chm | Python package for CHM files handling * wxGTK | GTK2 port of the wxWidgets GUI library ---- ["CategoryEPELReports"] From caillon at redhat.com Mon Dec 31 16:29:42 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 31 Dec 2007 17:29:42 +0100 Subject: kernel build failed last few times In-Reply-To: <1199117526.3056.2.camel@sonlaptop> References: <1199117526.3056.2.camel@sonlaptop> Message-ID: <477918F6.8060309@redhat.com> On 12/31/2007 05:12 PM, Louis E Garcia II wrote: > Koji shows that kernel build failed for the last few times. Anyone > looking into this? You might want to read the list archives from several days ago. From rdieter at math.unl.edu Mon Dec 31 19:57:24 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 31 Dec 2007 13:57:24 -0600 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions References: <200712301248.31541.ville.skytta@iki.fi> <1199062957.4326.2.camel@localhost.localdomain> Message-ID: Rex Dieter wrote: > Rex Dieter wrote: > >> Matthias Clasen wrote: >> >>> I thought there was an xsettings >>> manager for kde somewhere. Does the Fedora KDE include that ? >> >> Not that I'm aware, but I'd love to be wrong here. > > Did some digging, looks like Mandriva includes a home-brew package named > xsettings-kde, and it looks like it could serve nicely. > > (and why oh why was this never upstreamed...) fyi, xsettings-kde is now packaged and in the kde-redhat/testing repo, at least until it is properly reviewed and in fedora. -- Rex From lowen at pari.edu Mon Dec 31 20:21:59 2007 From: lowen at pari.edu (Lamar Owen) Date: Mon, 31 Dec 2007 15:21:59 -0500 Subject: GNU Radio Message-ID: <200712311522.00012.lowen@pari.edu> Before I go into the whole process of coming up to speed with the Fedora packaging guidelines, etc, I wanted to ask here if anyone else here is working on GNU Radio packages for Fedora. If not, I'm going to work on such; it may take me a little time to come up to speed with 'modern' packaging (it has, after all, been a little while since I last spun a PostgreSQL RPMset, back in 2004). So I know I have a lot to learn; thankfully, the documentation is far superior to what I remember in 2004 and earlier.... -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From debarshi.ray at gmail.com Mon Dec 31 20:28:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 1 Jan 2008 01:58:03 +0530 Subject: GNU Radio In-Reply-To: <200712311522.00012.lowen@pari.edu> References: <200712311522.00012.lowen@pari.edu> Message-ID: <3170f42f0712311228q5429c06do4e1c4f6225422284@mail.gmail.com> > Before I go into the whole process of coming up to speed with the Fedora > packaging guidelines, etc, I wanted to ask here if anyone else here is > working on GNU Radio packages for Fedora. GNU Radio is there on the WishList: http://fedoraproject.org/wiki/PackageMaintainers/WishList and no one has claimed it there yet. Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ (Fedora) * http://fedora.glug-nith.org/ (Fedora) * http://gnu.glug-nith.org/ (GNU) * http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP) From dwalsh at redhat.com Mon Dec 31 20:39:42 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 15:39:42 -0500 Subject: SELinux macro broken? In-Reply-To: <1198688969.14312.2.camel@choeger4> References: <1198688969.14312.2.camel@choeger4> Message-ID: <4779538E.9000400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph H?ger wrote: > Hi, > > when I tried to build a custom SELinux module, this strange behavior > occured: > > when I used: > > libs_read_lib_files(tomcat5_t) > > I got "read" denied source: tomcat5_t target: lib_t > > but using > > require { > type lib_t; > type tomcat5_t; > class file read; > } > > allow tomcat5_t lib_t:file read; > > worked fine. Although this should essentially be the same in my > understanding. > > Any explanations for that? > > regards > > christoph > Please attach the compilation errors. tomcat5_t is marked as a domain_type? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5U44ACgkQrlYvE4MpobP9egCdG+J82YNQyTFNSKnh7uyku4Aa iAgAoKR7A+DEWGIFNJV+48MPt+BlxIyr =wOR2 -----END PGP SIGNATURE----- From lowen at pari.edu Mon Dec 31 20:50:41 2007 From: lowen at pari.edu (Lamar Owen) Date: Mon, 31 Dec 2007 15:50:41 -0500 Subject: GNU Radio In-Reply-To: <3170f42f0712311228q5429c06do4e1c4f6225422284@mail.gmail.com> References: <200712311522.00012.lowen@pari.edu> Message-ID: <200712311550.41528.lowen@pari.edu> On Monday 31 December 2007, Debarshi 'Rishi' Ray wrote: > > Before I go into the whole process of coming up to speed with the Fedora > > packaging guidelines, etc, I wanted to ask here if anyone else here is > > working on GNU Radio packages for Fedora. > > GNU Radio is there on the WishList: > http://fedoraproject.org/wiki/PackageMaintainers/WishList and no one > has claimed it there yet. Yeah, I saw it on the Wishlist, but didn't know if it had yet been claimed. The only potential snags I know of with it are the two firmware files needed for the usrp portion of the package; the one is the firmware for the USB device controller on the USRP, which is easily generated with the free toolchain 'sdcc' already in Fedora, and thus isn't probably a snag at all. On the other hand, the FPGA bitstream, while it itself is open and the verilog source is GPL'd, it needs a non-Free toolchain (Quartus II; although the web edition is no-cost, it is not Free) to build. Prebuilt FPGA bitstreams meet the requirements mentioned in the Firmware section of the packaging guidelines on the wiki, as far as I can tell, but I would certainly submit whether that is the case or not to the group. I actively use GNURadio here, and have the USRP hardware on which to test builds and such. Learning this new build system will be what will challenge me the most; it does appear to be a timesaving system, though, and quite well thought-out (back in the day, I built PostgreSQL RPMs on the actual target platform; even if that meant pressing an old 486 into use, which I did, frequently, for Red Hat 6.2 builds (when Red Hat 9 was Old Hat and Fedora Core 1 was the talk of the town); Mock looks like it makes builds so much easier and more automatic; I still remember taking a full weekend to get all the builds done for all the archs I supported). -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From denis at poolshark.org Mon Dec 31 21:20:22 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 31 Dec 2007 22:20:22 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <1199102564.8488.64.camel@gibraltar.str.redhat.com> References: <64b14b300712221243q6f1d825alc4bf1653e681b748@mail.gmail.com> <64b14b300712231155u3116ad66o538c10211bd7ca7a@mail.gmail.com> <476EBC95.5050707@fedoraproject.org> <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <20071228151331.6af2f7fb@redhat.com> <1198929588.31425.5.camel@localhost.localdomain> <1199102564.8488.64.camel@gibraltar.str.redhat.com> Message-ID: <47795D16.1030508@poolshark.org> Nils Philippsen wrote: > On Sat, 2007-12-29 at 12:59 +0100, David Nielsen wrote: > >> Personally when it comes to burning I favor integrating it in the places >> where I really want that functionality as I have a hard time seeing how >> aside historically being burdened as such this is functionality that >> requires or is best utilized as a seperate task. Burning a music cd >> should be in Banshee, photo cds in f-spot and so on. > > And authoring a CD (think of mixed mode CDs, or if you want/need to > tweak settings, or exact copies of audio CDs so they later still work > with cddb and don't annoy you with gaps between live tracks ;-)) should > be done in an authoring program (that's how I see k3b nowadays). gcdmaster