From Matt_Domsch at dell.com Sun Jun 1 05:04:02 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 1 Jun 2008 00:04:02 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <8886.1212269945@sss.pgh.pa.us> References: <20080531072422.A1480@humbolt.us.dell.com> <8886.1212269945@sss.pgh.pa.us> Message-ID: <20080601050402.GA3672@auslistsprd01.us.dell.com> On Sat, May 31, 2008 at 05:39:05PM -0400, Tom Lane wrote: > Matt Domsch writes: > > Fedora Rawhide-in-Mock Build Results for x86_64 > > ... > > libjpeg-6b-41.fc9 (build/make) tgl > > This appears to be a newly-introduced autoconf bug: > https://bugzilla.redhat.com/show_bug.cgi?id=449245 > which very possibly has broken a few other packages besides mine. > > I could add a patch to work around it, but unless Karsten rejects > 449245 as not-a-bug I'm disinclined to do so. There's no policy > expecting maintainers to put in short-term workarounds for toolchain > bugs is there? no. The right thing is to fix autoconf of course; then subsequent rebuilds won't flag your package any more. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sun Jun 1 05:07:54 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 1 Jun 2008 00:07:54 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <1212246128.3364.5.camel@eagle.danny.cz> References: <20080531072422.A1480@humbolt.us.dell.com> <20080531145710.0ef4b266@metropolis.intra.city-fan.org> <20080531142906.GB9722@auslistsprd01.us.dell.com> <1212246128.3364.5.camel@eagle.danny.cz> Message-ID: <20080601050754.GB3672@auslistsprd01.us.dell.com> On Sat, May 31, 2008 at 05:02:08PM +0200, Dan Hor?k wrote: > > Matt Domsch p????e v So 31. 05. 2008 v 09:29 -0500: > > On Sat, May 31, 2008 at 02:57:10PM +0100, Paul Howarth wrote: > > > > dledford lat-1.2.3-3.fc9 ['241911 ASSIGNED'] (build/make) pghmcfc > > > > > > Bug #241911 is the ppc64 excludearch tracker bug for lat, not a FTBFS > > > bug. The package currently fails to build in Rawhide due to broken deps > > > in the mono stack that it buildreqs. > > > > the same situation is with > cdcollect-0.6.0-5.fc9 ['309191 ASSIGNED'] (build/make) sharkcz > > > Odd; I do a simple recursion via bugzilla queries, down the > > 'blockedby' chain, starting from FTBFS. Not sure how it picked up > > that bug though. I'll keep an eye out for this. 'blockedby' is not the same as 'dependson'. It's the latter that's correct. Fixed now. I've rerun just the stats generation. There's a bug yet where it incorrectly shows a pile of bugs to close, so just ignore that part. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/00-stats.txt http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/00-stats.txt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mschwendt at gmail.com Sun Jun 1 07:14:45 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 1 Jun 2008 09:14:45 +0200 Subject: no updates? In-Reply-To: <1212275595.6925.42.camel@localhost.localdomain> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> <1212275595.6925.42.camel@localhost.localdomain> Message-ID: <20080601091445.e7fa8583.mschwendt@gmail.com> On Sun, 01 Jun 2008 09:13:15 +1000, Rodd Clarkson wrote: > On Fri, 2008-05-30 at 11:32 +0200, Michael Schwendt wrote: > > On Fri, 30 May 2008 10:33:43 +0200, Christoph H?ger wrote: > > > > > Hi, > > > > Wrong list? You seem to refer to F9 => fedora-list not > > fedora-devel-list. > > > > > since some days I get absolutely no updates. > > > > Are they available on your favourite mirror already? > > Or do you use the mirrorlist? > > I've had this same problem a couple of times. You'll see updates coming > in in email to fedora-test-list and then after a couple of days you'll > notice that the updates never happened. > > If I then yum clean all the updates work as soon as I run yum update > manually. > > I think there might be a bug here, but haven't got any idea how to test > for it, and haven't got around to reporting it either. You can test for it by examining the cached metadata files below /var/cache/yum/updates. Start with the timestamp on "cachecookie". Only if old enough, Yum loads new metadata. [The default is 1800 seconds in yum.conf's metadata_expire= value.] Compare timestamp of "repomd.xml" with the mirror that is assigned to you (file "mirrorlist.txt". Recent Yum versions ignore mirrors that offer repomd.xml files which are older than what you've got in your cache. This way you can find mirrors which don't sync daily. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.21 1.17 0.74 From rc040203 at freenet.de Sun Jun 1 06:44:55 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jun 2008 08:44:55 +0200 Subject: Hylafax review issues In-Reply-To: References: <48414CCD.4010401@hhs.nl> <48418990.7090307@hhs.nl> Message-ID: <1212302695.9275.159.camel@beck.corsepiu.local> On Sat, 2008-05-31 at 14:00 -0500, Jason L Tibbitts III wrote: > >>>>> "HdG" == Hans de Goede writes: > > HdG> Well the question here IMHO is not so much how to name the > HdG> package as it is which fork to package, making them parallel > HdG> installable will be very hard todo and AFAIK we don't want > HdG> conflicting packages. > HdG> I believe that hylafax+ best fits Fedora. > > I don't see any point in attempting to decide which of many choices > fits Fedora; hylafax+ is simply the only one that's been submitted. ACK. > For comparison, Debian and Ubuntu don't seem to ship hylafax+; they > ship hylafax and in addition split the package into -client, -server > and -doc subpackages (which may be worth considering here). > > Gentoo has ebuilds for both hylafax and hylafax+ named accordingly. > > I'm not sure how to check Suse. SuSE ships "hylafax", originating from www.hylafax.org's hylafax-4.* tarballs with many patches having been added. Ralf From pertusus at free.fr Sun Jun 1 09:51:09 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 1 Jun 2008 11:51:09 +0200 Subject: a new page for packaging recommendations by everyone Message-ID: <20080601095109.GA2599@free.fr> Hello, I have begun a wiki page with something that looks like guidelines, but that are opened for everyone, and allow to have controversial recommendations: https://fedoraproject.org/wiki/PackagingTricks It would be nice if reviewers, especially those with a lot of experience who have said more than once something in reviews, to document their knowledge. Also I think that controversial packaging issues that result in long threads on mailing lists could be documented there. -- Pat From rawhide at fedoraproject.org Sun Jun 1 10:32:14 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 1 Jun 2008 10:32:14 +0000 (UTC) Subject: rawhide report: 20080601 changes Message-ID: <20080601103214.2F49A209D2A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080531/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080601/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package ext3grep Recovery tool for ext3 filesystems New package nled Nifty Little EDitor New package perl-BDB Asynchronous Berkeley DB access New package perl-Event-RPC Event based transparent Client/Server RPC framework New package perl-Gtk2-Ex-FormFactory Framework for Gtk2 perl applications New package perl-Lingua-EN-Numbers-Ordinate Perl functions for giving the ordinal form of a number given its cardinal value New package perl-Template-Provider-Encoding Explicitly declare encodings of your templates New package python-beaker WSGI middleware layer to provide sessions New package python-mako Mako template library for Python New package python-routes Rails-like routes for Python New package python-webhelpers Helper library for aiding the writing of web templates in Python Updated Packages: balsa-2.3.24-1.fc10 ------------------- * Sat May 31 18:00:00 2008 Pawel Salek - 2.3.24-1 - update to upstream 2.3.24. bogofilter-1.1.7-1.fc10 ----------------------- * Sat May 31 18:00:00 2008 Adrian Reber - 1.1.7-1 - updated to 1.1.7 - moved bogoupgrade to its own package to remove the perl dependency on bogofilter (bz #442843) compface-1.5.2-8 ---------------- * Sat May 31 18:00:00 2008 Michael Schwendt - 1.5.2-8 - Drop "|| :" from check section. It failed to build for mdomsch in Rawhide today. cyrus-imapd-2.3.11-2.fc10 ------------------------- * Sat May 31 18:00:00 2008 Dan Hor??k - 2.6.0-2 - Fix build. * Sat May 31 18:00:00 2008 Behdad Esfahbod - 2.6.0-1 - Update to 2.6.0. geos-3.0.0-4.fc10 ----------------- * Wed May 28 18:00:00 2008 Balint Cristian - 3.0.0-4 - disable bindings for REL4 gkrellm-wifi-0.9.12-8.fc10 -------------------------- * Sat May 31 18:00:00 2008 Hans de Goede 0.9.12-8 - Fix compiling with mix of latest glibc + kernel headers (avoid header conflict) glibmm24-2.16.2-1.fc10 ---------------------- * Sat May 17 18:00:00 2008 Denis Leroy - 2.16.2-1 - Update to upstream 2.16.2 * Sat Apr 12 18:00:00 2008 Denis Leroy - 2.16.1-1 - Update to upstream 2.16.1, filechooser refcount bugfix gtk-sharp2-2.12.0-2.fc10 ------------------------ * Sat May 31 18:00:00 2008 Xavier Lamien - 2.12.0-2 - Fixed monodoc libdir. gtkmm24-2.13.0-1.fc10 --------------------- * Sat May 31 18:00:00 2008 Denis Leroy - 2.13.0-1 - Following gtk2 to 2.13 unstable branch * Sat Apr 12 18:00:00 2008 Denis Leroy - 2.12.7-1 - Update to upstream 2.12.7 jd-2.0.0-0.5.svn2081_trunk.fc10 ------------------------------- * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.5.svn2081_trunk - Workarround for bug 449225 * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - svn trunk 2081 json-glib-0.6.2-1.fc10 ---------------------- * Sat May 31 18:00:00 2008 Brian Pepple - 0.6.2-1 - Update to 0.6.2. - Enable tests. k3b-1.0.5-2.fc10 ---------------- * Sat May 31 18:00:00 2008 Rex Dieter - 0:1.0.5-2 - (re)enable reload patch kanyremote-4.9-1.fc10 --------------------- * Sun May 25 18:00:00 2008 Mikhail Fedotov - 4.9-1 - Bugfixes and enhancements to better support anyremote-J2ME client v4.6 and anyremote2html v0.5. kdelibs-4.0.80-2.fc10 --------------------- * Fri May 30 18:00:00 2008 Than Ngo 4.0.80-2 - fix #447965, order issue in kde path, thanks to Kevin - backport patch to check html style version libpng-1.2.29-1.fc10 -------------------- * Sat May 31 18:00:00 2008 Tom Lane 2:1.2.29-1 - Update to libpng 1.2.29 (fixes low-priority security issue CVE-2008-1382) Related: #441839 lxsplit-0.2.2-4.fc10 -------------------- * Sat May 31 18:00:00 2008 Rahul Sundaram - 0.2.2-4 - Apply upstream build patch mecab-0.97-3.fc10 ----------------- * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - 0.97-3 - Remove ancient || : after %check nntpgrab-0.3.0-1.fc10 --------------------- * Sun Jun 1 18:00:00 2008 Erik van Pienbroek - 0.3.0-1 - Update to version 0.3.0 openhpi-2.10.2-2.fc10 --------------------- * Fri Apr 18 18:00:00 2008 Dan Horak - 2.10.2-2 - enable the sysfs plugin - add missing R: for -devel subpackage perl-B-Keywords-1.08-2.fc10 --------------------------- * Sat May 31 18:00:00 2008 Chris Weyl 1.08-2 - update buildrequires * Sat Mar 15 18:00:00 2008 Chris Weyl 1.08-1 - update to 1.08 perl-Convert-UUlib-1.09-5.fc10 ------------------------------ * Sat May 31 18:00:00 2008 Robert Scheck 1:1.09-5 - Fixed %check section in order to get the package built perl-DateTime-0.4302-1.fc10 --------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 1:0.4302-1 - Update to DateTime 0.4302. - Update to DateTime::TimeZone 0.77. - Update to DateTime::Locale 0.4001. - BR List::MoreUtils. - Define IS_MAINTAINER so we run the pod tests. perl-Error-0.17014-1.fc10 ------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 1:0.17014-1 - Update to 0.17014. perl-Exception-Class-1.24-1.fc10 -------------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 1.24-1 - Update to 1.24. - Bump Devel::StackTrace dependency to 1.17. - Clean up to match current cpanspec output. - Improve Summary and description. - Build with Module::Build. - BR Test::Pod and Test::Pod::Coverage and define IS_MAINTAINER. perl-Imager-0.65-1.fc10 ----------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 0.65-1 - Update to 0.65. perl-Module-Install-0.74-1.fc10 ------------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 0.74-1 - Update to 0.74. - Update versioned dependencies for File::Remove, Module::ScanDeps, PAR::Dist, and YAML::Tiny. - BR Test::CPAN::Meta. perl-PAR-Dist-0.31-1.fc10 ------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 0.31-1 - Update to 0.31. - BR Test::Pod and Test::Pod::Coverage. perl-Template-Alloy-1.012-1.fc10 -------------------------------- * Sat May 31 18:00:00 2008 Chris Weyl 1.012-1 - update to 1.012 perl-Test-Deep-0.102-1.fc10 --------------------------- * Sat May 31 18:00:00 2008 Steven Pritchard 0.102-1 - Update to 0.102. perl-Unix-Syslog-1.1-1.fc10 --------------------------- * Fri May 30 18:00:00 2008 Steven Pritchard 1.1-1 - Update to 1.1. php-pear-Net-Sieve-1.1.6-1.fc10 ------------------------------- * Tue May 27 18:00:00 2008 Remi Collet 1.1.6-1 - update to 1.1.6 - add generated CHANGELOG po4a-0.32-8.fc10 ---------------- * Sun Jun 1 18:00:00 2008 Ralf Cors??pius - 0.32-8 - Let package own %{perl_vendorlib}/Locale (BZ 449258). pth-2.0.7-7 ----------- * Sat May 31 18:00:00 2008 Michael Schwendt - 2.0.7-7 - Drop "|| :" from check section. It failed to build for mdomsch in Rawhide today. python-lxml-2.0.6-1.fc10 ------------------------ * Sat May 31 18:00:00 2008 Jeffrey C. Ollie - 2.0.6-1 - Update to 2.0.6 python-toscawidgets-0.8.7-1.fc10 -------------------------------- * Sat May 31 18:00:00 2008 Luke Macken - 0.8.7-1 - Update to latest release. ruby-mecab-0.97-2.fc10 ---------------------- * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - 0.97-2 - Remove ancient || : after %check scons-0.98.4-2.fc10 ------------------- * Sun Jun 1 18:00:00 2008 Gerard Milmeister - 0.98.4-2 - added buildreq sed * Sat May 31 18:00:00 2008 Gerard Milmeister - 0.98.4-1 - new release 0.98.4 soundtracker-0.6.8-4.fc10 ------------------------- * Sat May 31 18:00:00 2008 Hans Ulrich Niedermann - 0.6.8-4 - Disable ALSA support. Upstream requires alsa 0.4 or 0.5 API, F9 has 1.0 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.6.8-3 - Autorebuild for GCC 4.3 svgalib-1.9.25-5.fc10 --------------------- * Sat May 31 18:00:00 2008 Hans de Goede 1.9.25-5 - Fix building with 2.6.26 kernel headers tailor-0.9.34-1.fc10 -------------------- * Sat May 31 18:00:00 2008 Dan Hor??k 0.9.34-1 - update to upstream version 0.9.34 vorbis-tools-1.2.0-2.fc10 ------------------------- * Sat May 31 18:00:00 2008 Hans de Goede - 1:1.2.0-2 - Stop calling autoconf, this was no longer necessarry and in current rawhide breaks us from building (because aclocal.m4 does not match the new autoconf version) - Drop our last 2 patches, they were modifying configure, but since we called autoconf after that in effect they were not doing anything, review has confirmed that they indeed are no longer needed) - Drop using system libtool hack, this is dangerous when the libtool used to generate ./configure and the one used differ - Remove various antique checks (for example check if RPM_BUILD_ROOT == /) - Drop unnecessary explicit library Requires - Cleanup BuildRequires wkf-1.3.11-3.fc10 ----------------- * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - 1.3.11-3 - Explicitly override config.{guess,sub} (due to redhat-rpm-config change on F-10) writer2latex-0.5-3.fc10 ----------------------- * Mon Mar 31 18:00:00 2008 Caolan McNamara 0.5-3 - tweak for guidelines - and adjust for OOo3 3 layer packaging xscreensaver-5.05-4.fc10 ------------------------ * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - 1:5.05-4 - Fix compilation error with GLib 2.17+ Summary: Added Packages: 11 Removed Packages: 0 Modified Packages: 45 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From dcbw at redhat.com Sun Jun 1 11:57:44 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 01 Jun 2008 07:57:44 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530184739.GA2473@imperial.ac.uk> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> Message-ID: <1212321464.25062.2.camel@localhost.localdomain> On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: > On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: > > > On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > > > Dan Williams (dcbw at redhat.com) said: > > > > On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > > > > > During the boot I have some samba shares mounted because I have them > > > > > configured to mount via fstab file. > > > > > > > > > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > > > > > smbfs service trying to unmount samba shares but NM service has > > > > > already shutdown and there is no working network connection :( > > > > > > > > > > I have seen this "bad" behaviour in F8 and have reported it on this > > > > > mailinglist, but I hoped that the new and smarter NM would take care > > > > > of it, but unfortunately it didn't :( > > > > > > > > Probably need to adjust the stop priorities of NM and haldaemon to be > > > > right after messagebus (K85) rather than where they currently are... > > > > The problem is that NM is being stopped to early. > > > > > > 'After netfs' should be good enough. Although netfs stop should possibly > > > do lazy umounts. > > > > Ok, just need to bump NM a few bits later it looks like; might as well > > be K84 to be right after messagebus. > > Why not go all the way to 90 as network to be on the safe side? With a > quick look I can see some scripts that might not be happy if the network > is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. NM depend on messagebus at least, so we should stop NM right before messagebus. But the same issues with startup are theoretically present with shutdown, meaning that since messagebus depends on rsyslog, and rsyslog depends on network. Standard installs don't use networked syslog, so standard installs don't actually need rsyslog to depend on network, but because rsyslog isn't smart enough to know when it does or does not depend on network, we can't just re-order the chain... :( Dan From fedora at leemhuis.info Sun Jun 1 12:45:09 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jun 2008 14:45:09 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <20080601095109.GA2599@free.fr> References: <20080601095109.GA2599@free.fr> Message-ID: <484299D5.1020801@leemhuis.info> On 01.06.2008 11:51, Patrice Dumas wrote: > > I have begun a wiki page with something that looks like guidelines, but > that are opened for everyone, and allow to have controversial > recommendations: > > https://fedoraproject.org/wiki/PackagingTricks > > It would be nice if reviewers, especially those with a lot of > experience who have said more than once something in reviews, to > document their knowledge. Also I think that controversial packaging > issues that result in long threads on mailing lists could be > documented there. Just my 2 cent: * I'd say that page should be merged into or with http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes as the topics are similar (albeit not 100% identical) * I'd say that page belongs into the http://fedoraproject.org/wiki/Packaging/ namespace CU knurd From dcbw at redhat.com Sun Jun 1 12:52:06 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 01 Jun 2008 08:52:06 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212176306.9616.26.camel@cutter> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: <1212324726.25062.53.camel@localhost.localdomain> On Fri, 2008-05-30 at 15:38 -0400, seth vidal wrote: > On Fri, 2008-05-30 at 15:33 -0400, Colin Walters wrote: > > On Fri, May 30, 2008 at 3:29 PM, Simo Sorce wrote: > > > > > > I am very glad the debian guys got "all cranky" on this issue, > > Temrinating network connections just because a component need > > to > > resytart is plain silly. > > > > DBus is not the same as any other random software because it is > > explicitly designed to provide reliable communication *between* > > components, much like the kernel. If you restart it at random times > > that reliability guarantee is destroyed. > > > > http://mail.gnome.org/archives/networkmanager-list/2005-March/thread.html#00027 > > > > Simo's point still holds though. What you've described above is a better > reason to have not designed nm around dbus not a reason why we should be > okay with our network services going away when we restart dbus. The reason we don't handle messagebus restarts (yet) is that it's a boatload of complex state to synchronize on re-init, for a case that should never ever be happening. It's not clear that the benefits of doing this actually equal or surpass the cost of writing and maintaining that code in NM and all of the other listed services for the one or two times a year that the bus _might_ crash if a cosmic ray hits your RAM and ECC doesn't fix it. 1) HAL - NM needs to synchronize it's device list with HAL, adding new devices, discarding no-longer-known devices, and ensuring that the details of existing devices (vendor, device id, driver name, etc) are still the same. NM has code to do this when HAL goes away but doesn't check device properties yet. 2) wpa_supplicant - assuming wpa_supplicant handles D-Bus restarts correctly, NM then needs to query wpa_supplicant for the interfaces the supplicant currently controls, add new devices that may have been found in step #1, remove devices that are no longer present from step 1, and re-read the current interface configuration and ensure that it hasn't changed since dbus stopped. If it has changed, NM needs to tear the connection down, and re-initialize the connection entirely, because the connection isn't consistent with the pre-dbus-restart state. And this means the wifi connection will drop, potentially leading to another DHCP transaction, etc. In cases like this, assuming incorrect state is actually _worse_ than tearing down the connection and restarting it. 3) pppd - need to check the state of the PPP connection, and pppd doesn't provide plugins a good way of asking about internal state, since plugins are just callouts. If the PPP connection got dropped during the dbus dropout, then NM needs to restart the PPP connection, because events from pppd are obviously lost while dbus is gone. 4) vpn - need to check the state of VPN connections for the same reason as (3). If the VPN connection got dropped during the dbus dropout, then NM need restart the VPN connection, because events from the vpn daemons are obviously lost while dbus is gone. 5) DHCP - if some interface was in the middle of doing a DHCP operation when dbus went away, NM needs to stop the ongoing DHCP transaction and restart it, because events and options are delivered back to NM via D-Bus. 6) System settings daemon - your system connections are provided by a dbus service. If the bus goes away, then NM would have to re-read all the system connections from the system settings daemon when the bus comes back, discard ones that no longer exist (and tear down that connection if it's active), add new ones, and verify that existing ones haven't changed (and if they have, restart that connection). All to cover the case where you touch an ifcfg file while dbus is gone. I do have some vague plans to merge NM and the system settings daemon back together after 0.7 since that would make some things a lot easier (and render this point moot) but we'll see about that. Patches accepted. There are some complex dependencies here that each have their own state. And to do it right, you need to ensure that the entire state of the system (NM, pppd, wpa_supplicant, hald, vpnc, openvpn, nm-system-settings, etc) is consistent with what the mothership (NM) expects. That's not simple, and all for a case that almost never happens. Dan [1] on a different topic, having NM handle restarts of itself is another thing; we could guarantee that _only_ statically addressed wired ethernet devices that don't use 802.1x don't get touched over NM restarts since they don't require an external controlling daemon like wpa_supplicant or BlueZ or whatever. And then, only if on restart there's a system connection (provided by an ifcfg file on Fedora) that matches the current settings of the device. That's also a pile of code (need to match multiple IP addresses/netmasks/gateways, routes, ensure resolv.conf is correct, ensure MTU is correct, ensure MAC address for the interface is the same as before, etc) but probably something that should be done eventually. From opensource at till.name Sun Jun 1 12:53:42 2008 From: opensource at till.name (Till Maas) Date: Sun, 01 Jun 2008 14:53:42 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <484299D5.1020801@leemhuis.info> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> Message-ID: <200806011453.52215.opensource@till.name> On Sun June 1 2008, Thorsten Leemhuis wrote: > * I'd say that page belongs into the > http://fedoraproject.org/wiki/Packaging/ > namespace Afaik pages in the Packaging namespace can only be edited by the Packaging Commitee, but the http://fedoraproject.org/wiki/PackageMaintainers namespace would fit. 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 fedora at leemhuis.info Sun Jun 1 13:06:48 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jun 2008 15:06:48 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <200806011453.52215.opensource@till.name> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> <200806011453.52215.opensource@till.name> Message-ID: <48429EE8.8050404@leemhuis.info> On 01.06.2008 14:53, Till Maas wrote: > On Sun June 1 2008, Thorsten Leemhuis wrote: > >> * I'd say that page belongs into the >> http://fedoraproject.org/wiki/Packaging/ >> namespace > Afaik pages in the Packaging namespace can only be edited by the Packaging > Commitee, but the http://fedoraproject.org/wiki/PackageMaintainers namespace > would fit. /me grumbles Yes, I forgot that special restriction (a quite bad one IMHO, but that's a different discussion). So IOW: Might be good idea to merge the old http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes and the new https://fedoraproject.org/wiki/PackagingTricks into a new page and place it somewhere where all contributors can edit them (which is not the case in http://fedoraproject.org/wiki/Packaging/ where such a page would logically fit best). Cu knur From dcbw at redhat.com Sun Jun 1 13:14:37 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 01 Jun 2008 09:14:37 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530204938.GC6179@devserv.devel.redhat.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> Message-ID: <1212326077.25062.73.camel@localhost.localdomain> On Fri, 2008-05-30 at 16:49 -0400, Alan Cox wrote: > On Fri, May 30, 2008 at 03:33:37PM -0400, Colin Walters wrote: > > DBus is not the same as any other random software because it is explicitly > > designed to provide reliable communication *between* components, much like > > the kernel. If you restart it at random times that reliability guarantee is > > destroyed. > > So the questions you should ask are > - Why does restarting dbus have to be unreliable It's a communication pipe; restarting D-Bus itself is reliable becuase it's just like TCP. Its the transport. But making what gets _transported_ reliable is the kicker. It's exactly like all those Cingular/AT&T dropped call commercials from a while ago: http://youtube.com/watch?v=DR26BZUo3Dk http://youtube.com/watch?v=GEd3pS1jXJ4 http://www.spike.com/video/2839248 (spoof) Suddenly all the state dependent on a D-Bus service is suspect, because you have no idea what's going on while the bus is down. You have to re-synchronize your state after the bus comes back, and that's not a simple task. > - Why isn't there a recovery mechanism The recovery mechanism would be in each service, because the service knows whether or not it needs recovery or not, and would know how to merge/synchronize it's state with the services that it depends on. Some don't need to. But ones with state dependent on other D-Bus services would. > - Why does network manager have to do the work itself not the support code Like above, because NM has specific state, and when D-Bus goes away, it's communication channels with the daemons that affect that NM-specific state are gone, and NM can't make any assumptions about what's happening in any other daemon while the bus is gone. Maybe your VPN just came up for rekeying, but the signal got lost because D-Bus isn't around. So when the bus comes back, your VPN connection is already dropped. Or DHCP re-bound while the bus was down, and your sysadmin changed DNS servers on you, and the signal from dhclient got lost (because the bus was down). Unless you re-do the entire DHCP transaction (or teach dhclient about dbus properly so it can answer questions without having to exec() stupid scripts that then re-emit state back over D-Bus) NM would have no idea that the returned DHCP options had changed. And thus your DNS is dead. > And more fundamentally > > Why the ... are people still writing software which doesn't try and tolerate > faults that are recoverable to a useful extent. Yes dbus might have to lose > a few messages and send everyone a "duh whoops" event so they can recover but > "oh dear it broke everyone reboot" is not good engineering. In some cases, it's a cost/benefit analysis. Is the cost of writing and maintaining a pile of code that handles a D-Bus restart, which shouldn't ever happen, worth the benefit? In some cases, definitely. In other cases, probably not. That isn't an excuse to write crappy software, but it's certainly not as simple of a problem as you present it. Dan > So I'm likewise pleased the Debian people raised a sensible point. > > Alan > From matt at truch.net Sun Jun 1 14:04:35 2008 From: matt at truch.net (Matthew D Truch) Date: Sun, 1 Jun 2008 10:04:35 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212324726.25062.53.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212324726.25062.53.camel@localhost.localdomain> Message-ID: <20080601140435.GB27694@truch.net> > It's not clear that the benefits of doing this actually equal or > surpass the cost of writing and maintaining that code in NM and all of > the other listed services for the one or two times a year that the bus > _might_ crash if a cosmic ray hits your RAM and ECC doesn't fix it. Not every box runs at sea level. Cosmic rays become a significant issue at altitude. Think of people living up in the mountains or astronomical observatories. Think of people on long-haul flights using their laptops. And my personal usage case, high altitude balloons (37km altitude). We can't afford RAD hardened boxes, so we have redundant machines with watchdogs to switch between them, which works great for the hard crashes (every couple days) but not so much for the 'soft' crashes where systems go wonky. -- "Two Hundred -- And Forty Dollars -- Worth of Pudding -- Aww Yeah!" -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sun Jun 1 14:07:32 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 01 Jun 2008 10:07:32 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212326077.25062.73.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> <1212326077.25062.73.camel@localhost.localdomain> Message-ID: <1212329253.25062.103.camel@localhost.localdomain> On Sun, 2008-06-01 at 09:14 -0400, Dan Williams wrote: > On Fri, 2008-05-30 at 16:49 -0400, Alan Cox wrote: > > On Fri, May 30, 2008 at 03:33:37PM -0400, Colin Walters wrote: > > > DBus is not the same as any other random software because it is explicitly > > > designed to provide reliable communication *between* components, much like > > > the kernel. If you restart it at random times that reliability guarantee is > > > destroyed. > > > > So the questions you should ask are > > - Why does restarting dbus have to be unreliable > > It's a communication pipe; restarting D-Bus itself is reliable becuase > it's just like TCP. Its the transport. But making what gets > _transported_ reliable is the kicker. > > It's exactly like all those Cingular/AT&T dropped call commercials from > a while ago: > > http://youtube.com/watch?v=DR26BZUo3Dk > http://youtube.com/watch?v=GEd3pS1jXJ4 > http://www.spike.com/video/2839248 (spoof) Except that in the case of NM, instead of being a one-to-one conversation like these, it's like NM is the foreman of a construction site, and just because his/her conversation to each one of the bulldozer, crane, and structure welders drops because the cell company had an outage at the base station his/her phone is patched through, doesn't mean that when the outage is over, that s/he can just assume that what the bulldozer, crane, and welders did in the mean time was exactly what needed to happen. S/He needs to go and verify that everything is exactly like s/he expects it, except s/he can't yell "All Stop!" but has to check and verify everything while the work keeps going. Not simple. Dan > Suddenly all the state dependent on a D-Bus service is suspect, because > you have no idea what's going on while the bus is down. You have to > re-synchronize your state after the bus comes back, and that's not a > simple task. > > > - Why isn't there a recovery mechanism > > The recovery mechanism would be in each service, because the service > knows whether or not it needs recovery or not, and would know how to > merge/synchronize it's state with the services that it depends on. Some > don't need to. But ones with state dependent on other D-Bus services > would. > > > - Why does network manager have to do the work itself not the support code > > Like above, because NM has specific state, and when D-Bus goes away, > it's communication channels with the daemons that affect that > NM-specific state are gone, and NM can't make any assumptions about > what's happening in any other daemon while the bus is gone. Maybe your > VPN just came up for rekeying, but the signal got lost because D-Bus > isn't around. So when the bus comes back, your VPN connection is > already dropped. > > Or DHCP re-bound while the bus was down, and your sysadmin changed DNS > servers on you, and the signal from dhclient got lost (because the bus > was down). Unless you re-do the entire DHCP transaction (or teach > dhclient about dbus properly so it can answer questions without having > to exec() stupid scripts that then re-emit state back over D-Bus) NM > would have no idea that the returned DHCP options had changed. And thus > your DNS is dead. > > > And more fundamentally > > > > Why the ... are people still writing software which doesn't try and tolerate > > faults that are recoverable to a useful extent. Yes dbus might have to lose > > a few messages and send everyone a "duh whoops" event so they can recover but > > "oh dear it broke everyone reboot" is not good engineering. > > In some cases, it's a cost/benefit analysis. Is the cost of writing and > maintaining a pile of code that handles a D-Bus restart, which shouldn't > ever happen, worth the benefit? In some cases, definitely. In other > cases, probably not. That isn't an excuse to write crappy software, but > it's certainly not as simple of a problem as you present it. > > Dan > > > So I'm likewise pleased the Debian people raised a sensible point. > > > > Alan > > > From billcrawford1970 at gmail.com Sun Jun 1 14:58:11 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Sun, 1 Jun 2008 15:58:11 +0100 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <604aa7910805301107k55bcafe4ve8d37844809b514f@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> <604aa7910805301107k55bcafe4ve8d37844809b514f@mail.gmail.com> Message-ID: <200806011558.11641.billcrawford1970@googlemail.com> On Friday 30 May 2008 19:07:12 Jeff Spaleta wrote: > On Fri, May 30, 2008 at 2:34 AM, Bill Crawford > > wrote: > > Um, maybe disabling the testing repo and running package-cleanup > > --orphans would help? > > > > [ answer: not necessarily; but it should then exclude stuff that's > > already been pushed to stable ] > > I am reasonable clued in on how to heuristically figure out what I am > running for testing. Trying to out pedantic me is a losing > proposition, and utterly not the point I trying to make. Dude, I was just trying to offer a suggestion / workaround :o) From ssorce at redhat.com Sun Jun 1 15:02:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 01 Jun 2008 11:02:43 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212326077.25062.73.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> <1212326077.25062.73.camel@localhost.localdomain> Message-ID: <1212332563.3156.28.camel@localhost.localdomain> On Sun, 2008-06-01 at 09:14 -0400, Dan Williams wrote: > On Fri, 2008-05-30 at 16:49 -0400, Alan Cox wrote: > > On Fri, May 30, 2008 at 03:33:37PM -0400, Colin Walters wrote: > > > DBus is not the same as any other random software because it is explicitly > > > designed to provide reliable communication *between* components, much like > > > the kernel. If you restart it at random times that reliability guarantee is > > > destroyed. > > > > So the questions you should ask are > > - Why does restarting dbus have to be unreliable > > It's a communication pipe; restarting D-Bus itself is reliable becuase > it's just like TCP. Its the transport. But making what gets > _transported_ reliable is the kicker. >From what you say below I think this statement need to be corrected. If it were a TCP like transport, then a restart wouldn't cause any problem, like a restart of a router down the pipe somewhere does not make my TCP connections drop, they are just delayed eventually (unless the outage is so long that the connections time out). If what you say later is accurate I think that the problem therefore is that DBUS is *not* a reliable transport, it seem like it does not have acks and store-and-forward facilities that would render most of this discussion moot. So far we can only consiuder DBUS as a sort of local UDP transport, if all goes well messages get to their destination but are not guaranteed. So the question is, why DBUS does not support a fully reliable transport mechanism ? The client side library should handle store-and-forward and acks (and timeouts of course). If this were implemented a simple "restart" of the daemon wouldn't cause any problem, just a short delay in delivering messages. Maybe both an unreliable and a reliable transport should be implemented and used for informational vs required communication. > > - Why isn't there a recovery mechanism > > The recovery mechanism would be in each service, because the service > knows whether or not it needs recovery or not, and would know how to > merge/synchronize it's state with the services that it depends on. Some > don't need to. But ones with state dependent on other D-Bus services > would. Yes, this is the key: "The recovery mechanism would be in each service", this should be provided by the dbus client library I guess, so that each application does not need but to tweak a few parameters: if a message ahs to be reliably delivered, what's the timeout, what to do if the timeout is reached ... > > - Why does network manager have to do the work itself not the support code > > Like above, because NM has specific state, and when D-Bus goes away, > it's communication channels with the daemons that affect that > NM-specific state are gone, and NM can't make any assumptions about > what's happening in any other daemon while the bus is gone. Maybe your > VPN just came up for rekeying, but the signal got lost because D-Bus > isn't around. So when the bus comes back, your VPN connection is > already dropped. With a reliable transport this would not be necessary, the only thing you'd need to listen for would be a message that say "hey, VPN daemon here, sorry, but I just started", which you would assume happens only if the vpn daemon crashes and restarts and at that point you have to consider how to deal with the situation (restart the vpn connection, transparently if possible). > Or DHCP re-bound while the bus was down, and your sysadmin changed DNS > servers on you, and the signal from dhclient got lost (because the bus > was down). Unless you re-do the entire DHCP transaction (or teach > dhclient about dbus properly so it can answer questions without having > to exec() stupid scripts that then re-emit state back over D-Bus) NM > would have no idea that the returned DHCP options had changed. And thus > your DNS is dead. > > > And more fundamentally > > > > Why the ... are people still writing software which doesn't try and tolerate > > faults that are recoverable to a useful extent. Yes dbus might have to lose > > a few messages and send everyone a "duh whoops" event so they can recover but > > "oh dear it broke everyone reboot" is not good engineering. > > In some cases, it's a cost/benefit analysis. Is the cost of writing and > maintaining a pile of code that handles a D-Bus restart, which shouldn't > ever happen, worth the benefit? In some cases, definitely. In other > cases, probably not. That isn't an excuse to write crappy software, but > it's certainly not as simple of a problem as you present it. The more central the system is, the more it need to be fault tolerant because it is a dependency for many services. What was the cost/benefit analysis in this case? Was it really made or was it based on subjective evaluations ? What case was taken into consideration ? Given some people is thinking of using NM by default also on servers then this issue become more critical, servers do serve clients, true in most of the cases they will use a permanent address not dhcp. But in many cases it would be preferable to use permanent IPs still delivered via DHCP (so that IP changes, even if rare can be still managed centrally), or the server might be a VPN concentrator. It would be extremely bad to loose all connections just because NM had to restart and could not understand how to deal with restarts trying to impact as little as possible other services. Simo. -- Simo Sorce * Red Hat, Inc * New York From a.badger at gmail.com Sun Jun 1 15:17:02 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jun 2008 08:17:02 -0700 Subject: a new page for packaging recommendations by everyone In-Reply-To: <48429EE8.8050404@leemhuis.info> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> <200806011453.52215.opensource@till.name> <48429EE8.8050404@leemhuis.info> Message-ID: <4842BD6E.2060208@gmail.com> Thorsten Leemhuis wrote: > > > On 01.06.2008 14:53, Till Maas wrote: >> On Sun June 1 2008, Thorsten Leemhuis wrote: >> >>> * I'd say that page belongs into the >>> http://fedoraproject.org/wiki/Packaging/ >>> namespace >> Afaik pages in the Packaging namespace can only be edited by the >> Packaging Commitee, but the >> http://fedoraproject.org/wiki/PackageMaintainers namespace would fit. > > /me grumbles > > Yes, I forgot that special restriction (a quite bad one IMHO, but that's > a different discussion). So IOW: > > Might be good idea to merge the old > http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes > and the new > https://fedoraproject.org/wiki/PackagingTricks > into a new page and place it somewhere where all contributors can edit > them (which is not the case in http://fedoraproject.org/wiki/Packaging/ > where such a page would logically fit best). > tibbs> | spot: Any chance we could work out access to some of the pages under Packaging? 0:55 < tibbs> | CommonRpmlintIssues and FrequentlyMadeMistakes? 0:55 < spot> | tibbs: sure. 0:56 --- | mspevack is now known as mspevack_mtg 0:56 < spot> | tibbs: i'll try to open the ACLs for those (assuming that moinmoin plays nice) - https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060608 Perhaps the ACLs just have to be re-opened now that we're using mediawiki? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Sun Jun 1 15:49:49 2008 From: walters at verbum.org (Colin Walters) Date: Sun, 1 Jun 2008 11:49:49 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212332563.3156.28.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> <1212326077.25062.73.camel@localhost.localdomain> <1212332563.3156.28.camel@localhost.localdomain> Message-ID: On Sun, Jun 1, 2008 at 11:02 AM, Simo Sorce wrote: > > So far we can only consiuder DBUS as a sort of local UDP transport, if > all goes well messages get to their destination but are not guaranteed. The argument here is that presently what we tell application authors is much more like TCP than UDP; if we allowed distributors to restart it in %post or the like automatically on upgrades, then we either have to change our guarantee, or try to "hide" the fact that the bus gets restarted under the covers. I think the only sensible solution is the latter. Which is certainly *possible*, just like how everything short of the halting problem is possible; but it would not be trivial. For many likely classes of DBus flaws, porting the Ksplice ( http://web.mit.edu/ksplice/) style approach would be easiest probably. But to handle the general case, I can imagine a system where we send a special message to all clients like org.freedesktop.Local.Restart and this causes them to enter a mode where they queue pending messages, waiting via inotify for the socket to reappear. The bus itself would try to flush all pending messages and save the current map of connections->service names and other state I'm not thinking of right now to JSON/XML/whatever. Then on startup you'd need to wait for all of the previous clients to connect, probably with some timeout; I can't think of offhand how to make this nrandomon-racy. After that we need to handle anything that changed in the meantime like clients having exited and thus lost their service name (this will happen for sure if we make other software restart on upgrade like setroubleshoot does). So we compute that delta and then send the relevant signals off to clients. For someone who knew the code and was an A+ hacker it might only be a two week or so job, though to actually know this worked you'd have to spend a lot of time creating test cases. > What was the cost/benefit analysis in this case? The original cost/benefit was "Absolutely nothing happens when I put my USB key into a Linux desktop" and "The networking system is a static mess of shell script that we edit via UIs run as root" =) Given some people is thinking of using NM by default also on servers > then this issue become more critical, servers do serve clients, Let's back up a second; if our overall goal is to make applying security/important-reliability updates happen more transparently, I think the best bang for the buck is going to be Linux. For example, we could spend the engineering time figuring out how to get Ksplice ( http://web.mit.edu/ksplice/) work under the RPM hood. DBus has so far had a pretty good security and reliability track record; while it's not simple software, it has simple goals and this has limited complexity. Something like the Linux kernel clearly has a much bigger goal and so is order(s) of magnitude more complex and with this complexity has come the concomitant security/reliability issues. And if I had the ability to herd security/reliability cats, I'd have them spend time on Firefox and try to take what Dan Walsh has been doing even farther - break it up into multiple processes with locked down security contexts and evaluate changes to the desktop to better handle the concept of processes with different privilege for example. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayvd at bludgeon.org Sun Jun 1 16:24:04 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Sun, 1 Jun 2008 09:24:04 -0700 Subject: Best way to enable _GNU_SOURCE Message-ID: <20080601162404.GA5694@bludgeon.org> automake / autoconf newbie here. I have a package that isn't currently being built with _GNU_SOURCE defined and is running into compile problems when a portion of it attempts to access hostent->h_addr. If I compile with -D_GNU_SOURCE all is well, but I want to get this fixed correctly upstream. What is the proper / preferred way to do this? I see a couple options: - Get it added to acinclude.m4 and it will show up somewhere in a header file(?) - Modify configure.ac (or other) to generage a configure.in that tacks it onto DEFS which shows up then as DEFS in configure and populates DEFS in the resultant Makefile so we have -D_GNU_SOURCE passed to the compiler What other ways are there to do this and what's the preferred way? I'll answer my own question if I find the answer in the automake / autoconf docs. :) Ray From rayvd at bludgeon.org Sun Jun 1 16:47:04 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Sun, 1 Jun 2008 09:47:04 -0700 Subject: Best way to enable _GNU_SOURCE In-Reply-To: <20080601162404.GA5694@bludgeon.org> References: <20080601162404.GA5694@bludgeon.org> Message-ID: <20080601164704.GA11491@bludgeon.org> > - Modify configure.ac (or other) to generage a configure.in that > tacks it onto DEFS which shows up then as DEFS in configure and > populates DEFS in the resultant Makefile so we have -D_GNU_SOURCE > passed to the compiler Well, the end solution was to modify configure.ac to include the following: AC_GNU_SOURCE Pretty straightforward. Ray From fedora at leemhuis.info Sun Jun 1 17:09:19 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jun 2008 19:09:19 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <4842BD6E.2060208@gmail.com> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> <200806011453.52215.opensource@till.name> <48429EE8.8050404@leemhuis.info> <4842BD6E.2060208@gmail.com> Message-ID: <4842D7BF.4080607@leemhuis.info> On 01.06.2008 17:17, Toshio Kuratomi wrote: > [...] > tibbs> | spot: Any chance we could work out access to some of the > pages under Packaging? > 0:55 < tibbs> | CommonRpmlintIssues and FrequentlyMadeMistakes? > 0:55 < spot> | tibbs: sure. > 0:56 --- | mspevack is now known as mspevack_mtg > 0:56 < spot> | tibbs: i'll try to open the ACLs for those > (assuming that moinmoin plays nice) > - https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060608 > Perhaps the ACLs just have to be re-opened now that we're using mediawiki? Don't think that's wise. Instead drop them completely; give everyone again a chance to *easily* participate everywhere in Fedora without being in committees; those should watch and coordinate/decide only if needed. IOW: it's a wiki, we should use it like one! But from older discussions I'm well aware that you guys don't want to that. I think that's totally stupid(?), but that's just my option. Thus move everything out of Packaging/ that is meant to be modified for ordinary packagers; that will avoid a lot of confusion, as it'll be crystal clear for everyone then that Packaging/ is completely maintained by the Packaging Committee. Cu knurd (?) note "that"; the packaging committee members are highly skilled people and I think they are doing a lot of good work; I just don't like the ACLs and the bureaucracy which is needed to get something improved; that is not specific to the Packaging Committee and has become a general problem in Fedora; I'm well aware that some of that is my fault from the days when I was more active/in FESCo From a.badger at gmail.com Sun Jun 1 17:10:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jun 2008 10:10:15 -0700 Subject: a new page for packaging recommendations by everyone In-Reply-To: <48429EE8.8050404@leemhuis.info> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> <200806011453.52215.opensource@till.name> <48429EE8.8050404@leemhuis.info> Message-ID: <4842D7F7.1060405@gmail.com> Thorsten Leemhuis wrote: > > > On 01.06.2008 14:53, Till Maas wrote: >> On Sun June 1 2008, Thorsten Leemhuis wrote: >> >>> * I'd say that page belongs into the >>> http://fedoraproject.org/wiki/Packaging/ >>> namespace >> Afaik pages in the Packaging namespace can only be edited by the >> Packaging Commitee, but the >> http://fedoraproject.org/wiki/PackageMaintainers namespace would fit. > > /me grumbles > > Yes, I forgot that special restriction (a quite bad one IMHO, but that's > a different discussion). So IOW: > > Might be good idea to merge the old > http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes > and the new > https://fedoraproject.org/wiki/PackagingTricks > into a new page and place it somewhere where all contributors can edit > them (which is not the case in http://fedoraproject.org/wiki/Packaging/ > where such a page would logically fit best). > 0:55 < tibbs> | spot: Any chance we could work out access to some of the pages under Packaging? 0:55 < tibbs> | CommonRpmlintIssues and FrequentlyMadeMistakes? 0:55 < spot> | tibbs: sure. 0:56 --- | mspevack is now known as mspevack_mtg 0:56 < spot> | tibbs: i'll try to open the ACLs for those (assuming that moinmoin plays nice) https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060608 Maybe the open acls weren't moved over when we switched from moinmoin to mediawiki? Someone outside the Packaging Committee please try to edit the page and if acls prevent it, ping infrastructure (#fedora-admin) to fix it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From opensource at till.name Sun Jun 1 17:23:43 2008 From: opensource at till.name (Till Maas) Date: Sun, 01 Jun 2008 19:23:43 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <4842D7BF.4080607@leemhuis.info> References: <20080601095109.GA2599@free.fr> <4842BD6E.2060208@gmail.com> <4842D7BF.4080607@leemhuis.info> Message-ID: <200806011923.56153.opensource@till.name> On Sun June 1 2008, Thorsten Leemhuis wrote: > Instead drop them completely; give everyone again a chance to *easily* > participate everywhere in Fedora without being in committees; those > should watch and coordinate/decide only if needed. IOW: it's a wiki, we > should use it like one! There is an extension for mediawiki to allow reviewing and marking revisions of a page as stable. Imho this would make it a lot easier to participate in the changing of acl-restricted pages: http://www.mediawiki.org/wiki/Extension:FlaggedRevs Of course it needs to be tested how good this works with the acl system in place. I already created an ticket in the Infrastructure trac to collect information about this: https://fedorahosted.org/fedora-infrastructure/ticket/583 > move everything out of Packaging/ that is meant to be modified for > ordinary packagers; that will avoid a lot of confusion, as it'll be > crystal clear for everyone then that Packaging/ is completely maintained > by the Packaging Committee. I agree, having some pages that may be edited is only confusing. 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 rakesh.pandit at gmail.com Sun Jun 1 17:42:11 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sun, 1 Jun 2008 23:12:11 +0530 Subject: Request for ownership: zile maintainer not responding Message-ID: Hello all, I am requesting for taking over this package as previous maintainer is not responding: https://bugzilla.redhat.com/show_bug.cgi?id=447125 Following Non-responsive Maintainer Policy, maintainer was mailed but he did not responded repeated mails at regular intervals. GNU zile-2.2.59 is already available. New Spec file: http://rakesh.gnulinuxcentar.org/zile.spec New SRPM: http://rakesh.gnulinuxcentar.org/zile-2.2.59-1.fc8.src.rpm I am very new at packaging(dnrd #445027, ntop #448397) and am looking for sponsor. May I go ahead? -- Regards, Rakesh Pandit From tibbs at math.uh.edu Sun Jun 1 18:30:48 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Jun 2008 13:30:48 -0500 Subject: Hylafax review issues In-Reply-To: <4841A229.3010808@hhs.nl> References: <48414CCD.4010401@hhs.nl> <48418990.7090307@hhs.nl> <4841A229.3010808@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> Hmm, I don't see them requesting that anywhere, or have you been HdG> in direct contact with them? It was requested in the review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=188542#c35 - J< From pertusus at free.fr Sun Jun 1 19:11:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 1 Jun 2008 21:11:56 +0200 Subject: a new page for packaging recommendations by everyone In-Reply-To: <48429EE8.8050404@leemhuis.info> References: <20080601095109.GA2599@free.fr> <484299D5.1020801@leemhuis.info> <200806011453.52215.opensource@till.name> <48429EE8.8050404@leemhuis.info> Message-ID: <20080601191156.GC2597@free.fr> On Sun, Jun 01, 2008 at 03:06:48PM +0200, Thorsten Leemhuis wrote: > > > Yes, I forgot that special restriction (a quite bad one IMHO, but that's > a different discussion). So IOW: > > Might be good idea to merge the old > http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes > and the new > https://fedoraproject.org/wiki/PackagingTricks > into a new page and place it somewhere where all contributors can edit > them (which is not the case in http://fedoraproject.org/wiki/Packaging/ > where such a page would logically fit best). I merged everything from Packaging/FrequentlyMadeMistakes that seemed relevant to me and moved the page to https://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks I also added a part with 'Recommendations for a sane review process' -- Pat From ville.skytta at iki.fi Sun Jun 1 21:29:37 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 2 Jun 2008 00:29:37 +0300 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072422.A1480@humbolt.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> Message-ID: <200806020029.37577.ville.skytta@iki.fi> On Saturday 31 May 2008, Matt Domsch wrote: > xemacs-21.5.28-6.fc9 (build/make) scop Sigh, m4_fst has silently disappeared from autoconf 2.62. It was defined as m4_define([m4_fst], [$1]) in 2.61, and there was no documentation for it. Does that mean that I could just replace occurrences of "m4_fst($x)" with "[$x]" or with "$x" or ...? > xemacs-packages-extra-20070427-1.fc8 (build/make) scop install-info segfaults: #449292 From katzj at redhat.com Sun Jun 1 21:36:08 2008 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 01 Jun 2008 17:36:08 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <483F7FDA.9000701@gmail.com> References: <483F7FDA.9000701@gmail.com> Message-ID: <48431648.9050205@redhat.com> Toshio Kuratomi wrote: > The python programming language is going to be releasing a new version > sometime around the time of the Fedora 10 release. Unlike past > releases, this one will have wide-spread backwards incompatibility in > the python language itself. We need to think about how we want to pull > the new language into the distribution and porting of existing > apps/modules. Here's a proposal to start us off but I hope geppetto > (the python maintainer) and ivazquez (who maintains python3.0 packages > in his spare time[1]_) will weigh in with their thoughts. So, while this is a large and incompatible change, there are lots of other large and incompatible changes that we've managed over the years. And in most of those, we've been far better off with actually making a transition rather than trying to keep two different things around. This is even _more_ true with things which are a framework that lots of other packages provide modules for -- things like apache, perl, python, and more. So in contrast, I think that we should evaluate python 2.6 for Fedora 10 (it seems reasonable, but I will defer to the current python maintainer's judgement :-). And the move to python 3.0 will need to wait until there's either a) sufficient reason for us to do a lot of legwork to get there or b) enough upstreams are "buying in" > * python3000 modules should have a separate namespace from python2.x > modules. The packaging committee will need to decide on that > (python3-foo, python3000-foo, python3k-foo are possibilities. > python3.0-foo should not be considered as 3.x versions should not have > the same backwards incompatibilities that 2.x->3.x has.) Except that many python modules are just included in with packages or in the same source tree. This then ends up with a need to build multiple versions of python modules and that way lies massive amounts of pain. It was a huge enough pain for just a very small number of modules in the python 1.5 -> python 2 transition. With the vastly greater number of modules these days, it becomes far far more difficult. > * Porting to python3000 will occur at some point but that should be a > post-Fedora 10 feature that we decide on after python-3.0 final has been > released. We will also need to discuss whether to port our tools > piecemeal or altogether at that time and to what extent (if any) we will > allow splitting from any upstreams that only support python-2.x. It's not as simple as that. What happens if (just to make up an example), anaconda and rhpl move to python 3 but no other tools do? Especially given that other tools depend on rhpl. Either a) the other tools have to be ported or b) multiple copies of the same code have to be maintained. The latter is filled with losing. The former is plausible, but it is going to be a big effort and we have to consistently commit to it across the board. Jeremy From mail at robertoragusa.it Sun Jun 1 22:33:49 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 02 Jun 2008 00:33:49 +0200 Subject: Successfully upgraded to F9 while keeping KDE 3 Message-ID: <484323CD.1080308@robertoragusa.it> Hi all, I managed to upgrade my F8 to F9 while keeping KDE 3, and it was certainly a bit beyond the abilities of a power user, but not too difficult. (refer to my previous thread "F8 -> F9 but keeping KDE3: technically feasible?") Apparently nobody tried that before, so I will describe the process for anyone interested (including google). In a few words: I upgraded via yum, with "--exclude=kde\*", but there are some little hairy details. - Modified the repo config to hardcode the F9 repository instead of 8. Well, not, I really downloaded the entire Everything directory (13GB) on a local disk and used createrepo to have my own full and fast repo. - Tried "yum --disablerepo=\* --enablerepo=ROB9_fedora_everything --exclude=kde\* upgrade" and got a list of dependency problems. Rerun the command adding "--exclude=extragear-plasma". The list was big but not too scary. In the mean time, I upgraded yum and rpm (it is considered good practice). - Some problems were very "peripheric", that is, were just caused by one or two packages: I simply used "yum remove" to remove the packages and kept note of them so I could readd them later. Some were old and unofficial stuff; just to give you an idea: ktorrent, compiz\*, alsaplayer, omgtools, transcode, vlc, pdftk, ckermit, cdecl, blender. The list got smaller. - The big issue appeared to be libssl.so.6 and libcrypto.so.6, as F9 switched to version so.7, but KDE3 needs v6 (openssl 0.9.8g vs 0.9.8b). While looking for a compat rpm, I was lucky to find a .src.rpm at https://bugzilla.redhat.com/show_bug.cgi?id=440560 which I rebuilt easily (on F8) to get my compat rpm. - Second issue: liblber-2.3.so.0 and libldap-2.3.so.0, which come from openldap-2.3.39 (F9 has 2.4.8). I downloaded the .src.rpm from F8 and modified the spec (Name: and a couple of %{name}) so I got another compat rpm I called openldap2339. - Third issue: libmikmod.so.2, which entangles to KDE3 somehow through xmms-libs. I got the .src.rpm from F8 and modified the spec to create my mikmod322 rpm. - Fourth issue: libopensync.so.0 libosengine.so.0 which are related to kdepim-libs. Created my libopensync022 by modifying the F8 src.rpm. - Fifth issue: libtcl8.4.so and tibtk8.4.so, but they were just needed for PIL (needed for scribus and others). There is a good PIL rpm in atrpms: PIL-1.1.6-8.fc9.i386.rpm. - So, finally I created my second local repository with these packages: libopensync022-0.22-4.fc8.i386.rpm libopensync022-debuginfo-0.22-4.fc8.i386.rpm mikmod322-3.2.2-6.fc8.i386.rpm mikmod322-debuginfo-3.2.2-6.fc8.i386.rpm openldap2339-2.3.39-3.fc8.i386.rpm openldap2339-debuginfo-2.3.39-3.fc8.i386.rpm openssl098b-0.9.8b-1.fc8.i386.rpm openssl098b-debuginfo-0.9.8b-1.fc8.i386.rpm PIL-1.1.6-8.fc9.i386.rpm - Retried the yum upgrade. Other dep problems were solved by removing some stuff (mplayer, openvpn, lrzip, lzop,...). - Another small issue could only be solved out of yum, with: rpm -e --nodeps libraw1394_8-1.3.0-3_11.fc8.i386 rpm -Uhv RPMS.everything/libraw1394-1.3.0-6.fc9.i386.rpm - Tried yum again: yum upgrade --disablerepo=\* --enablerepo=ROB9_fedora_everything --enablerepo=ROB9_fedora_mycompat --exclude=kde\* --exclude=extragear-plasma This time the upgrade succeeded. Install 124 Package(s) Update 1793 Package(s) Remove 2 Package(s) At this point the system was still perfectly running (I upgraded with X and firefox running, I just avoided starting new things during the upgrade). - Finally rebooted the machine to switch to the new system. The machine was not able to shutdown correctly because of the documented init/upstart change I forgot. So, it was an unclean reboot to F9 (reiserfs complained about replayed transactions on restart). - Got to runlevel 3. Installed some rpms from livna as I need the nvidia binary driver. - Switched to runlevel 5. Logged in as usual, my KDE3 desktop started up perfectly. - Activated all the F9 repos I normally use and ran yum a few times to update everything and install the stuff I had removed before (mplayer, vlc,...). - Realized that a few F9 KDE3 packages can be installed: kdevelop, kdevweb, kdesvn, kdetv (but not kdepim-libs). Everything is running fine; KDE3 is as perfect as before, including removable media, pulseaudio audio etc. The yum/rpm dependency rules proved very robust; I just had to satisfy a few deps, while tons of other deps were handled automatically. The (qt.rpm, qt4.rpm -> qt3.rpm, qt.rpm) switch happened totally unnoticed. This convoluted F9 upgrade actually was very smooth. The "normal" upgrade to F8 (with anaconda) was a disaster for me. But this time there was no need to restore my preupgrade backup. :-) The biggest issue is now that some firefox extensions are unavailable on version 3... Thank you to everyone involved in such a great distro. -- Roberto Ragusa mail at robertoragusa.it From ndbecker2 at gmail.com Sun Jun 1 22:35:19 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 01 Jun 2008 18:35:19 -0400 Subject: Howto build kde4 app on F9? Message-ID: I just tried to build kopete-otr-0.8. I did: cmake . make sudo make install Everything wound up in /usr/local What is the correct procedure? From ssorce at redhat.com Sun Jun 1 23:07:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 01 Jun 2008 19:07:32 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> <1212326077.25062.73.camel@localhost.localdomain> <1212332563.3156.28.camel@localhost.localdomain> Message-ID: <1212361652.3156.41.camel@localhost.localdomain> On Sun, 2008-06-01 at 11:49 -0400, Colin Walters wrote: > On Sun, Jun 1, 2008 at 11:02 AM, Simo Sorce wrote: > > So far we can only consiuder DBUS as a sort of local UDP > transport, if > all goes well messages get to their destination but are not > guaranteed. > > The argument here is that presently what we tell application authors > is much more like TCP than UDP; if we allowed distributors to restart > it in %post or the like automatically on upgrades, then we either have > to change our guarantee, or try to "hide" the fact that the bus gets > restarted under the covers. > > I think the only sensible solution is the latter. Which is certainly > *possible*, just like how everything short of the halting problem is > possible; but it would not be trivial. Yes I agree, handling the restart inside dbus libraries is the best choice. > For many likely classes of DBus flaws, porting the Ksplice > (http://web.mit.edu/ksplice/) style approach would be easiest > probably. To work you would have to separate very clearly functions from data structures, standardize the latter, hanging them off the main code and put the former into a loadable library, then you might be able to get to a state where you can dlclose() and dlopen() again the library and iot all just works. This, in theory, I never saw code clean enough to work this way, but usually this is just because it does not need to. :-) > But to handle the general case, I can imagine a system where we send > a special message to all clients like org.freedesktop.Local.Restart > and this causes them to enter a mode where they queue pending > messages, waiting via inotify for the socket to reappear. Yes this would be a decent solution too, although this would require some handling on the client apps. > The bus itself would try to flush all pending messages and save the > current map of connections->service names and other state I'm not > thinking of right now to JSON/XML/whatever. > > Then on startup you'd need to wait for all of the previous clients to > connect, probably with some timeout; I can't think of offhand how to > make this nrandomon-racy. After that we need to handle anything that > changed in the meantime like clients having exited and thus lost their > service name (this will happen for sure if we make other software > restart on upgrade like setroubleshoot does). So we compute that > delta and then send the relevant signals off to clients. yup > For someone who knew the code and was an A+ hacker it might only be a > two week or so job, though to actually know this worked you'd have to > spend a lot of time creating test cases. it may be tricky, but with a good test suite that insure this works it would be really worth it. > What was the cost/benefit analysis in this case? > > The original cost/benefit was "Absolutely nothing happens when I put > my USB key into a Linux desktop" and "The networking system is a > static mess of shell script that we edit via UIs run as root" =) eh.. :-) > Given some people is thinking of using NM by default also on > servers > then this issue become more critical, servers do serve > clients, > > Let's back up a second; if our overall goal is to make applying > security/important-reliability updates happen more transparently, I > think the best bang for the buck is going to be Linux. For example, > we could spend the engineering time figuring out how to get Ksplice > (http://web.mit.edu/ksplice/) work under the RPM hood. > > DBus has so far had a pretty good security and reliability track > record; while it's not simple software, it has simple goals and this > has limited complexity. Something like the Linux kernel clearly has a > much bigger goal and so is order(s) of magnitude more complex and with > this complexity has come the concomitant security/reliability issues. > > And if I had the ability to herd security/reliability cats, I'd have > them spend time on Firefox and try to take what Dan Walsh has been > doing even farther - break it up into multiple processes with locked > down security contexts and evaluate changes to the desktop to better > handle the concept of processes with different privilege for example. Security updates is just one aspect imo, reliability and self-repairing with minimal service disruption is another very important goal. Simo. -- Simo Sorce * Red Hat, Inc * New York From rdieter at math.unl.edu Mon Jun 2 00:44:23 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 01 Jun 2008 19:44:23 -0500 Subject: Howto build kde4 app on F9? References: Message-ID: Neal Becker wrote: > I just tried to build kopete-otr-0.8. I did: > cmake . > make > sudo make install > > Everything wound up in /usr/local > > What is the correct procedure? See: http://fedoraproject.org/wiki/SIGs/KDE/KDE4FAQ#How_can_I_package_kde4_software_for_fedora.3F In short, if you want it built in the same default prefix you need at least cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr if you want an app built the same as most other kde4 modules in fedora, you ought to envoke cmake such as the output of: rpm --eval "%{cmake_kde4}" (as defined in kde-filesystem pkg, see /etc/rpm/macros.kde4) -- Rex From kwade at redhat.com Mon Jun 2 01:03:38 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Sun, 01 Jun 2008 18:03:38 -0700 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530212028.6b0f0839@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> <1212199688.16130.135.camel@localhost.localdomain> <20080530212028.6b0f0839@vader.jdub.homelinux.org> Message-ID: <1212368618.17426.105.camel@calliope.phig.org> On Fri, 2008-05-30 at 21:20 -0500, Josh Boyer wrote: > On Fri, 30 May 2008 22:08:08 -0400 > Jesse Keating wrote: > > > On Fri, 2008-05-30 at 17:17 -0700, Karsten 'quaid' Wade wrote: > > > Not all contributors slavishly read every word on fedora-devel-list. > > > > Perhaps not. But perhaps the chance to participate in the naming of a > > distribution is a treat we gift upon those that do... > > I think you tread a fine line there. > > Most contributors are on fedora-devel list or follow it some way. > However, I can see how some on docs or art, who _are_ doing, wouldn't > be. Hence my offer to extend it for 4 days so Karsten can forward the > rules email to the contributing groups he thinks might not be following > fedora-devel. Josh and all, thanks. Sorry for my original parade raining attitude; I'm as responsible as anyone for not making sure changes were written down enough to be fixed or repeated next time. By now all of you (who have signed/agreed to the CLA) have received the email I sent. You can let me know if it is in the right spirit. When given the task by Josh to "make the list we send the announcement to", I realized there was no way I could make such a list and be fair. Thus, I picked the mark of those have agreed to the the CLA, as that is our general mark for "contributor." Of course, they still have to be bold enough to come on this list and put forward their suggestion. :) - Karsten -- Karsten Wade, Sr. 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 fedora at slated.org Mon Jun 2 02:28:51 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 03:28:51 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? Message-ID: <8g2ch5-52b.ln1@sky.matrix> Any comments on the following, and how it might pertain to future releases?: [quote] I noticed a comment thread on Groklaw about Moonlight, with a link to the license terms on Microsoft's website. They call it Covenant to Downstream Recipients of Moonlight - Microsoft & Novell Interoperability Collaboration . A comment by Microsoft's Brian Goldfarb on Dana Blankenhorn's article about Novell being a lead pony for Silverlight started the discussion originally. Goldfarb represented that anyone can use Moonlight: "Moonlight is usable for anyone on any distribution of Linux (redhat, ubuntu, etc.) -- it is not limited just to Novell as Mono is." And he linked to the covenant, saying it "applies to all downstream recepients of the software." Is that true? ... "Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not to sue Downstream Recipients of Novell and its Subsidiaries for infringement under Necessary Claims of Microsoft on account of such Downstream Recipients? use of Moonlight Implementations to the extent originally provided by Novell during the Term and, if applicable, the Extension or Post-Extension Period, but only to the extent such Moonlight Implementations are used to provide Plug-In Functionality. The foregoing covenants shall survive termination of the Agreement, but only as to specific copies of such Moonlight Implementations distributed during the Term, and if applicable, the Extension or Post-Extension Period." ... Q: But the definitions section seems to be saying that Moonlight is safe from threat only if you get it from Novell AND DO NOT PASS IT ON, as there are no protections for downstream recipients. A: Correct, unless those downstream recipients get it from an 'Intermediate Recipient' defined to only include authorized resellers. [quote] http://www.groklaw.net/article.php?story=20080528133529454 I was particularly interested in the phrase "it is not limited just to Novell as Mono is." ^^^^^^^^^^ I know you don't ship Moonlight, and I sincerely hope you never do, but you /do/ ship Mono, and I have been vigorously campaigning (in various places) for distros not to, without much success. I think this latest revelation is finally vindication of my concerns, and you should drop Mono like a hot brick. On the subject of Microsoft's "covenants", there's also this: [quote] So much quarreling about open standards. Jason Matusow advocates for a document format with RAND licensing conditions for the patents. What does he mean when he talks about RAND? RAND stands for "reasonable and non-discriminatory". But Jason Matusow's company Microsoft lacks honesty when it talks about "reasonable and non-discriminatory" conditions. ... Reasonable and non-discriminatory in patent licensing means "we apply a uniform fee". ... RAND patent licensing conditions are a tool to ban Free Software, which is entirely incompatible with RAND licensing conditions. Now one side of the debate blames it on the patent licensing conditions, the other side on the software licensing conditions. "The reason I agree with the statement about patents and Free Software not mixing is that there have been terms written into GPL licenses that explicitly conflict with software patents. Okay, that is the choice of the authors and users of those licenses." [quote] http://www.digitalmajority.org/forum/t-54546/reasonable-and-not-non-discriminatory It seems clear to me that the cloak of ECMA's RAND, that Microsoft hides their .NET and OOXML patents behind, has been exposed as a sham. IOW the Emperor has no clothes. Why are you still shipping Mono? Then there's this new debacle over Firefox: [quote] I decided to upgrade my copy of Firefox 3 Beta5 to the recent Release Candidate today and was greeted with something quite unexpected. Instead of my browser window opening as it was supposed to do I was given a End-User Software License Agreement (EULA) screen which would not let me use Firefox until I agreed with the terms and conditions. While Mozilla has had a EULA since Firefox 1.5 or so they have never brazenly shoved it into the end-user's face until now. It immediately set me on edge because this behavior is indicative of proprietary software and not something you would expect to see when using something that is open source. [quote] http://www.linuxinfusion.com/firefox-3-rc1-forces-you-agree-eula-usage Why are you still shipping Firefox instead of GNU IceCat, which is after all exactly the same software - but without the additional restrictions that make Firefox? non-Free? -- Regards, Keith G. Robertson-Turner From vonbrand at inf.utfsm.cl Mon Jun 2 02:59:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 01 Jun 2008 22:59:39 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <8g2ch5-52b.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> Message-ID: <200806020259.m522xdur009235@laptop13.inf.utfsm.cl> As far as I see, the Moonlight "Covenant" is /far/ from open source; so as long as the conditions stay as today, this is just out of the question for Fedora. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Jun 2 02:59:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 01 Jun 2008 22:59:39 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <8g2ch5-52b.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> Message-ID: <200806020259.m522xdur009235@laptop13.inf.utfsm.cl> As far as I see, the Moonlight "Covenant" is /far/ from open source; so as long as the conditions stay as today, this is just out of the question for Fedora. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From debarshi.ray at gmail.com Mon Jun 2 05:45:40 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon, 2 Jun 2008 11:15:40 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: Message-ID: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Following Non-responsive Maintainer Policy, maintainer was mailed but > he did not responded repeated mails at regular intervals. I had sent a couple of mails too but none of the addresses are working. Cheerio, Debarshi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIQ4d/TMO+PGPUpacRAr0NAJ9rxc/qCZWu0YXLkAPDnp1y5YUK8gCfah5k d9NKgGAViq9TNrcf410jitw= =WGeY -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Mon Jun 2 06:11:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jun 2008 11:41:08 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <8g2ch5-52b.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> Message-ID: <48438EFC.8010402@fedoraproject.org> Keith G. Robertson-Turner wrote: > Any comments on the following, and how it might pertain to future releases?: Moonlight: http://fedoraproject.org/wiki/ForbiddenItems#Moonlight Mono has been discussed extensively in the past. So just refer to list archives for details. Firefox: EULA shown is just MPL/LGPL/GPL and doesn't really make it non-free anymore than showing EULA in previous Fedora releases made it non-free. However refer https://bugzilla.redhat.com/show_bug.cgi?id=447661 Rahul From jamatos at fc.up.pt Mon Jun 2 07:18:36 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Mon, 2 Jun 2008 08:18:36 +0100 Subject: Successfully upgraded to F9 while keeping KDE 3 In-Reply-To: <484323CD.1080308@robertoragusa.it> References: <484323CD.1080308@robertoragusa.it> Message-ID: <200806020818.37534.jamatos@fc.up.pt> On Sunday 01 June 2008 23:33:49 Roberto Ragusa wrote: > PIL-1.1.6-8.fc9.i386.rpm python-imaging is in Fedora. Why do you need this packaged differently? -- Jos? Ab?lio From fdinitto at redhat.com Mon Jun 2 07:58:40 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Mon, 02 Jun 2008 09:58:40 +0200 Subject: multiple updates to F-9 procedure Message-ID: <1212393520.27942.3.camel@diapolon.int.fabbione.net> Hi guys, I have prepared a bunch of updates for F-9 in coordination with the involved maintainers for the following packages: openais cman gfs2-utils rgmanager I am now at the step to submit the request to bodhi but there is one little problem I am not sure how to address. All the updates need to go into testing/stable at the same time in order to work. What is the right procedure to guarantee that it will happen properly? Thanks Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Mon Jun 2 08:12:13 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 2 Jun 2008 10:12:13 +0200 Subject: multiple updates to F-9 procedure In-Reply-To: <1212393520.27942.3.camel@diapolon.int.fabbione.net> References: <1212393520.27942.3.camel@diapolon.int.fabbione.net> Message-ID: <20080602101213.552e093f.mschwendt@gmail.com> On Mon, 02 Jun 2008 09:58:40 +0200, Fabio M. Di Nitto wrote: > Hi guys, > > I have prepared a bunch of updates for F-9 in coordination with > the involved maintainers for the following packages: > > openais > cman > gfs2-utils > rgmanager > > I am now at the step to submit the request to bodhi but there is one > little problem I am not sure how to address. > > All the updates need to go into testing/stable at the same time in order > to work. > > What is the right procedure to guarantee that it will happen properly? In Bodhi you can add multiple packages to a single update request. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.18 1.21 1.21 From dan at danny.cz Mon Jun 2 08:13:55 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 02 Jun 2008 10:13:55 +0200 Subject: multiple updates to F-9 procedure In-Reply-To: <1212393520.27942.3.camel@diapolon.int.fabbione.net> References: <1212393520.27942.3.camel@diapolon.int.fabbione.net> Message-ID: <1212394435.3436.3.camel@eagle.danny.cz> Fabio M. Di Nitto p??e v Po 02. 06. 2008 v 09:58 +0200: > Hi guys, > > I have prepared a bunch of updates for F-9 in coordination with > the involved maintainers for the following packages: > > openais > cman > gfs2-utils > rgmanager > > I am now at the step to submit the request to bodhi but there is one > little problem I am not sure how to address. > > All the updates need to go into testing/stable at the same time in order > to work. > > What is the right procedure to guarantee that it will happen properly? Use the button "Add another build" in the Bodhi web interface, so you will create one request with multiple packages. Dan From fdinitto at redhat.com Mon Jun 2 08:25:20 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Mon, 02 Jun 2008 10:25:20 +0200 Subject: multiple updates to F-9 procedure In-Reply-To: <20080602101213.552e093f.mschwendt@gmail.com> References: <1212393520.27942.3.camel@diapolon.int.fabbione.net> <20080602101213.552e093f.mschwendt@gmail.com> Message-ID: <1212395120.27942.4.camel@diapolon.int.fabbione.net> On Mon, 2008-06-02 at 10:12 +0200, Michael Schwendt wrote: > On Mon, 02 Jun 2008 09:58:40 +0200, Fabio M. Di Nitto wrote: > > > Hi guys, > > > > I have prepared a bunch of updates for F-9 in coordination with > > the involved maintainers for the following packages: > > > > openais > > cman > > gfs2-utils > > rgmanager > > > > I am now at the step to submit the request to bodhi but there is one > > little problem I am not sure how to address. > > > > All the updates need to go into testing/stable at the same time in order > > to work. > > > > What is the right procedure to guarantee that it will happen properly? > > In Bodhi you can add multiple packages to a single update request. Ok thanks a lot. It did look a lot like multiple build of the same package.. Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Jun 2 08:26:59 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Jun 2008 10:26:59 +0200 (CEST) Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <48438EFC.8010402@fedoraproject.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> Message-ID: <34533.192.54.193.52.1212395219.squirrel@rousalka.dyndns.org> Le Lun 2 juin 2008 08:11, Rahul Sundaram a ?crit : > Firefox: EULA shown is just MPL/LGPL/GPL It's not. In particular the "privacy policy" bits are more than borderline in any country but the USA. (not just from a FLOSS angle, from a general legal angle). > and doesn't really make it > non-free anymore than showing EULA in previous Fedora releases made it > non-free. Is this a legal opinion? -- Nicolas Mailhot From fedora at slated.org Mon Jun 2 08:24:35 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 09:24:35 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <48438EFC.8010402@fedoraproject.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> Message-ID: <4843AE43.4050801@slated.org> Verily I say unto thee, that Rahul Sundaram spake thusly: > Keith G. Robertson-Turner wrote: >> Any comments on the following, and how it might pertain to future >> releases?: > > Moonlight: > > http://fedoraproject.org/wiki/ForbiddenItems#Moonlight Thank you. I hadn't actually seen that page, but I was aware that you'd blocked Moonlight as non-Free. Indeed, this is why I'm so surprised that you don't block Mono for the same, or similar, reasons. > Mono has been discussed extensively in the past. So just refer to > list archives for details. In advance of reviewing the archives, I'd just like to reiterate concerns that have been made about Mono elsewhere: [quote] I read the agreement between Xandros and Microsoft, and one of the excluded products was Mono, so Microsoft promises to not sue Xandros over their distribution but excluding Mono and a few other products, i.e. they reserve the right to sue over Mono. I wonder if this is an interesting preview of on what basis they want to fight the free world. Interestingly, the Novell deal seems to be different, Mono is not excluded from the Novell deal. So Microsoft seems to be promising not to sue Novell over Mono, but keeps the option open for Xandros. Weird but true. [/quote] http://commandline.org.uk/linux/2007/aug/5/be-careful-who-you-kiss/ Coupled with the revelations of Microsoft's agenda for Moonlight, I'd say it's pretty clear that Mono is a serious (and unnecessary) risk, since Mono is encumbered by similar terms, by the same patent holder. > Firefox: EULA shown is just MPL/LGPL/GPL and doesn't really make it > non-free anymore than showing EULA in previous Fedora releases made > it non-free. Having read the EULA, I see there is considerably more in there than just the MPL, in fact there is no mention of the GPL at all, and only a very brief reference to the MPL. The vast majority of the document details Intellectual Property restrictions, and other insidious elements such as export restrictions. Also, I really don't think that Free Software should require an affirmative confirmation of license acceptance to allow use of that software, especially when what one is "accepting" is the revocation of one's rights WRT that software. The EULA itself does not even read like an expression of Freedom, but much more like a corporate declaration that /inhibits/ Freedom. In fact I couldn't even locate a copy of that version of the license on Mozilla Corp's Website, to review before deciding whether or not to download the software, although this is a preview release, so that may (hopefully) change. Ultimately I had to download the tarball, and even then I could not find a license file to read, I had to actually run the software to see the (presumably embedded) license. I've published a copy here (I assume that publishing a copy of the license is not, in and of itself, some form of Intellectual Property violation): http://slated.org/firefox_3_is_this_really_free_software [quote] By clicking the "Accept" button, or by installing or using the Mozilla Firefox Browser, you are consenting to be bound by the Agreement. If you do not agree to the terms and conditions of this Agreement, do not click the "Accept" button, and do not install or use any part of the Mozilla Firefox Browser. ... Mozilla, for itself and on behalf of its licensors, hereby reserves all intellectual property rights in the Product, except for the rights expressly granted in this Agreement. You may not remove or alter any trademark, logo, copyright or other proprietary notice in or on the Product. This license does not grant you any right to use the trademarks, service marks or logos of Mozilla or its licensors. ... 8. EXPORT CONTROLS. This license is subject to all applicable export restrictions. You must comply with all export and import laws and restrictions and regulations of any United States or foreign agency or authority relating to the Product and its use. 9. U.S. GOVERNMENT END-USERS. This Product is a "commercial item," as that term is defined in 48 C.F.R. 2.101, consisting of "commercial computer software" and "commercial computer software documentation," as such terms are used in 48 C.F.R. 12.212 (Sept. 1995) and 48 C.F.R. 227.7202 (June 1995). Consistent with 48 C.F.R. 12.212, 48 C.F.R. 27.405(b)(2) (June 1998) and 48 C.F.R. 227.7202, all U.S. Government End Users acquire the Product with only those rights as set forth therein. [/quote] IMHO this is non-Free, and obviously both Debian and FSF agree with me, since they have each forked Firefox. Personally I just don't see why there should be an issue switching to the Freest available version of any given software. > However refer > > https://bugzilla.redhat.com/show_bug.cgi?id=447661 Thank you. -- Regards, Keith G. Robertson-Turner From rjones at redhat.com Mon Jun 2 08:29:17 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 2 Jun 2008 09:29:17 +0100 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072422.A1480@humbolt.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> Message-ID: <20080602082917.GB29726@amd.home.annexia.org> On Sat, May 31, 2008 at 07:24:22AM -0500, Matt Domsch wrote: > ocaml-SDL-0.7.2-12.fc10 (build/make) rjones I deliberately removed the old 'lablgl' dependency last week, but obviously my scripts missed this package which still needed it. Now fixed in Rawhide. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Mon Jun 2 08:38:15 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 2 Jun 2008 09:38:15 +0100 Subject: Orphaning my Packages - "packager pump-ups" :-) In-Reply-To: <483C0A79.9000404@iinet.net.au> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> <483C0A79.9000404@iinet.net.au> Message-ID: <20080602083815.GA590@amd.home.annexia.org> On Tue, May 27, 2008 at 11:19:53PM +1000, David Timms wrote: > How many times has my package, and it's updates been downloaded ? You might want to have a look at Debian popcon, which collects similar sorts of stats for Debian: http://popcon.debian.org/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rawhide at fedoraproject.org Mon Jun 2 09:15:13 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 2 Jun 2008 09:15:13 +0000 (UTC) Subject: rawhide report: 20080602 changes Message-ID: <20080602091513.58359209CE6@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080601/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080602/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package automoc KDE4 automoc New package gstreamermm C++ wrapper for GStreamer library New package guidance-power-manager KDE Power Manager New package libyahoo2 Library for the Yahoo! Messenger Protocol New package msort Sort files in sophisticated ways New package perl-Catalyst-Plugin-Session-State-Cookie Maintain session IDs using cookies New package python-dictclient Python client for DICT protocol New package squirrel High level imperative/OO programming language New package trophy Car racing game with special features Updated Packages: GraphicsMagick-1.1.10-4.fc10 ---------------------------- * Sun Jun 1 18:00:00 2008 Dennis Gilmore - 1.1.10-4 - sparc64 is a 64 bit arch autodownloader-0.3.0-1.fc10 --------------------------- * Sun Jun 1 18:00:00 2008 Hans de Goede 0.3.0-1 - New upstream release (all patches merged) - Includes new icons by Michael Beckwith bigloo-3.1a-1.fc10 ------------------ * Sat May 31 18:00:00 2008 Gerard Milmeister - 3.1a-1 - new release 3.1a * Mon Apr 14 18:00:00 2008 Gerard Milmeister - 3.0c-4.1 - new release 3.0c-4 cairo-dock-1.5.6-2.svn1064_trunk.fc10 ------------------------------------- * Sun Jun 1 18:00:00 2008 Mamoru Tasaka - svn 1064 chmsee-1.0.1-3.fc10 ------------------- * Sat May 17 18:00:00 2008 bbbush - 1.0.1-3 - update to 1.0.1 - specify gecko-provider to "libxul", add nspr in patch to configure - BR libgcrypt-devel instead of openssl-devel * Fri Apr 25 18:00:00 2008 bbbush - 1.0.0-2.37 - patch from Martin Stransky to fix crash on open files (rh#427622) cluster-2.99.03-1.fc10 ---------------------- * Mon Jun 2 18:00:00 2008 Fabio M. Di Nitto - 2.99.03-1 - New upstream release - cman Requires telnet and ssh client - drops some tree fix up bits that are now upstream eclipse-epic-0.6.24-1.fc10 -------------------------- * Sun Jun 1 18:00:00 2008 Mat Booth 0.6.24-1 - Updated to version 0.6.24. eclipse-phpeclipse-1.1.8-18.fc10 -------------------------------- fwbackups-1.43.2-0.1.rc2.fc10 ----------------------------- * Sat May 31 18:00:00 2008 Stewart Adam 1.43.2-0.1.rc2 - Update to 1.43.2rc2 - Don't require vixie-cron, but do require /usr/bin/crontab gdb-6.8-10.fc10 --------------- * Sun Jun 1 18:00:00 2008 Jan Kratochvil - 6.8-10 - Fix crash on a watchpoint update on an inferior stop. - Fix the s390x part of the hardware watchpoints after a fork. jd-2.0.0-0.6.beta080601.fc10 ---------------------------- mkvtoolnix-2.2.0-1.fc10 ----------------------- * Sun Jun 1 18:00:00 2008 Dominik Mierzejewski 2.2.0-1 - updated to 2.2.0 - dropped redundant BRs munipack-1.1.24-1.fc10 ---------------------- * Sun Jun 1 18:00:00 2008 Marek Mahut - 1.1.24-1 - Project fork to cmunipack pciutils-3.0.0-1.fc10 --------------------- * Mon Jun 2 18:00:00 2008 Harald Hoyer 3.0.0-1 - version 3.0.0 * Mon May 26 18:00:00 2008 Tom "spot" Callaway 2.2.10-2 - add sparc support perl-CSS-1.08-3.fc10 -------------------- * Thu May 1 18:00:00 2008 Terje Rosten - 1.08-3 - Fix broken build perl-Catalyst-View-TT-0.27-1.fc10 --------------------------------- * Wed May 28 18:00:00 2008 Chris Weyl 0.27-1 - update to 0.27 python-sqlalchemy-0.4.6-1.fc10 ------------------------------ * Sun Jun 1 18:00:00 2008 Toshio Kuratomi 0.4.6-1 - Update to 0.4.6. * Tue Apr 8 18:00:00 2008 Toshio Kuratomi 0.4.5-1 - Update to 0.4.5. stunnel-4.25-1 -------------- * Mon Jun 2 18:00:00 2008 Miloslav Trma?? - 4.25-1 - Update to stunnel-4.25 wine-docs-1.0-0.3.rc3.fc10 -------------------------- * Sun Jun 1 18:00:00 2008 Andreas Bierfert - 1.0-0.3.rc3 - version upgrade xdrawchem-1.9.9-10.fc10 ----------------------- * Sun Jun 1 18:00:00 2008 Dominik Mierzejewski 1.9.9-10 - fix segfault (#447531), patch by Mamoru Tasaka - don't use %makeinstall xine-plugin-1.0.1-3.fc10 ------------------------ * Sun Jun 1 18:00:00 2008 Martin Sourada - 1.0.1-3 - require mozilla-filesystem instead of xulrunner on >= F9 xorg-x11-drv-openchrome-0.2.902-7.fc10 -------------------------------------- * Sat May 31 18:00:00 2008 Xavier Bachelot - 0.2.902-7 - New panel and hardware cursor code from randr branch. * Sat May 31 18:00:00 2008 Xavier Bachelot - 0.2.902-6 - Disable XvDMA for K8M890 and P4M890 (RHBZ #391621). * Mon May 26 18:00:00 2008 Xavier Bachelot - 0.2.902-5 - Add patch to fix Xv on LCD for CX700. * Sun May 25 18:00:00 2008 Xavier Bachelot - 0.2.902-4 - Unbreak ActiveDevice option. Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 22 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From alan at redhat.com Mon Jun 2 09:24:22 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Jun 2008 05:24:22 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212326077.25062.73.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> <1212326077.25062.73.camel@localhost.localdomain> Message-ID: <20080602092422.GC18697@devserv.devel.redhat.com> On Sun, Jun 01, 2008 at 09:14:37AM -0400, Dan Williams wrote: > Suddenly all the state dependent on a D-Bus service is suspect, because > you have no idea what's going on while the bus is down. You have to > re-synchronize your state after the bus comes back, and that's not a > simple task. No. This is a myth. It is *desirable* to resynchronize state. Dbus clients come and go and get restarted (or do you want to argue the farcical 'any dbus connected service cannot be restarted' in which case have a spade and keep digging) > > - Why isn't there a recovery mechanism > > The recovery mechanism would be in each service, because the service > knows whether or not it needs recovery or not, and would know how to > merge/synchronize it's state with the services that it depends on. Some > don't need to. But ones with state dependent on other D-Bus services > would. For 99% of cases if dbus sent a 'dbus restart' message (or the dbus library did that) then application behaviour would be acceptable but not ideal if - Applications ignored it - Some applications just restarted themselves from scratch Almost no work required > it's communication channels with the daemons that affect that > NM-specific state are gone, and NM can't make any assumptions about > what's happening in any other daemon while the bus is gone. Maybe your > VPN just came up for rekeying, but the signal got lost because D-Bus > isn't around. So when the bus comes back, your VPN connection is > already dropped. Which is fine. In a proper model NM takes a "dbus exploded" message from the support library and either restarts itself or reconfigures. > > "oh dear it broke everyone reboot" is not good engineering. > > In some cases, it's a cost/benefit analysis. Is the cost of writing and > maintaining a pile of code that handles a D-Bus restart, which shouldn't > ever happen, worth the benefit? In some cases, definitely. In other > cases, probably not. That isn't an excuse to write crappy software, but > it's certainly not as simple of a problem as you present it. For the complex cases like changing nautilus icons agreed but for the 99% case the 'I missed it' and 'restart' responses are both better than praying it doesn't occur. Another approach of course would be to hang a persistant state daemon off dbus which is the way a lot of object models actually work and which can answer "last state of X was" - that also helps sort out a pile of runtime ordering issues. Alan From mail at robertoragusa.it Mon Jun 2 09:34:16 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 02 Jun 2008 11:34:16 +0200 Subject: Successfully upgraded to F9 while keeping KDE 3 In-Reply-To: <200806020818.37534.jamatos@fc.up.pt> References: <484323CD.1080308@robertoragusa.it> <200806020818.37534.jamatos@fc.up.pt> Message-ID: <4843BE98.6060905@robertoragusa.it> Jos? Matos wrote: > On Sunday 01 June 2008 23:33:49 Roberto Ragusa wrote: >> PIL-1.1.6-8.fc9.i386.rpm > > python-imaging is in Fedora. Why do you need this packaged differently? The auto deps resolution didn't notice that, just complained that we need PIL, which needs tck8.4 and tcl8.4. Indeed, I had almost finished packaging tk/tcl 8.4 when I discovered the PIL rpm in atrpms. I've just tried to remove PIL (atrpms) and install python-imaging (f9). It is not OK, because mytharchive (atrpms) requires PIL. Mytharchive could be fixed or maybe python-imaging could provide PIL. Added Cc to Axel Thimm. Best regards. [root at thinkpad RPMS.everything]# rpm -e PIL error: Failed dependencies: python-imaging is needed by (installed) skencil-0.6.17-18.20070606svn.fc9.i386 python-imaging is needed by (installed) scribus-1.3.4-5.fc9.i386 python-imaging is needed by (installed) hplip-2.8.2-2.fc9.i386 PIL is needed by (installed) mytharchive-0.21-189.fc9.i386 [root at thinkpad RPMS.everything]# rpm -e --nodeps PIL [root at thinkpad RPMS.everything]# rpm -ihv python-imaging-1.1.6-9.fc9.i386.rpm Preparing... ########################################### [100%] 1:python-imaging ########################################### [100%] [root at thinkpad RPMS.everything]# rpm -e python-imaging error: Failed dependencies: python-imaging is needed by (installed) skencil-0.6.17-18.20070606svn.fc9.i386 python-imaging is needed by (installed) scribus-1.3.4-5.fc9.i386 python-imaging is needed by (installed) hplip-2.8.2-2.fc9.i386 -- Roberto Ragusa mail at robertoragusa.it From sundaram at fedoraproject.org Mon Jun 2 09:39:42 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jun 2008 15:09:42 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <34533.192.54.193.52.1212395219.squirrel@rousalka.dyndns.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <34533.192.54.193.52.1212395219.squirrel@rousalka.dyndns.org> Message-ID: <4843BFDE.9060909@fedoraproject.org> Nicolas Mailhot wrote: > Le Lun 2 juin 2008 08:11, Rahul Sundaram a ?crit : > >> Firefox: EULA shown is just MPL/LGPL/GPL > > It's not. In particular the "privacy policy" bits are more than > borderline in any country but the USA. (not just from a FLOSS angle, > from a general legal angle). Feel free to comment on the bugzilla report referenced earlier. > >> and doesn't really make it >> non-free anymore than showing EULA in previous Fedora releases made it >> non-free. > > Is this a legal opinion? You have to find a lawyer for that. Rahul From sundaram at fedoraproject.org Mon Jun 2 09:43:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jun 2008 15:13:52 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4843AE43.4050801@slated.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <4843AE43.4050801@slated.org> Message-ID: <4843C0D8.2060403@fedoraproject.org> Keith G. Robertson-Turner wrote: > > Also, I really don't think that Free Software should require an > affirmative confirmation of license acceptance to allow use of that > software, especially when what one is "accepting" is the revocation of > one's rights WRT that software. This is correct which is which is why I asked the person complaining about this on fedora-test list to file a bug report which has already been done. So further comments should go there. > > IMHO this is non-Free, and obviously both Debian and FSF agree with me, > since they have each forked Firefox. Debian forked because the logo is non-free and FSF has forked earlier due to non-free components like talkback which we didn't include in Fedora. Export controls do not make a software non-free according to FSF. Refer http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF Rahul From bnocera at redhat.com Mon Jun 2 10:05:25 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 02 Jun 2008 11:05:25 +0100 Subject: Kernel headers changes in F10? Message-ID: <1212401125.30350.17.camel@cookie.hadess.net> Heya, I'm having trouble compiling the GStreamer V4L2 plugin on F10, when it work perfectly for the exact same source in F9. F10: http://koji.fedoraproject.org/koji/getfile?taskID=640403&name=build.log F9: http://koji.fedoraproject.org/koji/getfile?taskID=640384&name=build.log Any changes somebody knows of? Cheers From j.w.r.degoede at hhs.nl Mon Jun 2 09:59:27 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jun 2008 11:59:27 +0200 Subject: Kernel headers changes in F10? In-Reply-To: <1212401125.30350.17.camel@cookie.hadess.net> References: <1212401125.30350.17.camel@cookie.hadess.net> Message-ID: <4843C47F.3000001@hhs.nl> Bastien Nocera wrote: > Heya, > > I'm having trouble compiling the GStreamer V4L2 plugin on F10, when it > work perfectly for the exact same source in F9. > > F10: > http://koji.fedoraproject.org/koji/getfile?taskID=640403&name=build.log > F9: > http://koji.fedoraproject.org/koji/getfile?taskID=640384&name=build.log > > Any changes somebody knows of? > There seem to be a number of changes in the 2.6.26 kernel headers causing compile breakage (and/or in the new glibc), I've had to fix both of: svgalib, really fixed gkrellm-wifi, conflict between and , worked around by no longer including So although I don't know anything about specific changes to the v4l headers, there are definitely problems with the kernel / glibc headers in rawhide all over the place. Regards, Hans From rjones at redhat.com Mon Jun 2 10:28:43 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 2 Jun 2008 11:28:43 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <8g2ch5-52b.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> Message-ID: <20080602102843.GB590@amd.home.annexia.org> On Mon, Jun 02, 2008 at 03:28:51AM +0100, Keith G. Robertson-Turner wrote: > Why are you still shipping Mono? Have MSFT actually revealed what patents Mono might infringe yet? Since Mono/.Net is just a warmed-over version of Java/p-Code and other concepts dating back 30 years or more it seems like these patents (if identified) are probably worthless anyway. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From dwmw2 at infradead.org Mon Jun 2 10:31:56 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Jun 2008 11:31:56 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <1212401125.30350.17.camel@cookie.hadess.net> References: <1212401125.30350.17.camel@cookie.hadess.net> Message-ID: <1212402716.16924.81.camel@pmac.infradead.org> On Mon, 2008-06-02 at 11:05 +0100, Bastien Nocera wrote: > Heya, > > I'm having trouble compiling the GStreamer V4L2 plugin on F10, when it > work perfectly for the exact same source in F9. > > F10: > http://koji.fedoraproject.org/koji/getfile?taskID=640403&name=build.log > F9: > http://koji.fedoraproject.org/koji/getfile?taskID=640384&name=build.log > > Any changes somebody knows of? Rather than a link to a huge text file, it might have been useful to include the failure mode, which is this: v4l2_calls.c:268: error: 'V4L2_CID_HCENTER' undeclared (first use in this function) v4l2_calls.c:268: error: (Each undeclared identifier is reported only once v4l2_calls.c:268: error: for each function it appears in.) v4l2_calls.c:269: error: 'V4L2_CID_VCENTER' undeclared (first use in this function) A few moments with git-annotate showed that the missing ioctls were removed in commit 26d507fcfef7f7d0cd2eec874a87169cc121c835? by Brandon Philips. In their place, we have the following: /* Deprecated, use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */ #define V4L2_CID_HCENTER_DEPRECATED (V4L2_CID_BASE+22) #define V4L2_CID_VCENTER_DEPRECATED (V4L2_CID_BASE+23) That seems like a rather dubious change to the user API -- shouldn't we ensure that existing software continues to build, but maybe add a compile-time or run-time warning for those using the deprecated ioctls? Mauro, Brendan: unless the removal of those ioctls has been properly documented in Documentation/feature-removal-schedule.txt for an appropriate amount of time, please could you put them back as they were. Changing the userspace API like this isn't acceptable. -- dwmw2 ? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=26d507fc From dwmw2 at infradead.org Mon Jun 2 10:33:45 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Jun 2008 11:33:45 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <4843C47F.3000001@hhs.nl> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> Message-ID: <1212402825.16924.84.camel@pmac.infradead.org> On Mon, 2008-06-02 at 11:59 +0200, Hans de Goede wrote: > There seem to be a number of changes in the 2.6.26 kernel headers causing > compile breakage (and/or in the new glibc), I've had to fix both of: > > svgalib, really fixed > > gkrellm-wifi, conflict between and , worked > around by no longer including I always like solutions which involve "include fewer kernel headers", but we should probably investigate that in case there is some need for someone to include both. John? > So although I don't know anything about specific changes to the v4l headers, > there are definitely problems with the kernel / glibc headers in rawhide all > over the place. Details or (preferably) bug numbers, please. -- dwmw2 From jroth at linux.vnet.ibm.com Mon Jun 2 10:46:36 2008 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Mon, 02 Jun 2008 12:46:36 +0200 Subject: Interest in Cell architecture SIG In-Reply-To: <1212237247.2784.8.camel@ScaryMonster> References: <1212237247.2784.8.camel@ScaryMonster> Message-ID: <4843CF8C.9070206@linux.vnet.ibm.com> > (a) Are you interested in a Fedora Architecture SIG for Cell who would > test and maintain a SPU tool chain, and Yes, indeed I'm interested. > (b) Are you interested in taking the route I've taken in constructing a > tool chain for Fedora (GCC 4.3 based) rather than supporting the IBM > Cell SDK (GCC 4.1 based)? It would be really good to have toolchain support in Fedora for the Cell architecture. Right now we are initially trying to get libspe2 as a package into Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=442507 As soon as we have this package approved we may try to get others included as well. I'll talk with our maintainers and let you know about the results. -- Jochen From fedora at slated.org Mon Jun 2 11:19:51 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 12:19:51 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080602102843.GB590@amd.home.annexia.org> References: <8g2ch5-52b.ln1@sky.matrix> <20080602102843.GB590@amd.home.annexia.org> Message-ID: Verily I say unto thee, that Richard W.M. Jones spake thusly: > On Mon, Jun 02, 2008 at 03:28:51AM +0100, Keith G. Robertson-Turner > wrote: >> Why are you still shipping Mono? > > Have MSFT actually revealed what patents Mono might infringe yet? Do they ever? Of course they never will, they don't need to - the FUD works better. > Since Mono/.Net is just a warmed-over version of Java/p-Code and > other concepts dating back 30 years or more it seems like these > patents (if identified) are probably worthless anyway. Yes I agree, but it isn't a very comfortable position to have Ballmer breathing down one's neck and leering in a menacing fashion. -- Regards, Keith G. Robertson-Turner From Christian.Iseli at unil.ch Mon Jun 2 11:25:43 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Mon, 2 Jun 2008 13:25:43 +0200 Subject: About FESCo Message-ID: <20080602132543.7b8225ff@ludwig-alpha.unil.ch> Dear All, Apologies for not participating in last week's meeting: real life got in the way... I read the #fedora-meeting logs, and thought I'd share my views here. I view the board as a political body, and an interface between corporate sponsors and the Fedora project. They get to deal with money matters, and have the final word on all Fedora matters. They can meddle in technical matters if they so wish, but I do not think it is their mandate. I like spot's approach of saying they tell us "we need to fly" and provide for some level ground for us to take off. Unless I'm mistaken, the board head is paid by RH, as is wwoods of QA and f13 of releng. These folks are incredibly useful and dedicated to get each release off the ground. I see FESCo as a bunch of elected volunteers that people come to and ask "is it ok if ..." when they have questions wrt what they can put in Fedora. FESCo's answer should have arbitration value for all technical matters. I think FESCo members should also be willing to act as emergency response team when some fire needs to be put out, e.g. a mass rebuild needs some manual help to complete. I do not think it is FESCo's role to come up with ideas of what the future should be like. I think this kind of creativity is better served by SIGs or individual contributors. I agree a lot of FESCo's work is just rubber stamping propositions from SIGs. But I think someone needs to be there to do it. As Fedora contributor, I feel better knowing that a bunch of elected volunteers is manning the deck at all time, watching what's going on and making sure we are not headed straight into the iceberg. CHF 0.02... Cheers, Christian From tcallawa at redhat.com Mon Jun 2 11:56:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jun 2008 07:56:55 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <8g2ch5-52b.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> Message-ID: <1212407815.7710.69.camel@localhost.localdomain> On Mon, 2008-06-02 at 03:28 +0100, Keith G. Robertson-Turner wrote: > Why are you still shipping Mono? Apologies in advance, I cannot be overly specific about legal issues. Red Hat (and I) are aware of your concerns around mono, and after discussing this in depth with Red Hat Legal, we have no immediate plans to remove mono from Fedora. As to the Firefox EULA, we are aware of this issue, and are currently investigating the situation. In the future if you (or anyone) has any legal concerns around Fedora, please feel free to do one of the following: * If it is an issue which you think can be discussed in public (e.g. "Is this license ok for Fedora?"), please send it to fedora-legal-list at redhat.com. * If it is an issue which you do not think can be discussed in public (sadly, most legal issues fall under this case), please email legal at fedoraproject.org (or tcallawa at redhat.com, if you'd prefer). Thanks, Tom Callaway, Fedora Legal p.s. IANAL, this does not represent legal advice. From karsten at redhat.com Mon Jun 2 12:08:09 2008 From: karsten at redhat.com (Karsten Hopp) Date: Mon, 02 Jun 2008 14:08:09 +0200 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <8886.1212269945@sss.pgh.pa.us> References: <20080531072422.A1480@humbolt.us.dell.com> <8886.1212269945@sss.pgh.pa.us> Message-ID: <4843E2A9.2020000@redhat.com> Tom Lane schrieb: > Matt Domsch writes: >> Fedora Rawhide-in-Mock Build Results for x86_64 >> ... >> libjpeg-6b-41.fc9 (build/make) tgl > > This appears to be a newly-introduced autoconf bug: > https://bugzilla.redhat.com/show_bug.cgi?id=449245 > which very possibly has broken a few other packages besides mine. > > I could add a patch to work around it, but unless Karsten rejects > 449245 as not-a-bug I'm disinclined to do so. There's no policy > expecting maintainers to put in short-term workarounds for toolchain > bugs is there? > > regards, tom lane > I've rejected 449245 as NOTABUG as these sources clearly violated what the documentation explicitely mentioned as 'don't do that !' Even autoconf-2.61 had this in its info docs: # Pay attention that `#undef' is in the first column, and there is #nothing after `HAVE_UNISTD_H', not even white space. You can then #decode the configuration header using the preprocessor directives ... #The use of old form templates, with `#define' instead of `#undef' is #strongly discouraged. Similarly with old templates with comments on #the same line as the `#undef'. Anyway, putting comments in #preprocessor macros has never been a good idea. autoconf-2.61 just happend to work even though unintended, autoconf-2.62 simply comments out the whole line without checking for inline comments. Karsten From felix.schwarz at oss.schwarz.eu Mon Jun 2 12:26:10 2008 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 02 Jun 2008 14:26:10 +0200 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: References: <4835E696.1010401@oss.schwarz.eu> Message-ID: <4843E6E2.1030908@oss.schwarz.eu> Colin Walters wrote: > On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz > wrote: >> I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora >> (and EPEL 5), PyLucene with JCC could possibly be included with Fedora. > > Wow, JCC is terrifying. Interacting with Lucene via Jython would be...saner =) In my understanding Jython better suited/the best possibility if I want to call Python from Java code. If the main program is in Python, using Jython will restrict you on a Python feature set that is roughly the same as in Python 2.2. This would make PyLucene worthless for many programmers - e.g. most of my libraries won't work as they require at least Python 2.3 (Python 2.2 did not even had "True" and "False"!) and a big percentage needs even 2.4 or 2.5. So I think JCC is basically the right thing to do as this is the only way you can always use the latest Python features (even Python packages that are written in C) and the latest Java (GCJ always had threading issues and is generally hard to debug). Furthermore using JCC you can even use Java from C++ without too much hassle - quite cool I think :-) >> d) JCC uses JNI so the library paths must be set correctly at runtime. >> Unfortunately, the OpenJDK package does not add its paths to >> /etc/ld.so.conf.d (did I miss something?) Is there another workaround >> besides using rpath (bad, see a) or filing a bug against OpenJDK? > > Right now, you should hardcode the paths to the library in your package. See: > http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932 > Specifically, "If the JNI-using code calls System.loadLibrary you'll > have to patch it to use System.load, passing it the full path to the > dynamic shared object." > > For an example of this see > http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ Sorry, my wording was not detailed enough. JCC does "JNI the other way round" so it calls Java from C++. Therefore there is no System.loadLibrary which could be patched. Instead I have to rely on the standard linker configuration (or use rpath). Felix Schwarz -- Felix Schwarz Dipl.-Informatiker Gubener Str. 38 10243 Berlin Germany www.schwarz.eu - software development and consulting From fedora at slated.org Mon Jun 2 12:28:32 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 13:28:32 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4843C0D8.2060403@fedoraproject.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <4843AE43.4050801@slated.org> <4843C0D8.2060403@fedoraproject.org> Message-ID: Verily I say unto thee, that Rahul Sundaram spake thusly: > http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF So it comes down to this: [quote] We think there is nothing wrong with distributing free software that implements patented ideas, as long as the patent holders don't stop you. [/quote] I will have to agree to disagree with Stallman on that one. IMO there are two types of threat - direct and implied. One may easily infer that Microsoft's intentions towards Free Software are not honourable. A man with a knife is just a chef chopping carrots, but a psycho with a knife is a killer. One needs to make the distinction and take preemptive measures. Anyway, I obviously need to take this discussion straight to the source. -- Regards, Keith G. Robertson-Turner From felix.schwarz at oss.schwarz.eu Mon Jun 2 12:31:26 2008 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 02 Jun 2008 14:31:26 +0200 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <48368AB5.2080405@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> Message-ID: <4843E81E.9020308@oss.schwarz.eu> Andrew Haley wrote: > Colin Walters wrote: >> On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz >> wrote: >> >>> d) JCC uses JNI so the library paths must be set correctly at runtime. >>> Unfortunately, the OpenJDK package does not add its paths to >>> /etc/ld.so.conf.d (did I miss something?) Is there another workaround >>> besides using rpath (bad, see a) or filing a bug against OpenJDK? > > OpenJDK doesn't need to add its paths to /etc/ld.so.conf.d. > It calls (for example) > putenv("LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:\ > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:\ > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64" + the old path.) > and re-execs java. Unfortunately, I don't see a possibility for me to do the same as OpenJDK does currently (maybe I'm just too blind to see). python-jcc is a Python library and how can I re-exec arbitrary programs which don't expect that? Furthermore setting LD_LIBRARY_PATH is only useful for new processes so I can't just add this env variable in the library (before loading the binary module). I filed a new review request so you may add comments directly in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=449360 Thanks for your input :-) Felix Schwarz From sundaram at fedoraproject.org Mon Jun 2 12:35:59 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jun 2008 18:05:59 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <4843AE43.4050801@slated.org> <4843C0D8.2060403@fedoraproject.org> Message-ID: <4843E92F.9020704@fedoraproject.org> Keith G. Robertson-Turner wrote: > Verily I say unto thee, that Rahul Sundaram spake thusly: > >> http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF > > So it comes down to this: > > [quote] > We think there is nothing wrong with distributing free software that > implements patented ideas, as long as the patent holders don't stop > you. > [/quote] > > I will have to agree to disagree with Stallman on that one. I discussed this in detail with RMS and other FSF members. They have published these set of guidelines which to some extend explains their rationale. http://www.gnu.org/philosophy/free-system-distribution-guidelines.html Rahul From dev at nigelj.com Mon Jun 2 12:46:15 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 03 Jun 2008 00:46:15 +1200 Subject: About FESCo In-Reply-To: <20080602132543.7b8225ff@ludwig-alpha.unil.ch> References: <20080602132543.7b8225ff@ludwig-alpha.unil.ch> Message-ID: <4843EB97.3070602@nigelj.com> Christian Iseli wrote: > Dear All, > > Apologies for not participating in last week's meeting: real life got > in the way... I read the #fedora-meeting logs, and thought I'd share > my views here. > > I view the board as a political body, and an interface between > corporate sponsors and the Fedora project. They get to deal with money > matters, and have the final word on all Fedora matters. They can > meddle in technical matters if they so wish, but I do not think it is > their mandate. I like spot's approach of saying they tell us "we need > to fly" and provide for some level ground for us to take off. Unless > I'm mistaken, the board head is paid by RH, as is wwoods of QA and f13 > of releng. These folks are incredibly useful and dedicated to get each > release off the ground. > From my POV FESCo is essentially an oversight group, keeping tabs making sure everything is how it should be and at the same time making sure that in the future the project is on a good pathway to success. > I see FESCo as a bunch of elected volunteers that people come to and > ask "is it ok if ..." when they have questions wrt what they can put in > Fedora. FESCo's answer should have arbitration value for all technical > matters. I think FESCo members should also be willing to act as > emergency response team when some fire needs to be put out, e.g. a mass > rebuild needs some manual help to complete. > Yes, your only too right, and by all means FESCo members should be one of the first people there to help out, but as you mentioned they are elected volunteers, they can't be around every single minute of every day to help out (I'm sure we'd like them to be, and it's something that can be looked at assuming a more regionally diverse group) I don't see how we can expect *that* much, at the very least, I expect them to be active and considerate of issues concerning Fedora. > I do not think it is FESCo's role to come up with ideas of what the > future should be like. I think this kind of creativity is better > served by SIGs or individual contributors. > > I agree a lot of FESCo's work is just rubber stamping propositions from > SIGs. But I think someone needs to be there to do it. As Fedora > contributor, I feel better knowing that a bunch of elected volunteers > is manning the deck at all time, watching what's going on and making > sure we are not headed straight into the iceberg. > I agree, BUT... An SIG can't draft every single policy isn't really practical, contributors like ourselves elect members to FESCo (one our rights as a contributor) to represent our views to not only rubber-stamp policy proposals from SIGs but to also ensure that the contributor (our) 'experience' is at it's optimum by passing new policies. For instance the Sponsors Responsibility Policy (a great step into maintainer retention). Just some extra cents for the kitty. - Nigel From kanarip at kanarip.com Mon Jun 2 12:59:55 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 02 Jun 2008 14:59:55 +0200 Subject: Spin SIG meeting (Tue Jun 10, 18:00 UTC) Message-ID: <4843EECB.8090702@kanarip.com> Hello there, I would like the Spin SIG members, current spin maintainers and other enthusiasts to get together in #fedora-meeting at Tuesday, June 10th, at 18:00 UTC, so you are hereby invited to join us. There's several items on the Agenda. - How come we did not have Fedora 9 Spins of: - XFCE - Electronic Lab - Games - Developer The Electronic Lab does have a certain amount of people interested but no one "accountable" maintainer, while there was a lot of exposure, whereas the Developer spin did not get any maintenance, afaics. Regardless, we will need to contact maintainers during the Alpha-Beta time-frame to update their spins, or come up with a policy/guideline for the maintainers to hold on to. - Drafted policies I've submitted the drafted policies[1] for the Spin SIG to -devel, but they did not get much feedback. We need to determine if they are sufficient to enter the F10 development/release cycle with. - The release process / spin process Right now, we put in a request at the Release Engineering Team[2] to have certain spins spun. This may or may not be "golden" spins, but regardless, I think we prefer to trigger building our own spins, and then hand one over to Release Engineering, that can be released. Let's talk about this at our meeting. - Updates to kickstarts are submitted... where? I think the spin-kickstarts GIT repository at fedorahosted.org[3] needs to have the latest kickstarts, whereas now developments still take place in the livecd-tools GIT repository at fedorahosted.org[4]. I've tried to come up with a branching policy that makes development go into the master branch, which we branch off for maintenance purposes every release. I've also been thinking about a commit access policy, and I think having commit access for at least the primary maintainers of each spin makes the most sense. - kickstarts RPM package for "Home Use" A review request has been submitted for a "spin-kickstarts" package[5], which I'd like you to look at and give some feedback on. This is to enable people getting approved (by Spin SIG and Board) kickstarts to their own computers in a controllable fashion. If you have any other topics you want to discuss at the meeting, please let me know; there's a bunch of kickstarts from Rahul that need reviewing as well[6]. I hope to see you all so that we can accomplish something (and a little more). I'm also planning to have a HackFest/BarCamp session at FUDCon in Boston[7], in two weeks. Kind regards, Jeroen van Meeuwen -kanarip [1] http://fedoraproject.org/wiki/SIGs/Spins [2] https://fedorahosted.org/rel-eng/ticket/24 [3] http://git.fedorahosted.org/git/?p=spin-kickstarts.git [4] http://git.fedorahosted.org/git/?p=livecd [5] https://bugzilla.redhat.com/show_bug.cgi?id=448072 [6] http://fedoraproject.org/wiki/SIGs/Spins/Agenda [7] http://fedoraproject.org/wiki/FUDCon/FUDConF10 From fedora at slated.org Mon Jun 2 12:56:48 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 13:56:48 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <1212407815.7710.69.camel@localhost.localdomain> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> Message-ID: Verily I say unto thee, that Tom "spot" Callaway spake thusly: > On Mon, 2008-06-02 at 03:28 +0100, Keith G. Robertson-Turner wrote: >> Why are you still shipping Mono? > > Apologies in advance, I cannot be overly specific about legal issues. > Red Hat (and I) are aware of your concerns around mono, and after > discussing this in depth with Red Hat Legal, we have no immediate > plans to remove mono from Fedora. Thanks Tom. IANAL either, but AFAICT there is no real threat of litigation. The "threat" is more in terms of manipulation (a la Novell, Linspire, etc.) My fear is that Microsoft will wait until their IP is firmly established in Free Software, then use that as leverage to coerce "deals" that both suppresses Free Software and fortifies Microsoft's monopoly. Their patents may well be completely indefensible for all the difference it makes to that agenda. Other distros have already conceded without any legal intervention. This tactic also brings mindshare to their platform at our expense (brain drain), since their technology indoctrinates the Windows paradigm (both technically and philosophically). It's hard to convict a criminal who has not yet committed the crime, but I'm ever hopeful of successfully forewarning the prospective victims. I'll move this to the appropriate list and RMS directly. -- Regards, Keith G. Robertson-Turner From aph at redhat.com Mon Jun 2 13:13:14 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Jun 2008 14:13:14 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4843E6E2.1030908@oss.schwarz.eu> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> Message-ID: <4843F1EA.6080300@redhat.com> Felix Schwarz wrote: > So I think JCC is basically the right thing to do as this is the only > way you can always use the latest Python features (even Python packages > that are written in C) and the latest Java (GCJ always had threading > issues and is generally hard to debug). I'm not going to let this one past. gcj does not have "threading issues", whatever that means, and I don't agree that it's hard to debug. The latter is a matter of opinion, but the former a matter of fact. >> Specifically, "If the JNI-using code calls System.loadLibrary you'll >> have to patch it to use System.load, passing it the full path to the >> dynamic shared object." >> >> For an example of this see >> http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ > > Sorry, my wording was not detailed enough. JCC does "JNI the other way > round" so it calls Java from C++. Therefore there is no > System.loadLibrary which could be patched. Instead I have to rely on the > standard linker configuration (or use rpath). Or use a full path in dlopen(). What libraries does JCC need to open? Just libjvm, or others? Andrew. From kaboom at oobleck.net Mon Jun 2 13:15:33 2008 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 2 Jun 2008 09:15:33 -0400 (EDT) Subject: Networkmanager service is shutdown too early In-Reply-To: <20080601140435.GB27694@truch.net> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212324726.25062.53.camel@localhost.localdomain> <20080601140435.GB27694@truch.net> Message-ID: On Sun, 1 Jun 2008, Matthew D Truch wrote: > flights using their laptops. And my personal usage case, high altitude > balloons (37km altitude). We can't afford RAD hardened boxes, so we > have redundant machines with watchdogs to switch between them, which > works great for the hard crashes (every couple days) but not so much for > the 'soft' crashes where systems go wonky. Off-topic but if these are boxes running Fedora this sounds like a great "how I use Fedora" story to get up on the website later, chris From tcallawa at redhat.com Mon Jun 2 13:25:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jun 2008 09:25:55 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> Message-ID: <1212413155.7710.73.camel@localhost.localdomain> On Mon, 2008-06-02 at 13:56 +0100, Keith G. Robertson-Turner wrote: > My fear is that Microsoft will wait until their IP is firmly > established in Free Software, then use that as leverage to coerce > "deals" that both suppresses Free Software and fortifies Microsoft's > monopoly. Hopefully, Red Hat's continued refusals to even consider negotiating such a "deal" should give you an idea of where Red Hat/Fedora stands with regards to such issues. As to the confluence of Software Patents and Freedom, I think you will find that the FSFs stance on them is that code under a free license is where their primary focus lies, and that they have little or no concern around whether that code is patent infringing or not. This is a notable area where Fedora and the FSF differ (Fedora makes every effort to avoid infringing software patents, as stupid as they all may be). ~spot From felix.schwarz at oss.schwarz.eu Mon Jun 2 13:35:00 2008 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 02 Jun 2008 15:35:00 +0200 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4843F1EA.6080300@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> <4843F1EA.6080300@redhat.com> Message-ID: <4843F704.8000102@oss.schwarz.eu> Andrew Haley schrieb: > Felix Schwarz wrote: > >> So I think JCC is basically the right thing to do as this is the only >> way you can always use the latest Python features (even Python packages >> that are written in C) and the latest Java (GCJ always had threading >> issues and is generally hard to debug). > > I'm not going to let this one past. gcj does not have "threading issues", > whatever that means, and I don't agree that it's hard to debug. The latter > is a matter of opinion, but the former a matter of fact. You are correct that threading inside of gcj was seemingly not that bad. I should be more precise in my wording because these "threading issues" were related to Python's threading - with a gcj compiled Lucene you had to be quite careful what Python threading implementation you use (something that caused some problems with CherryPy/TurboGears). >>> Specifically, "If the JNI-using code calls System.loadLibrary you'll >>> have to patch it to use System.load, passing it the full path to the >>> dynamic shared object." >>> >>> For an example of this see >>> http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ >> Sorry, my wording was not detailed enough. JCC does "JNI the other way >> round" so it calls Java from C++. Therefore there is no >> System.loadLibrary which could be patched. Instead I have to rely on the >> standard linker configuration (or use rpath). > > Or use a full path in dlopen(). I may be wrong but it seems that JCC does do any dlopens. Instead the code is just linked against the Java libraries. I may be wrong on this, though. > What libraries does JCC need to open? Just libjvm, or others? libjava.so and libjvm.so. fs From aph at redhat.com Mon Jun 2 13:48:11 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Jun 2008 14:48:11 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4843F704.8000102@oss.schwarz.eu> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> <4843F1EA.6080300@redhat.com> <4843F704.8000102@oss.schwarz.eu> Message-ID: <4843FA1B.2080706@redhat.com> Felix Schwarz wrote: > Andrew Haley schrieb: >> Felix Schwarz wrote: >> >>>> Specifically, "If the JNI-using code calls System.loadLibrary you'll >>>> have to patch it to use System.load, passing it the full path to the >>>> dynamic shared object." >>>> >>>> For an example of this see >>>> http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ >>> Sorry, my wording was not detailed enough. JCC does "JNI the other way >>> round" so it calls Java from C++. Therefore there is no >>> System.loadLibrary which could be patched. Instead I have to rely on the >>> standard linker configuration (or use rpath). >> >> Or use a full path in dlopen(). > > I may be wrong but it seems that JCC does do any dlopens. Instead the code > is just linked against the Java libraries. I may be wrong on this, though. > >> What libraries does JCC need to open? Just libjvm, or others? > > libjava.so and libjvm.so. OK, I understand now. I'm going to ping a few of my colleagues to see what they think we should do. Andrew. From Matt_Domsch at dell.com Mon Jun 2 13:57:39 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 08:57:39 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 Message-ID: <20080602085739.A5900@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 based on rawhide as of 01-June-2008. Bugs will be automatically filed for each of the failures below, if there is not already a bug that (recursively) blocks the master FTBFS bug. If your package fails due to a bug in another package, be sure there is a bug filed against the other package, and add that bug number to your package bug's "Depends on" list. Don't just close your package's bug. Once the dependent bug is fixed and your package build properly again, you can close your package's bug. There is a proposal before FESCo to remove packages that Fail To Build >From Source (FTBFS)[1] from the distribution, if the package owner has no bug comments indicating it will be fixed in a reasonable amount of time before the next major release. This would take place immediately following the Alpha release[2]. Please comment on the thread on fedora-devel-list[3], or come to the FESCo meeting next Thursday[4], if you have concerns. [1] http://fedoraproject.org/wiki/FTBFS [2] http://fedoraproject.org/wiki/Schedule (shows F9 presently, extrapolate for F10) [3] https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02369.html [4] http://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5747 Number failed to build: 340 Number expected to fail due to ExclusiveArch or ExcludeArch: 35 Leaving: 305 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 206 ---------------------------------- amanda-2.5.2p1-10.fc9 (build/make) rbrich ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astromenace-1.2-8.fc9 (build/make) limb axis-1.2.1-3jpp.8.fc9 (build/make) pcheung basket-1.0.2-5.fc9 (build/make) abompard beagle-0.3.7-5.fc10 (build/make) drago01,drago01,psytux blam-1.8.3-13.fc9 (build/make) alexlan,sindrepb bmpx-0.40.13-11.fc9 (build/make) akahl boo-0.8.1.2865-4.fc9 (build/make) pfj brltty-3.9-2.2.fc9 (build/make) kasal cdcollect-0.6.0-5.fc9 (build/make) sharkcz cernlib-2006-29.fc9 (build/make) pertusus cernlib-g77-2006-29.fc9 (build/make) pertusus compat-db-4.5.20-5.fc9 (build/make) jnovy compat-erlang-R10B-11.9.fc9 (build/make) gemi condor-7.0.0-8.fc9 (build/make) matt contacts-0.8-3.fc10 (build/make) jkeating cpio-2.9-7.fc9 (build/make) ovasik cvs-1.11.22-13.fc9 (build/make) jmoskovc db4-4.6.21-5.fc9 (build/make) jnovy dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dosfstools-2.11-9.fc9 (build/make) kasal dxpc-3.9.1-0.3.b1.fc9 (build/make) guthrie ekg2-0.2-0.1.rc1.fc10 (build/make) rathann elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart epiphany-2.22.1.1-1.fc9 (build/make) gecko-maint erlang-R12B-1.1.fc9 (build/make) gemi evolution-brutus-1.2.11-2.fc9 (build/make) bpepple,colding evolution-remove-duplicates-0.0.3-3.fc9 (build/make) salimma evolution-zimbra-0.1.0-5.fc9 (build/make) mbarnes,mmahut expect-5.43.0-13.fc9 (build/make) vcrhonek fakechroot-2.5-13.fc9 (build/make) athimm fakeroot-1.6.4-16.fc9 (build/make) athimm Falcon-0.8.8-3.fc9 (build/make) salimma firewalk-5.0-2.fc9 (build/make) sindrepb fontmatrix-0.4.2-1.fc9 (build/make) pnemade fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig f-spot-0.4.3.1-1.fc10 (build/make) orphan fusion-icon-0.1.0-0.2.5e2dc9git.fc9 (build/make) karlik galeon-2.0.5-1.fc9 (build/make) denis gauche-0.8.13-1.fc9 (build/make) gemi gauche-gl-0.4.4-3.fc9 (build/make) gemi gauche-gtk-0.4.1-17.fc9 (build/make) gemi gbrainy-0.61-5.fc9 (build/make) sereinit gcombust-0.1.55-13 (build/make) thias geronimo-specs-1.0-1.M2.2jpp.12 (build/make) fnasser ghc-6.8.2-2.fc9 (build/make) bos,petersen,ynemoy gl-117-1.3.2-4.fc7 (build/make) steve glib-1.2.10-29.fc9 (build/make) rdieter gnome-applet-timer-2.0.1-1.fc9 (build/make) cwickert gnome-do-0.4.2.0-1.fc10 (build/make) sindrepb,sindrepb gnome-subtitles-0.8-2.fc10 (build/make) belegdol gnome-themes-2.23.1-1.fc10 (build/make) mclasen gnupg2-2.0.9-1.fc9 (build/make) rdieter,nalin gnu-smalltalk-3.0.1-3.fc9 (build/make) s4504kr,laxathom gpgme-1.1.6-3.fc9 (build/make) rdieter gphoto2-2.4.0-10.fc9 (build/make) jnovy graphviz-2.16.1-0.5.fc9 (build/make) jima gridengine-6.1u4-1.fc10 (build/make) orion gstreamer-plugins-good-0.10.8-1.fc10 (build/make) ajax gtk+-1.2.10-61.fc9 (build/make) rdieter gtkglext-1.2.0-6.fc9 (build/make) corsepiu gtkmozembedmm-1.4.2.cvs20060817-17.fc9 (build/make) hguemar gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtksourceview-sharp-2.0-25.fc7 (build/make) pfj guilt-0.30-1.fc8 (build/make) sandeen hedgewars-0.9.3-1.fc10 (build/make) jwrdegoede HelixPlayer-1.0.9-2.fc9 (build/make) abompard hesiod-3.1.0-10 (build/make) nalin iksemel-1.3-4.fc9 (build/make) jcollie Inventor-2.1.5-31.fc9 (build/make) corsepiu javasqlite-20080420-1.fc10 (build/make) scop jed-0.99.18-7.fc9 (build/make) notting jgroups-2.2.9.2-3jpp.2 (build/make) dbhole junitperf-1.9.1-2jpp.1.fc7 (build/make) mwringe kdebluetooth-1.0-0.41.beta8.fc9 (build/make) gilboa,scop kickpim-0.5.3-14.fc9 (build/make) rdieter kismet-0.0.2007.10.R1-3.fc9 (build/make) ensc kleansweep-0.2.9-7.fc9 (build/make) chitlesh ktechlab-0.3.69-5.fc8 (build/make) chitlesh LabPlot-1.5.1.6-6.fc9 (build/make) chitlesh,chitlesh,tnorth ladspa-1.12-9.fc9 (build/make) thomasvs lat-1.2.3-3.fc9 (build/make) pghmcfc lib765-0.4.1-3.fc9 (build/make) lucilanga,pfj libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan libfwbuilder-2.1.16-2.fc9 (build/make) ertzing libgii-1.0.2-6.fc9 (build/make) kwizart libidn-0.6.14-7 (build/make) jorton libitl-0.6.4-4.fc9 (build/make) izhar libjpeg-6b-41.fc9 (build/make) tgl libnet10-1.0.2a-14.fc9 (build/make) pertusus libopensync-0.36-2.fc9 (build/make) awjb libopensync-plugin-google-calendar-0.35-2.fc9 (build/make) awjb libopensync-plugin-kdepim-0.35-2.fc9 (build/make) awjb libsigsegv-2.4-6.fc9 (build/make) rdieter libstroke-0.5.1-17.fc9 (build/make) chitlesh libzzub-0.2.3-12.fc9 (build/make) akahl,mtasaka linux-atm-2.5.0-5 (build/make) dwmw2 log4net-1.2.10-4.fc9 (build/make) snecker mercurial-1.0-4.fc9 (build/make) nbecker,ausil,mmcgrath,nbecker mesa-7.1-0.31.fc9 (build/make) ajax,ajax mod_suphp-0.6.3-1.fc9 (build/make) ixs monodevelop-0.19-6.fc9 (build/make) pfj mono-ndoc-1.3.1-2.fc10 (build/make) spot mono-nunit22-2.2.10-3.fc10 (build/make) spot mono-sharpcvslib-0.35-2.fc10 (build/make) spot muine-0.8.8-9.fc9 (build/make) sindrepb muine-scrobbler-0.1.8-5.fc9 (build/make) sindrepb mx-2.0.6-3 (build/make) misa MyPasswordSafe-0.6.7-4.20061216.fc9 (build/make) ertzing mysql-connector-java-3.1.12-5.fc9 (build/make) ifoox nant-0.85-21.fc9 (build/make) pfj nautilus-open-terminal-0.9-2.fc9 (build/make) pfrields nautilus-search-tool-0.2.2-3.fc9 (build/make) pfrields nco-3.9.3-1.fc9 (build/make) edhill,pertusus nethack-vultures-2.1.0-10.fc8 (build/make) meme ngspice-17-14.fc9 (build/make) chitlesh ntfs-config-1.0-0.6.rc5.fc9 (build/make) laxathom ntl-5.4.2-2.fc9 (build/make) rdieter ocaml-SDL-0.7.2-12.fc10 (build/make) rjones oooqs2-1.0-3.fc6 (build/make) ausil openoffice.org-voikko-2.2-4.fc9 (build/make) vpv openssl-0.9.8g-9.fc10 (build/make) tmraz pam_abl-0.2.3-4.fc9 (build/make) adalloz,tmraz pan-0.132-2.fc8 (build/make) adalloz,mpeters pdfedit-0.3.2-4.fc9 (build/make) bjohnson perl-5.10.0-24.fc10 (build/make) mmaslano,spot,corsepiu,rnorwood,kasal perl-Class-MethodMaker-2.10-3.fc9 (build/make) dgregor,perl-sig perl-Crypt-Simple-0.06-5.fc9 (needs_perl_ExtUtils_MakeMaker) allisson perl-CSS-1.08-2.fc10 (build/make) terjeros perl-DBD-SQLite-1.14-7.fc9 (build/make) kasal,perl-sig,steve,rnorwood,mmaslano perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig perl-Gnome2-GConf-1.044-3.fc9 (build/make) cweyl,perl-sig perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig perl-Log-Dispatch-FileRotate-1.16-2.fc9 (build/make) spot,perl-sig,corsepiu perl-MIME-Lite-3.01-6.fc9 (build/make) mmcgrath,perl-sig perl-mogilefs-server-2.17-5.fc9 (build/make) ruben perl-Net-CUPS-0.55-4.fc9 (build/make) cweyl,perl-sig perl-Net-Netmask-1.9015-1.fc8 (build/make) wtogami,perl-sig perl-Net-Packet-3.25-3.fc9 (build/make) sindrepb perl-Net-Server-0.97-2.fc9 (build/make) nim,perl-sig perl-Net-Write-1.00-3.fc9 (build/make) sindrepb perl-OLE-Storage_Lite-0.15-2.fc9 (build/make) spot,perl-sig perl-Pod-POM-0.17-9.fc9 (build/make) spot,perl-sig perl-Spreadsheet-WriteExcel-2.20-2.fc9 (build/make) spot,perl-sig perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig perl-Text-CharWidth-0.04-4.fc9 (build/make) athimm perl-Text-Kakasi-2.04-8.fc9 (build/make) tagoh,perl-sig perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig perl-Text-WrapI18N-0.06-3.fc9 (build/make) athimm perl-Time-modules-2006.0814-2.fc9 (build/make) kaboom,perl-sig,xavierb perl-Unicode-Map-0.112-14.fc9 (build/make) abompard,perl-sig perl-Unicode-Map8-0.12-17.fc9 (build/make) abompard,perl-sig perl-Unicode-MapUTF8-1.11-6.fc8 (build/make) abompard,perl-sig perl-Unicode-String-2.09-8.fc9 (build/make) abompard,perl-sig perl-XML-LibXSLT-1.63-5.fc9 (build/make) shishz,perl-sig perl-XML-XPath-1.13-6.fc9 (build/make) kasal,perl-sig,rnorwood,mmaslano piklab-0.15.0-1.fc9 (build/make) chitlesh,dionysos plplot-5.9.0-1.fc9 (build/make) orion powerman-1.0.32-5.fc9 (build/make) jwilson powerpc-utils-papr-1.0.4-3.fc9 (build/make) dwmw2,rrakus psacct-6.3.2-50.fc9 (build/make) varekova python-imaging-1.1.6-9.fc9 (build/make) jamatos,jgranado python-xlrd-0.6.1-5.fc9 (build/make) ondrejj,jafo qcad-2.0.5.0-8.fc9 (build/make) gemi qgis-0.9.1-5.fc9 (build/make) silfreed,rezso qmmp-0.1.5-2.fc9 (build/make) kvolny,jwrdegoede qof-0.7.5-2.fc9 (build/make) limb qscintilla-2.2-1.fc10 (build/make) rdieter rapidsvn-0.9.6-1.fc9 (build/make) timj repoman-0.9-3.fc8 (build/make) dcantrel,clumens ricci-0.13.0-3.fc9 (build/make) rmccabe rkward-0.5.0b-2.fc10 (build/make) pingou R-Matrix-0.999375-4.fc9 (build/make) tmoertel ruby-1.8.6.114-1.fc9 (build/make) tagoh ruby-gnome2-0.16.0-28.fc9 (build/make) allisson samba-3.2.0-1.pre3.10.fc10 (build/make) simo,gd scim-tomoe-0.6.0-2.fc8 (build/make) ryo,petersen selinux-policy-3.3.1-45.fc10 (build/make) dwalsh,jkubin slrn-0.9.8.1pl1-8.20070716cvs.fc9 (build/make) mlichvar smarteiffel-2.3-2.fc9 (build/make) gemi sudo-1.6.9p13-6.fc10 (build/make) pvrabec,kzak sugar-toolkit-0.81.3-1.gitfcc468a323.fc10 (build/make) mpg,tomeu,erikos svnmailer-1.0.8-3.fc7 (build/make) mfleming synaptics-0.14.6-7.fc9 (build/make) krh syslinux-3.61-2.fc9 (build/make) pjones taglib-sharp-2.0.3.0-4.fc10 (build/make) spot taskjuggler-2.4.1-1.fc10 (build/make) ovasik tclchecker-1.4-4.20061030cvs.fc9 (build/make) wart tcldebugger-1.4-6.20061030cvs.fc9 (build/make) wart tcpdump-3.9.8-4.fc9 (build/make) mlichvar tomboy-0.10.1-2.fc9 (build/make) rstrode tomcat5-5.5.26-1jpp.2.fc9 (build/make) devrim,devrim vtk-5.0.4-21.fc9 (build/make) athimm,orion wlassistant-0.5.7-7.fc9 (build/make) spot xbase-2.0.0-11.fc9 (build/make) spot xemacs-21.5.28-6.fc9 (build/make) scop xemacs-packages-extra-20070427-1.fc8 (build/make) scop xen-3.2.0-10.fc9 (build/make) xen-maint,berrange xfce4-mailwatch-plugin-1.0.1-8.fc9 (build/make) cwickert xfce4-verve-plugin-0.3.5-4.fc9 (build/make) cwickert,kevin xlhtml-0.5-8.fc9 (build/make) abompard xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xmms-cdread-0.14-13.fc9 (build/make) jsoeterb xscorch-0.2.0-12.fc8 (build/make) mgarski xsupplicant-1.2.8-6.fc9.2 (build/make) spot With bugs filed: 99 ---------------------------------- aiksaurus-1.2.1-15.fc6 ['440795 NEW'] (build/make) uwog astyle-1.21-6.fc8 ['440797 NEW'] (build/make) addutko,mtasaka aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 NEW'] (build/make) ixs,mmcgrath banshee-0.99.2-2.fc10 ['448365 ASSIGNED'] (build/make) nigelj,spot bes-3.5.3-3.fc9 ['440807 NEW'] (build/make) pertusus bitbake-1.8.8-1.fc8 ['440562 NEW'] (build/make) ixs blobby-0.6-0.7.a.fc8 ['440725 NEW'] (build/make) abompard brutus-keyring-0.9.0-6.fc8 ['440809 NEW'] (build/make) bpepple,colding callweaver-1.2-0.4.rc5.20071230.fc9 ['440927 NEW'] (build/make) dwmw2 camstream-0.26.3-12.fc8 ['440878 NEW'] (build/make) nomis80 conexusmm-0.5.0-3.fc7 ['440847 NEW'] (build/make) rvinyard coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne crystal-clear-20050622-6.fc8 ['440851 NEW'] (build/make) chitlesh dap-freeform_handler-3.7.7-2.fc9 ['440885 NEW'] (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 ['440714 NEW'] (build/make) pertusus dar-2.3.6-3.fc9 ['440746 NEW'] (build/make) xris djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gdmap-0.7.5-6.fc6 ['440889 NEW'] (build/make) splinux gnome-applet-tvn24-0.2.8-3.fc9 ['440715 NEW'] (build/make) orphan gnome-specimen-0.3-1.fc8 ['440868 NEW'] (build/make) splinux gprolog-1.3.0-12.fc9 ['440945 NEW'] (build/make) s4504kr gpsim-0.22.0-5.fc8 ['440835 NEW'] (build/make) dionysos gresistor-0.0.1-11.fc8 ['440866 NEW'] (build/make) chitlesh gstm-1.2-6.fc7 ['440719 NEW'] (build/make) splinux gtk2hs-0.9.12.1-8.fc9 ['440493 NEW'] (build/make) bos,petersen gwget-0.99-5.fc9 ['440744 NEW'] (build/make) cwickert ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox itpp-4.0.0-2.fc9 ['440939 NEW'] (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa kazehakase-0.5.4-4.fc9 ['402641 NEW'] (build/make) mtasaka klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal lam-7.1.2-11.fc9 ['440926 NEW'] (build/make) dledford libdap-3.7.10-2.fc9 ['440854 NEW'] (build/make) pertusus libFoundation-1.1.3-11.fc9 ['440564 NEW'] (build/make) athimm libgtksourceviewmm-0.3.1-1.fc8 ['440877 NEW'] (build/make) splinux libnc-dap-3.7.0-9.fc9 ['440768 NEW'] (build/make) pertusus lilypond-2.10.33-1.fc8 ['440826 NEW'] (build/make) qspencer lineakd-0.9-5.fc6 ['440774 NEW'] (build/make) xris lineak-defaultplugin-0.9-2.fc6 ['440821 NEW'] (build/make) xris lineak-xosdplugin-0.9-2.fc6 ['440929 NEW'] (build/make) xris linpsk-0.9-3.fc9 ['440778 NEW'] (build/make) bjensen,sindrepb,sconklin lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux mbuffer-20070502-1.fc7 ['440836 ASSIGNED'] (build/make) adalloz mimetic-0.9.3-2.fc8 ['440838 NEW'] (build/make) ensc moto4lin-0.3-6.fc7 ['440713 NEW'] (build/make) jafo mtd-utils-1.1.0-2.fc8 ['440845 NEW'] (build/make) dwmw2,jwboyer multiget-1.1.4-7.fc8 ['440801 ASSIGNED'] (build/make) orphan,mtasaka mx4j-3.0.1-6jpp.4 ['440731 NEW'] (build/make) fnasser mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW'] (build/make) ausil oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa orpie-1.4.3-5.fc6 ['440823 NEW'] (build/make) xris pcmanx-gtk2-0.3.5-9.336svn.fc7 ['440745 NEW'] (open_missing_mode) leo pdsh-2.11-6.fc9 ['440811 NEW'] (build/make) kg6fnk pekwm-0.1.5-5.fc7 ['440883 NEW'] (build/make) errr petitboot-0.0.1-7.fc8 ['440853 NEW'] (build/make) dwmw2,jwboyer pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa plague-0.4.4.1-4.fc7 ['440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar proftpd-1.3.1-3.fc9 ['440729 NEW'] (build/make) thias python-dialog-2.7-7.fc8 ['440819 NEW'] (build/make) abompard python-durus-3.5-3.fc7 ['440781 NEW'] (build/make) shahms python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-reportlab-2.1-2.fc9 ['440827 NEW'] (build/make) bpepple python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie pyzor-0.4.0-11.fc7 ['440790 NEW'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qca-1.0-10.fc9 ['440850 NEW'] (build/make) abompard qca-tls-1.0-13.fc9 ['440909 NEW'] (build/make) abompard qgo-1.5.4r2-1.fc9 ['440728 NEW'] (build/make) kaboom qps-1.9.19-0.2.b.fc7 ['440904 NEW'] (build/make) makghosh qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando qtiplot-0.9-8.fc9 ['440844 NEW'] (build/make) frankb QuantLib-0.9.0-5.fc9 ['440934 NEW'] (build/make) spot ruby-bdb-0.6.0-1.fc7 ['440882 NEW'] (build/make) errr rudeconfig-5.0.5-1.fc7 ['440848 NEW'] (build/make) homeless rxvt-unicode-9.02-2.fc9 ['440789 ASSIGNED'] (build/make) awjb sblim-wbemcli-1.5.1-5.fc7 ['440893 NEW'] (build/make) hamzy scim-skk-0.5.2-8.fc6 ['440863 NEW'] (build/make) ryo scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb seq24-0.8.7-8.fc8 ['440363 ASSIGNED'] (build/make) green showimg-0.9.5-16.fc9 ['440890 NEW'] (build/make) abompard sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip supertux-0.3.1-1.fc9 ['440816 NEW'] (build/make) steve trousers-0.3.1-5.fc9 ['440733 NEW'] (build/make) key,ejratl yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa ---------------------------------- Packages by owner: abompard: HelixPlayer,basket,blobby,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,python-dialog,qca,qca-tls,showimg,xlhtml adalloz: mbuffer,pam_abl,pan addutko: astyle agk: dmraid ajax: gstreamer-plugins-good,mesa,mesa akahl: bmpx,libzzub alexlan: blam,perl-GD-SVG,perl-Graph,perl-SVG,perl-Text-Shellwords allisson: perl-Crypt-Simple,ruby-gnome2 ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mercurial,mysql-gui-tools,oooqs2 awjb: aterm,koffice-langpack,libopensync,libopensync-plugin-google-calendar,libopensync-plugin-kdepim,rxvt-unicode,scribus belegdol: gnome-subtitles berrange: xen bjensen: linpsk bjohnson: pdfedit bmr: dmraid bojan: libapreq2 bos: ghc,gtk2hs bpepple: brutus-keyring,evolution-brutus,python-reportlab chitlesh: LabPlot,LabPlot,crystal-clear,gresistor,kleansweep,ktechlab,libstroke,ngspice,piklab clumens: repoman colding: brutus-keyring,evolution-brutus corsepiu: Inventor,gtkglext,perl,perl-Log-Dispatch-FileRotate cr33dog: fontypython cweyl: perl-Gnome2-GConf,perl-Net-CUPS cwickert: gnome-applet-timer,gwget,xfce4-mailwatch-plugin,xfce4-verve-plugin dbhole: jgroups dcantrel: repoman dcbw: plague denis: galeon devrim: tomcat5,tomcat5 dgregor: perl-Class-MethodMaker dionysos: gpsim,piklab dledford: lam drago01: beagle,beagle dwalsh: selinux-policy dwmw2: callweaver,linux-atm,mtd-utils,petitboot,powerpc-utils-papr dwysocha: dmraid edhill: itpp,nco ejratl: trousers ensc: kismet,mimetic erikos: sugar-toolkit errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fnasser: geronimo-specs,mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython frankb: qtiplot gd: samba gecko-maint: epiphany gemi: compat-erlang,erlang,gauche,gauche-gl,gauche-gtk,qcad,smarteiffel gilboa: kdebluetooth green: ardour,seq24 guthrie: dxpc hamzy: sblim-wbemcli hguemar: gtkmozembedmm,plotmm homeless: rudeconfig icon: gazpacho ifoox: ht2html,mysql-connector-java ixs: bacula,bitbake,mod_suphp,pyzor izhar: libitl jafo: moto4lin,python-memcached,python-pydns,python-pyspf,python-xlrd jamatos: python-imaging jcollie: iksemel,python-urljr jgranado: python-imaging jima: graphviz jkeating: contacts jkubin: selinux-policy jmagne: coolkey jmoskovc: cvs jnovy: compat-db,db4,gphoto2 jorton: libidn jsoeterb: xmms-cdread jwboyer: mtd-utils,petitboot jwilson: powerman jwrdegoede: ardour,hedgewars,qmmp kaboom: perl-Time-modules,qgo karlik: fusion-icon kasal: brltty,dosfstools,perl,perl-DBD-SQLite,perl-XML-XPath kevin: xfce4-verve-plugin key: trousers kg6fnk: pdsh krh: synaptics kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra,libgii kzak: sudo laxathom: gnu-smalltalk,ntfs-config leo: pcmanx-gtk2 limb: astromenace,qof lucilanga: lib765 lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbarnes: evolution-zimbra mbroz: dmraid mclasen: gnome-themes meme: nethack-vultures mfleming: svnmailer mgarski: xscorch misa: mx mlichvar: slrn,tcpdump mmahut: evolution-zimbra mmaslano: perl,perl-DBD-SQLite,perl-XML-XPath mmcgrath: bacula,mercurial,perl-MIME-Lite mornfall: dmraid mpeters: pan mpg: sugar-toolkit mtasaka: astyle,kazehakase,libzzub,multiget mwringe: junitperf nalin: gnupg2,hesiod nando: qsynth navid: sos nbecker: mercurial,mercurial ngompa: oggconvert nigelj: banshee nim: perl-Net-Server nomis80: camstream notting: jed oliver: fish ondrejj: python-xlrd orion: gridengine,plplot,vtk orphan: f-spot,gnome-applet-tvn24,multiget ovasik: cpio,taskjuggler pcheung: axis perl-sig: perl-Class-MethodMaker,perl-DBD-SQLite,perl-GD-SVG,perl-Gnome2-GConf,perl-Graph,perl-Log-Dispatch-FileRotate,perl-MIME-Lite,perl-Net-CUPS,perl-Net-Netmask,perl-Net-Server,perl-OLE-Storage_Lite,perl-Pod-POM,perl-SVG,perl-Spreadsheet-WriteExcel,perl-Text-Kakasi,perl-Text-Shellwords,perl-Time-modules,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,perl-XML-LibXSLT,perl-XML-XPath pertusus: bes,cernlib,cernlib-g77,dap-freeform_handler,dap-hdf4_handler,elektra,libdap,libnc-dap,libnet10,nco petersen: ghc,gtk2hs,scim-tomoe pfj: boo,gtk-sharp,gtksourceview-sharp,lib765,monodevelop,nant pfrields: nautilus-open-terminal,nautilus-search-tool pghmcfc: lat pingou: rkward pjones: syslinux pknirsch: freeipmi pnemade: fontmatrix psytux: beagle pvrabec: sudo qspencer: lilypond rathann: ekg2 rbrich: amanda rdieter: glib,gnupg2,gpgme,gtk+,kickpim,libsigsegv,ntl,qscintilla rezso: qgis rjones: ocaml-SDL rmccabe: ricci rnorwood: perl,perl-DBD-SQLite,perl-XML-XPath roozbeh: fonttools rrakus: powerpc-utils-papr rrelyea: coolkey rstrode: tomboy ruben: perl-mogilefs-server rvinyard: conexusmm ryo: scim-skk,scim-tomoe s4504kr: gnu-smalltalk,gprolog salimma: Falcon,evolution-remove-duplicates sandeen: guilt sconklin: linpsk scop: javasqlite,kdebluetooth,xemacs,xemacs-packages-extra sereinit: gbrainy shahms: python-durus,python-simpletal,python-tpg sharkcz: cdcollect shishz: perl-XML-LibXSLT silfreed: qgis simo: samba sindrepb: blam,firewalk,gnome-do,gnome-do,linpsk,muine,muine-scrobbler,perl-Net-Packet,perl-Net-Write snecker: log4net splinux: gdmap,gnome-specimen,gstm,libgtksourceviewmm,lostirc,lostirc spot: QuantLib,banshee,mono-ndoc,mono-nunit22,mono-sharpcvslib,perl,perl-Log-Dispatch-FileRotate,perl-OLE-Storage_Lite,perl-Pod-POM,perl-Spreadsheet-WriteExcel,taglib-sharp,wlassistant,xbase,xsupplicant steve: gl-117,perl-DBD-SQLite,supertux subhodip: straw tagoh: perl-Text-Kakasi,ruby terjeros: perl-CSS tgl: libjpeg thias: djvulibre,gcombust,proftpd thomasvs: ladspa timj: rapidsvn tmoertel: R-Matrix tmraz: openssl,pam_abl tnorth: LabPlot tomeu: sugar-toolkit toshio: qa-assistant trasher: klear uwog: aiksaurus varekova: psacct vcrhonek: expect vpv: openoffice.org-voikko wart: tclchecker,tcldebugger wtogami: perl-Net-Netmask xavierb: perl-Time-modules xen-maint: xen xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd,orpie ynemoy: ghc -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Mon Jun 2 13:58:38 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 08:58:38 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 Message-ID: <20080602085838.A5948@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 based on rawhide as of 01-June-2008. Bugs will be automatically filed for each of the failures below, if there is not already a bug that (recursively) blocks the master FTBFS bug. If your package fails due to a bug in another package, be sure there is a bug filed against the other package, and add that bug number to your package bug's "Depends on" list. Don't just close your package's bug. Once the dependent bug is fixed and your package build properly again, you can close your package's bug. There is a proposal before FESCo to remove packages that Fail To Build >From Source (FTBFS)[1] from the distribution, if the package owner has no bug comments indicating it will be fixed in a reasonable amount of time before the next major release. This would take place immediately following the Alpha release[2]. Please comment on the thread on fedora-devel-list[3], or come to the FESCo meeting next Thursday[4], if you have concerns. [1] http://fedoraproject.org/wiki/FTBFS [2] http://fedoraproject.org/wiki/Schedule (shows F9 presently, extrapolate for F10) [3] https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02369.html [4] http://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5748 Number failed to build: 278 Number expected to fail due to ExclusiveArch or ExcludeArch: 12 Leaving: 266 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 169 ---------------------------------- amanda-2.5.2p1-10.fc9 (build/make) rbrich ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astromenace-1.2-8.fc9 (build/make) limb basket-1.0.2-5.fc9 (build/make) abompard beagle-0.3.7-5.fc10 (build/make) drago01,drago01,psytux blam-1.8.3-13.fc9 (build/make) alexlan,sindrepb bmpx-0.40.13-11.fc9 (build/make) akahl brltty-3.9-2.2.fc9 (build/make) kasal cernlib-2006-29.fc9 (build/make) pertusus cernlib-g77-2006-29.fc9 (build/make) pertusus clisp-2.43-5.fc9 (build/make) gemi,green compat-db-4.5.20-5.fc9 (build/make) jnovy compat-erlang-R10B-11.9.fc9 (build/make) gemi condor-7.0.0-8.fc9 (build/make) matt cpio-2.9-7.fc9 (build/make) ovasik db4-4.6.21-5.fc9 (build/make) jnovy dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dosfstools-2.11-9.fc9 (build/make) kasal dxpc-3.9.1-0.3.b1.fc9 (build/make) guthrie eclipse-subclipse-1.2.4-9.fc9 (build/make) robmv ekg2-0.2-0.1.rc1.fc10 (build/make) rathann elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart epiphany-2.22.1.1-1.fc9 (build/make) gecko-maint erlang-R12B-1.1.fc9 (build/make) gemi evolution-brutus-1.2.11-2.fc9 (build/make) bpepple,colding evolution-remove-duplicates-0.0.3-3.fc9 (build/make) salimma evolution-zimbra-0.1.0-5.fc9 (build/make) mbarnes,mmahut fakechroot-2.5-13.fc9 (build/make) athimm fakeroot-1.6.4-16.fc9 (build/make) athimm Falcon-0.8.8-3.fc9 (build/make) salimma fontmatrix-0.4.2-1.fc9 (build/make) pnemade fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig fusion-icon-0.1.0-0.2.5e2dc9git.fc9 (build/make) karlik galeon-2.0.5-1.fc9 (build/make) denis ghc-6.8.2-2.fc9 (build/make) bos,petersen,ynemoy gl-117-1.3.2-4.fc7 (build/make) steve glib-1.2.10-29.fc9 (build/make) rdieter gnome-applet-timer-2.0.1-1.fc9 (build/make) cwickert gnome-themes-2.23.1-1.fc10 (build/make) mclasen gnupg2-2.0.9-1.fc9 (build/make) rdieter,nalin gnu-smalltalk-3.0.1-3.fc9 (build/make) s4504kr,laxathom gpgme-1.1.6-3.fc9 (build/make) rdieter gphoto2-2.4.0-10.fc9 (build/make) jnovy graphviz-2.16.1-0.5.fc9 (build/make) jima gstreamer-plugins-good-0.10.8-1.fc10 (build/make) ajax gtk+-1.2.10-61.fc9 (build/make) rdieter gtkglext-1.2.0-6.fc9 (build/make) corsepiu gtkmozembedmm-1.4.2.cvs20060817-17.fc9 (build/make) hguemar gtk-sharp-1.0.10-12.fc7 (build/make) pfj guilt-0.30-1.fc8 (build/make) sandeen HelixPlayer-1.0.9-2.fc9 (build/make) abompard iksemel-1.3-4.fc9 (build/make) jcollie Inventor-2.1.5-31.fc9 (build/make) corsepiu jed-0.99.18-7.fc9 (build/make) notting jgroups-2.2.9.2-3jpp.2 (build/make) dbhole kdebluetooth-1.0-0.41.beta8.fc9 (build/make) gilboa,scop kickpim-0.5.3-14.fc9 (build/make) rdieter kismet-0.0.2007.10.R1-3.fc9 (build/make) ensc kleansweep-0.2.9-7.fc9 (build/make) chitlesh ktechlab-0.3.69-5.fc8 (build/make) chitlesh LabPlot-1.5.1.6-6.fc9 (build/make) chitlesh,chitlesh,tnorth ladspa-1.12-9.fc9 (build/make) thomasvs libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan libfwbuilder-2.1.16-2.fc9 (build/make) ertzing libidn-0.6.14-7 (build/make) jorton libitl-0.6.4-4.fc9 (build/make) izhar libjpeg-6b-41.fc9 (build/make) tgl libopensync-0.36-2.fc9 (build/make) awjb libopensync-plugin-google-calendar-0.35-2.fc9 (build/make) awjb libopensync-plugin-kdepim-0.35-2.fc9 (build/make) awjb libsigsegv-2.4-6.fc9 (build/make) rdieter libzzub-0.2.3-12.fc9 (build/make) akahl,mtasaka linux-atm-2.5.0-5 (build/make) dwmw2 lrmi-0.10-4.fc9 (build/make) kevin mercurial-1.0-4.fc9 (build/make) nbecker,ausil,mmcgrath,nbecker mesa-7.1-0.31.fc9 (build/make) ajax,ajax mod_suphp-0.6.3-1.fc9 (build/make) ixs monodevelop-0.19-6.fc9 (build/make) pfj mosml-2.01-11.fc9 (build/make) gemi muine-scrobbler-0.1.8-5.fc9 (build/make) sindrepb mx-2.0.6-3 (build/make) misa MyPasswordSafe-0.6.7-4.20061216.fc9 (build/make) ertzing nant-0.85-21.fc9 (build/make) pfj nautilus-open-terminal-0.9-2.fc9 (build/make) pfrields nautilus-search-tool-0.2.2-3.fc9 (build/make) pfrields nco-3.9.3-1.fc9 (build/make) edhill,pertusus nethack-vultures-2.1.0-10.fc8 (build/make) meme ngspice-17-14.fc9 (build/make) chitlesh ntfs-config-1.0-0.6.rc5.fc9 (build/make) laxathom ntl-5.4.2-2.fc9 (build/make) rdieter ocaml-SDL-0.7.2-12.fc10 (build/make) rjones oooqs2-1.0-3.fc6 (build/make) ausil openoffice.org-voikko-2.2-4.fc9 (build/make) vpv pam_abl-0.2.3-4.fc9 (build/make) adalloz,tmraz pan-0.132-2.fc8 (build/make) adalloz,mpeters pdfedit-0.3.2-4.fc9 (build/make) bjohnson perl-5.10.0-24.fc10 (build/make) mmaslano,spot,corsepiu,rnorwood,kasal perl-Class-MethodMaker-2.10-3.fc9 (build/make) dgregor,perl-sig perl-Crypt-Simple-0.06-5.fc9 (needs_perl_ExtUtils_MakeMaker) allisson perl-CSS-1.08-2.fc10 (build/make) terjeros perl-DBD-SQLite-1.14-7.fc9 (build/make) kasal,perl-sig,steve,rnorwood,mmaslano perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig perl-Gnome2-GConf-1.044-3.fc9 (build/make) cweyl,perl-sig perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig perl-Log-Dispatch-FileRotate-1.16-2.fc9 (build/make) spot,perl-sig,corsepiu perl-MIME-Lite-3.01-6.fc9 (build/make) mmcgrath,perl-sig perl-Net-CUPS-0.55-4.fc9 (build/make) cweyl,perl-sig perl-Net-Netmask-1.9015-1.fc8 (build/make) wtogami,perl-sig perl-Net-Packet-3.25-3.fc9 (build/make) sindrepb perl-Net-Server-0.97-2.fc9 (build/make) nim,perl-sig perl-Net-Write-1.00-3.fc9 (build/make) sindrepb perl-OLE-Storage_Lite-0.15-2.fc9 (build/make) spot,perl-sig perl-Pod-POM-0.17-9.fc9 (build/make) spot,perl-sig perl-Spreadsheet-WriteExcel-2.20-2.fc9 (build/make) spot,perl-sig perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig perl-Text-CharWidth-0.04-4.fc9 (build/make) athimm perl-Text-Kakasi-2.04-8.fc9 (build/make) tagoh,perl-sig perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig perl-Text-WrapI18N-0.06-3.fc9 (build/make) athimm perl-Time-modules-2006.0814-2.fc9 (build/make) kaboom,perl-sig,xavierb perl-Unicode-Map-0.112-14.fc9 (build/make) abompard,perl-sig perl-Unicode-Map8-0.12-17.fc9 (build/make) abompard,perl-sig perl-Unicode-MapUTF8-1.11-6.fc8 (build/make) abompard,perl-sig perl-Unicode-String-2.09-8.fc9 (build/make) abompard,perl-sig perl-XML-LibXSLT-1.63-5.fc9 (build/make) shishz,perl-sig perl-XML-XPath-1.13-6.fc9 (build/make) kasal,perl-sig,rnorwood,mmaslano piklab-0.15.0-1.fc9 (build/make) chitlesh,dionysos plplot-5.9.0-1.fc9 (build/make) orion powerman-1.0.32-5.fc9 (build/make) jwilson powerpc-utils-papr-1.0.4-3.fc9 (build/make) dwmw2,rrakus psacct-6.3.2-50.fc9 (build/make) varekova python-imaging-1.1.6-9.fc9 (build/make) jamatos,jgranado python-xlrd-0.6.1-5.fc9 (build/make) ondrejj,jafo qcad-2.0.5.0-8.fc9 (build/make) gemi qgis-0.9.1-5.fc9 (build/make) silfreed,rezso qmmp-0.1.5-2.fc9 (build/make) kvolny,jwrdegoede qof-0.7.5-2.fc9 (build/make) limb qscintilla-2.2-1.fc10 (build/make) rdieter rapidsvn-0.9.6-1.fc9 (build/make) timj repoman-0.9-3.fc8 (build/make) dcantrel,clumens ricci-0.13.0-3.fc9 (build/make) rmccabe rkward-0.5.0b-2.fc10 (build/make) pingou R-Matrix-0.999375-4.fc9 (build/make) tmoertel ruby-1.8.6.114-1.fc9 (build/make) tagoh ruby-gnome2-0.16.0-28.fc9 (build/make) allisson samba-3.2.0-1.pre3.10.fc10 (build/make) simo,gd scim-tomoe-0.6.0-2.fc8 (build/make) ryo,petersen selinux-policy-3.3.1-45.fc10 (build/make) dwalsh,jkubin slrn-0.9.8.1pl1-8.20070716cvs.fc9 (build/make) mlichvar smarteiffel-2.3-2.fc9 (build/make) gemi sudo-1.6.9p13-6.fc10 (build/make) pvrabec,kzak sugar-toolkit-0.81.3-1.gitfcc468a323.fc10 (build/make) mpg,tomeu,erikos svnmailer-1.0.8-3.fc7 (build/make) mfleming synaptics-0.14.6-7.fc9 (build/make) krh syslinux-3.61-2.fc9 (build/make) pjones taglib-sharp-2.0.3.0-4.fc10 (build/make) spot taskjuggler-2.4.1-1.fc10 (build/make) ovasik tclchecker-1.4-4.20061030cvs.fc9 (build/make) wart tcldebugger-1.4-6.20061030cvs.fc9 (build/make) wart vtk-5.0.4-21.fc9 (build/make) athimm,orion wlassistant-0.5.7-7.fc9 (build/make) spot xemacs-21.5.28-6.fc9 (build/make) scop xemacs-packages-extra-20070427-1.fc8 (build/make) scop xen-3.2.0-10.fc9 (build/make) xen-maint,berrange xfce4-mailwatch-plugin-1.0.1-8.fc9 (build/make) cwickert xfce4-verve-plugin-0.3.5-4.fc9 (build/make) cwickert,kevin xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xsupplicant-1.2.8-6.fc9.2 (build/make) spot zhcon-0.2.6-8.fc9 (build/make) zhu With bugs filed: 97 ---------------------------------- aiksaurus-1.2.1-15.fc6 ['440795 NEW'] (build/make) uwog astyle-1.21-6.fc8 ['440797 NEW'] (build/make) addutko,mtasaka aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 NEW'] (build/make) ixs,mmcgrath banshee-0.99.2-2.fc10 ['448365 ASSIGNED'] (build/make) nigelj,spot bes-3.5.3-3.fc9 ['440807 NEW'] (build/make) pertusus bitbake-1.8.8-1.fc8 ['440562 NEW'] (build/make) ixs blobby-0.6-0.7.a.fc8 ['440725 NEW'] (build/make) abompard brutus-keyring-0.9.0-6.fc8 ['440809 NEW'] (build/make) bpepple,colding callweaver-1.2-0.4.rc5.20071230.fc9 ['440927 NEW'] (build/make) dwmw2 camstream-0.26.3-12.fc8 ['440878 NEW'] (build/make) nomis80 conexusmm-0.5.0-3.fc7 ['440847 NEW'] (build/make) rvinyard coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne crystal-clear-20050622-6.fc8 ['440851 NEW'] (build/make) chitlesh dap-freeform_handler-3.7.7-2.fc9 ['440885 NEW'] (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 ['440714 NEW'] (build/make) pertusus dar-2.3.6-3.fc9 ['440746 NEW'] (build/make) xris djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gcl-2.6.7-18.fc9 ['440913 NEW'] (build/make) gemi,green gdmap-0.7.5-6.fc6 ['440889 NEW'] (build/make) splinux gnome-applet-tvn24-0.2.8-3.fc9 ['440715 NEW'] (build/make) orphan gpsim-0.22.0-5.fc8 ['440835 NEW'] (build/make) dionysos gresistor-0.0.1-11.fc8 ['440866 NEW'] (build/make) chitlesh gstm-1.2-6.fc7 ['440719 NEW'] (build/make) splinux gtk2hs-0.9.12.1-8.fc9 ['440493 NEW'] (build/make) bos,petersen gwget-0.99-5.fc9 ['440744 NEW'] (build/make) cwickert ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox itpp-4.0.0-2.fc9 ['440939 NEW'] (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa kazehakase-0.5.4-4.fc9 ['402641 NEW'] (build/make) mtasaka klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal lam-7.1.2-11.fc9 ['440926 NEW'] (build/make) dledford libdap-3.7.10-2.fc9 ['440854 NEW'] (build/make) pertusus libFoundation-1.1.3-11.fc9 ['440564 NEW'] (build/make) athimm libgtksourceviewmm-0.3.1-1.fc8 ['440877 NEW'] (build/make) splinux libnc-dap-3.7.0-9.fc9 ['440768 NEW'] (build/make) pertusus lilypond-2.10.33-1.fc8 ['440826 NEW'] (build/make) qspencer lineakd-0.9-5.fc6 ['440774 NEW'] (build/make) xris lineak-defaultplugin-0.9-2.fc6 ['440821 NEW'] (build/make) xris lineak-xosdplugin-0.9-2.fc6 ['440929 NEW'] (build/make) xris linpsk-0.9-3.fc9 ['440778 NEW'] (build/make) bjensen,sindrepb,sconklin lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux mbuffer-20070502-1.fc7 ['440836 ASSIGNED'] (build/make) adalloz mimetic-0.9.3-2.fc8 ['440838 NEW'] (build/make) ensc moto4lin-0.3-6.fc7 ['440713 NEW'] (build/make) jafo mtd-utils-1.1.0-2.fc8 ['440845 NEW'] (build/make) dwmw2,jwboyer multiget-1.1.4-7.fc8 ['440801 ASSIGNED'] (build/make) orphan,mtasaka mx4j-3.0.1-6jpp.4 ['440731 NEW'] (build/make) fnasser mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW'] (build/make) ausil oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa orpie-1.4.3-5.fc6 ['440823 NEW'] (build/make) xris pcmanx-gtk2-0.3.5-9.336svn.fc7 ['440745 NEW'] (open_missing_mode) leo pdsh-2.11-6.fc9 ['440811 NEW'] (build/make) kg6fnk pekwm-0.1.5-5.fc7 ['440883 NEW'] (build/make) errr petitboot-0.0.1-7.fc8 ['440853 NEW'] (build/make) dwmw2,jwboyer pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa plague-0.4.4.1-4.fc7 ['440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar proftpd-1.3.1-3.fc9 ['440729 NEW'] (build/make) thias python-dialog-2.7-7.fc8 ['440819 NEW'] (build/make) abompard python-durus-3.5-3.fc7 ['440781 NEW'] (build/make) shahms python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie pyzor-0.4.0-11.fc7 ['440790 NEW'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qca-1.0-10.fc9 ['440850 NEW'] (build/make) abompard qca-tls-1.0-13.fc9 ['440909 NEW'] (build/make) abompard qgo-1.5.4r2-1.fc9 ['440728 NEW'] (build/make) kaboom qps-1.9.19-0.2.b.fc7 ['440904 NEW'] (build/make) makghosh qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando qtiplot-0.9-8.fc9 ['440844 NEW'] (build/make) frankb ruby-bdb-0.6.0-1.fc7 ['440882 NEW'] (build/make) errr rudeconfig-5.0.5-1.fc7 ['440848 NEW'] (build/make) homeless rxvt-unicode-9.02-2.fc9 ['440789 ASSIGNED'] (build/make) awjb sblim-wbemcli-1.5.1-5.fc7 ['440893 NEW'] (build/make) hamzy scim-skk-0.5.2-8.fc6 ['440863 NEW'] (build/make) ryo scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb seq24-0.8.7-8.fc8 ['440363 ASSIGNED'] (build/make) green showimg-0.9.5-16.fc9 ['440890 NEW'] (build/make) abompard sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip supertux-0.3.1-1.fc9 ['440816 NEW'] (build/make) steve trousers-0.3.1-5.fc9 ['440733 NEW'] (build/make) key,ejratl wine-0.9.58-1.fc9 ['440951 ON_QA'] (build/make) awjb yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa ---------------------------------- Packages by owner: abompard: HelixPlayer,basket,blobby,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,python-dialog,qca,qca-tls,showimg adalloz: mbuffer,pam_abl,pan addutko: astyle agk: dmraid ajax: gstreamer-plugins-good,mesa,mesa akahl: bmpx,libzzub alexlan: blam,perl-GD-SVG,perl-Graph,perl-SVG,perl-Text-Shellwords allisson: perl-Crypt-Simple,ruby-gnome2 ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mercurial,mysql-gui-tools,oooqs2 awjb: aterm,koffice-langpack,libopensync,libopensync-plugin-google-calendar,libopensync-plugin-kdepim,rxvt-unicode,scribus,wine berrange: xen bjensen: linpsk bjohnson: pdfedit bmr: dmraid bojan: libapreq2 bos: ghc,gtk2hs bpepple: brutus-keyring,evolution-brutus chitlesh: LabPlot,LabPlot,crystal-clear,gresistor,kleansweep,ktechlab,ngspice,piklab clumens: repoman colding: brutus-keyring,evolution-brutus corsepiu: Inventor,gtkglext,perl,perl-Log-Dispatch-FileRotate cr33dog: fontypython cweyl: perl-Gnome2-GConf,perl-Net-CUPS cwickert: gnome-applet-timer,gwget,xfce4-mailwatch-plugin,xfce4-verve-plugin dbhole: jgroups dcantrel: repoman dcbw: plague denis: galeon dgregor: perl-Class-MethodMaker dionysos: gpsim,piklab dledford: lam drago01: beagle,beagle dwalsh: selinux-policy dwmw2: callweaver,linux-atm,mtd-utils,petitboot,powerpc-utils-papr dwysocha: dmraid edhill: itpp,nco ejratl: trousers ensc: kismet,mimetic erikos: sugar-toolkit errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fnasser: mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython frankb: qtiplot gd: samba gecko-maint: epiphany gemi: clisp,compat-erlang,erlang,gcl,mosml,qcad,smarteiffel gilboa: kdebluetooth green: ardour,clisp,gcl,seq24 guthrie: dxpc hamzy: sblim-wbemcli hguemar: gtkmozembedmm,plotmm homeless: rudeconfig icon: gazpacho ifoox: ht2html ixs: bacula,bitbake,mod_suphp,pyzor izhar: libitl jafo: moto4lin,python-memcached,python-pydns,python-pyspf,python-xlrd jamatos: python-imaging jcollie: iksemel,python-urljr jgranado: python-imaging jima: graphviz jkubin: selinux-policy jmagne: coolkey jnovy: compat-db,db4,gphoto2 jorton: libidn jwboyer: mtd-utils,petitboot jwilson: powerman jwrdegoede: ardour,qmmp kaboom: perl-Time-modules,qgo karlik: fusion-icon kasal: brltty,dosfstools,perl,perl-DBD-SQLite,perl-XML-XPath kevin: lrmi,xfce4-verve-plugin key: trousers kg6fnk: pdsh krh: synaptics kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra kzak: sudo laxathom: gnu-smalltalk,ntfs-config leo: pcmanx-gtk2 limb: astromenace,qof lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbarnes: evolution-zimbra mbroz: dmraid mclasen: gnome-themes meme: nethack-vultures mfleming: svnmailer misa: mx mlichvar: slrn mmahut: evolution-zimbra mmaslano: perl,perl-DBD-SQLite,perl-XML-XPath mmcgrath: bacula,mercurial,perl-MIME-Lite mornfall: dmraid mpeters: pan mpg: sugar-toolkit mtasaka: astyle,kazehakase,libzzub,multiget nalin: gnupg2 nando: qsynth navid: sos nbecker: mercurial,mercurial ngompa: oggconvert nigelj: banshee nim: perl-Net-Server nomis80: camstream notting: jed oliver: fish ondrejj: python-xlrd orion: plplot,vtk orphan: gnome-applet-tvn24,multiget ovasik: cpio,taskjuggler perl-sig: perl-Class-MethodMaker,perl-DBD-SQLite,perl-GD-SVG,perl-Gnome2-GConf,perl-Graph,perl-Log-Dispatch-FileRotate,perl-MIME-Lite,perl-Net-CUPS,perl-Net-Netmask,perl-Net-Server,perl-OLE-Storage_Lite,perl-Pod-POM,perl-SVG,perl-Spreadsheet-WriteExcel,perl-Text-Kakasi,perl-Text-Shellwords,perl-Time-modules,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,perl-XML-LibXSLT,perl-XML-XPath pertusus: bes,cernlib,cernlib-g77,dap-freeform_handler,dap-hdf4_handler,elektra,libdap,libnc-dap,nco petersen: ghc,gtk2hs,scim-tomoe pfj: gtk-sharp,monodevelop,nant pfrields: nautilus-open-terminal,nautilus-search-tool pingou: rkward pjones: syslinux pknirsch: freeipmi pnemade: fontmatrix psytux: beagle pvrabec: sudo qspencer: lilypond rathann: ekg2 rbrich: amanda rdieter: glib,gnupg2,gpgme,gtk+,kickpim,libsigsegv,ntl,qscintilla rezso: qgis rjones: ocaml-SDL rmccabe: ricci rnorwood: perl,perl-DBD-SQLite,perl-XML-XPath robmv: eclipse-subclipse roozbeh: fonttools rrakus: powerpc-utils-papr rrelyea: coolkey rvinyard: conexusmm ryo: scim-skk,scim-tomoe s4504kr: gnu-smalltalk salimma: Falcon,evolution-remove-duplicates sandeen: guilt sconklin: linpsk scop: kdebluetooth,xemacs,xemacs-packages-extra shahms: python-durus,python-simpletal,python-tpg shishz: perl-XML-LibXSLT silfreed: qgis simo: samba sindrepb: blam,linpsk,muine-scrobbler,perl-Net-Packet,perl-Net-Write splinux: gdmap,gstm,libgtksourceviewmm,lostirc,lostirc spot: banshee,perl,perl-Log-Dispatch-FileRotate,perl-OLE-Storage_Lite,perl-Pod-POM,perl-Spreadsheet-WriteExcel,taglib-sharp,wlassistant,xsupplicant steve: gl-117,perl-DBD-SQLite,supertux subhodip: straw tagoh: perl-Text-Kakasi,ruby terjeros: perl-CSS tgl: libjpeg thias: djvulibre,proftpd thomasvs: ladspa timj: rapidsvn tmoertel: R-Matrix tmraz: pam_abl tnorth: LabPlot tomeu: sugar-toolkit toshio: qa-assistant trasher: klear uwog: aiksaurus varekova: psacct vpv: openoffice.org-voikko wart: tclchecker,tcldebugger wtogami: perl-Net-Netmask xavierb: perl-Time-modules xen-maint: xen xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd,orpie ynemoy: ghc zhu: zhcon -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From naheemzaffar at gmail.com Mon Jun 2 14:20:47 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 2 Jun 2008 15:20:47 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> Message-ID: <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> > It's hard to convict a criminal who has not yet committed the crime totally off-topic, but if no crime has been committed, the person is not a criminal. Unless we head into 1984-istan. "Thought crime" is not a real crime. Slightly on topic (only because I feel there should be something on topic in this post), yes some people are uncomfortable with Mono (I myself uninstall it as my first task after installing Fedora), but there are some checks and balances - there is the ECMA standards certification and more importantly there is (or was - no idea where it is after the Novell deal.) "protection" on this item from the OIN - something which preceded mono's inclusion into Fedora. From james.antill at redhat.com Mon Jun 2 14:45:42 2008 From: james.antill at redhat.com (James Antill) Date: Mon, 02 Jun 2008 10:45:42 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <48431648.9050205@redhat.com> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> Message-ID: <1212417942.14461.25.camel@code.and.org> On Sun, 2008-06-01 at 17:36 -0400, Jeremy Katz wrote: > Toshio Kuratomi wrote: > > The python programming language is going to be releasing a new version > > sometime around the time of the Fedora 10 release. Unlike past > > releases, this one will have wide-spread backwards incompatibility in > > the python language itself. We need to think about how we want to pull > > the new language into the distribution and porting of existing > > apps/modules. Here's a proposal to start us off but I hope geppetto > > (the python maintainer) and ivazquez (who maintains python3.0 packages > > in his spare time[1]_) will weigh in with their thoughts. > > So, while this is a large and incompatible change, there are lots of > other large and incompatible changes that we've managed over the years. > And in most of those, we've been far better off with actually making > a transition rather than trying to keep two different things around. While you obviously have more direct experience than I, can you think of a case where a change was this large and incompatible? > This is even _more_ true with things which are a framework that lots of > other packages provide modules for -- things like apache, perl, python, > and more. So in contrast, I think that we should evaluate python 2.6 > for Fedora 10 (it seems reasonable, but I will defer to the current > python maintainer's judgement :-). I completely agree. In theory the change will be smaller and less incompatible if you first port to the subset of python-2.6.z that is most compatible with python-3.y.z, however I've not seen anyway to test that you've successfully done this apart from inspecting the code by hand. > And the move to python 3.0 will need > to wait until there's either > a) sufficient reason for us to do a lot of legwork to get there or > b) enough upstreams are "buying in" > > > * python3000 modules should have a separate namespace from python2.x > > modules. The packaging committee will need to decide on that > > (python3-foo, python3000-foo, python3k-foo are possibilities. > > python3.0-foo should not be considered as 3.x versions should not have > > the same backwards incompatibilities that 2.x->3.x has.) > > Except that many python modules are just included in with packages or in > the same source tree. This then ends up with a need to build multiple > versions of python modules and that way lies massive amounts of pain. > It was a huge enough pain for just a very small number of modules in the > python 1.5 -> python 2 transition. With the vastly greater number of > modules these days, it becomes far far more difficult. Right, all of the bindings will be a big pain point (does swig support py3k yet?). Also having every package that uses python be renamed from foo to py3k-foo is horrible ugliness we'll have to live with forever. > > * Porting to python3000 will occur at some point but that should be a > > post-Fedora 10 feature that we decide on after python-3.0 final has been > > released. We will also need to discuss whether to port our tools > > piecemeal or altogether at that time and to what extent (if any) we will > > allow splitting from any upstreams that only support python-2.x. > > It's not as simple as that. What happens if (just to make up an > example), anaconda and rhpl move to python 3 but no other tools do? > Especially given that other tools depend on rhpl. Either a) the other > tools have to be ported or b) multiple copies of the same code have to > be maintained. The latter is filled with losing. The former is > plausible, but it is going to be a big effort and we have to > consistently commit to it across the board. Probably the most interesting python application is yum, as if it breaks you can't easily update/install to fix anything, and it currently depends on: pygpgme - binding python-iniparse rpm-python - binding urlgrabber yum-metadata-parser - binding ...now all of those and yum need to move to the "py3k language" as one unit, and as far as I can see there's no way we can do that automatically without renaming everything (at which point we don't need to). -- 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 katzj at redhat.com Mon Jun 2 14:56:11 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 02 Jun 2008 10:56:11 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <1212417942.14461.25.camel@code.and.org> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> Message-ID: <48440A0B.6090907@redhat.com> James Antill wrote: > On Sun, 2008-06-01 at 17:36 -0400, Jeremy Katz wrote: >> Toshio Kuratomi wrote: >>> The python programming language is going to be releasing a new version >>> sometime around the time of the Fedora 10 release. Unlike past >>> releases, this one will have wide-spread backwards incompatibility in >>> the python language itself. We need to think about how we want to pull >>> the new language into the distribution and porting of existing >>> apps/modules. Here's a proposal to start us off but I hope geppetto >>> (the python maintainer) and ivazquez (who maintains python3.0 packages >>> in his spare time[1]_) will weigh in with their thoughts. >> So, while this is a large and incompatible change, there are lots of >> other large and incompatible changes that we've managed over the years. >> And in most of those, we've been far better off with actually making >> a transition rather than trying to keep two different things around. > > While you obviously have more direct experience than I, can you think > of a case where a change was this large and incompatible? python 1.5 -> python 2 wasn't this large. But it was pretty large and ended up requiring a number of source changes in modules. >>> * Porting to python3000 will occur at some point but that should be a >>> post-Fedora 10 feature that we decide on after python-3.0 final has been >>> released. We will also need to discuss whether to port our tools >>> piecemeal or altogether at that time and to what extent (if any) we will >>> allow splitting from any upstreams that only support python-2.x. >> It's not as simple as that. What happens if (just to make up an >> example), anaconda and rhpl move to python 3 but no other tools do? >> Especially given that other tools depend on rhpl. Either a) the other >> tools have to be ported or b) multiple copies of the same code have to >> be maintained. The latter is filled with losing. The former is >> plausible, but it is going to be a big effort and we have to >> consistently commit to it across the board. > > Probably the most interesting python application is yum, as if it > breaks you can't easily update/install to fix anything, and it currently > depends on: > > pygpgme - binding > python-iniparse > rpm-python - binding > urlgrabber > yum-metadata-parser - binding > > ...now all of those and yum need to move to the "py3k language" as one > unit, and as far as I can see there's no way we can do that > automatically without renaming everything (at which point we don't need > to). But to keep things more fun, there's a significant body of other stuff which sits on top of yum now. So all of that will need to be ported at the same time also. Doom! :) Jeremy From skvidal at fedoraproject.org Mon Jun 2 15:01:23 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Jun 2008 11:01:23 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <1212417942.14461.25.camel@code.and.org> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> Message-ID: <1212418883.12635.6.camel@cutter> On Mon, 2008-06-02 at 10:45 -0400, James Antill wrote: > Probably the most interesting python application is yum, as if it > breaks you can't easily update/install to fix anything, and it currently > depends on: > > pygpgme - binding > python-iniparse > rpm-python - binding > urlgrabber > yum-metadata-parser - binding > the other question I have is how many of the 'batteries included' modules in python will not yet be ported to py3k? I mean if something like bzip2 or fnmatch or logging isn't ported yet we will have issues. -sv From dwmw2 at infradead.org Mon Jun 2 15:20:36 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Jun 2008 16:20:36 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <20080602115539.1cacfb4d@gaivota> References: <1212401125.30350.17.camel@cookie.hadess.net> <1212402716.16924.81.camel@pmac.infradead.org> <20080602115539.1cacfb4d@gaivota> Message-ID: <1212420036.16924.234.camel@pmac.infradead.org> On Mon, 2008-06-02 at 11:55 -0300, Mauro Carvalho Chehab wrote: > Hi David, > > On Mon, 02 Jun 2008 11:31:56 +0100 > David Woodhouse wrote: > > > A few moments with git-annotate showed that the missing ioctls were > > removed in commit 26d507fcfef7f7d0cd2eec874a87169cc121c835? by Brandon > > Philips. In their place, we have the following: > > > > /* Deprecated, use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */ > > #define V4L2_CID_HCENTER_DEPRECATED (V4L2_CID_BASE+22) > > #define V4L2_CID_VCENTER_DEPRECATED (V4L2_CID_BASE+23) > > > > That seems like a rather dubious change to the user API -- shouldn't we > > ensure that existing software continues to build, but maybe add a > > compile-time or run-time warning for those using the deprecated ioctls? > > > > Mauro, Brendan: unless the removal of those ioctls has been properly > > documented in Documentation/feature-removal-schedule.txt for an > > appropriate amount of time, please could you put them back as they were. > > Changing the userspace API like this isn't acceptable. > > IMO, there's nothing to be added at feature-removal-schedule.txt. Those controls > aren't used by any kernel drivers on a long time (I suspect that they were > never used). > > The issue is that they are targeted to do exactly what V4L2_CID_PAN_RESET and > V4L2_CID_TILT_RESET do. So, they are duplicated stuff. > > I was not aware that an userspace is using those symbols, but, if so, it is > likely to be related to some binary-only or out-of-tree drivers [1]. It was part of the published API, and it was being used by the gstreamer v4l2 plugin -- which now fails to build. Yes, of course we'll fix the code in question, but just removing APIs from the headers and causing source code to break without any prior warning is not acceptable. That's precisely what feature-removal-schedule.txt is _for_. -- dwmw2 From aph at redhat.com Mon Jun 2 15:41:23 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Jun 2008 16:41:23 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4843FA1B.2080706@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> <4843F1EA.6080300@redhat.com> <4843F704.8000102@oss.schwarz.eu> <4843FA1B.2080706@redhat.com> Message-ID: <484414A3.2090606@redhat.com> Andrew Haley wrote: > Felix Schwarz wrote: >> Andrew Haley schrieb: >>> Felix Schwarz wrote: >>> >>>>> Specifically, "If the JNI-using code calls System.loadLibrary you'll >>>>> have to patch it to use System.load, passing it the full path to the >>>>> dynamic shared object." >>>>> >>>>> For an example of this see >>>>> http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ >>>> Sorry, my wording was not detailed enough. JCC does "JNI the other way >>>> round" so it calls Java from C++. Therefore there is no >>>> System.loadLibrary which could be patched. Instead I have to rely on the >>>> standard linker configuration (or use rpath). >>> Or use a full path in dlopen(). >> I may be wrong but it seems that JCC does do any dlopens. Instead the code >> is just linked against the Java libraries. I may be wrong on this, though. >> >>> What libraries does JCC need to open? Just libjvm, or others? >> libjava.so and libjvm.so. > > OK, I understand now. I'm going to ping a few of my colleagues to see > what they think we should do. I've pinged. Please open a Bugzilla item and we'll look into adding libjvm.so and its dependencies to /etc/ld.so.conf.d and/or ld.so.cache. This will be in the Fedora 10 timeframe. We'll also have to talk to upstream about this. Thanks, Andrew. From lesmikesell at gmail.com Mon Jun 2 15:41:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 02 Jun 2008 10:41:28 -0500 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4843C0D8.2060403@fedoraproject.org> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <4843AE43.4050801@slated.org> <4843C0D8.2060403@fedoraproject.org> Message-ID: <484414A8.1040201@gmail.com> Rahul Sundaram wrote: >> >> Also, I really don't think that Free Software should require an >> affirmative confirmation of license acceptance to allow use of that >> software, especially when what one is "accepting" is the revocation of >> one's rights WRT that software. > > This is correct which is which is why I asked the person complaining > about this on fedora-test list to file a bug report which has already > been done. So further comments should go there. >> >> IMHO this is non-Free, and obviously both Debian and FSF agree with me, >> since they have each forked Firefox. > > Debian forked because the logo is non-free and FSF has forked earlier > due to non-free components like talkback which we didn't include in > Fedora. Export controls do not make a software non-free according to > FSF. Refer > > http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF > I disagree with the FSF on just about every point regarding the best ways to encourage the development and use of open source software, but this position on patents is even more bizarre than usual. I can sort-of understand the claim that patent coverage is harder to determine, but in cases where it is obvious, how can restrictions imposed by patents be considered any differently than restrictions imposed by other people's copyrights with respect to whether the GPL can be applied to the work as a whole with its explicit claim of redistribution rights under its own terms? -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Mon Jun 2 15:44:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Jun 2008 11:44:47 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <48440A0B.6090907@redhat.com> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> Message-ID: <1212421487.3437.9.camel@localhost.localdomain> On Mon, 2008-06-02 at 10:56 -0400, Jeremy Katz wrote: > python 1.5 -> python 2 wasn't this large. But it was pretty large and > ended up requiring a number of source changes in modules. Same with the recent perl upgrade, which requires spot and others make a number of source level changes at at the very least rebuild all the perl packages. This was accomplished using an 'on the side' repo within Koji, and an agreement ahead of time to not mess (too much) with perl packages while the building was ongoing so that the whole mess could be tagged over to rawhide in one shot instead of weeks of breakage. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Mon Jun 2 15:47:37 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 02 Jun 2008 11:47:37 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212199688.16130.135.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> <1212199688.16130.135.camel@localhost.localdomain> Message-ID: <48441619.8020804@redhat.com> Jesse Keating wrote: > The spirit is the same, those that are slogging along and putting up > with the traffic and doing the necessary work are those who get > some bonus in offering suggestions for the name of the next release. I'm not sure I like the incinuation that reading f-d-l on a constant basis and "doing the necessary work" are the same thing. (Or even directly related...) -- Peter From pemboa at gmail.com Mon Jun 2 15:51:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 2 Jun 2008 10:51:02 -0500 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <483F7FDA.9000701@gmail.com> References: <483F7FDA.9000701@gmail.com> Message-ID: <16de708d0806020851n5adcd76bo4b3e1226fae836b5@mail.gmail.com> 2008/5/29 Toshio Kuratomi : > The python programming language is going to be releasing a new version > sometime around the time of the Fedora 10 release. Unlike past releases, > this one will have wide-spread backwards incompatibility in the python > language itself. We need to think about how we want to pull the new > language into the distribution and porting of existing apps/modules. Here's > a proposal to start us off but I hope geppetto (the python maintainer) and > ivazquez (who maintains python3.0 packages in his spare time[1]_) will weigh > in with their thoughts. Good looking plan, one suggestion: Try to maintain a TODO list of things/features that need to be ported from Python2 to python3000. I would like to try to help, and having a list that I can pick from would be helpful -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jkeating at redhat.com Mon Jun 2 15:59:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Jun 2008 11:59:55 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48441619.8020804@redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> <1212199688.16130.135.camel@localhost.localdomain> <48441619.8020804@redhat.com> Message-ID: <1212422395.3437.11.camel@localhost.localdomain> On Mon, 2008-06-02 at 11:47 -0400, Peter Jones wrote: > > I'm not sure I like the incinuation that reading f-d-l on a constant > basis and "doing the necessary work" are the same thing. (Or even > directly related...) Yeah I think I phrased that poorly. I meant it as a treat for those that put up with reading through all the mail. But as we all know, the best intentions yadda yadda. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Jun 2 16:03:05 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 02 Jun 2008 10:03:05 -0600 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <20080602085739.A5900@humbolt.us.dell.com> References: <20080602085739.A5900@humbolt.us.dell.com> Message-ID: <484419B9.4030106@cora.nwra.com> Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > based on rawhide as of 01-June-2008. > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > gridengine-6.1u4-1.fc10 (build/make) orion It appears that your builder is bringing in .i386 java on x86_64: DEBUG util.py:250: ---> Package java-1.6.0-openjdk-devel.i386 1:1.6.0.0-0.14.b09.fc10 set to be updated DEBUG util.py:250: Checking deps for java-1.6.0-openjdk-devel.i386 1-1.6.0.0-0.14.b09.fc10 - u -- 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 sundaram at fedoraproject.org Mon Jun 2 16:07:03 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jun 2008 21:37:03 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <484414A8.1040201@gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <48438EFC.8010402@fedoraproject.org> <4843AE43.4050801@slated.org> <4843C0D8.2060403@fedoraproject.org> <484414A8.1040201@gmail.com> Message-ID: <48441AA7.6040305@fedoraproject.org> Les Mikesell wrote: > I disagree with the FSF on just about every point regarding the best > ways to encourage the development and use of open source software, but > this position on patents is even more bizarre than usual. I can sort-of > understand the claim that patent coverage is harder to determine, but in > cases where it is obvious, how can restrictions imposed by patents be > considered any differently than restrictions imposed by other people's > copyrights with respect to whether the GPL can be applied to the work as > a whole with its explicit claim of redistribution rights under its own > terms? Unlike copyrights, patents are far from universally enforced. If you want to further clarifications, I suggest you take it with FSF rather than here. Rahul From kaboom at oobleck.net Mon Jun 2 16:27:36 2008 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 2 Jun 2008 12:27:36 -0400 (EDT) Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <484419B9.4030106@cora.nwra.com> References: <20080602085739.A5900@humbolt.us.dell.com> <484419B9.4030106@cora.nwra.com> Message-ID: On Mon, 2 Jun 2008, Orion Poplawski wrote: > Matt Domsch wrote: > > Fedora Rawhide-in-Mock Build Results for x86_64 > > based on rawhide as of 01-June-2008. > > > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > gridengine-6.1u4-1.fc10 (build/make) orion > > It appears that your builder is bringing in .i386 java on x86_64: > > DEBUG util.py:250: ---> Package java-1.6.0-openjdk-devel.i386 > 1:1.6.0.0-0.14.b09.fc10 set to be updated > DEBUG util.py:250: Checking deps for java-1.6.0-openjdk-devel.i386 > 1-1.6.0.0-0.14.b09.fc10 - u I'm seeing oddities too qgo builds in koji -- scratch build logs at http://koji.fedoraproject.org/koji/taskinfo?taskID=640889 it fails in the full Rawhide rebuild http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/qgo-1.5.4r2-1.fc9.src.rpm/result/ The difference on that one appears to be that BuildRequires: qt3-devel in the spec, on koji, pulls in all the necessary qt3 stuff, but doesn't on Matt's rebuild? later, chris From limb at jcomserv.net Mon Jun 2 16:37:20 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jun 2008 11:37:20 -0500 (CDT) Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <20080602085838.A5948@humbolt.us.dell.com> References: <20080602085838.A5948@humbolt.us.dell.com> Message-ID: <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> > astromenace-1.2-8.fc9 (build/make) limb Already foxed qof. astromenace builds fine locally, but it looks like this build failed because it was missing sdl-config, which is in SDL-devel, an explicit BR, which mock pulled. Running my own mock build against devel now as a test. . . Jon -- novus ordo absurdum From Matt_Domsch at dell.com Mon Jun 2 16:47:30 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 11:47:30 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <484419B9.4030106@cora.nwra.com> References: <20080602085739.A5900@humbolt.us.dell.com> <484419B9.4030106@cora.nwra.com> Message-ID: <20080602164730.GA24278@auslistsprd01.us.dell.com> On Mon, Jun 02, 2008 at 10:03:05AM -0600, Orion Poplawski wrote: > Matt Domsch wrote: > >Fedora Rawhide-in-Mock Build Results for x86_64 > >based on rawhide as of 01-June-2008. > > > > > >Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > >gridengine-6.1u4-1.fc10 (build/make) orion > > It appears that your builder is bringing in .i386 java on x86_64: > > DEBUG util.py:250: ---> Package java-1.6.0-openjdk-devel.i386 > 1:1.6.0.0-0.14.b09.fc10 set to be updated > DEBUG util.py:250: Checking deps for java-1.6.0-openjdk-devel.i386 > 1-1.6.0.0-0.14.b09.fc10 - u Very odd, as I'm using a Fedora 9 build system, with yum 3.2.14, which shouldn't have done that AFAIK. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From limb at jcomserv.net Mon Jun 2 17:01:02 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jun 2008 12:01:02 -0500 (CDT) Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> References: <20080602085838.A5948@humbolt.us.dell.com> <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> Message-ID: <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> > >> astromenace-1.2-8.fc9 (build/make) limb > > Already foxed qof. astromenace builds fine locally, but it looks like > this build failed because it was missing sdl-config, which is in > SDL-devel, an explicit BR, which mock pulled. Running my own mock build > against devel now as a test. . . Finished. Same error. Builds just fine oon fc9 local. > Jon > > -- > 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 linville at redhat.com Mon Jun 2 17:09:31 2008 From: linville at redhat.com (John W. Linville) Date: Mon, 2 Jun 2008 13:09:31 -0400 Subject: Kernel headers changes in F10? In-Reply-To: <1212402825.16924.84.camel@pmac.infradead.org> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> Message-ID: <20080602170931.GA27063@redhat.com> On Mon, Jun 02, 2008 at 11:33:45AM +0100, David Woodhouse wrote: > On Mon, 2008-06-02 at 11:59 +0200, Hans de Goede wrote: > > There seem to be a number of changes in the 2.6.26 kernel headers causing > > compile breakage (and/or in the new glibc), I've had to fix both of: > > > > svgalib, really fixed > > > > gkrellm-wifi, conflict between and , worked > > around by no longer including > > I always like solutions which involve "include fewer kernel headers", > but we should probably investigate that in case there is some need for > someone to include both. John? Almost certainly because of this commit: commit 2218228392080f0ca2fc2974604e79f57b12c436 Author: Kirill A. Shutemov Date: Tue Apr 22 16:38:55 2008 +0300 Make linux/wireless.h be able to compile Signed-off-by: Kirill A. Shutemov Signed-off-by: John W. Linville I may have let this slip by due to the "able to compile" bit -- should I not have merged it? I don't have a record or recollection of what motivated the patch originally. John -- John W. Linville linville at redhat.com From j.w.r.degoede at hhs.nl Mon Jun 2 17:13:27 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jun 2008 19:13:27 +0200 Subject: Kernel headers changes in F10? In-Reply-To: <20080602170931.GA27063@redhat.com> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> Message-ID: <48442A37.8030501@hhs.nl> John W. Linville wrote: > On Mon, Jun 02, 2008 at 11:33:45AM +0100, David Woodhouse wrote: >> On Mon, 2008-06-02 at 11:59 +0200, Hans de Goede wrote: >>> There seem to be a number of changes in the 2.6.26 kernel headers causing >>> compile breakage (and/or in the new glibc), I've had to fix both of: >>> >>> svgalib, really fixed >>> >>> gkrellm-wifi, conflict between and , worked >>> around by no longer including >> I always like solutions which involve "include fewer kernel headers", >> but we should probably investigate that in case there is some need for >> someone to include both. John? > > Almost certainly because of this commit: > > commit 2218228392080f0ca2fc2974604e79f57b12c436 > Author: Kirill A. Shutemov > Date: Tue Apr 22 16:38:55 2008 +0300 > > Make linux/wireless.h be able to compile > > Signed-off-by: Kirill A. Shutemov > Signed-off-by: John W. Linville > > I may have let this slip by due to the "able to compile" bit -- > should I not have merged it? I don't have a record or recollection > of what motivated the patch originally. > Erm, I'm no git guru, can you tranlate this: commit 2218228392080f0ca2fc2974604e79f57b12c436 Into an url showing the diff for me, then I can take try to take a guess at what this is trying to fix, and how this might be done without conflicting with net/if.h Thanks, Hans From tibbs at math.uh.edu Mon Jun 2 17:18:12 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2008 12:18:12 -0500 Subject: On-the-side repos (Was: Let's make a plan for python3.0 in Fedora 10+) In-Reply-To: <1212421487.3437.9.camel@localhost.localdomain> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> <1212421487.3437.9.camel@localhost.localdomain> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Same with the recent perl upgrade, which requires spot and others JK> make a number of source level changes at at the very least rebuild JK> all the perl packages. This was accomplished using an 'on the JK> side' repo within Koji, and an agreement ahead of time to not mess JK> (too much) with perl packages while the building was ongoing so JK> that the whole mess could be tagged over to rawhide in one shot JK> instead of weeks of breakage. Is there any possibility of being able to do this on a more regular basis for other destabilizing updates? There was an IRC discussion recently calling for something more experimental than rawhide, which I don't really think would be productive, but it still might be nice to have a relatively easy way to handle the situation where a maintainer knows they're going to do something destabilizing. - J< From jkeating at redhat.com Mon Jun 2 17:28:53 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Jun 2008 13:28:53 -0400 Subject: On-the-side repos (Was: Let's make a plan for python3.0 in Fedora 10+) In-Reply-To: References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> <1212421487.3437.9.camel@localhost.localdomain> Message-ID: <1212427733.3437.15.camel@localhost.localdomain> On Mon, 2008-06-02 at 12:18 -0500, Jason L Tibbitts III wrote: > > Is there any possibility of being able to do this on a more regular > basis for other destabilizing updates? There was an IRC discussion > recently calling for something more experimental than rawhide, which I > don't really think would be productive, but it still might be nice to > have a relatively easy way to handle the situation where a maintainer > knows they're going to do something destabilizing. Sounds like a job for Kopers. https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos Now all it needs is somebody with enough time to code it up. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From linville at redhat.com Mon Jun 2 17:28:53 2008 From: linville at redhat.com (John W. Linville) Date: Mon, 2 Jun 2008 13:28:53 -0400 Subject: Kernel headers changes in F10? In-Reply-To: <48442A37.8030501@hhs.nl> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> Message-ID: <20080602172853.GB27063@redhat.com> On Mon, Jun 02, 2008 at 07:13:27PM +0200, Hans de Goede wrote: > John W. Linville wrote: > >On Mon, Jun 02, 2008 at 11:33:45AM +0100, David Woodhouse wrote: > >>On Mon, 2008-06-02 at 11:59 +0200, Hans de Goede wrote: > >>>There seem to be a number of changes in the 2.6.26 kernel headers > >>>causing compile breakage (and/or in the new glibc), I've had to fix both > >>>of: > >>> > >>>svgalib, really fixed > >>> > >>>gkrellm-wifi, conflict between and , > >>>worked around by no longer including > >>I always like solutions which involve "include fewer kernel headers", > >>but we should probably investigate that in case there is some need for > >>someone to include both. John? > > > >Almost certainly because of this commit: > > > >commit 2218228392080f0ca2fc2974604e79f57b12c436 > >Author: Kirill A. Shutemov > >Date: Tue Apr 22 16:38:55 2008 +0300 > > > > Make linux/wireless.h be able to compile > > > > Signed-off-by: Kirill A. Shutemov > > Signed-off-by: John W. Linville > > > >I may have let this slip by due to the "able to compile" bit -- > >should I not have merged it? I don't have a record or recollection > >of what motivated the patch originally. > > > > Erm, > > I'm no git guru, can you tranlate this: > commit 2218228392080f0ca2fc2974604e79f57b12c436 > > Into an url showing the diff for me, then I can take try to take a guess at > what this is trying to fix, and how this might be done without conflicting > with net/if.h http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2218228392080f0ca2fc2974604e79f57b12c436 As I said, I have no record or memory of why this patch was needed. It looks like it was a mistake for me to let it though in the first place. My guess is that he wanted to include linux/wireless.h from userland without including other kernel headers...? I am happy to entertain arguments in favor of reverting (or keeping) this patch. John -- John W. Linville linville at redhat.com From j.w.r.degoede at hhs.nl Mon Jun 2 17:45:07 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jun 2008 19:45:07 +0200 Subject: Kernel headers changes in F10? In-Reply-To: <20080602172853.GB27063@redhat.com> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> <20080602172853.GB27063@redhat.com> Message-ID: <484431A3.6010706@hhs.nl> John W. Linville wrote: > On Mon, Jun 02, 2008 at 07:13:27PM +0200, Hans de Goede wrote: >> John W. Linville wrote: >>> On Mon, Jun 02, 2008 at 11:33:45AM +0100, David Woodhouse wrote: >>>> On Mon, 2008-06-02 at 11:59 +0200, Hans de Goede wrote: >>>>> There seem to be a number of changes in the 2.6.26 kernel headers >>>>> causing compile breakage (and/or in the new glibc), I've had to fix both >>>>> of: >>>>> >>>>> svgalib, really fixed >>>>> >>>>> gkrellm-wifi, conflict between and , >>>>> worked around by no longer including >>>> I always like solutions which involve "include fewer kernel headers", >>>> but we should probably investigate that in case there is some need for >>>> someone to include both. John? >>> Almost certainly because of this commit: >>> >>> commit 2218228392080f0ca2fc2974604e79f57b12c436 >>> Author: Kirill A. Shutemov >>> Date: Tue Apr 22 16:38:55 2008 +0300 >>> >>> Make linux/wireless.h be able to compile >>> >>> Signed-off-by: Kirill A. Shutemov >>> Signed-off-by: John W. Linville >>> >>> I may have let this slip by due to the "able to compile" bit -- >>> should I not have merged it? I don't have a record or recollection >>> of what motivated the patch originally. >>> >> Erm, >> >> I'm no git guru, can you tranlate this: >> commit 2218228392080f0ca2fc2974604e79f57b12c436 >> >> Into an url showing the diff for me, then I can take try to take a guess at >> what this is trying to fix, and how this might be done without conflicting >> with net/if.h > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2218228392080f0ca2fc2974604e79f57b12c436 > > As I said, I have no record or memory of why this patch was needed. > It looks like it was a mistake for me to let it though in the first > place. My guess is that he wanted to include linux/wireless.h from > userland without including other kernel headers...? > Looks like a good candidate for reverting. I see little arguments to keep this patch in, it will probably break compilation of other users of linux/wireless.h too, as those probably also already include to get the necessary stuff from there. Regards, Hans From Matt_Domsch at dell.com Mon Jun 2 18:17:09 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 13:17:09 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> References: <20080602085838.A5948@humbolt.us.dell.com> <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> Message-ID: <20080602181709.GA27019@auslistsprd01.us.dell.com> On Mon, Jun 02, 2008 at 12:01:02PM -0500, Jon Ciesla wrote: > > > > >> astromenace-1.2-8.fc9 (build/make) limb > > > > Already foxed qof. astromenace builds fine locally, but it looks like > > this build failed because it was missing sdl-config, which is in > > SDL-devel, an explicit BR, which mock pulled. Running my own mock build > > against devel now as a test. . . > > Finished. Same error. Builds just fine oon fc9 local. There's something wrong with $PATH for the build user inside the buildroot when it fails for me. I built it inside mock again, and see the same failure. However, if I edit the makefiles to point at /usr/bin/sdl-config instead of simply sdl-config, it succeeds. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From felix.schwarz at oss.schwarz.eu Mon Jun 2 18:21:04 2008 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 02 Jun 2008 20:21:04 +0200 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <484414A3.2090606@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> <4843F1EA.6080300@redhat.com> <4843F704.8000102@oss.schwarz.eu> <4843FA1B.2080706@redhat.com> <484414A3.2090606@redhat.com> Message-ID: <48443A10.5040906@oss.schwarz.eu> Hi Andrew, Andrew Haley wrote: > I've pinged. Please open a Bugzilla item and we'll look into adding > libjvm.so and its dependencies to /etc/ld.so.conf.d and/or ld.so.cache. > This will be in the Fedora 10 timeframe. We'll also have to talk to > upstream about this. Thanks for caring about this. Bugzilla issue is: https://bugzilla.redhat.com/show_bug.cgi?id=449456 Do you have any advise on how to proceed with python-jcc (bz 449360) in the mean time? Felix Schwarz From pbrobinson at gmail.com Mon Jun 2 18:31:07 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 2 Jun 2008 19:31:07 +0100 Subject: howto push dependencies into sub packages Message-ID: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> Hi All, I maintain the geoclue package. It has a number of providers that can be compiled in. I've tried to introduce a couple of subpackages for the gpsd and gypsy providers so that you can just install the providers you need and not have to pull in extra packages that you might not need (gpsd and gypsy do essentially the same thing so you probably don't need both). The problem I'm having is that with the addition of the gpsd provider (see F-9 testing if you aren't on rawhide) pulls in gpsd for the main package and not for the geoclue-gpsd package. How do I push this requirement down to the sub package so that it doesn't affect the main package (I've got the gpsd requirements in the sub package). Cheers, Peter From tcallawa at redhat.com Mon Jun 2 18:33:26 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jun 2008 14:33:26 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1212431606.3367.22.camel@localhost.localdomain> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". 1. Sulphur is a breed of horse... Abaco Barb, Abtenauer, Abyssinian, Aegidienberger, Akhal-Teke, Albanian, Altai, Alter Real, American Cream Draft, American Paint, American Quarter, American Saddlebred, American Warmblood, Andalusian, Andravida, Anglo-Arabian, Anglo-Kabarda, Appaloosa, Arabian, Ardennes, Asturcon, Brumby, Australian Stock, Austrian Warmblood, Auxois, Azteca, Balearic, Balikun, Baluchi, Ban'ei, Banker, Barb, Bavarian Warmblood, Belgian, Belgian Warmblood, Black Forest, Bloulonnais, Brandenburger, Brazilian Sport, Breton, Budyonny, Byelorussian Harness, Calabrese, Camargue, Camarillo White, Campolina, Canadian, Canadian Pacer, Carolina Marsh Tacky, Carthusian, Castilian, Chilean, Cleveland Bay, Clydesdale, Colorado Ranger, Comtois, Cretan, Criollo, Cuban Criollo, Curly, Czech Warmblood, Daliboz, Danish Warmblood, East Bulgarian, Estonian Draft, Falabella, Faroese, Finnish, Fleuve, Fjord, Florida Cracker, Fouta, Frederiksborg, Freiberger, Friesian, Galiceno, Gelderland, German Warmblood, Groningen, Gypsy Vanner, Hackney, Haflinger, Hanoverian, Heck, Heihe, Hispano, Hirzai, Holsteiner, Hungarian Warmblood, Icelandic, Iomud, Irish Draught, Irish Sport, Italian Heavy Draft, Jutland, Kabarda, Kaimanawa, Karabair, Karabakh, Kathiawari, Kentucky Mountain Saddle, Kinsky, Kisber Felver, Kladruber, Knabstrup, Konik, Kustanair, Latvian, Lipizzan, Lithuanian Heavy Draught, Lokai, Lusitano, M'Bayar, Malapolski, Mangalarga, Maremmano, Marwari, Messara, Miniature, Missouri Fox Trotter, Mongolian, Morab, Morgan, Mustang, Murakoz. Murgese, National Show, Nez Perce, Nokota, Nonius, Noriker, North Swedish, Novokirghiz, Oberlander, Oldenburg, Orlov Trotter, Pampa, Paso Fino, Percheron, Peruvian Paso, Pleven, Poitevin, Qatgani, Quarab, Racking, Rhenish-German Cold-Blood, Rhinlander, Rocky Mountain, Russian Don, Russian Heavy Draft, Russian Trottler, Salerno, San Fratello, Sardinian, Selle Fran?ais, Shagya Arabian, Shire, Sorraia, Sokolsky, Soviet Heavy Draft, Spanish Jennet, Spanish Mustang, Spotted Saddle, Standardbred, Suffolk Punsh, Swedish Ardennes, Swedish Warmblood, Taishuh, Tawleed, Tennessee Walking, Tersk, Thoroughbred, Tiger, Tori, Trait Du Nord, Trakehner, Ukranian Riding, Unmol, Uzunyayla, Ventasso, Virginia Highlander, Vlaamperd, Vladimir Heavy Draft, Waler, Walkaloosa, Wielkopolski, W?rttemberger, Xilingol, Yili, Yonaguini, Zangersheide, Zweibr?cker 2. Sulphur is a death metal band. I'm not sure we want to follow that one, though. (http://en.wikipedia.org/wiki/List_of_death_metal_bands) It does give us "Xenomorph"... ~spot From ville.skytta at iki.fi Mon Jun 2 18:37:50 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 2 Jun 2008 21:37:50 +0300 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <20080602164730.GA24278@auslistsprd01.us.dell.com> References: <20080602085739.A5900@humbolt.us.dell.com> <484419B9.4030106@cora.nwra.com> <20080602164730.GA24278@auslistsprd01.us.dell.com> Message-ID: <200806022137.50928.ville.skytta@iki.fi> On Monday 02 June 2008, Matt Domsch wrote: > On Mon, Jun 02, 2008 at 10:03:05AM -0600, Orion Poplawski wrote: > > Matt Domsch wrote: > > >Fedora Rawhide-in-Mock Build Results for x86_64 > > >based on rawhide as of 01-June-2008. > > > > > > > > >Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > > >gridengine-6.1u4-1.fc10 (build/make) orion > > > > It appears that your builder is bringing in .i386 java on x86_64: > > > > DEBUG util.py:250: ---> Package java-1.6.0-openjdk-devel.i386 > > 1:1.6.0.0-0.14.b09.fc10 set to be updated > > DEBUG util.py:250: Checking deps for java-1.6.0-openjdk-devel.i386 > > 1-1.6.0.0-0.14.b09.fc10 - u > > Very odd, as I'm using a Fedora 9 build system, with yum 3.2.14, which > shouldn't have done that AFAIK. Same thing here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/javasqlite-20080420-1.fc10.src.rpm/result/root.log "BuildRequires: java-devel java-javadoc" resulted in these installed: java-1.5.0-gcj-devel.x86_64 java-1.5.0-gcj-javadoc.x86_64 java-1.5.0-gcj.x86_64 java-1.6.0-openjdk-devel.i386 java-1.6.0-openjdk.i386 I suppose the i386 openjdk was used for the build, causing the test suite to fail when loading libsqlite_jni. From limb at jcomserv.net Mon Jun 2 18:48:11 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jun 2008 13:48:11 -0500 (CDT) Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <20080602181709.GA27019@auslistsprd01.us.dell.com> References: <20080602085838.A5948@humbolt.us.dell.com> <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> <20080602181709.GA27019@auslistsprd01.us.dell.com> Message-ID: <33057.198.175.55.5.1212432491.squirrel@mail.jcomserv.net> > On Mon, Jun 02, 2008 at 12:01:02PM -0500, Jon Ciesla wrote: >> >> > >> >> astromenace-1.2-8.fc9 (build/make) limb >> > >> > Already foxed qof. astromenace builds fine locally, but it looks like >> > this build failed because it was missing sdl-config, which is in >> > SDL-devel, an explicit BR, which mock pulled. Running my own mock >> build >> > against devel now as a test. . . >> >> Finished. Same error. Builds just fine oon fc9 local. > > There's something wrong with $PATH for the build user inside the > buildroot when it fails for me. I built it inside mock again, and see > the same failure. However, if I edit the makefiles to point at > /usr/bin/sdl-config instead of simply sdl-config, it succeeds. Could this be causing other problems/failures as well? > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > -- novus ordo absurdum From rnorwood at redhat.com Mon Jun 2 18:51:35 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 2 Jun 2008 14:51:35 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212431606.3367.22.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212431606.3367.22.camel@localhost.localdomain> Message-ID: <20080602145135.27f2cafd@solitude.devel.redhat.com> On Mon, 02 Jun 2008 14:33:26 -0400 "Tom \"spot\" Callaway" wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > > > 2) The link between and Sulphur cannot be the same as > > between Werewolf and Sulphur. That link was "things that react > > badly with silver". > > 1. > Sulphur is a breed of horse... In that case, I nominate "Tennessee Stud". The only problem left is to tie that to "Ours goes to..." for F11. :-) ( ref: http://www.youtube.com/watch?v=Utka_BXEUK4 ) -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From notting at redhat.com Mon Jun 2 18:55:55 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Jun 2008 14:55:55 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212431606.3367.22.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212431606.3367.22.camel@localhost.localdomain> Message-ID: <20080602185555.GC5054@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > 2. Sulphur is a death metal band. I'm not sure we want to follow that > one, though. (http://en.wikipedia.org/wiki/List_of_death_metal_bands) > It does give us "Xenomorph"... It's a bug hunt. Bill From Matt_Domsch at dell.com Mon Jun 2 19:00:21 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 14:00:21 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <33057.198.175.55.5.1212432491.squirrel@mail.jcomserv.net> References: <20080602085838.A5948@humbolt.us.dell.com> <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> <20080602181709.GA27019@auslistsprd01.us.dell.com> <33057.198.175.55.5.1212432491.squirrel@mail.jcomserv.net> Message-ID: <20080602190021.GB27019@auslistsprd01.us.dell.com> On Mon, Jun 02, 2008 at 01:48:11PM -0500, Jon Ciesla wrote: > > > On Mon, Jun 02, 2008 at 12:01:02PM -0500, Jon Ciesla wrote: > >> > >> > > >> >> astromenace-1.2-8.fc9 (build/make) limb > >> > > >> > Already foxed qof. astromenace builds fine locally, but it looks like > >> > this build failed because it was missing sdl-config, which is in > >> > SDL-devel, an explicit BR, which mock pulled. Running my own mock > >> build > >> > against devel now as a test. . . > >> > >> Finished. Same error. Builds just fine oon fc9 local. > > > > There's something wrong with $PATH for the build user inside the > > buildroot when it fails for me. I built it inside mock again, and see > > the same failure. However, if I edit the makefiles to point at > > /usr/bin/sdl-config instead of simply sdl-config, it succeeds. > > Could this be causing other problems/failures as well? Turns out it's not quite that simple... I just didn't let it run long enough. >From sitting inside the chroot, as the building user, I run: $ make Linking CXX executable AstroMenace c++: `/usr/bin/sdl-config: No such file or directory make[2]: *** [AstroMenace] Error 1 make[1]: *** [CMakeFiles/AstroMenace.dir/all] Error 2 make: *** [all] Error 2 but of course it's present. CMakeFiles/AstroMenace.dir/link.txt is our culprit. If you look at that file, the line length is huge (>10k characters). The `sdl-config --libs` is not getting evaluated in a shell, like the code expects, it's being evaluated by /usr/bin/c++, which of course fails. Short story is, the invocations of sdl-config --libs and sdl-config --cflags should happen not quite as late as they are, but earlier, where they can be evaluated and expanded by Makefile and not by c++. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From aph at redhat.com Mon Jun 2 19:07:35 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Jun 2008 20:07:35 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <48443A10.5040906@oss.schwarz.eu> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> <4843F1EA.6080300@redhat.com> <4843F704.8000102@oss.schwarz.eu> <4843FA1B.2080706@redhat.com> <484414A3.2090606@redhat.com> <48443A10.5040906@oss.schwarz.eu> Message-ID: <484444F7.3000806@redhat.com> Felix Schwarz wrote: > Hi Andrew, > > Andrew Haley wrote: >> I've pinged. Please open a Bugzilla item and we'll look into adding >> libjvm.so and its dependencies to /etc/ld.so.conf.d and/or ld.so.cache. >> This will be in the Fedora 10 timeframe. We'll also have to talk to >> upstream about this. > > Thanks for caring about this. Bugzilla issue is: > https://bugzilla.redhat.com/show_bug.cgi?id=449456 > > Do you have any advise on how to proceed with python-jcc (bz 449360) in > the mean time? OpenOffice searches for the .so, dlopen()s it, and uses dlsym() to find the various entry points. A PITA I know, but I can think of no better way right now. Andrew. From walters at verbum.org Mon Jun 2 19:11:02 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 2 Jun 2008 15:11:02 -0400 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4843E6E2.1030908@oss.schwarz.eu> References: <4835E696.1010401@oss.schwarz.eu> <4843E6E2.1030908@oss.schwarz.eu> Message-ID: On Mon, Jun 2, 2008 at 8:26 AM, Felix Schwarz wrote: > > In my understanding Jython better suited/the best possibility if I want to > call Python from Java code. If the main program is in Python, using Jython > will restrict you on a Python feature set that is roughly the same as in > Python 2.2. Jython in SVN is 2.3 + some 2.4 features, and some 2.5 libraries. Here's a slightly old status report: http://groups.google.com/group/jvm-languages/browse_thread/thread/e53015c684f69d2d Hopefully they'll do a new release sometime soon. So I think JCC is basically the right thing to do as this is the only way > you can always use the latest Python features (even Python packages that are > written in C) and the latest Java (GCJ always had threading issues and is > generally hard to debug). There are different tradeoffs; wedging two completely separate runtimes into the same process gives you a lot of integration issues - garbage collectors that aren't aware of each other, etc. Furthermore using JCC you can even use Java from C++ without too much hassle > - quite cool I think :-) > Yeah; it does make sense I think to ship JCC. But once Jython is able to run major web frameworks like Django/TurboGears, there will be less need for it. > Sorry, my wording was not detailed enough. JCC does "JNI the other way > round" so it calls Java from C++. Therefore there is no System.loadLibrary > which could be patched. Instead I have to rely on the standard linker > configuration (or use rpath). Ah, I see. I think it makes the most sense to either put libjvm.so in $libdir or use dlopen, but that's more of a detail for the OpenJDK/Icedtea hackers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Mon Jun 2 19:13:25 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jun 2008 15:13:25 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212431606.3367.22.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212431606.3367.22.camel@localhost.localdomain> Message-ID: <1212434005.3367.28.camel@localhost.localdomain> Okay, here is my short list: Banker Barb Belgian Curly Fjord Hackney ~spot From Matt_Domsch at dell.com Mon Jun 2 20:57:06 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 2 Jun 2008 15:57:06 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <200806022137.50928.ville.skytta@iki.fi> References: <20080602085739.A5900@humbolt.us.dell.com> <484419B9.4030106@cora.nwra.com> <20080602164730.GA24278@auslistsprd01.us.dell.com> <200806022137.50928.ville.skytta@iki.fi> Message-ID: <20080602205706.GC27019@auslistsprd01.us.dell.com> On Mon, Jun 02, 2008 at 09:37:50PM +0300, Ville Skytt? wrote: > On Monday 02 June 2008, Matt Domsch wrote: > > On Mon, Jun 02, 2008 at 10:03:05AM -0600, Orion Poplawski wrote: > > > Matt Domsch wrote: > > > >Fedora Rawhide-in-Mock Build Results for x86_64 > > > >based on rawhide as of 01-June-2008. > > > > > > > > > > > >Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > > > > >gridengine-6.1u4-1.fc10 (build/make) orion > > > > > > It appears that your builder is bringing in .i386 java on x86_64: > > > > > > DEBUG util.py:250: ---> Package java-1.6.0-openjdk-devel.i386 > > > 1:1.6.0.0-0.14.b09.fc10 set to be updated > > > DEBUG util.py:250: Checking deps for java-1.6.0-openjdk-devel.i386 > > > 1-1.6.0.0-0.14.b09.fc10 - u > > > > Very odd, as I'm using a Fedora 9 build system, with yum 3.2.14, which > > shouldn't have done that AFAIK. > > Same thing here: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/javasqlite-20080420-1.fc10.src.rpm/result/root.log > > "BuildRequires: java-devel java-javadoc" resulted in these installed: > > java-1.5.0-gcj-devel.x86_64 > java-1.5.0-gcj-javadoc.x86_64 > java-1.5.0-gcj.x86_64 > java-1.6.0-openjdk-devel.i386 > java-1.6.0-openjdk.i386 > > I suppose the i386 openjdk was used for the build, causing the test suite to > fail when loading libsqlite_jni. https://bugzilla.redhat.com/show_bug.cgi?id=449554 filed, adding debug info now. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From choeger at cs.tu-berlin.de Mon Jun 2 20:58:54 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 02 Jun 2008 22:58:54 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <483F7FDA.9000701@gmail.com> References: <483F7FDA.9000701@gmail.com> Message-ID: <1212440334.3133.13.camel@choeger6> Hi, could you point out why exactly there is "something to do"? I mean, python3000 is a new language and no replacement so if someone is willing to package it (or a package that depends on py3k) she/he should make sure its a python2.x compatible installation (especially in the naming of the package). That should be all, right? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora at slated.org Mon Jun 2 22:48:00 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Mon, 02 Jun 2008 23:48:00 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> Message-ID: <0u9eh5-4vi.ln1@sky.matrix> Verily I say unto thee, that Naheem Zaffar spake thusly: >> It's hard to convict a criminal who has not yet committed the crime >> > totally off-topic, but if no crime has been committed, the person is > not a criminal. To elucidate my analogy: This particular criminal has "form", they've already been convicted, at least twice, on two continents. Any FBI profiler would describe this as a high risk scenario, providing sufficient due cause to take steps that would usually be a violation of that individual's civil rights, by e.g. invoking the Patriot Act. But stepping back from the analogy, I don't literally mean "conviction" in this case ... I mean taking measures to protect others. Protect /us/ from a known bad element who clearly has unambiguously bad intentions. > Slightly on topic (only because I feel there should be something on > topic in this post), yes some people are uncomfortable with Mono (I > myself uninstall it as my first task after installing Fedora), but > there are some checks and balances - there is the ECMA standards > certification and more importantly there is (or was - no idea where > it is after the Novell deal.) "protection" on this item from the OIN > - something which preceded mono's inclusion into Fedora. AFAIK the OIN do not own all the patents in mono-core. It's Microsoft's "Intellectual Property", provided under ECMA's supposedly "RAND" patent terms. If this isn't the case, I'd be most relieved to be proved wrong. -- Regards, Keith G. Robertson-Turner From sundaram at fedoraproject.org Mon Jun 2 23:31:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jun 2008 05:01:44 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <0u9eh5-4vi.ln1@sky.matrix> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> Message-ID: <484482E0.2080108@fedoraproject.org> Keith G. Robertson-Turner wrote: > > AFAIK the OIN do not own all the patents in mono-core. It's Microsoft's > "Intellectual Property", provided under ECMA's supposedly "RAND" patent > terms. If this isn't the case, I'd be most relieved to be proved wrong. You seem to misunderstand how OIN works. OIN doesn't need any patents related to Mono. http://gregdek.livejournal.com/4008.html Rahul From bojan at rexursive.com Mon Jun 2 23:40:33 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 2 Jun 2008 23:40:33 +0000 (UTC) Subject: Fedora i386 rawhide rebuild in mock status 2008-05-27 References: <20080531072528.A2064@humbolt.us.dell.com> Message-ID: Matt Domsch dell.com> writes: > libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan Looking at the build log: ----------------------------------- /etc/profile: line 38: /bin/hostname: No such file or directory sh: /usr/sbin/apxs: No such file or directory cat: /.mmn : No such file or directory ----------------------------------- Without apxs, this build has zero chance of succeeding. The package spec file correctly includes: ----------------------------------- BuildRequires: httpd-devel >= 2.0.48 ----------------------------------- Which in turn delivers /usr/sbin/apxs. So, I don't know what's going on here. Maybe we don't have permission to look into /usr/sbin or something in the build system? -- Bojan From tibbs at math.uh.edu Mon Jun 2 23:46:08 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2008 18:46:08 -0500 Subject: Bizarre debugedit complaint Message-ID: Anyone seen anything like the following before? extracting debug info from /var/tmp/lazarus-0.9.24-3.fc10-root-mockbuild/usr/lib64/lazarus/lazarus /usr/lib/rpm/debugedit: /var/tmp/lazarus-0.9.24-3.fc10-root-mockbuild/usr/lib64/lazarus/lazarus: Wrong directory table index 3 The last bit repeats many times; somethings the '3' is '102' instead. This package (https://bugzilla.redhat.com/show_bug.cgi?id=187243) is written in pascal and built using the fpc compiler. It seems that fpc generates some kind of debug symbols, but they're not quite in the format that the debuginfo extraction bits understand. Is this worth a bug report, and if so, is the bug in rpm or fpc? - J< From roland at redhat.com Tue Jun 3 00:38:02 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jun 2008 17:38:02 -0700 (PDT) Subject: Bizarre debugedit complaint In-Reply-To: Jason L Tibbitts III's message of , 2 June 2008 18:46:08 -0500 References: Message-ID: <20080603003802.EE82B26FC2F@magilla.localdomain> fpc generates DWARF, the same format that gcc generates and that the tools know how to process. It might be that fpc has bugs and generates bad DWARF. Or it might be that it generates valid DWARF but with patterns that GCC never generates. Since most everything has DWARF generated by the same codebase in GCC, the DWARF-consuming tools like debugedit might have bugs that were never noticed until fpc came along. I will try to reproduce the failing build and look at the DWARF data. Thanks, Roland From stickster at gmail.com Tue Jun 3 01:00:35 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 02 Jun 2008 21:00:35 -0400 Subject: Board IRC meeting Message-ID: <1212454835.4023.143.camel@victoria> In the past few months, the Board has scheduled a public IRC meeting on the first meeting of the month. Because of the timing of LinuxTag last week, however, there will not be a public Board IRC meeting on Tuesday, June 3. We will announce the next public IRC meeting well in advance so community members can attend if desired. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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 ivazqueznet at gmail.com Tue Jun 3 01:14:22 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 02 Jun 2008 21:14:22 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <1212418883.12635.6.camel@cutter> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <1212418883.12635.6.camel@cutter> Message-ID: <1212455662.3057.24.camel@ignacio.lan> On Mon, 2008-06-02 at 11:01 -0400, seth vidal wrote: > On Mon, 2008-06-02 at 10:45 -0400, James Antill wrote: > > > Probably the most interesting python application is yum, as if it > > breaks you can't easily update/install to fix anything, and it currently > > depends on: > > > > pygpgme - binding > > python-iniparse > > rpm-python - binding > > urlgrabber > > yum-metadata-parser - binding > > > > the other question I have is how many of the 'batteries included' > modules in python will not yet be ported to py3k? I mean if something > like bzip2 or fnmatch or logging isn't ported yet we will have issues. The stdlib is about 98% ready. The big things to watch for are the removed modules, not many of which yum et al are terribly likely to use (md5 and sha, off the top of my head). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Tue Jun 3 01:15:33 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 02 Jun 2008 21:15:33 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <1212440334.3133.13.camel@choeger6> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> Message-ID: <1212455733.3057.26.camel@ignacio.lan> On Mon, 2008-06-02 at 22:58 +0200, Christoph H?ger wrote: > could you point out why exactly there is "something to do"? > > I mean, python3000 is a new language and no replacement so if someone is > willing to package it (or a package that depends on py3k) she/he should > make sure its a python2.x compatible installation (especially in the > naming of the package). That should be all, right? Python 2.x *will* be discontinued at some time in the future. It may be a few years, but it will happen. -- 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 rodd at clarkson.id.au Tue Jun 3 04:34:13 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 03 Jun 2008 14:34:13 +1000 Subject: no updates? In-Reply-To: <20080601091445.e7fa8583.mschwendt@gmail.com> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> <1212275595.6925.42.camel@localhost.localdomain> <20080601091445.e7fa8583.mschwendt@gmail.com> Message-ID: <1212467653.19918.34.camel@localhost.localdomain> On Sun, 2008-06-01 at 09:14 +0200, Michael Schwendt wrote: > You can test for it by examining the cached metadata files below > /var/cache/yum/updates. Start with the timestamp on "cachecookie". Only if > old enough, Yum loads new metadata. [The default is 1800 seconds in > yum.conf's metadata_expire= value.] Compare timestamp of "repomd.xml" with > the mirror that is assigned to you (file "mirrorlist.txt". Recent Yum > versions ignore mirrors that offer repomd.xml files which are older than > what you've got in your cache. This way you can find mirrors which don't > sync daily. Right, so I see this: in repomd.xml In mirrorlist.txt # repo = updates-released-f9 arch = i386 country = AU http://mirror.optus.net/fedora/linux/updates/9/i386 http://ftp.iinet.net.au/pub/fedora/linux/updates/9/i386 http://mirror.3fl.net.au/pub/fedora/linux/updates/9/i386 http://mirror.internode.on.net/pub/fedora/linux/updates/9/i386 http://mirror.aarnet.edu.au/pub/fedora/linux/updates/9/i386 http://ringtail.its.monash.edu.au/pub/fedora/linux/updates/9/i386 I'm not seeing linux.duke.edu in here. Should I? R. > > -- > Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 > loadavg: 1.21 1.17 0.74 > -- "It's a fine line between denial and faith. It's much better on my side" From fedora at slated.org Tue Jun 3 05:28:31 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Tue, 03 Jun 2008 06:28:31 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <484482E0.2080108@fedoraproject.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> Message-ID: <4844D67F.7090307@slated.org> Verily I say unto thee, that Rahul Sundaram spake thusly: > You seem to misunderstand how OIN works. OIN doesn't need any patents > related to Mono. > > http://gregdek.livejournal.com/4008.html Ah, I get it now - "If you attack us, our OIN soldiers will attack you." That works if your resources can outlast your enemy's, or if your enemy is bluffing. Still, this seems like an odd basis upon which to make the deliberate and voluntary decision to wheel the enemy's Trojan Horse through the gates of the city. BTW, I've fully reviewed the archive now, and this is pretty much all the information I could find: 1. The decision to allow Mono to enter the tree seems to have been made arbitrarily by Red Hat, with no community consultation, and in spite of protests (including some by high profile Red Hat personnel - mostly expressed as a rejection of Mono before the announcement). 2. There has only ever been one public announcement on the subject, and that was made (with some dismay, it seems) by Tom Callaway: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00588.html 3. There has only ever been one, extremely reserved, explanation given for this decision, in a blog post by Greg DeKoenigsberg: "Business considerations that prevented certain Mono components from being included in Fedora previously have now been resolved." http://gregdek.livejournal.com/3597.html The specific nature of this resolution is not given. 4. There is precious little concrete information about precisely who made these arbitrary decisions that also affected the Fedora community distro, but as best as I can deduce, the key players seem to be Greg DeKoenigsberg (as above) and Christopher Blizzard, although it may be that these were simply the only people discussing it publicly: http://www.0xdeadbeef.com/weblog/?p=188 5. The nearest thing to an actual justification for this acceptance of Mono, is that the OIN offers a kind of Mexican Stand-Off protection to those who implement it: http://gregdek.livejournal.com/4008.html My final conclusion is that Fedora includes encumbered, non-Free software, that is covered by patents owned by Microsoft, and assured by a patent covenant that is not worth the (metaphorical) paper it's written on, since Moonlight, which is also covered by this same type of covenant by the same company, has recently been exposed by Groklaw as undistributable (I'm advised that PJ is currently investigating Mono as well). The announcement and justification for this inclusion is extremely sparse, and there has been almost no community consultation on the subject, either before or after the fact. I hope I don't seem judgmental, I'm just trying to establish the facts. OK, this really is my final post on the subject, and I apologise for being off-topic. If anyone still wishes to continue this off-topic conversation with me, please feel free to Email me at fedora[at]slated.org. Thanks. -- Regards, Keith G. Robertson-Turner From seg at haxxed.com Tue Jun 3 06:19:00 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 3 Jun 2008 01:19:00 -0500 Subject: About FESCo In-Reply-To: <4843EB97.3070602@nigelj.com> References: <20080602132543.7b8225ff@ludwig-alpha.unil.ch> <4843EB97.3070602@nigelj.com> Message-ID: <1218b5bc0806022319l4685aa8ep2a02dee44436d022@mail.gmail.com> On Mon, Jun 2, 2008 at 7:46 AM, Nigel Jones wrote: > An SIG can't draft every single policy isn't really practical, contributors > like ourselves elect members to FESCo (one our rights as a contributor) to > represent our views Meritocracy not democracy. We vote as a vote of confidence in the elected's judgment and leadership, it should not come with an expectation of representation. IMHO at any rate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Tue Jun 3 06:47:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 3 Jun 2008 01:47:02 -0500 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4844D67F.7090307@slated.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> Message-ID: <16de708d0806022347i5f23242ah6349c4478494e3ec@mail.gmail.com> On Tue, Jun 3, 2008 at 12:28 AM, Keith G. Robertson-Turner wrote: > 1. The decision to allow Mono to enter the tree seems to have been made > arbitrarily by Red Hat, with no community consultation, and in spite > of protests (including some by high profile Red Hat personnel - > mostly expressed as a rejection of Mono before the announcement). Is this true? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sundaram at fedoraproject.org Tue Jun 3 06:57:29 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jun 2008 12:27:29 +0530 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4844D67F.7090307@slated.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> Message-ID: <4844EB59.2020902@fedoraproject.org> Keith G. Robertson-Turner wrote: > 1. The decision to allow Mono to enter the tree seems to have been made > arbitrarily by Red Hat, with no community consultation, and in spite > of protests (including some by high profile Red Hat personnel - > mostly expressed as a rejection of Mono before the announcement). The complete risk is for Red Hat as the legal entity behind Fedora and the legal team has evaluated and taken the decisions they have. > My final conclusion is that Fedora includes encumbered, non-Free > software, that is covered by patents owned by Microsoft, and assured by > a patent covenant that is not worth the (metaphorical) paper it's > written on, since Moonlight, which is also covered by this same type of > covenant by the same company, has recently been exposed by Groklaw as > undistributable * Patent encumbered code is not the same as non-free code * There is no specific patents owned by Microsoft that you have listed * It is definitely not the same type of covenant. Rahul From rmy at tigress.co.uk Tue Jun 3 08:36:34 2008 From: rmy at tigress.co.uk (Ron Yorston) Date: Tue, 03 Jun 2008 09:36:34 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <1212407815.7710.69.camel@localhost.localdomain> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> Message-ID: <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> "Tom \"spot\" Callaway" wrote: >On Mon, 2008-06-02 at 03:28 +0100, Keith G. Robertson-Turner wrote: >> Why are you still shipping Mono? > >Apologies in advance, I cannot be overly specific about legal issues. >Red Hat (and I) are aware of your concerns around mono, and after >discussing this in depth with Red Hat Legal, we have no immediate plans >to remove mono from Fedora. Never mind the legal stuff, is there any technical reason for having Mono in the core distribution? (Or in the distribution at all.) One of the first things I do after installing Fedora is remove mono-core and its dependencies. A tiny number of applications depend on Mono, none of which I miss. I'm sure they could easily be replaced with non-Mono equivalents for those who do find them useful. With Java itself now Free Software why bother with Mono? Ron From A.J.Delaney at brighton.ac.uk Mon Jun 2 18:36:05 2008 From: A.J.Delaney at brighton.ac.uk (A.J.Delaney at brighton.ac.uk) Date: Mon, 02 Jun 2008 19:36:05 +0100 Subject: Fedora 9 Cell processor packages Message-ID: <1212431765.3687.5.camel@ScaryMonster> I?m building a toolchain for the Cell processor. This is the processor found in the PS3 and IBM blade servers. Others have built the toolchain before notably IBM, the Barcelona Supercomputing group and YellowDog Linux. However, these sets of packages do not move at the speed that Fedora does. They are currently GCC 4.1 based whereas Fedora 9 includes GCC 4.3. Furthermore, the other implementations of a Cell toolchain do not include the Fedora patches to GCC and binutils. Thus my packages are closer to the Fedora packages than the IBM ones. This makes maintenance and debugging easier from the system integrators point of view (i.e. my point of view). This toolchain is also part of my evil plan to replace Mesa on the Cell architecture with Gallium3d. Gallium3d is an implementation of OpenGL (amongst other things) using the Cell SPUs. This will allow developers to develop OpenGL applications on PS3 Linux. In order to do this I need to build the following packages * binutils for the SPU (http://foss.it.brighton.ac.uk/~balor/rpm/binutils-spu-2.18.50.0.6-1.src.rpm), * gcc for the SPU, * libspe2 in order to control the SPUs (http://foss.it.brighton.ac.uk/~balor/rpm/libspe2-2.2.80-121.src.rpm), * newlib for the SPU, and * gallium3d using the toolchain developed in the previous packages. My libspe2 package is based on the IBM package but recompiled for Fedora 9, the binutils package is based on the binutils in Fedora 9. Both of these packages are complete. I?m currently arguing with GCC. Then I?ll tackle newlib (a much easier issue) and then Gallium3d. I want to get these packages into F10. I believe that posting them to this list is the first step as mentioned on https://fedoraproject.org/wiki/PackageMaintainers If this is not the correct protocol, could you kindly point me in the right direction. -- Aidan Delaney From mschwendt at gmail.com Tue Jun 3 09:05:42 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 3 Jun 2008 11:05:42 +0200 Subject: no updates? In-Reply-To: <1212467653.19918.34.camel@localhost.localdomain> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> <1212275595.6925.42.camel@localhost.localdomain> <20080601091445.e7fa8583.mschwendt@gmail.com> <1212467653.19918.34.camel@localhost.localdomain> Message-ID: <20080603110542.238387e6.mschwendt@gmail.com> On Tue, 03 Jun 2008 14:34:13 +1000, Rodd Clarkson wrote: > On Sun, 2008-06-01 at 09:14 +0200, Michael Schwendt wrote: > > > You can test for it by examining the cached metadata files below > > /var/cache/yum/updates. Start with the timestamp on "cachecookie". Only if > > old enough, Yum loads new metadata. [The default is 1800 seconds in > > yum.conf's metadata_expire= value.] Compare timestamp of "repomd.xml" with > > the mirror that is assigned to you (file "mirrorlist.txt". Recent Yum > > versions ignore mirrors that offer repomd.xml files which are older than > > what you've got in your cache. This way you can find mirrors which don't > > sync daily. > > Right, so I see this: > > in repomd.xml > > > > > In mirrorlist.txt > > # repo = updates-released-f9 arch = i386 country = AU > http://mirror.optus.net/fedora/linux/updates/9/i386 > http://ftp.iinet.net.au/pub/fedora/linux/updates/9/i386 > http://mirror.3fl.net.au/pub/fedora/linux/updates/9/i386 > http://mirror.internode.on.net/pub/fedora/linux/updates/9/i386 > http://mirror.aarnet.edu.au/pub/fedora/linux/updates/9/i386 > http://ringtail.its.monash.edu.au/pub/fedora/linux/updates/9/i386 > > I'm not seeing linux.duke.edu in here. Should I? No, because it's only an XML namespace parameter in the repomd.xml header pointing to the DTD file. Every repomd.xml file contains it at the beginning. From guido.ledermann at googlemail.com Tue Jun 3 09:26:53 2008 From: guido.ledermann at googlemail.com (Guido Ledermann) Date: Tue, 3 Jun 2008 11:26:53 +0200 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> Message-ID: <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> 2008/6/3 Ron Yorston : > With Java itself now Free Software why bother with Mono? Because there is already a very nice collection of free software available if you think of f-spot, banshee aso. So why do I, as a user, have to choose between Java and Mono if there is not the same software available for both sub-platforms? I use Mono because I develop in C# to write programs for multiple OS. I'm sure we'll see more and more Mono programs in the future that will follow that approach. If we are over legal issues, and I think we are, Mono should stay in Fedora. Guido From rawhide at fedoraproject.org Tue Jun 3 09:32:28 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 3 Jun 2008 09:32:28 +0000 (UTC) Subject: rawhide report: 20080603 changes Message-ID: <20080603093228.72F39209CD9@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080602/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080603/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package ca-certificates The Mozilla CA root certificate bundle New package cpufrequtils CPU Frequency changing related utilities New package emma Code Coverage Tool New package gnome-hearts Hearts game for GNOME New package nautilus-sound-converter Nautilus extension to convert audio files New package perl-DBIx-Class Extensible and flexible object <-> relational mapper Removed package cpufreq-utils Removed package nautilus-flac-converter Updated Packages: alliance-5.0-16.20070718snap.fc10 --------------------------------- * Fri May 30 18:00:00 2008 Chitlesh Goorah - 5.0-16.20070718snap - Bugfix /etc/profile.d/alc_env.csh problem #449062 #448480 anacron-2.3-61.fc10 ------------------- * Wed May 28 18:00:00 2008 Marcela Maslanova 2.3-61 - cleaning lots of scripts in anacron & crontabs * Wed Apr 9 18:00:00 2008 Marcela Maslanova 2.3-60 - correct spooldir logged checkpolicy-2.0.16-2.fc10 ------------------------- * Wed May 28 18:00:00 2008 Tom "spot" Callaway 2.0.16-2 - fix license tag * Wed May 28 18:00:00 2008 Dan Walsh - 2.0.16-1 - Latest update from NSA * Update checkpolicy for user and role mapping support from Joshua Brindle. cronie-1.1-1.fc10 ----------------- * Wed May 28 18:00:00 2008 Marcela Maslanova - 1.1-1 - release 1.1 crontabs-1.10-22.fc10 --------------------- * Wed May 28 18:00:00 2008 Marcela Maslanova 1.10-22 - remove scripts for delay, anacron now own most of the scripts. Crontabs owns only run-parts, /etc/crontab and crontabs sysconfig. empathy-0.23.3-1.fc10 --------------------- * Mon Jun 2 18:00:00 2008 Brian Pepple - 0.23.3-1 - Update to 0.23.3. - Remove reference to stream-engine in connections managers readme. evolution-2.23.3.1-1.fc10 ------------------------- * Mon Jun 2 18:00:00 2008 Matthew Barnes - 2.23.3.1-1.fc10 - Update to 2.23.3.1 - Bump eds_version to 2.23.3. evolution-data-server-2.23.3-1.fc10 ----------------------------------- * Mon Jun 2 18:00:00 2008 Matthew Barnes - 3.23.3-1.fc10 - Update to 2.23.3 - Remove patch for GNOME bug #531439 (fixed upstream). evolution-exchange-2.23.3-1.fc10 -------------------------------- * Mon Jun 2 18:00:00 2008 Matthew Barnes - 2.23.3-1.fc10 - Update to 2.23.3 evolution-sharp-0.17.3-1.fc10 ----------------------------- * Mon Jun 2 18:00:00 2008 Matthew Barnes - 0.17.3-1.fc10 - Update to 0.17.3. gammu-1.19.0-2.fc9 ------------------ * Mon Jun 2 18:00:00 2008 Xavier Lamien - 1.19.0-2 - Added Require dialog. * Tue Apr 15 18:00:00 2008 Xavier Lamien - 1.19.0-1 - Updated Release. gengetopt-2.22.1-1.fc10 ----------------------- * Mon Jun 2 18:00:00 2008 Debarshi Ray - 2.22.1-1 - Version bump to 2.22.1. Closes Red Hat Bugzilla bug #444335. - Parallel build problems fixed by upstream. ghdl-0.26-0.98svn.0.fc10 ------------------------ * Mon Jun 2 18:00:00 2008 Thomas Sailer - 0.26-0.98svn.0 - update to svn98 gnome-commander-1.2.6-2.fc10 ---------------------------- * Mon Jun 2 18:00:00 2008 Mamoru Tasaka - 1.2.6-2 - 1.2.6 - Add patch to compile with GTK 2.13.X gstreamer-0.10.19-3.fc10 ------------------------ * Mon Jun 2 18:00:00 2008 - Bastien Nocera - 0.10.19-3 - Package more documentation (#240656) * Wed May 21 18:00:00 2008 - Tom "spot" Callaway - 0.10.19-2 - fix license tag gstreamer-plugins-base-0.10.19-5.fc10 ------------------------------------- * Mon Jun 2 18:00:00 2008 - Bastien Nocera - 0.10.19-5 - Let the package build its own documentation gtkglext-1.2.0-7.fc10 --------------------- * Tue Jun 3 18:00:00 2008 Ralf Cors??pius - 1.2.0-7 - Use 0%{?fedora} conditionals instead of "%{fedora}" (BZ 449635). gtkhtml3-3.23.3-1.fc10 ---------------------- * Mon Jun 2 18:00:00 2008 Matthew Barnes - 3.23.3-1.fc10 - Update to 3.23.3 - Remove patch for GNOME bug #524338 (fixed upstream). guilt-0.30-1.fc9 ---------------- gv-3.6.4-1.fc10 --------------- * Mon Jun 2 18:00:00 2008 Orion Poplawski 3.6.4-1 - Update to 3.6.4 - Cleanup desktop file a little hwdata-0.219-1.fc10 ------------------- * Mon Jun 2 18:00:00 2008 Karsten Hopp 0.219-1 - update pci.ids, usb.ids, oui.txt - blacklist snd-pcsp (#448425) ikarus-0.0.3-1.fc10 ------------------- * Mon Jun 2 18:00:00 2008 Michel Salim - 0.0.3-1 - Update to 0.0.3 jed-0.99.18-8.fc10 ------------------ * Mon Jun 2 18:00:00 2008 Bill Nottingham - 0.99.18-8 - fix for new autoconf (#449580) junitperf-1.9.1-2jpp.1.fc10 --------------------------- kernel-2.6.26-0.46.rc4.git2.fc10 -------------------------------- * Mon Jun 2 18:00:00 2008 John W. Linville - Revert misguided wireless.h "fix" from upstream libgphoto2-2.4.1-1.fc10 ----------------------- * Mon Jun 2 18:00:00 2008 Jindrich Novy 2.4.1-1 - update to 2.4.1 (#443515, #436138) lirc-0.8.3-3.fc10 ----------------- * Mon Jun 2 18:00:00 2008 Jarod Wilson - 0.8.3-3 - Add additional required patches for gnome-lirc-properties (#442248) - Put remote definitions in their own sub-package (#442328) * Mon May 12 18:00:00 2008 Jarod Wilson - 0.8.3-2 - Include upstream patch for lircd.conf remote include directives (#442248) - Include upstream patch to validate transmit buffers man-1.6f-7.fc10 --------------- * Mon Jun 2 18:00:00 2008 Ivana Varekova - 1.6f-7 - Resolves: #448049 Error messages will exhibit when quit from mount man page mutt-1.5.18-2.fc10 ------------------ * Mon Jun 2 18:00:00 2008 Miroslav Lichvar 5:1.5.18-2 - allow interrupts when reading, writing or closing sockets (#447887) - fix possible crash when opening IMAP mailbox neon-0.28.2-3 ------------- * Mon Jun 2 18:00:00 2008 Joe Orton 0.28.2-3 - require ca-certificates package nspr-4.7.1-2.fc10 ----------------- * Mon Jun 2 18:00:00 2008 Kai Engert - 4.7.1-2 - Update to 4.7.1 nss-3.12.0.3-2.fc10 ------------------- * Mon Jun 2 18:00:00 2008 Kai Engert - 3.12.0.3-2 - Update to NSS_3_12_RC4 * Mon Apr 14 18:00:00 2008 Kai Engert - 3.12.0.1-1 - Update to NSS_3_12_RC2 ocaml-SDL-0.7.2-13.fc10 ----------------------- * Mon Jun 2 18:00:00 2008 Richard W.M. Jones - 0.7.2-13 - labgl -> ocaml-lablgl-devel perl-Log-Dispatch-FileRotate-1.16-3.fc10 ---------------------------------------- * Tue Jun 3 18:00:00 2008 Ralf Cors??pius - 1.16-3 - Use %%check in comments to work-around rpm bogusly parsing %check in comments (BZ 449419). perl-Net-Server-0.97-3.fc10 --------------------------- * Tue Jun 2 18:00:00 2009 Nicolas Mailhot - 0.97-3 ??? remove old %check Dag leftover rpmbuild does not like anymore perl-Params-Util-0.33-1.fc10 ---------------------------- * Mon Jun 2 18:00:00 2008 Ralf Cors??pius - 0.33-1 - Upstream update. - Conditionally BR: perl(Test::CPAN::Meta). - Hack testsuite to accept Test::CPAN::Meta != 0.07. perl-Test-Inline-2.208-3.fc10 ----------------------------- * Mon Jun 2 18:00:00 2008 Ralf Cors??pius - 2.208-3 - BR: perl(List::Utils) >= 1.19 perl-Time-modules-2006.0814-3.fc10 ---------------------------------- * Sat May 31 18:00:00 2008 Xavier Bachelot 2006.0814-3 - Remove '|| :' from %check perl-XML-XPath-1.13-7.fc10 -------------------------- * Mon Jun 2 18:00:00 2008 Marcela Maslanova - 1.13-7 - rebuild and remove ||: from check part python-toscawidgets-0.9.1-1.fc10 -------------------------------- * Mon Jun 2 18:00:00 2008 Luke Macken - 0.9.1-1 - Update to latest release - Remove python-paste-script, python-ruledispatch, python-decorator and python-decoratortools dependencies. python-xlrd-0.6.1-6.fc10 ------------------------ * Mon Jun 2 18:00:00 2008 Jan ONDREJ (SAL) - 0.6.1-5 - removed "" for fedora macro qof-0.7.5-3.fc10 ---------------- * Mon Jun 2 18:00:00 2008 Jon Ciesla - 0.7.5-3 - Fix %check FTBTS error. Bug promised, not yet filed. ricci-0.13.0-4.fc10 ------------------- * Mon Jun 2 18:00:00 2008 Ryan McCabe 0.13.0-4 - No longer need -lgroup with the new cman packages. selinux-policy-3.4.1-1.fc10 --------------------------- * Fri May 9 18:00:00 2008 Dan Walsh 3.4.1-1 - Merge Upstream * Wed May 7 18:00:00 2008 Dan Walsh 3.3.1-48 - Allow amanada to create data files * Wed May 7 18:00:00 2008 Dan Walsh 3.3.1-47 - Fix initial install, semanage setup * Tue May 6 18:00:00 2008 Dan Walsh 3.3.1-46 - Allow system_r for httpd_unconfined_script_t smb4k-0.9.5-1.fc10 ------------------ * Mon Jun 2 18:00:00 2008 Marcin Garski 0.9.5-1 - Update to 0.9.5 synergy-1.3.1-9.fc10 -------------------- * Mon Jun 2 18:00:00 2008 Hans de Goede 1.3.1-9 - Drop no longer needed patch0, stop regenerating autoxxx files - Apply the following bug fixes from upstream's bug tracker: -off by one bugfix to X11 selection (fixes copy and paste by selection) -call DPMSOn() when entering screen to make sure powersaving mode is canceled on X11 client systems when the fake mouse / keyb become active - Add manpages (courtesy of Debian) * Mon Jun 2 18:00:00 2008 Hans de Goede 1.3.1-8 - Fix synergy crashing on copy and paste (bz 434539) tcpdump-3.9.8-5.fc10 -------------------- * Mon Jun 2 18:00:00 2008 Miroslav Lichvar - 14:3.9.8-5 - update config.{guess,sub} when building tcpslice - remove -D_GNU_SOURCE from CFLAGS - disable libsmi check in configure texinfo-4.12-3.fc10 ------------------- * Mon Jun 2 18:00:00 2008 Vitezslav Crhonek - 4.12-3 - Fix install-info crashes on some info files Resolves: #449292 xgrep-0.07-1.fc10 ----------------- * Mon Jun 2 18:00:00 2008 Brendt Wohlberg - 0.07-1 - Fixed bugzilla bug 447719 Summary: Added Packages: 6 Removed Packages: 2 Modified Packages: 49 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From rms at 1407.org Tue Jun 3 09:52:01 2008 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 3 Jun 2008 10:52:01 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> Message-ID: <20080603095201.GA6254@roque.1407.org> On Tue, Jun 03, 2008 at 11:26:53AM +0200, Guido Ledermann wrote: > 2008/6/3 Ron Yorston : > > With Java itself now Free Software why bother with Mono? > > Because there is already a very nice collection of free software > available if you think of f-spot, banshee aso. So why do I, as a user, > have to choose between Java and Mono if there is not the same software > available for both sub-platforms? erms... you don't have to choose between Java or Mono. Even though I prefer GNOME, digiKam is far superior to f-spot, banshee always seemed, to me, like a cpu hog, TomBoy looks like a wiki but is disappointing, in comparison. Rui -- Or not. Today is Prickle-Prickle, the 8th day of Confusion in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From guido.ledermann at googlemail.com Tue Jun 3 10:16:26 2008 From: guido.ledermann at googlemail.com (Guido Ledermann) Date: Tue, 3 Jun 2008 12:16:26 +0200 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080603095201.GA6254@roque.1407.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> <20080603095201.GA6254@roque.1407.org> Message-ID: <4ee84c5f0806030316h40efd408tcbd929cd1cae5658@mail.gmail.com> 2008/6/3 Rui Miguel Silva Seabra : > On Tue, Jun 03, 2008 at 11:26:53AM +0200, Guido Ledermann wrote: >> 2008/6/3 Ron Yorston : >> > With Java itself now Free Software why bother with Mono? >> >> Because there is already a very nice collection of free software >> available if you think of f-spot, banshee aso. So why do I, as a user, >> have to choose between Java and Mono if there is not the same software >> available for both sub-platforms? > > erms... you don't have to choose between Java or Mono. Even though I But that's what I would have to if there is no Mono in Fedora. > prefer GNOME, digiKam is far superior to f-spot, banshee always seemed, > to me, like a cpu hog, TomBoy looks like a wiki but is disappointing, in > comparison. Rui, no offense, but did you read what this thread is about? We are not talking about how good programs are or if we like or use them or not. From rjones at redhat.com Tue Jun 3 10:20:26 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 3 Jun 2008 11:20:26 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> Message-ID: <20080603102026.GA13455@amd.home.annexia.org> On Tue, Jun 03, 2008 at 09:36:34AM +0100, Ron Yorston wrote: > "Tom \"spot\" Callaway" wrote: > >On Mon, 2008-06-02 at 03:28 +0100, Keith G. Robertson-Turner wrote: > >> Why are you still shipping Mono? > > > >Apologies in advance, I cannot be overly specific about legal issues. > >Red Hat (and I) are aware of your concerns around mono, and after > >discussing this in depth with Red Hat Legal, we have no immediate plans > >to remove mono from Fedora. > > Never mind the legal stuff, is there any technical reason for having > Mono in the core distribution? (Or in the distribution at all.) [...] In the distribution at all to give people choice. You could make the same argument for other minority languages or applications, OCaml for instance. Maybe we should remove any amateur radio software or electronic CAD or 2D games or support for Norwegian language users. All of those are minorities. As long as there is someone willing to support a package and there are no legal or packaging problems, we should have it in. One thing that Debian has is a huge range of very obscure packages. > With Java itself now Free Software why bother with Mono? .Net/CLR potentially has better support for functional programming, although unfortunately there are no mainstream free languages out there which exploit this (see my signature however). There are also various fairly minor but technically useful improvements in the bytecode, eg. Java has an annoying limit on the size of methods and doesn't allow you to jump between methods (meaning that tail-call optimization can't be done in many useful cases). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From loupgaroublond at gmail.com Tue Jun 3 11:02:19 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 3 Jun 2008 13:02:19 +0200 Subject: On-the-side repos (Was: Let's make a plan for python3.0 in Fedora 10+) In-Reply-To: <1212427733.3437.15.camel@localhost.localdomain> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> <1212421487.3437.9.camel@localhost.localdomain> <1212427733.3437.15.camel@localhost.localdomain> Message-ID: <7f692fec0806030402l295631efqe6e2aeaef40fc2b9@mail.gmail.com> 2008/6/2 Jesse Keating : > On Mon, 2008-06-02 at 12:18 -0500, Jason L Tibbitts III wrote: >> >> Is there any possibility of being able to do this on a more regular >> basis for other destabilizing updates? There was an IRC discussion >> recently calling for something more experimental than rawhide, which I >> don't really think would be productive, but it still might be nice to >> have a relatively easy way to handle the situation where a maintainer >> knows they're going to do something destabilizing. > > Sounds like a job for Kopers. > https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos > > Now all it needs is somebody with enough time to code it up. This looks like a job for an intern. Oh wait.... Well, mike asked me to look at koji anyways. Let me give it a shot. -Yaakov From jamatos at fc.up.pt Tue Jun 3 11:23:05 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 3 Jun 2008 12:23:05 +0100 Subject: Successfully upgraded to F9 while keeping KDE 3 In-Reply-To: <4843BE98.6060905@robertoragusa.it> References: <484323CD.1080308@robertoragusa.it> <200806020818.37534.jamatos@fc.up.pt> <4843BE98.6060905@robertoragusa.it> Message-ID: <200806031223.05791.jamatos@fc.up.pt> On Monday 02 June 2008 10:34:16 Roberto Ragusa wrote: > Jos? Matos wrote: > > On Sunday 01 June 2008 23:33:49 Roberto Ragusa wrote: > >> PIL-1.1.6-8.fc9.i386.rpm > > > > python-imaging is in Fedora. Why do you need this packaged differently? > > The auto deps resolution didn't notice that, just complained that > we need PIL, which needs tck8.4 and tcl8.4. > Indeed, I had almost finished packaging tk/tcl 8.4 when I discovered > the PIL rpm in atrpms. > > I've just tried to remove PIL (atrpms) and install python-imaging (f9). > It is not OK, because mytharchive (atrpms) requires PIL. > Mytharchive could be fixed or maybe python-imaging could provide PIL. > > Added Cc to Axel Thimm. > > Best regards. I have no problems with providing PIL = %{version}-%{release} in the python-imaging spec file. > [root at thinkpad RPMS.everything]# rpm -e PIL > error: Failed dependencies: > python-imaging is needed by (installed) > skencil-0.6.17-18.20070606svn.fc9.i386 python-imaging is needed by > (installed) scribus-1.3.4-5.fc9.i386 python-imaging is needed by > (installed) hplip-2.8.2-2.fc9.i386 PIL is needed by (installed) > mytharchive-0.21-189.fc9.i386 [root at thinkpad RPMS.everything]# rpm -e > --nodeps PIL > [root at thinkpad RPMS.everything]# rpm -ihv > python-imaging-1.1.6-9.fc9.i386.rpm Preparing... > ########################################### [100%] 1:python-imaging > ########################################### [100%] [root at thinkpad > RPMS.everything]# rpm -e python-imaging > error: Failed dependencies: > python-imaging is needed by (installed) > skencil-0.6.17-18.20070606svn.fc9.i386 python-imaging is needed by > (installed) scribus-1.3.4-5.fc9.i386 python-imaging is needed by > (installed) hplip-2.8.2-2.fc9.i386 > > -- > Roberto Ragusa mail at robertoragusa.it -- Jos? Ab?lio From jwboyer at gmail.com Tue Jun 3 12:16:16 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Jun 2008 07:16:16 -0500 Subject: Fedora 9 Cell processor packages In-Reply-To: <1212431765.3687.5.camel@ScaryMonster> References: <1212431765.3687.5.camel@ScaryMonster> Message-ID: <20080603071616.53ea8b88@vader.jdub.homelinux.org> On Mon, 02 Jun 2008 19:36:05 +0100 A.J.Delaney at brighton.ac.uk wrote: > * libspe2 in order to control the SPUs > (http://foss.it.brighton.ac.uk/~balor/rpm/libspe2-2.2.80-121.src.rpm), libspe2 is currently under review already: https://bugzilla.redhat.com/show_bug.cgi?id=442507 josh From hughsient at gmail.com Tue Jun 3 12:59:40 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 03 Jun 2008 13:59:40 +0100 Subject: rawhide report: 20080603 changes In-Reply-To: <20080603093228.72F39209CD9@releng1.fedora.phx.redhat.com> References: <20080603093228.72F39209CD9@releng1.fedora.phx.redhat.com> Message-ID: <1212497980.3439.10.camel@hughsie-work> On Tue, 2008-06-03 at 09:32 +0000, Rawhide wrote: > New package ca-certificates > The Mozilla CA root certificate bundle Test Transaction Errors: file /etc/pki/tls/certs/ca-bundle.crt from install of ca-certificates-2008-5.noarch conflicts with file from package openssl-0.9.8g-9.fc10.i686 Richard. From jorton at redhat.com Tue Jun 3 13:11:55 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 3 Jun 2008 14:11:55 +0100 Subject: rawhide report: 20080603 changes In-Reply-To: <1212497980.3439.10.camel@hughsie-work> References: <20080603093228.72F39209CD9@releng1.fedora.phx.redhat.com> <1212497980.3439.10.camel@hughsie-work> Message-ID: <20080603131155.GA11263@redhat.com> On Tue, Jun 03, 2008 at 01:59:40PM +0100, Richard Hughes wrote: > On Tue, 2008-06-03 at 09:32 +0000, Rawhide wrote: > > New package ca-certificates > > The Mozilla CA root certificate bundle > > Test Transaction Errors: file /etc/pki/tls/certs/ca-bundle.crt from > install of ca-certificates-2008-5.noarch conflicts with file from > package openssl-0.9.8g-9.fc10.i686 Tomas has fixed this already, the rebuilds yesterday were failing due to a bash problem. Working build here: http://koji.fedoraproject.org/koji/buildinfo?buildID=51331 joe From jkeating at redhat.com Tue Jun 3 13:28:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Jun 2008 09:28:41 -0400 Subject: On-the-side repos (Was: Let's make a plan for python3.0 in Fedora 10+) In-Reply-To: <7f692fec0806030402l295631efqe6e2aeaef40fc2b9@mail.gmail.com> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> <1212421487.3437.9.camel@localhost.localdomain> <1212427733.3437.15.camel@localhost.localdomain> <7f692fec0806030402l295631efqe6e2aeaef40fc2b9@mail.gmail.com> Message-ID: <1212499721.19568.8.camel@localhost.localdomain> On Tue, 2008-06-03 at 13:02 +0200, Yaakov Nemoy wrote: > > Sounds like a job for Kopers. > > https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos > > > > Now all it needs is somebody with enough time to code it up. > > This looks like a job for an intern. Oh wait.... > > Well, mike asked me to look at koji anyways. Let me give it a shot. Awesome! I was going to have Casey look at it eventually to as spot and I get to share his intern powers. But if you have time before he does, by all means have at it. I have plenty of other tasks for Casey to look into. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From loupgaroublond at gmail.com Tue Jun 3 13:33:55 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 3 Jun 2008 15:33:55 +0200 Subject: On-the-side repos (Was: Let's make a plan for python3.0 in Fedora 10+) In-Reply-To: <1212499721.19568.8.camel@localhost.localdomain> References: <483F7FDA.9000701@gmail.com> <48431648.9050205@redhat.com> <1212417942.14461.25.camel@code.and.org> <48440A0B.6090907@redhat.com> <1212421487.3437.9.camel@localhost.localdomain> <1212427733.3437.15.camel@localhost.localdomain> <7f692fec0806030402l295631efqe6e2aeaef40fc2b9@mail.gmail.com> <1212499721.19568.8.camel@localhost.localdomain> Message-ID: <7f692fec0806030633h150f0f08kce57e6862634e292@mail.gmail.com> 2008/6/3 Jesse Keating : > On Tue, 2008-06-03 at 13:02 +0200, Yaakov Nemoy wrote: >> > Sounds like a job for Kopers. >> > https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos >> > >> > Now all it needs is somebody with enough time to code it up. >> >> This looks like a job for an intern. Oh wait.... >> >> Well, mike asked me to look at koji anyways. Let me give it a shot. > > Awesome! I was going to have Casey look at it eventually to as spot and > I get to share his intern powers. But if you have time before he does, > by all means have at it. I have plenty of other tasks for Casey to look > into. I've actually hit one speedbump though. postgresql is being a pain to setup. But I'm trying to get a local setup of koji setup, and a friend has offered to donate some hardware for a while. -Yaakov From linville at redhat.com Tue Jun 3 13:47:25 2008 From: linville at redhat.com (John W. Linville) Date: Tue, 3 Jun 2008 09:47:25 -0400 Subject: Kernel headers changes in F10? In-Reply-To: <484431A3.6010706@hhs.nl> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> <20080602172853.GB27063@redhat.com> <484431A3.6010706@hhs.nl> Message-ID: <20080603134725.GA12485@redhat.com> On Mon, Jun 02, 2008 at 07:45:07PM +0200, Hans de Goede wrote: > John W. Linville wrote: > >On Mon, Jun 02, 2008 at 07:13:27PM +0200, Hans de Goede wrote: > >>John W. Linville wrote: > >>>Almost certainly because of this commit: > >>> > >>>commit 2218228392080f0ca2fc2974604e79f57b12c436 > >>>Author: Kirill A. Shutemov > >>>Date: Tue Apr 22 16:38:55 2008 +0300 > >>> > >>> Make linux/wireless.h be able to compile > >>> > >>> Signed-off-by: Kirill A. Shutemov > >>> Signed-off-by: John W. Linville > >>> > >>>I may have let this slip by due to the "able to compile" bit -- > >>>should I not have merged it? I don't have a record or recollection > >>>of what motivated the patch originally. > >As I said, I have no record or memory of why this patch was needed. > >It looks like it was a mistake for me to let it though in the first > >place. My guess is that he wanted to include linux/wireless.h from > >userland without including other kernel headers...? > > Looks like a good candidate for reverting. I see little arguments to keep > this patch in, it will probably break compilation of other users of > linux/wireless.h too, as those probably also already include to > get the necessary stuff from there. I have reverted that patch in rawhide, and I'm working with Kirill for a more permanent solution. Thanks, John -- John W. Linville linville at redhat.com From hughsient at gmail.com Tue Jun 3 13:47:39 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 03 Jun 2008 14:47:39 +0100 Subject: rawhide report: 20080603 changes In-Reply-To: <20080603131155.GA11263@redhat.com> References: <20080603093228.72F39209CD9@releng1.fedora.phx.redhat.com> <1212497980.3439.10.camel@hughsie-work> <20080603131155.GA11263@redhat.com> Message-ID: <1212500859.3439.11.camel@hughsie-work> On Tue, 2008-06-03 at 14:11 +0100, Joe Orton wrote: > On Tue, Jun 03, 2008 at 01:59:40PM +0100, Richard Hughes wrote: > > On Tue, 2008-06-03 at 09:32 +0000, Rawhide wrote: > > > New package ca-certificates > > > The Mozilla CA root certificate bundle > > > > Test Transaction Errors: file /etc/pki/tls/certs/ca-bundle.crt from > > install of ca-certificates-2008-5.noarch conflicts with file from > > package openssl-0.9.8g-9.fc10.i686 > > Tomas has fixed this already, the rebuilds yesterday were failing due to > a bash problem. Working build here: Legend, thanks. Richard. From bkoz at redhat.com Tue Jun 3 14:29:34 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Tue, 3 Jun 2008 09:29:34 -0500 Subject: Fedora 9 Cell processor packages In-Reply-To: <1212431765.3687.5.camel@ScaryMonster> References: <1212431765.3687.5.camel@ScaryMonster> Message-ID: <20080603092934.5cb175e7@balbo.artheist.org> > * binutils for the SPU > (http://foss.it.brighton.ac.uk/~balor/rpm/binutils-spu-2.18.50.0.6-1.src.rpm), > * gcc for the SPU, > * libspe2 in order to control the SPUs > (http://foss.it.brighton.ac.uk/~balor/rpm/libspe2-2.2.80-121.src.rpm), > * newlib for the SPU, and > * gallium3d using the toolchain developed in the previous > packages. > > My libspe2 package is based on the IBM package but recompiled for > Fedora 9, the binutils package is based on the binutils in Fedora 9. > Both of these packages are complete. I?m currently arguing with GCC. What are the details of this argument? I thought that 4.3.x natively supported cell/SPU. What problems are you running into? Perhaps an additional item or place to start on this might be a cross-compilation package for x86 to SPU. -benjamin From pasik at iki.fi Tue Jun 3 14:04:50 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Tue, 3 Jun 2008 17:04:50 +0300 Subject: Fedora 9 Cell processor packages In-Reply-To: <1212431765.3687.5.camel@ScaryMonster> References: <1212431765.3687.5.camel@ScaryMonster> Message-ID: <20080603140450.GW8042@edu.joroinen.fi> On Mon, Jun 02, 2008 at 07:36:05PM +0100, A.J.Delaney at brighton.ac.uk wrote: > I???m building a toolchain for the Cell processor. This is the processor > found in the PS3 and IBM blade servers. Others have built the toolchain > before notably IBM, the Barcelona Supercomputing group and YellowDog > Linux. However, these sets of packages do not move at the speed that > Fedora does. They are currently GCC 4.1 based whereas Fedora 9 includes > GCC 4.3. Furthermore, the other implementations of a Cell toolchain do > not include the Fedora patches to GCC and binutils. Thus my packages are > closer to the Fedora packages than the IBM ones. This makes maintenance > and debugging easier from the system integrators point of view (i.e. my > point of view). > > This toolchain is also part of my evil plan to replace Mesa on the Cell > architecture with Gallium3d. Gallium3d is an implementation of OpenGL > (amongst other things) using the Cell SPUs. This will allow developers > to develop OpenGL applications on PS3 Linux. > I'm not sure if Gallium3d is "replacing" Mesa.. >From http://www.mesa3d.org/ "Gallium3D is the codename for the new Mesa device driver architecture which is currently under development." http://www.tungstengraphics.com/wiki/index.php/Gallium3D "Gallium3D is Tungsten Graphics' new architecture for building 3D graphics drivers. Initially supporting Mesa and Linux graphics drivers, Gallium3D is designed to allow portability to all major operating systems and graphics interfaces. " So if I understood everything correctly you still use Mesa (as a OpenGL library) but behind the scenes Mesa is using Gallium3d drivers.. -- Pasi From rms at 1407.org Tue Jun 3 14:58:26 2008 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 3 Jun 2008 15:58:26 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4ee84c5f0806030316h40efd408tcbd929cd1cae5658@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> <20080603095201.GA6254@roque.1407.org> <4ee84c5f0806030316h40efd408tcbd929cd1cae5658@mail.gmail.com> Message-ID: <20080603145826.GA12274@roque.1407.org> On Tue, Jun 03, 2008 at 12:16:26PM +0200, Guido Ledermann wrote: > 2008/6/3 Rui Miguel Silva Seabra : > > On Tue, Jun 03, 2008 at 11:26:53AM +0200, Guido Ledermann wrote: > >> 2008/6/3 Ron Yorston : > >> > With Java itself now Free Software why bother with Mono? > >> > >> Because there is already a very nice collection of free software > >> available if you think of f-spot, banshee aso. So why do I, as a user, > >> have to choose between Java and Mono if there is not the same software > >> available for both sub-platforms? > > > > erms... you don't have to choose between Java or Mono. Even though I > > But that's what I would have to if there is no Mono in Fedora. What, Fedora does bring Perl, Python, PHP, the GNU Compiler Collection (which, BTW, also compiles Java), etc... not to mention all those esoteric programming languages you can install. No way you would be so limited... ;) > > prefer GNOME, digiKam is far superior to f-spot, banshee always seemed, > > to me, like a cpu hog, TomBoy looks like a wiki but is disappointing, in > > comparison. > Rui, no offense, but did you read what this thread is about? We are > not talking about how good programs are or if we like or use them or > not. Yes, I did, no offense taken of course. My point is precisely that there are *better* alternatives (both in the sense of Freedom and technical). Rui -- Hail Eris, Hack GNU/Linux! Today is Prickle-Prickle, the 8th day of Confusion in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From mlichvar at redhat.com Tue Jun 3 15:41:11 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 3 Jun 2008 17:41:11 +0200 Subject: rpmreaper Message-ID: <20080603154111.GA24155@localhost> Hi, I've put together a small ncurses application for removing unnecessary packages and their dependencies from the system. In a mutt-like interface it allows to browse through dependencies, select packages and run rpm -e on them. For those who don't want to start under root some random stuff downloaded from internet, it can be used under a regular user too. On exit, when asked to not try to run rpm -e, it will write to stdout the list of selected packages. Available here: http://mlichvar.fedorapeople.org/rpmreaper/ Review request filed here: https://bugzilla.redhat.com/show_bug.cgi?id=449784 -- Miroslav Lichvar From skvidal at fedoraproject.org Tue Jun 3 15:51:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Jun 2008 11:51:09 -0400 Subject: rpmreaper In-Reply-To: <20080603154111.GA24155@localhost> References: <20080603154111.GA24155@localhost> Message-ID: <1212508269.3774.21.camel@cutter> On Tue, 2008-06-03 at 17:41 +0200, Miroslav Lichvar wrote: > Hi, > > I've put together a small ncurses application for removing unnecessary > packages and their dependencies from the system. > > In a mutt-like interface it allows to browse through dependencies, > select packages and run rpm -e on them. > > For those who don't want to start under root some random stuff downloaded > from internet, it can be used under a regular user too. On exit, when > asked to not try to run rpm -e, it will write to stdout the list of > selected packages. out of curiosity: any reason you did this in c directly to rpmlib rather than just using the routines that already exist in python and yum's libraries? -sv From guido.ledermann at googlemail.com Tue Jun 3 16:03:34 2008 From: guido.ledermann at googlemail.com (Guido Ledermann) Date: Tue, 3 Jun 2008 18:03:34 +0200 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080603145826.GA12274@roque.1407.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> <20080603095201.GA6254@roque.1407.org> <4ee84c5f0806030316h40efd408tcbd929cd1cae5658@mail.gmail.com> <20080603145826.GA12274@roque.1407.org> Message-ID: <4ee84c5f0806030903x6727b5b3r7c892c55ae1cc93c@mail.gmail.com> 2008/6/3 Rui Miguel Silva Seabra : > Yes, I did, no offense taken of course. My point is precisely that there are > *better* alternatives (both in the sense of Freedom and technical). Thank god and mainly a lot of people there are alternatives. For me Mono is one of them and it's free IMHO. And even if there are better alternatives in technical way it should also be the programmers choice which to use. Guido From mlichvar at redhat.com Tue Jun 3 16:28:10 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 3 Jun 2008 18:28:10 +0200 Subject: rpmreaper In-Reply-To: <1212508269.3774.21.camel@cutter> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> Message-ID: <20080603162810.GA26319@localhost> On Tue, Jun 03, 2008 at 11:51:09AM -0400, seth vidal wrote: > > I've put together a small ncurses application for removing unnecessary > > packages and their dependencies from the system. > > out of curiosity: any reason you did this in c directly to rpmlib rather > than just using the routines that already exist in python and yum's > libraries? I prefer C for this kind of applications and the code for reading rpmdb is quite simple, so using the libraries probably wouldn't help much. -- Miroslav Lichvar From a.j.delaney at brighton.ac.uk Tue Jun 3 16:29:08 2008 From: a.j.delaney at brighton.ac.uk (Aidan Delaney) Date: Tue, 03 Jun 2008 17:29:08 +0100 Subject: Fedora 9 Cell processor packages In-Reply-To: <20080603092934.5cb175e7@balbo.artheist.org> References: <1212431765.3687.5.camel@ScaryMonster> <20080603092934.5cb175e7@balbo.artheist.org> Message-ID: <1212510548.2829.13.camel@ScaryMonster> Benjamin, On Tue, 2008-06-03 at 09:29 -0500, Benjamin Kosnik wrote: > What are the details of this argument? I thought that 4.3.x natively > supported cell/SPU. What problems are you running into? GCC 4.3 natively supports the SPU target. However you need to build gcc with SPU code generation support. This would be in a similar vein to the avr-gcc currently available in Fedora. > Perhaps an additional item or place to start on this might be a > cross-compilation package for x86 to SPU. Any spu-gcc package will build on x86, x86_64 and on Cell (the architectures I have available for testing). -- Aidan Delaney From a.j.delaney at brighton.ac.uk Tue Jun 3 16:20:48 2008 From: a.j.delaney at brighton.ac.uk (Aidan Delaney) Date: Tue, 03 Jun 2008 17:20:48 +0100 Subject: Fedora 9 Cell processor packages In-Reply-To: <20080603140450.GW8042@edu.joroinen.fi> References: <1212431765.3687.5.camel@ScaryMonster> <20080603140450.GW8042@edu.joroinen.fi> Message-ID: <1212510048.2829.7.camel@ScaryMonster> Pasi, On Tue, 2008-06-03 at 17:04 +0300, Pasi K?rkk?inen wrote: > I'm not sure if Gallium3d is "replacing" Mesa.. It's not in the near future, but for developing graphics on the PlayStation it's the best choice at the moment. Even if it is alpha software. > So if I understood everything correctly you still use Mesa (as a OpenGL > library) but behind the scenes Mesa is using Gallium3d drivers.. Yeah. The code lives on freedesktop.org in the Mesa git tree. -- Aidan Delaney From skvidal at fedoraproject.org Tue Jun 3 16:34:45 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Jun 2008 12:34:45 -0400 Subject: rpmreaper In-Reply-To: <20080603162810.GA26319@localhost> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> Message-ID: <1212510885.3774.23.camel@cutter> On Tue, 2008-06-03 at 18:28 +0200, Miroslav Lichvar wrote: > On Tue, Jun 03, 2008 at 11:51:09AM -0400, seth vidal wrote: > > > I've put together a small ncurses application for removing unnecessary > > > packages and their dependencies from the system. > > > > out of curiosity: any reason you did this in c directly to rpmlib rather > > than just using the routines that already exist in python and yum's > > libraries? > > I prefer C for this kind of applications and the code for reading > rpmdb is quite simple, so using the libraries probably wouldn't help > much. What is 'this kind of application'? -sv From mlichvar at redhat.com Tue Jun 3 16:48:47 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 3 Jun 2008 18:48:47 +0200 Subject: rpmreaper In-Reply-To: <1212510885.3774.23.camel@cutter> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> Message-ID: <20080603164847.GA26868@localhost> On Tue, Jun 03, 2008 at 12:34:45PM -0400, seth vidal wrote: > On Tue, 2008-06-03 at 18:28 +0200, Miroslav Lichvar wrote: > > On Tue, Jun 03, 2008 at 11:51:09AM -0400, seth vidal wrote: > > > > I've put together a small ncurses application for removing unnecessary > > > > packages and their dependencies from the system. > > > > > > out of curiosity: any reason you did this in c directly to rpmlib rather > > > than just using the routines that already exist in python and yum's > > > libraries? > > > > I prefer C for this kind of applications and the code for reading > > rpmdb is quite simple, so using the libraries probably wouldn't help > > much. > > What is 'this kind of application'? Simple applications that process lot of data in a way that doesn't justifies using a high-level language like python. -- Miroslav Lichvar From sandeen at redhat.com Tue Jun 3 16:50:05 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 03 Jun 2008 11:50:05 -0500 Subject: strange koji build failures...? Message-ID: <4845763D.7000203@redhat.com> Trying to get newer ecryptfs-utils built I'm seeing something odd (or not seeing something obvious...) http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log for things like this in the specfile: %doc README COPYING AUTHORS NEWS THANKS I'm getting this sort of failure: Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.27877 + umask 022 + cd /builddir/build/BUILD + cd ecryptfs-utils-46 + DOCDIR=/var/tmp/ecryptfs-utils-46-0.fc10-root-mockbuild/usr/share/doc/ecryptfs-utils-46 + export DOCDIR + rm -rf /var/tmp/ecryptfs-utils-46-0.fc10-root-mockbuild/usr/share/doc/ecryptfs-utils-46 + /bin/mkdir -p /var/tmp/ecryptfs-utils-46-0.fc10-root-mockbuild/usr/share/doc/ecryptfs-utils-46 + cp -pr README COPYING AUTHORS NEWS THANKS /var/tmp/ecryptfs-utils-46-0.fc10-root-mockbuild/usr/share/doc/ecryptfs-utils-46 cp: preserving times for `/var/tmp/ecryptfs-utils-46-0.fc10-root-mockbuild/usr/share/doc/ecryptfs-utils-46/README' : No such file or directory ... I'm not sure what to make of this... Any suggestions to debug (if it's not an obvious thing that I'm missing?) Thanks, -Eric From ivazqueznet at gmail.com Tue Jun 3 17:00:25 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 03 Jun 2008 13:00:25 -0400 Subject: rpmreaper In-Reply-To: <20080603164847.GA26868@localhost> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> Message-ID: <1212512425.3273.8.camel@ignacio.lan> On Tue, 2008-06-03 at 18:48 +0200, Miroslav Lichvar wrote: > On Tue, Jun 03, 2008 at 12:34:45PM -0400, seth vidal wrote: > > What is 'this kind of application'? > > Simple applications that process lot of data in a way that doesn't > justifies using a high-level language like python. HUH? That... that makes no sense... -- 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 stickster at gmail.com Tue Jun 3 17:07:37 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 03 Jun 2008 17:07:37 +0000 Subject: FESCo election delay In-Reply-To: <1212269437.4837.11.camel@kennedy> References: <1212269437.4837.11.camel@kennedy> Message-ID: <1212512857.4023.189.camel@victoria> On Sat, 2008-05-31 at 17:30 -0400, Brian Pepple wrote: > Hi all, > > At Thursday's FESCo meeting, it was decided to delay the upcoming FESCo > election since we are working on defining what FESCo's > role/responsibility will be in the future. Until this is finished, we > felt that it didn't make sense to run the election since candidates > expectations of FESCo's role might be different than what it evolves > into. We're hoping this will be resolved fairly soon, and we'll send > out an announcement on the decision and when the new election will be > held. If anyone has any questions, don't hesitate to contact me. This would be an opportune time also to solicit community input on this issue. I'd expect it would be more important to hear from people who are materially affected by FESCo, i.e. people who are doing development or packaging work in Fedora. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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 mtasaka at ioa.s.u-tokyo.ac.jp Tue Jun 3 17:54:14 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 04 Jun 2008 02:54:14 +0900 Subject: strange koji build failures...? In-Reply-To: <4845763D.7000203@redhat.com> References: <4845763D.7000203@redhat.com> Message-ID: <48458546.8050207@ioa.s.u-tokyo.ac.jp> Eric Sandeen wrote, at 06/04/2008 01:50 AM +9:00: > Trying to get newer ecryptfs-utils built I'm seeing something odd (or > not seeing something obvious...) > > http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log I just tried scratch build and it was all successful... http://koji.fedoraproject.org/koji/taskinfo?taskID=643448 Mamoru From sandeen at redhat.com Tue Jun 3 18:04:18 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 03 Jun 2008 13:04:18 -0500 Subject: strange koji build failures...? In-Reply-To: <48458546.8050207@ioa.s.u-tokyo.ac.jp> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> Message-ID: <484587A2.6050102@redhat.com> Mamoru Tasaka wrote: > Eric Sandeen wrote, at 06/04/2008 01:50 AM +9:00: >> Trying to get newer ecryptfs-utils built I'm seeing something odd (or >> not seeing something obvious...) >> >> http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log > > I just tried scratch build and it was all successful... > http://koji.fedoraproject.org/koji/taskinfo?taskID=643448 > > Mamoru > My scratch builds also were successful... and now a proper build was too. I think maybe there's a race somewhere... ? -Eric From lists at timj.co.uk Tue Jun 3 18:30:59 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 03 Jun 2008 19:30:59 +0100 Subject: strange koji build failures...? In-Reply-To: <4845763D.7000203@redhat.com> References: <4845763D.7000203@redhat.com> Message-ID: <48458DE3.8040706@timj.co.uk> Eric Sandeen wrote: > Trying to get newer ecryptfs-utils built I'm seeing something odd (or > not seeing something obvious...) > > http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log > > for things like this in the specfile: > > %doc README COPYING AUTHORS NEWS THANKS Yes, me too on x86_64. http://koji.fedoraproject.org/koji/getfile?taskID=643592&name=build.log Tim From tibbs at math.uh.edu Tue Jun 3 18:37:47 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jun 2008 13:37:47 -0500 Subject: Summary of the 2008-06-03 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2008-06-03 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20080603 Executive summary: No new guidelines and no votes this week. Instead we discussed issues relating to some early explorations of possible packaging harmonization with SuSE, and talked about some issues surrounding the issues of wiki ACLs covering the Packaging/ pages. - J< From denis at poolshark.org Tue Jun 3 19:57:54 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 03 Jun 2008 21:57:54 +0200 Subject: rpmreaper In-Reply-To: <1212512425.3273.8.camel@ignacio.lan> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> Message-ID: <4845A242.4050306@poolshark.org> Ignacio Vazquez-Abrams wrote: > On Tue, 2008-06-03 at 18:48 +0200, Miroslav Lichvar wrote: >> On Tue, Jun 03, 2008 at 12:34:45PM -0400, seth vidal wrote: >>> What is 'this kind of application'? >> Simple applications that process lot of data in a way that doesn't >> justifies using a high-level language like python. > > HUH? That... that makes no sense... Do i sense some python bias on this list ? :-) From skvidal at fedoraproject.org Tue Jun 3 20:02:55 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Jun 2008 16:02:55 -0400 Subject: rpmreaper In-Reply-To: <4845A242.4050306@poolshark.org> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> Message-ID: <1212523375.3774.35.camel@cutter> On Tue, 2008-06-03 at 21:57 +0200, Denis Leroy wrote: > Ignacio Vazquez-Abrams wrote: > > On Tue, 2008-06-03 at 18:48 +0200, Miroslav Lichvar wrote: > >> On Tue, Jun 03, 2008 at 12:34:45PM -0400, seth vidal wrote: > >>> What is 'this kind of application'? > >> Simple applications that process lot of data in a way that doesn't > >> justifies using a high-level language like python. > > > > HUH? That... that makes no sense... > > Do i sense some python bias on this list ? :-) I don't really care if it comes across or bias or not. We have most of the package mgmt infrastructure written in python. It just makes sense to write apps like this to use the same libs, if only b/c then it behaves consistently. -sv From roland at redhat.com Tue Jun 3 20:10:09 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Jun 2008 13:10:09 -0700 (PDT) Subject: Bizarre debugedit complaint In-Reply-To: Jason L Tibbitts III's message of , 2 June 2008 18:46:08 -0500 References: Message-ID: <20080603201009.746E726FC84@magilla.localdomain> It turns out fpc is generating invalid DWARF in the .debug_line section. It looks to me like the data might be mostly fine, but the unit length in the header is too short. Try {eu-,}readelf --debug-dump=line on the unstripped binary and see it complain about the bad format. Thanks, Roland From michael.wiktowy at gmail.com Tue Jun 3 20:18:39 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 3 Jun 2008 16:18:39 -0400 Subject: rpmreaper In-Reply-To: <1212523375.3774.35.camel@cutter> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> Message-ID: <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> On Tue, Jun 3, 2008 at 4:02 PM, seth vidal wrote: > I don't really care if it comes across or bias or not. We have most of > the package mgmt infrastructure written in python. It just makes sense > to write apps like this to use the same libs, if only b/c then it > behaves consistently. If you have a package that has the sole task of helping to cull down the list of installed packages, you'd want it to depend on the minimum number of packages so you could cull, for example, python. From the description of the OP, it looks like it doesn't do dependency resolution, just rpm -e, so there is no behaviour to keep consistent. /Mike From skvidal at fedoraproject.org Tue Jun 3 20:27:40 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Jun 2008 16:27:40 -0400 Subject: rpmreaper In-Reply-To: <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> Message-ID: <1212524860.3774.42.camel@cutter> On Tue, 2008-06-03 at 16:18 -0400, Michael Wiktowy wrote: > On Tue, Jun 3, 2008 at 4:02 PM, seth vidal wrote: > > I don't really care if it comes across or bias or not. We have most of > > the package mgmt infrastructure written in python. It just makes sense > > to write apps like this to use the same libs, if only b/c then it > > behaves consistently. > > If you have a package that has the sole task of helping to cull down > the list of installed packages, you'd want it to depend on the minimum > number of packages so you could cull, for example, python. It is very hard to remove python from a fedora system and have a functional (or even quasi-functional system) so why don't we start with that given. > From the > description of the OP, it looks like it doesn't do dependency > resolution, just rpm -e, so there is no behaviour to keep consistent. /me boggles. -sv From ville.skytta at iki.fi Tue Jun 3 20:42:59 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 3 Jun 2008 23:42:59 +0300 Subject: Fedora i386 rawhide rebuild in mock status 2008-05-27 In-Reply-To: References: <20080531072528.A2064@humbolt.us.dell.com> Message-ID: <200806032343.00304.ville.skytta@iki.fi> On Tuesday 03 June 2008, Bojan Smojver wrote: > Matt Domsch dell.com> writes: > > libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan > > Looking at the build log: > ----------------------------------- > /etc/profile: line 38: /bin/hostname: No such file or directory > sh: /usr/sbin/apxs: No such file or directory > cat: > /.mmn > > : No such file or directory > > ----------------------------------- > > Without apxs, this build has zero chance of succeeding. The package spec > file correctly includes: > ----------------------------------- > BuildRequires: httpd-devel >= 2.0.48 > ----------------------------------- > > Which in turn delivers /usr/sbin/apxs. Sure, but those messages at the top of your build log are just harmless stderr spewage from the source rpm build stage - various %(...) commands are run at specfile parse time before anything has had the chance to evaluate BuildRequires so naturally /usr/sbin/apxs is not available at that time. So that's not the cause for the build failure (thanks to the "%(... || echo ERROR)" stuff). > So, I don't know what's going on here. Maybe we don't have permission to > look into /usr/sbin or something in the build system? The actual build failure is caused by: cd perl; perl Makefile.PL -apxs /usr/sbin/apxs INSTALLDIRS=vendor Can't find apache include directory at Makefile.PL line 66. make[1]: *** [perl/Makefile] Error 9 Also, earlier in the build log, there's lots of this which could have something to do with it: Package libapreq2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libapreq2.pc' to the PKG_CONFIG_PATH environment variable From vonbrand at inf.utfsm.cl Tue Jun 3 21:09:56 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 03 Jun 2008 17:09:56 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080603145826.GA12274@roque.1407.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> <20080603095201.GA6254@roque.1407.org> <4ee84c5f0806030316h40efd408tcbd929cd1cae5658@mail.gmail.com> <20080603145826.GA12274@roque.1407.org> Message-ID: <200806032109.m53L9uB1006623@laptop13.inf.utfsm.cl> Rui Miguel Silva Seabra wrote: > On Tue, Jun 03, 2008 at 12:16:26PM +0200, Guido Ledermann wrote: [...] > > Rui, no offense, but did you read what this thread is about? We are > > not talking about how good programs are or if we like or use them or > > not. > Yes, I did, no offense taken of course. My point is precisely that there are > *better* alternatives (both in the sense of Freedom and technical). Sorry, but "better" is in the eye of the beholder... and Fedora is not in any way limited in the number of packages it supports, quite the contrary: The more, the merrier. If you don't see any use for a package, don't install it. As long as the interested parties do the heavy lifting of handling the package for Fedora, what do you care? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From pertusus at free.fr Tue Jun 3 21:18:31 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jun 2008 23:18:31 +0200 Subject: rpmreaper In-Reply-To: <1212524860.3774.42.camel@cutter> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> Message-ID: <20080603211831.GA2598@free.fr> On Tue, Jun 03, 2008 at 04:27:40PM -0400, seth vidal wrote: > > It is very hard to remove python from a fedora system and have a > functional (or even quasi-functional system) so why don't we start with > that given. Nothing really important requires python (though a lot of packages indeed requires it, including some that I wouldn't have thought they required it, like tex vim-enhanced, subversion), while the libc and ncurse are essential (required by bash for instance) so it is perfectly right to code basic tasks in C and avoid python. -- Pat From michael.wiktowy at gmail.com Tue Jun 3 21:22:18 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 3 Jun 2008 17:22:18 -0400 Subject: rpmreaper In-Reply-To: <1212524860.3774.42.camel@cutter> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> Message-ID: <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> On Tue, Jun 3, 2008 at 4:27 PM, seth vidal wrote: > On Tue, 2008-06-03 at 16:18 -0400, Michael Wiktowy wrote: >> From the >> description of the OP, it looks like it doesn't do dependency >> resolution, just rpm -e, so there is no behaviour to keep consistent. > > /me boggles. Looking at the man page in the tarball it looks like there *is* some reinvention of the wheel but only for the simpler matter of figuring out what dependencies to remove. You could argue about the utility of such a tool and what programming language/libraries it uses (and I would agree with you for what its worth) but is that really relevant to reviewing it for acceptance into Extras? http://fedoraproject.org/wiki/Packaging/ReviewGuidelines doesn't say anything about not reinventing the wheel and if it did we wouldn't have a lot of things people feel pretty passionately about (redundant desktop environments, search tools, editors ... you name the flamewar) and Fedora would be a pretty stagnant distro. Man file stripped of formatting: rpmreaper - A tool for removing unnecessary packages from system rpmreaper is a simple ncurses application with a mutt-like interface that allows removing unnecessary packages and their dependencies from the system. List installed packages. List leaf packages. List partial leaf packages. List broken packages. Verbose listing. Mark the highlighted package to be removed. Mark the highlighted package to be removed even when there are packages that depend on the package. Unmark the highlighted package. Unmark the highlighted package even when some dependencies are marked to be removed. Show/hide subtree of packages that are required by the highlighted package. Show/hide subtree of packages that require the highlighted package. Sort packages by name, flags or size. Run rpm -qi | less on the highlighted package. Run rpm -e on marked packages. Run rpm -e --nodeps on marked packages. Ask to remove marked packages and quit. Exit immediately. PACKAGE FLAGS Leaf, no package depends on the package. Partial leaf, some packages may depend on the package and removing the package may remove flag from other packages. Marked to be removed. Missing dependencies. Some packages required by the package are marked to be removed. From jonathan at jonmasters.org Tue Jun 3 21:39:32 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Tue, 03 Jun 2008 17:39:32 -0400 Subject: rpmreaper In-Reply-To: <20080603211831.GA2598@free.fr> References: <20080603154111.GA24155@localhost> <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> Message-ID: <1212529172.22357.66.camel@londonpacket.bos.redhat.com> On Tue, 2008-06-03 at 23:18 +0200, Patrice Dumas wrote: > On Tue, Jun 03, 2008 at 04:27:40PM -0400, seth vidal wrote: > > > > It is very hard to remove python from a fedora system and have a > > functional (or even quasi-functional system) so why don't we start with > > that given. > > Nothing really important requires python (though a lot of packages > indeed requires it, including some that I wouldn't have thought they > required it, like tex vim-enhanced, subversion), while the libc and > ncurse are essential (required by bash for instance) so it is perfectly > right to code basic tasks in C and avoid python. I think that used to be true. FWIW, I agree with the notion that python shouldn't have to be a fundamental dependency on Linux systems, but it's gone that way long since, so we should live with it and embrace it :) Jon. From sgrubb at redhat.com Tue Jun 3 21:44:49 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 3 Jun 2008 17:44:49 -0400 Subject: rpmreaper In-Reply-To: <20080603154111.GA24155@localhost> References: <20080603154111.GA24155@localhost> Message-ID: <200806031744.49706.sgrubb@redhat.com> On Tuesday 03 June 2008 11:41:11 Miroslav Lichvar wrote: > I've put together a small ncurses application for removing unnecessary > packages and their dependencies from the system. Did we ever fix rpmbuild to gather shell script interdependencies? If not, a tool like this might think you can remove a package without realizing that a shell script calls a program in it. -Steve From valent.turkovic at gmail.com Tue Jun 3 21:39:28 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jun 2008 23:39:28 +0200 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> Message-ID: <64b14b300806031439m56fd0b56t4cc81f7f4ff78d15@mail.gmail.com> On Sat, May 31, 2008 at 10:14 PM, Valent Turkovic wrote: > On Tue, May 27, 2008 at 1:34 PM, Jeff Spaleta wrote: >> On Tue, May 27, 2008 at 2:58 AM, Valent Turkovic >> wrote: >>> Hi, I must share this report with you. >>> I don't use Ubuntu but I installed it on one PC in a lab for students >>> and kids to learn using it (we have half Fedora and half Ubuntu lab). >>> I opened Firefox and went to www.redhatmagazine.com and immediately I >>> got a pop up window with a choice to install Adobe Flash, Swhdec or >>> Gnash plugin. I was amazed how well this worked and that I had a >>> choice to pick any one plugin that I believe it better. >>> I know about Fedora's upstream mentality but I must take my hat to >>> Ubuntu devels for making their "Ubuntu plugin service" work great. I >>> know that this is what Mozilla should have made but with their track >>> for supporting linux isn't the best one. >> >> >> Are you volunteering to create the necessary firefox extension and the >> plugin finder service implementation which mimics what Ubuntu is >> doing? Can you find the code that implements the service as they >> provide it for review? Until we know how they do it, and what data >> they use to do it, we don't really have a starting point worth talking >> about as to whether we can do what they do. I would have some >> concerns about running a central Fedora service, because any service >> Fedora would run would not be able to point at or reference a 3rd >> party repository at all..which would sort of defeat the point i think. >> >> I've also already had conversations with upstream Mozilla people >> concerning enhancing the upstream plugin finder... upstream >> contribution is welcome... its just a matter of people working with >> them. >> >> I'm not even sure we would need to run a service actually, if a client >> side firefox extension could intercept the plugin request and >> translate it into a packaging provides to send to packagekit. This is >> something to bring up with the packagekit developers. >> >> Regardless of whether this was upstream code or a Fedora specific >> extension or service... >> someone who cares about this would need to step forward to work on it >> or it's not going to go anywhere. >> >> -jef >> > > https://wiki.ubuntu.com/FlashExperienceIntrepid > > Have you maybe also talked with Ubuntu devels that made Ubuntu "Plugin > finder service" ? > Maybe they are willing to contribute their code and expertise to > upstream Mozilla for this ? > > 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 > I contacted ubuntu-develpers and here is the answer I got: from Alexander Sack: https://lists.ubuntu.com/archives/ubuntu-devel/2008-June/025472.htm https://lists.ubuntu.com/archives/ubuntu-devel/2008-June/025474.html Does anybody know Alexander? Cheers, 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 opensource at till.name Tue Jun 3 22:00:35 2008 From: opensource at till.name (Till Maas) Date: Wed, 04 Jun 2008 00:00:35 +0200 Subject: rpmreaper In-Reply-To: <200806031744.49706.sgrubb@redhat.com> References: <20080603154111.GA24155@localhost> <200806031744.49706.sgrubb@redhat.com> Message-ID: <200806040000.41128.opensource@till.name> On Tue June 3 2008, Steve Grubb wrote: > Did we ever fix rpmbuild to gather shell script interdependencies? If not, > a tool like this might think you can remove a package without realizing > that a shell script calls a program in it. The dependencies need to be specified manually in the spec as Requires:, then this won't happen. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Tue Jun 3 22:11:44 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jun 2008 00:11:44 +0200 Subject: State of fedoratv.com? Message-ID: <64b14b300806031511i5594c248yed1b0b59078a1c41@mail.gmail.com> Hi, I searched and haven't find any discussions regarding fedoratv.com and what is going on with it because it looks as frontend hasn't had any changes. How to get an account and upload videos to fedoratv? Why does fedoratv have a .com instead of .org ? Cheers, 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 dwmw2 at infradead.org Tue Jun 3 22:56:03 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Jun 2008 23:56:03 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <20080603134725.GA12485@redhat.com> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> <20080602172853.GB27063@redhat.com> <484431A3.6010706@hhs.nl> <20080603134725.GA12485@redhat.com> Message-ID: <1212533763.4042.19.camel@shinybook.infradead.org> On Tue, 2008-06-03 at 09:47 -0400, John W. Linville wrote: > I have reverted that patch in rawhide, and I'm working with Kirill > for a more permanent solution. Personally, my advice would be to ditch the __uXX nonsense types and write code in C instead. :) -- dwmw2 From kevin at scrye.com Tue Jun 3 23:29:54 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 3 Jun 2008 17:29:54 -0600 Subject: source file audit - 2008-06-03 Message-ID: <20080603172954.69b3bb51@ohm.scrye.com> Here's attached another run of my sources/patches url checker. - There are 642 lines in this run. Down from 660 last run. Congratulations to everyone for the good downward trend. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt 660 sourcecheck-20080501.txt - I am going to try and spam maintainers later this week with their packages that have issues from this list. I didn't get around to it last cycle, but I will try and do so this time. You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20080603.txt And also attached to this mail. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. kevin -- abompard:BADURL:glest_data_3.1.2.zip:glest-data aconway:BADURL:qpidc-0.2.656926.tar.gz:qpidc aconway:BADURL:rhm-0.2.2060.tar.gz:rhm adalloz:BADURL:pan-0.132.tar.bz2:pan adrian:BADURL:xlockmore-5.25.tar.bz2:xlockmore ajax:BADURL:pyxf86config-0.3.37.tar.bz2:pyxf86config akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx alexlan:BADSOURCE:coverart.py:picard alexlan:BADSOURCE:discnumber.py:picard alexlan:BADSOURCE:featartist.py:picard alexlan:BADSOURCE:__init__.py:picard andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio ascii:BADURL:fish-1.23.0.tar.bz2:fish athimm:BADSOURCE:po4a-0.32.tar.gz:po4a athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:fakeroot_1.6.4.tar.gz:fakeroot athimm:BADURL:greylistd_0.8.3.2.tar.gz:greylistd atkac:BADURL:rexec-1.5.tar.gz:rsh atkac:BADURL:vnc-4_1_2-unixsrc.tar.gz:vnc atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta ausil:BADSOURCE:usb8388-5.110.22.p6.bin.md5:libertas-usb8388-firmware ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools ausil:BADURL:snort-2.8.1.tar.gz:snort awjb:BADURL:atitvout_0.4-2.diff.gz:atitvout awjb:BADURL:koffice-1.9.95.8.tar.bz2:koffice awjb:BADURL:synce-kpm-0.11.tar.gz:synce-kpm awjb:BADURL:treecc-0.3.8.tar.gz:treecc awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker belegdol:BAD_CVS_SOURCE:museek+-0.1.13.tar.bz2:museek+ belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa belegdol:BADURL:gchempaint-0.8.7.tar.bz2:gchempaint belegdol:BADURL:gnome-chemistry-utils-0.8.7.tar.bz2:gnome-chemistry-utils belegdol:BADURL:goffice-0.4.3.tar.bz2:goffice04 ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31 bjensen:BADSOURCE:xnec2c-1.0b5.tar.gz:xnec2c bjensen:BADURL:fldigi-2.10.3.tar.gz:fldigi bjensen:BADURL:gpsk31-0.3.tar.gz:gpsk31 bjensen:BADURL:xfhell-1.4.tar.gz:xfhell bojan:BADURL:libapreq2-2.09.tar.gz:libapreq2 bos:BADSOURCE:gtk2hs-0.9.12.1.tar.gz:gtk2hs bouska:BADURL:kitsune2.0.tar.gz:kitsune bpeck:BADURL:conmux-493svn.tar.gz:conmux bpepple:BADURL:ggz-gtk-client-0.0.14.1.tar.gz:ggz-gtk-client bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter bpepple:BADURL:swfdec-gnome-2.22.0.tar.bz2:swfdec-gnome bpepple:BADURL:swfdec-mozilla-0.6.0.tar.gz:swfdec-mozilla bpostle:BADURL:hugin-0.7.0.tar.gz:hugin bpostle:BADURL:libpano13-2.9.12.tar.bz2:libpano13 buc:BADURL:enca-1.9.tar.bz2:enca c4chris:BADURL:seaview_2.0.tar.gz:seaview candyz:BADSOURCE:gcin-1.4.0.tar.bz2:gcin caolanm:BADSOURCE:lp_solve_5.5.0.12_source.tar.gz:lpsolve caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de caolanm:BADURL:evolocal.odb:openoffice.org caolanm:BADURL:sjp-myspell-pl-20080513.zip:hunspell-pl cchance:BADSOURCE:emesene-1.0.tar.gz:emesene cchance:BADURL:nhpf-1.42.tar.gz:nhpf cgrau:BADURL:frotz-2.43.tar.gz:frotz cgrau:BADURL:ifm-5.1.tar.gz:ifm chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome chitlesh:BADURL:26521-kio_resources-0.2.tar.bz2:kio_resources chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal chitlesh:BADURL:geda-docs-1.4.0.tar.gz:geda-docs chitlesh:BADURL:geda-examples-1.4.0.tar.gz:geda-examples chitlesh:BADURL:geda-gattrib-1.4.0.tar.gz:geda-gattrib chitlesh:BADURL:geda-gnetlist-1.4.0.tar.gz:geda-gnetlist chitlesh:BADURL:geda-gschem-1.4.0.tar.gz:geda-gschem chitlesh:BADURL:geda-gsymcheck-1.4.0.tar.gz:geda-gsymcheck chitlesh:BADURL:geda-symbols-1.4.0.tar.gz:geda-symbols chitlesh:BADURL:geda-utils-1.4.0.tar.gz:geda-utils chitlesh:BADURL:guile-1.6.7.tar.gz:compat-guile-16 chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc chitlesh:BADURL:ktechlab-0.3.69.tar.bz2:ktechlab chitlesh:BADURL:libgeda-1.4.0.tar.gz:libgeda chitlesh:BADURL:liborigin-20071119.tar.gz:liborigin chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito clumens:BADURL:gnu-efi-3.0d.tar.gz:gnu-efi clumens:BADURL:rhpxl-1.9.tar.gz:rhpxl coldwell:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs corsepiu:BADURL:Mail-GnuPG-0.15.tar.gz:perl-Mail-GnuPG cr33dog:BADURL:fontypython-0.2.0.tar.gz:fontypython cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools cweyl:BADURL:Catalyst-Manual-5.700701.tar.gz:perl-Catalyst-Manual cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym cweyl:BADURL:Hash-Case-1.003.tar.gz:perl-Hash-Case cweyl:BADURL:JSON-XS-2.01.tar.gz:perl-JSON-XS cweyl:BADURL:MooseX-Object-Pluggable-0.0005.tar.gz:perl-MooseX-Object-Pluggable cweyl:BADURL:Perl-Critic-1.080.tar.gz:perl-Perl-Critic cweyl:BADURL:POE-0.9999.tar.gz:perl-POE cweyl:BADURL:POE-Component-IRC-5.29.tar.gz:perl-POE-Component-IRC cweyl:BADURL:POE-Component-Server-SimpleHTTP-1.23.tar.gz:perl-POE-Component-Server-SimpleHTTP cweyl:BADURL:POE-Component-SSLify-0.08.tar.gz:perl-POE-Component-SSLify cweyl:BADURL:POE-Filter-Zlib-1.8.tar.gz:perl-POE-Filter-Zlib cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym cweyl:BADURL:WWW-Myspace-0.60.tar.gz:perl-WWW-Myspace cwickert:BADURL:xfce4-minicmd-plugin-0.4.tar.bz2:xfce4-minicmd-plugin danken:BADURL:bidiv-1.5.tgz:bidiv danken:BADURL:hspell-1.0.tar.gz:hspell davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator dbhole:BADURL:lucene-2.3.1-src.tar.gz:lucene dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound dcbw:BADURL:plague-0.4.4.1.tar.bz2:plague dchen:BADSOURCE:scim-array-1.0.0.tar.gz:scim-array dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration deji:BADSOURCE:texmaker-1.7.tar.bz2:texmaker deji:BADURL:gparted-0.3.7.tar.bz2:gparted denis:BADURL:hamlib-1.2.7.tar.gz:hamlib denis:BADURL:libpanelappletmm-2.22.0.tar.bz2:libpanelappletmm denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite devrim:BADSOURCE:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja dionysos:BADSOURCE:mansupfr.tar.bz2:man-pages-fr dionysos:BADURL:eurofont.tar.gz:tetex-eurofont dionysos:BADURL:kbackup-0.5.3.tar.bz2:kbackup dionysos:BADURL:kicad-sources--2007-07-09.zip:kicad drago01:BADSOURCE:iotop-0.2.tar.bz2:iotop drago01:BADURL:compiz-bcop-0.7.2.tar.bz2:compiz-bcop drago01:BADURL:compiz-fusion-plugins-extra-0.7.2.tar.bz2:compiz-fusion-extras drago01:BADURL:compiz-fusion-plugins-main-0.7.2.tar.bz2:compiz-fusion dwalsh:BADSOURCE:selinux-doc-1.26.tgz:selinux-doc dwalsh:BADSOURCE:sepolgen-1.0.11.tgz:policycoreutils dwalsh:BADURL:checkpolicy-2.0.16.tgz:checkpolicy dwalsh:BADURL:libselinux-2.0.65.tgz:libselinux dwalsh:BADURL:libsemanage-2.0.25.tgz:libsemanage dwalsh:BADURL:libsepol-2.0.29.tgz:libsepol dwalsh:BADURL:mcstrans-0.2.11.tgz:mcstrans dwalsh:BADURL:policycoreutils-2.0.49.tgz:policycoreutils dwmw2:BADSOURCE:petitboot-0.0.1.tar.gz:petitboot dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot dwmw2:BADURL:apmud-1.0.0.tgz:apmud dwmw2:BADURL:callweaver-RC-1.1.99.20071230.tar.gz:callweaver dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot dwmw2:BADURL:nano-2.0.6.tar.gz:nano ecik:BADURL:audacious_mediaplayer-20080423.tar.bz2:kadu ecik:BADURL:kadu-0.6.0.1.tar.bz2:kadu ecik:BADURL:kadu-autostatus-0.1.tar.bz2:kadu ecik:BADURL:kadu-firewall-0.7.5.1.tar.bz2:kadu ecik:BADURL:kadu-last_seen-0.1.1.tar.bz2:kadu ecik:BADURL:kadu-osdhints_notify-0.4.2.tar.bz2:kadu ecik:BADURL:kadu-powerkadu-2.0.4.tar.bz2:kadu ecik:BADURL:kadu-tabs-1.1.6.tar.bz2:kadu ecik:BADURL:mime_tex-1.4.1.1.tar.bz2:kadu ecik:BADURL:oa076.zip:openarena ecik:BADURL:ZSI-2.0.tar.gz:python-ZSI edhill:BADSOURCE:cdo.pdf:cdo edhill:BADSOURCE:cdo_refcard.pdf:cdo edhill:BADURL:wifiroamd-1.14.tar.gz:wifiroamd ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder ensc:BADURL:hunt-1.5.tgz:hunt errr:BADURL:pekwm-0.1.5.tar.bz2:pekwm errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg faucamp:BADURL:12956-knemo-0.4.7.tar.bz2:knemo fche:BADURL:systemtap-0.6.2.tar.gz:systemtap firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab fitzsim:BADSOURCE:icedtea-1.6.tar.gz:java-1.7.0-icedtea fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail frankb:BAD_CVS_SOURCE:nasd.init:nas frankb:BADURL:nas-1.9.1.src.tar.gz:nas gemi:BADSOURCE:cook-2.30.tar.gz:cook gemi:BADSOURCE:curry-0.9.11.tar.gz:curry gemi:BADSOURCE:HTMLmanual.tar.gz:pl gemi:BADSOURCE:SmartEiffel-2-3.tar.bz2:smarteiffel gemi:BADURL:ffcall-1.10.tar.gz:ffcall gemi:BADURL:scons-0.98.4.tar.gz:scons gemi:BADURL:skencil-0.6.tar.gz:skencil gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm green:BADURL:libffi-3.0.1.tar.gz:libffi green:BADURL:liblo-0.24.tar.gz:liblo grenier:BADSOURCE:testdisk-6.9.tar.bz2:testdisk hadess:BADURL:gnome-settings-daemon-2.23.2.tar.bz2:gnome-settings-daemon hadess:BADURL:totem-pl-parser-2.23.1.tar.bz2:totem-pl-parser hamzy:BADURL:sblim-cmpi-base-1.5.4.tar.bz2:sblim-cmpi-base hman-it:BADURL:themonospot-0.7.0.1.tar.gz:themonospot homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo ianweller:BADURL:flam3-2.7.12.tar.gz:flam3 iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class icon:BADURL:cvs2svn-2.1.1.tar.gz:cvs2svn icon:BADURL:gazpacho-0.7.2.tar.bz2:gazpacho icon:BADURL:libxml++-2.22.0.tar.bz2:libxml++ icon:BADURL:verbiste-0.1.22.tar.gz:verbiste ixs:BADURL:commoncpp2-1.6.1.tar.gz:commoncpp2 ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel ixs:BADURL:scmxx-0.9.0.tar.bz2:scmxx ixs:BADURL:ser-0.9.6_src.tar.gz:ser jafo:BADURL:python-memcached-1.39.tar.gz:python-memcached jakub:BADURL:prelink-20071009.tar.bz2:prelink jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib james:BADURL:zsh-4.3.4.tar.gz:zsh jbowes:BADURL:ipython-0.8.3.tar.gz:ipython jcm:BADSOURCE:module-init-tools-3.4.tar.bz2:module-init-tools jcm:BADSOURCE:module-init-tools-3.4.tar.bz2.sign:module-init-tools jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2 jgarzik:BADURL:reiserfsprogs-3.6.19.tar.gz:reiserfs-utils jgu:BADURL:dvipdfmx-20080520.tar.gz:dvipdfmx jgu:BADURL:ebib-1.5.2.tar.gz:emacs-common-ebib jima:BADURL:videodog0.31.tar.gz:videodog jjohnstn:BADURL:eclipse-changelog-src-2.6.1.zip:eclipse-changelog jlaska:BADURL:snake-0.11-0.4.tar.bz2:snake jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate jlayton:BADURL:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd jmoskovc:BADURL:rdate-1.4.tar.gz:rdate jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats jmrcpn:BADURL:clement-2.1-241.tar.gz:clement jnovy:BAD_CVS_SOURCE:patch.4.6.21.1:db4 jnovy:BADSOURCE:db-4.2.52.tar.gz:compat-db jnovy:BADSOURCE:db-4.3.29.tar.gz:compat-db jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive jnovy:BADURL:mc-4.6.2-pre1.tar.gz:mc jnovy:BADURL:platex209.tar.bz2:texlive-texmf joost:BADURL:fpc-2.2.0.compiler.bin.tar.gz:fpc jorge:BADSOURCE:mimetex.zip:mimetex jorton:BADURL:imap-2004g.tar.Z:libc-client jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx jsteffan:BADURL:revisor-2.1.1.tar.gz:revisor jwb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard jwb:BADSOURCE:blacklists.tar.gz:squidGuard jwboyer:BADURL:ctrlproxy-3.0.6.tar.gz:ctrlproxy jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt jwilson:BADURL:firecontrol-0.2.tar.gz:firecontrol kanarip:BADURL:pyjigdo-0.3.0.tar.gz:pyjigdo karlik:BADURL:warzone2100-2.1_beta2.tar.bz2:warzone2100 karsten:BADURL:autoconf-2.62.tar.bz2:autoconf kasal:BADURL:Business-ISBN-Data-1.15.tar.gz:perl-Business-ISBN-Data kasal:BADURL:gdbm-1.8.0.tar.gz:gdbm kasal:BADURL:IO-Zlib-1.07.tar.gz:perl-IO-Zlib kasal:BADURL:Text-CSV_XS-0.30.tar.gz:perl-Text-CSV_XS kasal:BADURL:transfig.3.2.5.tar.gz:transfig kasal:BADURL:Xaw3d-1.3.tar.gz:Xaw3d kasal:BADURL:xfig.3.2.5.full.tar.gz:xfig kasal:BADURL:XML-Grove-0.46alpha.tar.bz2:perl-XML-Grove kevin:BADSOURCE:Inconsolata.sfd:inconsolata-fonts kevin:BADSOURCE:twinkle-1.2.tar.gz:twinkle kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf kwizart:BADSOURCE:libewf-20080501.tar.gz:libewf kwizart:BADURL:aqsis-1.2.0.tar.gz:aqsis kwizart:BADURL:GLC_Player_src_1.0.2.zip:GLC_Player kwizart:BADURL:oyranos-repack-0.1.7.tar.bz2:oyranos kzak:BADURL:lslk_1.29_W.tar.gz:lslk kzak:BADURL:mwords.tar.Z:words kzak:BADURL:vlock-1.3.tar.gz:vlock lennart:BADSOURCE:pavucontrol-0.9.6.tar.gz:pavucontrol lennart:BADURL:pulseaudio-0.9.11.svn20080529.tar.gz:pulseaudio leo:BADURL:pcmanx-gtk2.tar.gz:pcmanx-gtk2 linville:BADURL:b43-fwcutter-011.tar.bz2:b43-fwcutter liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak llim:BAD_CVS_SOURCE:lsb-release-2.0.tar.gz:redhat-lsb lmacken:BADSOURCE:TurboFlot-0.1.1.tar.bz2:python-turboflot lmacken:BADURL:deskbar-applet-2.23.2.tar.bz2:deskbar-applet lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears lucilanga:BADSOURCE:fuse-0.9.0.tar.gz:fuse-emulator lvm-team:BADURL:dmraid-1.0.0.rc14.tar.bz2:dmraid maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine mbarabas:BADURL:system-config-vsftpd-0.5.1.tar.gz:system-config-vsftpd mccann:BADURL:gnome-screensaver-2.23.3.tar.bz2:gnome-screensaver mebourne:BADSOURCE:ZoneMinder-1.22.3.tar.gz:zoneminder mebrown:BADSOURCE:libsmbios-2.0.1.tar.gz:libsmbios meme:BADSOURCE:vultures-2.1.0-full.tar.bz2:nethack-vultures mfleming:BADURL:mod-cband-0.9.7.5.tgz:mod_cband mgarski:BADSOURCE:linuxdcpp-1.0.1.tar.bz2:linuxdcpp mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV misa:BADURL:pyOpenSSL-0.6.tar.gz:pyOpenSSL mitr:BADURL:stunnel-4.24.tar.gz.asc:stunnel mitr:BADURL:stunnel-4.24.tar.gz:stunnel mlichvar:BADSOURCE:setlayout.c:openbox mlichvar:BADURL:openbox-3.4.7.2.tar.gz:openbox mlichvar:BADURL:slrn-0.9.8.1pl1.tar.bz2:slrn mmahut:BADURL:munipack-0.3.1.tar.gz:munipack mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart mmaslano:BADSOURCE:cronie-1.0.tar.gz:cronie mmcgrath:BADURL:phpMyAdmin-2.11.6-all-languages.tar.bz2:phpMyAdmin mmcgrath:BADURL:SOAP-Lite-0.68.tar.gz:perl-SOAP-Lite mpg:BADURL:hulahop-0.4.0.tar.bz2:hulahop mpg:BADURL:sugar-base-0.79.0.tar.bz2:sugar-base mpg:BADURL:sugar-datastore-0.6.0.tar.bz2:sugar-datastore mtasaka:BADURL:jd-2.0.0-svn2081_trunk.tgz:jd mtasaka:BADURL:manedit-0.8.1.tar.bz2:manedit mtasaka:BADURL:wallpapoz-0.4.1-svn87_trunk.tar.bz2:wallpapoz muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras mwiriadi:BADURL:gpicview-0.1.9.tar.gz:gpicview mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend mwringe:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler mwringe:BADURL:nekohtml-0.9.5.tar.gz:nekohtml nalin:BADURL:nss_db-2.2.tar.gz:nss_db nalin:BADURL:nss_ldap-259.tar.gz:nss_ldap nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap nbecker:BADURL:unuran-1.2.4p1.tar.gz:unuran ngompa:BADURL:oggconvert-0.3.0.tar.gz:oggconvert nhorman:BADURL:cscope-15.6.tar.gz:cscope nhorman:BADURL:numactl-2.0.0.tar.gz:numactl nigelj:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice nim:BADURL:edrip-src-20080523.tar.bz2:edrip-fonts nixaff4:BADURL:knotify-plugin_0.1.tar.gz:pidgin-knotify nmurray:BADURL:giflib-4.1.3.tar.bz2:giflib nmurray:BADURL:ImageMagick-6.4.0-10.tar.bz2:ImageMagick nomis80:BADURL:camstream-0.26.3.tar.gz:camstream nphilipp:BADSOURCE:gtkimageview-1.5.0.tar.gz:gtkimageview nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp ondrejj:BADSOURCE:sagator-1.0.0.tar.bz2:sagator orion:BADSOURCE:GSHHS1.10_coast.tar.bz2:GMT-coastlines orion:BADSOURCE:GSHHS1.10_full.tar.bz2:GMT-coastlines orion:BADSOURCE:GSHHS1.10_high.tar.bz2:GMT-coastlines orion:BADURL:GMT4.3.0_pdf.tar.bz2:GMT-doc orion:BADURL:GMT4.3.0_tut.tar.bz2:GMT-doc orion:BADURL:GMT4.3.0_web.tar.bz2:GMT-doc orion:BADURL:ncarg_src-4.4.2.tar.gz:ncarg orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof orphan:BADURL:FreeWnn-1.1.1-a021.tar.bz2:FreeWnn orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog orphan:BADURL:gnome-ppp-0.3.23.tar.bz2:gnome-ppp orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum orphan:BADURL:new-1.3.9.tar.gz:new orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script otaylor:BADURL:mugshot-1.1.95.tar.gz:mugshot ovasik:BADSOURCE:docbook-slides-3.4.0.tar.gz:docbook-slides ovasik:BADURL:gnome-bluetooth-0.11.0.tar.bz2:gnome-bluetooth ovasik:BADURL:passivetex-1.25.zip:passivetex ovasik:BADURL:xmltex-1.9.tar.gz:xmltex owentl:BADSOURCE:GoodWeather-0.3.tar.gz:gdesklets-goodweather pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit pertusus:BADURL:lesstif2_0.95.0-2.diff.gz:lesstif petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk pfj:BADSOURCE:CastPodder-5.0.tar.bz2:CastPodder pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o pfj:BADSOURCE:mono-tools-1.9.tar.bz2:mono-tools pfj:BADURL:gDeskCal-1.01.tar.gz:gdeskcal pfj:BADURL:gtksourceview2-sharp-89788.tar.bz2:gtksourceview2-sharp pfj:BADURL:gtksourceview-sharp-2.0-0.11.tar.bz2:gtksourceview-sharp pfj:BADURL:ikvm-0.22.tar.gz:ikvm pfj:BADURL:mod_mono-1.9.tar.bz2:mod_mono pfj:BADURL:mono-debugger-0.60.tar.bz2:mono-debugger pfj:BADURL:monodoc-1.9.zip:monodoc pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks pgordon:BADURL:deluge-0.5.9.1.tar.gz:deluge pgordon:BADURL:empathy-0.23.2.tar.bz2:empathy pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth pgordon:BADURL:libtorrent-0.12.1.tar.gz:rb_libtorrent phuang:BADSOURCE:scim-1.4.7.tar.gz:scim phuang:BADSOURCE:scim-python-0.1.12.tar.gz:scim-python pingou:BADURL:Biobase_2.0.0.tar.gz:R-Biobase pingou:BADURL:multtest_1.20.0.tar.gz:R-multtest pingou:BADURL:qvalue_1.14.0.tar.gz:R-qvalue pjones:BADSOURCE:cdparanoia-III-alpha9.8.src.tgz:cdparanoia pknirsch:BADSOURCE:ipmitool-1.8.9.tar.gz:OpenIPMI pnemade:BADSOURCE:iso-codes-2.1.tar.bz2:iso-codes pwouters:BADURL:ks3switch-0.1.tar.gz:ks3switch pwouters:BADURL:s3ssrc.zip:s3switch qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas rafalzaq:BADURL:htop-0.7.tar.gz:htop rajeeshknambiar:BADSOURCE:ooo-hunspell-ml-0.1.tar.bz2:hunspell-ml rathann:BADURL:crm114-20070810-BlameTheSegfault.src.tar.gz:crm114 rathann:BADURL:libnemesi-0.6.4-rc2.tar.bz2:libnemesi rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2 rbhalera:BADURL:Madan.ttf:madan-fonts rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview rdieter:BADSOURCE:Macaulay2-1.1-src.tar.gz:Macaulay2 rdieter:BADURL:libofa-0.9.3.tar.gz:libofa rdieter:BADURL:macref.pdf:maxima rdieter:BADURL:mtextralic.htm:mathml-fonts rdieter:BADURL:pinentry-0.7.4.tar.gz:pinentry rdieter:BADURL:pinentry-0.7.4.tar.gz.sig:pinentry rezso:BAD_CVS_SOURCE:proj.copyright:proj rezso:BADURL:geos-3.0.0.tar.bz2:geos rezso:BADURL:ogdi-3.2.0.beta2.tar.gz:ogdi rishi:BADSOURCE:httrack-3.42.tar.gz:httrack rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap rmeggins:BADURL:fedora-ds-base-1.1.1.tar.bz2:fedora-ds-base rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP rnorwood:BADURL:gnome-packagekit-0.2.2-20080529.tar.gz:gnome-packagekit rnorwood:BADURL:PackageKit-0.2.2-20080529.tar.gz:PackageKit robert:BADURL:idn_1.2b.tar.gz:php-idn robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish roland:BADURL:elfutils-0.135.tar.gz:elfutils roland:BADURL:lcov-1.6.tar.gz:lcov rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd rrakus:BADURL:cleanfeed-0.95.7b.tar.gz:cleanfeed rrelyea:BADSOURCE:ccid-1.2.1.tar.gz:ccid rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 rstrode:BADSOURCE:gnome-desktop-2.23.2.tar.bz2:gnome-desktop rvokal:BADURL:gaim-guifications-2.13beta6.tar.bz2:gaim-guifications rvokal:BADURL:pidgin-guifications-2.14.tar.bz2:pidgin-guifications ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender s4504kr:BADURL:inadyn.v1.96.2.zip:inadyn s4504kr:BADURL:lightning-1.2.tar.gz:lightning s4504kr:BADURL:stellarium_user_guide-0.9.0-1.pdf:stellarium s4504kr:BADURL:suck-4.3.2.tar.gz:suck salimma:BADSOURCE:fbreader-sources-0.8.12.tgz:fbreader sandeen:BADURL:blktrace-git-20080103162505.tar.gz:blktrace sconklin:BADURL:db-4.6.19.tar.gz:cyrus-sasl sconklin:BADURL:ipsec-tools-0.7.tar.bz2:ipsec-tools sergiopr:BADURL:cpl-4.1.0.tar.gz:cpl sergiopr:BADURL:ds9.5.2.tar.gz:ds9 sergiopr:BADURL:esorex-3.6.8.tar.gz:esorex sergiopr:BADURL:qfits-6.2.0.tar.gz:qfits sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools sgrubb:BADURL:libprelude-0.9.17.1.tar.gz:libprelude shahms:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols sharkcz:BADSOURCE:tinyerp-client-4.2.2.tar.gz:tinyerp sharkcz:BADSOURCE:tinyerp-server-4.2.2.tar.gz:tinyerp sheltren:BADURL:cfengine-2.2.6.tar.gz:cfengine sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod sheltren:BADURL:fortune-tao.tar.gz:fortune-mod sheltren:BADURL:osfortune.tar.gz:fortune-mod silfreed:BADURL:qgis-0.9.1.tar.gz:qgis simo:BADURL:rsync-3.0.2.tar.gz:rsync simo:BADURL:rsync-patches-3.0.2.tar.gz:rsync sindrepb:BADURL:DBIx-SQLite-Simple-0.34.tar.gz:perl-DBIx-SQLite-Simple sindrepb:BADURL:gnome-do-0.4.2.0.tar.gz:gnome-do sindrepb:BADURL:nikto-1.36.tar.bz2:nikto sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib snecker:BADURL:jokosher-20080216svn.tar.gz:jokosher snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim snirkel:BADURL:gnokii-0.6.25.tar.bz2:gnokii snirkel:BADURL:njb-sharp-0.3.0.tar.bz2:njb-sharp splinux:BADURL:gdmap-0.7.5.tar.gz:gdmap splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm splinux:BADURL:pessulus-2.16.2.tar.bz2:pessulus spot:BADSOURCE:mpiblacs.tgz:blacs spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware spot:BADSOURCE:srecord-1.39.tar.gz:srecord spot:BADURL:Class-Data-Inheritable-0.06.tar.gz:perl-Class-Data-Inheritable spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg spot:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI spot:BADURL:IO-CaptureOutput-1.06.tar.gz:perl-IO-CaptureOutput spot:BADURL:libgdamm-3.0.0.tar.bz2:libgdamm spot:BADURL:Mail-Box-2.073.tar.gz:perl-Mail-Box spot:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record spot:BADURL:rx-1.5.tar.bz2:librx spot:BADURL:Scalar-Properties-0.13.tar.gz:perl-Scalar-Properties spot:BADURL:Tree-DAG_Node-1.06.tar.gz:perl-Tree-DAG_Node spot:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile steve:BADURL:cpanspec-1.75.tar.gz:cpanspec steve:BADURL:eperl_2.2.14-13.diff.gz:perl-eperl steved:BADURL:nfs.doc.tar.gz:nfs-utils stransky:BADURL:awesfx-0.5.0d.tar.gz:awesfx stransky:BADURL:gu11-rom.zip:awesfx sundaram:BADURL:gyachi-1.1.32.tar.gz:gyachi svahl:BADURL:kcoloredit-4.0.80.tar.bz2:kcoloredit sxw:BADURL:kstart-3.11.tar.gz:kstart tagoh:BADSOURCE:scim-anthy-1.2.4.tar.gz:scim-anthy tagoh:BADURL:anthy-9100e.tar.gz:anthy tagoh:BADURL:Canna37p3.tar.bz2:Canna tagoh:BADURL:k14-oldkanji.tar.gz:fonts-japanese tagoh:BADURL:mew-6.1rc1.tar.gz:mew tagoh:BADURL:mplus_bitmap_fonts-2.2.4.tar.gz:fonts-japanese tagoh:BADURL:nkf-2.0.8b.tar.gz:nkf tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql tgl:BADURL:jpegsrc.v6b.tar.bz2:libjpeg tgl:BADURL:mysql-5.0.51a.tar.gz:mysql tgl:BADURL:mysql-connector-odbc-3.51.24r1071.tar.gz:mysql-connector-odbc tgl:BADURL:pg_filedump-8.3.0.tar:rhdb-utils tgl:BADURL:postgresql-8.3.1-US.pdf:postgresql tgl:BADURL:psqlodbc-08.03.0100.tar.gz:postgresql-odbc than:BAD_CVS_SOURCE:French.txt:wordtrans than:BADSOURCE:css.tar.bz2:kdewebdev than:BADSOURCE:doxygen-1.5.6.src.tar.gz:doxygen than:BADSOURCE:html.tar.bz2:kdewebdev than:BADSOURCE:javascript.tar.bz2:kdewebdev than:BADSOURCE:qt-x11-opensource-src-4.4.0.tar.bz2:qt than:BADURL:arts-1.5.9.tar.bz2:arts than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R than:BADURL:efax-0.9a-001114.tar.gz:efax than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils than:BADURL:kde-i18n-ar-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bg-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ca-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-cs-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-da-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-de-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-el-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-en_GB-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-es-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-et-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-he-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hu-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-is-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-it-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ja-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ko-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-lt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nb-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pa-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt_BR-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ro-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ru-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sv-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ta-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-tr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-uk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_CN-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_TW-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-l10n-ar-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-be-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ca-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-cs-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-csb-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-de-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-el-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-en_GB-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-eo-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-es-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-et-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-eu-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-fi-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-fr-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ga-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-gl-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-hi-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-hu-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-it-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ja-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-km-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ko-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-lv-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-mk-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-nb-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-nds-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ne-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-nl-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-nn-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-pa-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-pl-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt_BR-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-ru-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-se-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-sl-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-sv-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-th-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-tr-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-uk-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-wa-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_CN-4.0.80.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_TW-4.0.80.tar.bz2:kde-l10n than:BADURL:kdesdk-4.0.80.tar.bz2:kdesdk than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R than:BADURL:mozplugger-1.10.1.tar.gz:mozplugger than:BADURL:rp-pppoe-3.8.tar.gz:rp-pppoe than:BADURL:urw-fonts-1.0.7pre44.tar.bz2:urw-fonts than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans thias:BADSOURCE:libcaca-0.99.beta11.tar.gz:libcaca thias:BADSOURCE:Nevow-0.9.29.tar.gz:python-nevow thias:BADURL:DirectFB-1.0.0.tar.gz:directfb thias:BADURL:tagpy-0.94.1.tar.gz:python-tag thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime timj:BADURL:rapidsvn-0.9.6.tar.gz:rapidsvn timj:BADURL:rpl_1.5.3.tar.gz:rpl tmraz:BAD_CVS_SOURCE:Linux-PAM-1.0.1.tar.bz2.sign:pam tmraz:BADURL:Linux-PAM-1.0.1.tar.bz2:pam twaugh:BADSOURCE:ppa-0.8.6.tar.gz:pnm2ppa twaugh:BADURL:cups-1.3.7-source.tar.bz2:cups twaugh:BADURL:foomatic-db-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-engine-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-hpijs-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-filters-3.0-20080507.tar.gz:foomatic twaugh:BADURL:libieee1284-0.2.11.tar.bz2:libieee1284 varekova:BADURL:acct-6.3.2.tar.gz:psacct varekova:BADURL:gzip-1.3.12.tar.gz:gzip varekova:BADURL:mailx-8.1.1.tar.gz:mailx varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl varekova:BADURL:mpfr-2.3.0.tar.bz2:mpfr varekova:BADURL:unzip552.tar.gz:unzip varekova:BADURL:zcrypt29.tar.gz:zip varekova:BADURL:zip231.tar.gz:zip vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect vcrhonek:BADURL:pegasus-2.7.0.tar.gz:tog-pegasus veillard:BADURL:libxml2-2.6.32.tar.gz:libxml2 veillard:BADURL:opal-2.2.11.tar.gz:opal veillard:BADURL:pwlib-1.10.10.tar.gz:pwlib vlg:BADURL:granule-1.3.0.tar.gz:granule walters:BADURL:bigboard-0.5.33.tar.gz:bigboard walters:BADURL:desktop-data-model-1.2.4.tar.bz2:desktop-data-model walters:BADURL:online-desktop-0.2.28.tar.gz:online-desktop wtogami:BADURL:IO-Socket-INET6-2.54.tar.gz:perl-IO-Socket-INET6 xavierb:BADURL:xerces-c-src_2_7_0.tar.gz:xerces-c27 xgl-maint:BADURL:font-util-1.0.1.tar.bz2:xorg-x11-font-utils xgl-maint:BADURL:xf86-video-vesa-20080404.tar.bz2:xorg-x11-drv-vesa zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar zmc:BADSOURCE:pyspi-0.6.1.tar.gz:pyspi zprikryl:BADURL:eject-2.1.5.tar.gz:eject zprikryl:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Tue Jun 3 23:50:17 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 3 Jun 2008 18:50:17 -0500 Subject: source file audit - 2008-06-03 In-Reply-To: <20080603172954.69b3bb51@ohm.scrye.com> References: <20080603172954.69b3bb51@ohm.scrye.com> Message-ID: <935ead450806031650ld022a6kc3f2c21bd630fad4@mail.gmail.com> 2008/6/3 Kevin Fenzi : > > jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr > jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis These have been marked as dead in CVS although they weren't blocked from the repos before F9 was branched. They are no longer in rawhide AFAICS. Jeff From sgrubb at redhat.com Tue Jun 3 23:56:56 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 3 Jun 2008 19:56:56 -0400 Subject: rpmreaper In-Reply-To: <200806040000.41128.opensource@till.name> References: <20080603154111.GA24155@localhost> <200806031744.49706.sgrubb@redhat.com> <200806040000.41128.opensource@till.name> Message-ID: <200806031956.56968.sgrubb@redhat.com> On Tuesday 03 June 2008 18:00:35 Till Maas wrote: > On Tue June 3 2008, Steve Grubb wrote: > > Did we ever fix rpmbuild to gather shell script interdependencies? If > > not, a tool like this might think you can remove a package without > > realizing that a shell script calls a program in it. > > The dependencies need to be specified manually in the spec as Requires:, > then this won't happen. Not really. Bash has been patched to to spit out the programs it calls (/bin/bash --rpm-requires). So, its a matter of overriding %__find_requires to run a program that gathers the information for shell scripts and falls back to the old way for others. No one should have to specify this, it can be automated easily. Without taking shell scripts into account, you run the risk of breaking unspecified requirements. -Steve From michael at laptop.org Wed Jun 4 00:15:20 2008 From: michael at laptop.org (Michael Stone) Date: Tue, 3 Jun 2008 20:15:20 -0400 Subject: Help packaging some OLPC network status scripts? Message-ID: <20080604001517.GA30553@teach.media.mit.edu> Friends, Yani Galanis has pieced together a variety of source code and dependencies at http://dev.laptop.org/ticket/7171 http://dev.laptop.org/ticket/7172 http://dev.laptop.org/ticket/7174 archived in http://dev.laptop.org/git/projects/olpc-netutils which I'd really like to be able to include in OLPC's August software release. Could anyone here spare a few hours to make appropriate Fedora packages for this collection of scripts? Thanks very much, Michael Stone P.S. - For people in the OLPC community who are not already familiar with Fedora and the packaging process, please see http://wiki.laptop.org/go/Developer/Fedora for some background. From seg at haxxed.com Wed Jun 4 00:35:08 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 3 Jun 2008 19:35:08 -0500 Subject: rpmreaper In-Reply-To: <20080603154111.GA24155@localhost> References: <20080603154111.GA24155@localhost> Message-ID: <1218b5bc0806031735m7d19793bl47d8f2da57407026@mail.gmail.com> On Tue, Jun 3, 2008 at 10:41 AM, Miroslav Lichvar wrote: > Hi, > > I've put together a small ncurses application for removing unnecessary > packages and their dependencies from the system. If you create a full featured clone of aptitude on top of yum/rpm I will love you long time. Aptitude is the most awesome tool I have ever seen for cleaning up package cruft and interactively resolving arcane dep problems. Why can't yum's dep resolving be instantaneous? ;) Is there any recent success in getting aptitude itself to run on Fedora? It worked long ago in the days of FC3 but then it broke with newer versions of apt-rpm.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From konrad at tylerc.org Wed Jun 4 00:50:25 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Tue, 3 Jun 2008 17:50:25 -0700 Subject: rpmreaper In-Reply-To: <20080603211831.GA2598@free.fr> References: <20080603154111.GA24155@localhost> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> Message-ID: <200806031750.25368.konrad@tylerc.org> Quoth Patrice Dumas: > On Tue, Jun 03, 2008 at 04:27:40PM -0400, seth vidal wrote: > > > > It is very hard to remove python from a fedora system and have a > > functional (or even quasi-functional system) so why don't we start with > > that given. > > Nothing really important requires python yum isn't important, then? > (though a lot of packages > indeed requires it, including some that I wouldn't have thought they > required it, like tex vim-enhanced, subversion), while the libc and > ncurse are essential (required by bash for instance) so it is perfectly > right to code basic tasks in C and avoid python. Regards, -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From jeff at ocjtech.us Wed Jun 4 00:58:14 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 3 Jun 2008 19:58:14 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072528.A2064@humbolt.us.dell.com> References: <20080531072528.A2064@humbolt.us.dell.com> Message-ID: <935ead450806031758k73b77a7fxed0f97ed7f2b5632@mail.gmail.com> On Sat, May 31, 2008 at 7:25 AM, Matt Domsch wrote: > > python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie This is declared dead in CVS for F-9 and rawhide, but apparently they didn't get blocked from the repositories. Jeff From lightsolphoenix at gmail.com Wed Jun 4 01:02:44 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Tue, 03 Jun 2008 21:02:44 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <200806030836.m538aZNZ018313@tiffany.internal.tigress.co.uk> <4ee84c5f0806030226g34ce5570o5360b26568801502@mail.gmail.com> Message-ID: <4845E9B4.6030304@gmail.com> Guido Ledermann wrote: > I use Mono because I develop in C# to write programs for multiple OS C# is far from a good language to be using for cross-platform development. From lightsolphoenix at gmail.com Wed Jun 4 01:05:47 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Tue, 03 Jun 2008 21:05:47 -0400 Subject: Rawhide: PulseAudio currently broken Message-ID: <4845EA6B.20007@gmail.com> I've noticed that the Rawhide PulseAudio keeps throwing a floating point exception when I try to connect to it. From pemboa at gmail.com Wed Jun 4 01:08:41 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 3 Jun 2008 20:08:41 -0500 Subject: rpmreaper In-Reply-To: <200806031750.25368.konrad@tylerc.org> References: <20080603154111.GA24155@localhost> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> <200806031750.25368.konrad@tylerc.org> Message-ID: <16de708d0806031808p1ac8d1cfs7690748e8decdc40@mail.gmail.com> 2008/6/3 Konrad Meyer : > Quoth Patrice Dumas: >> On Tue, Jun 03, 2008 at 04:27:40PM -0400, seth vidal wrote: >> > >> > It is very hard to remove python from a fedora system and have a >> > functional (or even quasi-functional system) so why don't we start with >> > that given. >> >> Nothing really important requires python > > yum isn't important, then? I really like Python. But yum isn't _that_ important. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From mclasen at redhat.com Wed Jun 4 01:09:48 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 03 Jun 2008 21:09:48 -0400 Subject: strange koji build failures...? In-Reply-To: <484587A2.6050102@redhat.com> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> Message-ID: <1212541788.4899.10.camel@localhost.localdomain> On Tue, 2008-06-03 at 13:04 -0500, Eric Sandeen wrote: > Mamoru Tasaka wrote: > > Eric Sandeen wrote, at 06/04/2008 01:50 AM +9:00: > >> Trying to get newer ecryptfs-utils built I'm seeing something odd (or > >> not seeing something obvious...) > >> > >> http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log > > > > I just tried scratch build and it was all successful... > > http://koji.fedoraproject.org/koji/taskinfo?taskID=643448 > > > > Mamoru > > > > My scratch builds also were successful... and now a proper build was too. > > I think maybe there's a race somewhere... ? Any insight on this ? I'm seeing quite a few of my builds fail in the same way, with 'setting times of `' errors from cp or touch. The latest is: http://koji.fedoraproject.org/koji/getfile?taskID=644137&name=build.log From Matt_Domsch at dell.com Wed Jun 4 01:14:03 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 3 Jun 2008 20:14:03 -0500 Subject: block python-urljr In-Reply-To: <935ead450806031758k73b77a7fxed0f97ed7f2b5632@mail.gmail.com> References: <20080531072528.A2064@humbolt.us.dell.com> <935ead450806031758k73b77a7fxed0f97ed7f2b5632@mail.gmail.com> Message-ID: <20080604011403.GB18411@auslistsprd01.us.dell.com> On Tue, Jun 03, 2008 at 07:58:14PM -0500, Jeffrey Ollie wrote: > On Sat, May 31, 2008 at 7:25 AM, Matt Domsch wrote: > > > > python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie > > This is declared dead in CVS for F-9 and rawhide, but apparently they > didn't get blocked from the repositories. copying rel-eng to get it blocked. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jspaleta at gmail.com Wed Jun 4 01:22:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Jun 2008 17:22:47 -0800 Subject: rpmreaper In-Reply-To: <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> References: <20080603154111.GA24155@localhost> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> Message-ID: <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> On Tue, Jun 3, 2008 at 1:22 PM, Michael Wiktowy wrote: > You could argue about the utility of such a tool and what programming > language/libraries it uses (and I would agree with you for what its > worth) but is that really relevant to reviewing it for acceptance into > Extras? > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines doesn't say > anything about not reinventing the wheel and if it did we wouldn't > have a lot of things people feel pretty passionately about (redundant > desktop environments, search tools, editors ... you name the flamewar) > and Fedora would be a pretty stagnant distro. We have yet to come to a point where we make a requirement on value. I would however state that I would very much like to see this tool have its own upstream project space hosted somewhere, with a clear upstream source release, that could be used beyond Fedora. I don't need to see Suse packages..but if this is meant to be a generally useful tool for rpm distributions..it should be handled that way as an upstream project. If this is meant to be Fedora specific, well then I think we might have a stronger case to be made that Fedora specific tools should integrate well with the existing direction. Having a package hosted out of fedora people is probably not a good idea. In fact its probably something we should forbid. There's a big difference between setting up a project at fedora hosted and throwing up a tarball on your fedora people space. -jef From jeff at ocjtech.us Wed Jun 4 01:25:38 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 3 Jun 2008 20:25:38 -0500 Subject: source file audit - 2008-06-03 In-Reply-To: <935ead450806031650ld022a6kc3f2c21bd630fad4@mail.gmail.com> References: <20080603172954.69b3bb51@ohm.scrye.com> <935ead450806031650ld022a6kc3f2c21bd630fad4@mail.gmail.com> Message-ID: <935ead450806031825g22b35442u2c812e4c02263ba1@mail.gmail.com> On Tue, Jun 3, 2008 at 6:50 PM, Jeffrey Ollie wrote: > 2008/6/3 Kevin Fenzi : >> >> jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr >> jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis > > These have been marked as dead in CVS although they weren't blocked > from the repos before F9 was branched. They are no longer in rawhide > AFAICS. Actually, it looks like they haven't been blocked... I've sent a new message to rel-eng to have them blocked from the repo. Jeff From jspaleta at gmail.com Wed Jun 4 01:49:39 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Jun 2008 17:49:39 -0800 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> Message-ID: <604aa7910806031849n21f78edfw9c06fe1a1d66beb5@mail.gmail.com> On Sat, May 31, 2008 at 12:14 PM, Valent Turkovic wrote: > https://wiki.ubuntu.com/FlashExperienceIntrepid > > Have you maybe also talked with Ubuntu devels that made Ubuntu "Plugin > finder service" ? > Maybe they are willing to contribute their code and expertise to > upstream Mozilla for this ? Have I asked? No.. because frankly this is not an issue I care about. I personally do not care about flash because flash is not important to me. But clearly its important to you. If you want to push this approach as something Fedora should be doing then I need you to do two things as a starting point for a discussion. 1) I need you to point us specifically to the client side code that Ubuntu is using to add capabilities to Firefox. 2) I need you to point us specifically to the server side code that Ubuntu is using to create a service. There really isn't a lot to talk about until we can specifically look at the implementation they are using and whether its compatible with our policies. I'm going to withhold judgement on whether we can do something similar until I understand how their implementation works by being able to play with the source code they've already put together. -jef From mathstuf at gmail.com Tue Jun 3 21:51:43 2008 From: mathstuf at gmail.com (Ben Boeckel) Date: Tue, 3 Jun 2008 17:51:43 -0400 Subject: rpmreaper In-Reply-To: <1218b5bc0806031735m7d19793bl47d8f2da57407026@mail.gmail.com> References: <20080603154111.GA24155@localhost> <1218b5bc0806031735m7d19793bl47d8f2da57407026@mail.gmail.com> Message-ID: <200806032151.43313.MathStuf@gmail.com> On Wednesday 04 June 2008 00:35:08 Callum Lerwick wrote: > On Tue, Jun 3, 2008 at 10:41 AM, Miroslav Lichvar > > wrote: > > Hi, > > > > I've put together a small ncurses application for removing unnecessary > > packages and their dependencies from the system. > > If you create a full featured clone of aptitude on top of yum/rpm I will > love you long time. Aptitude is the most awesome tool I have ever seen for > cleaning up package cruft and interactively resolving arcane dep problems. > Why can't yum's dep resolving be instantaneous? ;) > > Is there any recent success in getting aptitude itself to run on Fedora? It > worked long ago in the days of FC3 but then it broke with newer versions of > apt-rpm.. I don't know about aptitude, but I use apt as my package manager. Synaptic is a great GUI for managing packages with apt, but I hardly ever use it (it works when I do though). One of the first things I do with a fresh install is `yum install synaptic`. --Ben From manolo at miconexion.com Wed Jun 4 02:23:34 2008 From: manolo at miconexion.com (Manuel Moreno) Date: Wed, 04 Jun 2008 03:23:34 +0100 Subject: rpmreaper In-Reply-To: <200806031956.56968.sgrubb@redhat.com> References: <20080603154111.GA24155@localhost> <200806031744.49706.sgrubb@redhat.com> <200806040000.41128.opensource@till.name> <200806031956.56968.sgrubb@redhat.com> Message-ID: <1212546214.3544.10.camel@mgmk7.mgmux.com> Small, _fast_ ( pythonists ;-), yum & al. are slowwww ), with only a few dependencies: very nice and useful. Some rough edges, though: dry run, multiarch. (x86_64 + i386), ... WFM. -- Manuel Moreno manolo at miconexion.com From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jun 4 02:45:17 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 04 Jun 2008 11:45:17 +0900 Subject: strange koji build failures...? In-Reply-To: <1212541788.4899.10.camel@localhost.localdomain> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> Message-ID: <484601BD.1080305@ioa.s.u-tokyo.ac.jp> Matthias Clasen wrote, at 06/04/2008 10:09 AM +9:00: > On Tue, 2008-06-03 at 13:04 -0500, Eric Sandeen wrote: >>> Eric Sandeen wrote, at 06/04/2008 01:50 AM +9:00: >>>> Trying to get newer ecryptfs-utils built I'm seeing something odd (or >>>> not seeing something obvious...) >>>> >>>> http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log > Any insight on this ? I'm seeing quite a few of my builds fail in the > same way, with 'setting times of `' errors from cp or touch. > The latest is: > > http://koji.fedoraproject.org/koji/getfile?taskID=644137&name=build.log Another example: https://bugzilla.redhat.com/show_bug.cgi?id=449328#c4 http://koji.fedoraproject.org/koji/getfile?taskID=644003&name=build.log It seems that something strange is really happening.. Mamoru From seg at haxxed.com Wed Jun 4 02:50:00 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 3 Jun 2008 21:50:00 -0500 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <4844D67F.7090307@slated.org> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> Message-ID: <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> On Tue, Jun 3, 2008 at 12:28 AM, Keith G. Robertson-Turner < fedora at slated.org> wrote: > 1. The decision to allow Mono to enter the tree seems to have been made > arbitrarily by Red Hat, with no community consultation, and in spite > of protests (including some by high profile Red Hat personnel - > mostly expressed as a rejection of Mono before the announcement). I think you are entirely mischaracterizing what happened. General Fedora policy is essentially a package is innocent until proven guilty. If it meets packaging policy, it can go in. (Keep in mind, policy does cover licensing and legal concerns) There was no decision to allow Mono in, rather, there was a decision to keep it *out* for legal reasons. Those legal concerns were addressed, thus Mono gets in by default. High profile people can protest it all they want, but unless a solid legal or technical issue can be presented, there's simply no grounds to disallow it. (Personally I'm a bit paranoid of Microsoft/C#/Mono myself, but I ? Tomboy. I just wish I could sync my Tomboy notes with Google somehow...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Wed Jun 4 03:31:20 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Jun 2008 19:31:20 -0800 Subject: rpmreaper In-Reply-To: <1212546214.3544.10.camel@mgmk7.mgmux.com> References: <20080603154111.GA24155@localhost> <200806031744.49706.sgrubb@redhat.com> <200806040000.41128.opensource@till.name> <200806031956.56968.sgrubb@redhat.com> <1212546214.3544.10.camel@mgmk7.mgmux.com> Message-ID: <604aa7910806032031ga36bb01x97cb0ab940576dcb@mail.gmail.com> On Tue, Jun 3, 2008 at 6:23 PM, Manuel Moreno wrote: > Some rough edges, though: dry run, multiarch. (x86_64 + i386), ... All of these these aspects would benefit from this being setup as its own upstream project, hosted somewhere appropriate with a communicated development roadmap and issue tracker and mailinglist, instead of first appearing as a package in fedora. -jef From jspaleta at gmail.com Wed Jun 4 03:36:07 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Jun 2008 19:36:07 -0800 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> Message-ID: <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> 2008/6/3 Callum Lerwick : > (Personally I'm a bit paranoid of Microsoft/C#/Mono myself, but I ? Tomboy. > I just wish I could sync my Tomboy notes with Google somehow...) I'm sure i'm not alone in saying that I would be interested in seeing an application that fills the role that tomboy currently does written in a language that has less of a legal cloud hanging over it which could be held up as a candidate to include in a default desktop install making tomboy less relevant to Fedora users who don't have a an existing preference for mono based apps. -jef From rayvd at bludgeon.org Wed Jun 4 04:36:05 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 3 Jun 2008 21:36:05 -0700 Subject: strange koji build failures...? In-Reply-To: <1212541788.4899.10.camel@localhost.localdomain> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> Message-ID: <20080604043605.GA29545@bludgeon.org> On Tue, Jun 03, 2008 at 09:09:48PM -0400, Matthias Clasen wrote: > On Tue, 2008-06-03 at 13:04 -0500, Eric Sandeen wrote: > > Mamoru Tasaka wrote: > > > Eric Sandeen wrote, at 06/04/2008 01:50 AM +9:00: > > >> Trying to get newer ecryptfs-utils built I'm seeing something odd (or > > >> not seeing something obvious...) > > >> > > >> http://koji.fedoraproject.org/koji/getfile?taskID=643262&name=build.log > > > > > > I just tried scratch build and it was all successful... > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=643448 > > > > > > Mamoru > > > > > > > My scratch builds also were successful... and now a proper build was too. > > > > I think maybe there's a race somewhere... ? > > Any insight on this ? I'm seeing quite a few of my builds fail in the > same way, with 'setting times of `' errors from cp or touch. > The latest is: > > http://koji.fedoraproject.org/koji/getfile?taskID=644137&name=build.log I had some weird build issues today. Seemed to fail only on the rawhide build and only with x86_64. It seemed to be erroring out in %doc trying to copy the README.txt file -- kind of like it was missing. I re-uploaded the source file and ran the build again and it worked fine at last... Two initial failed builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=643987 http://koji.fedoraproject.org/koji/taskinfo?taskID=644076 Build that succeeded after re-uploading the source portion: http://koji.fedoraproject.org/koji/taskinfo?taskID=644117 Everything had built fine and error free in my local x86_64 rawhide mock setup, so I was _pretty_ sure my package wasn't bad. Ray From sandeen at redhat.com Wed Jun 4 04:42:55 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 03 Jun 2008 23:42:55 -0500 Subject: strange koji build failures...? In-Reply-To: <20080604043605.GA29545@bludgeon.org> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> Message-ID: <48461D4F.9010000@redhat.com> Ray Van Dolson wrote: > I had some weird build issues today. Seemed to fail only on the > rawhide build and only with x86_64. It seemed to be erroring out in > %doc trying to copy the README.txt file -- kind of like it was missing. > I re-uploaded the source file and ran the build again and it worked > fine at last... > > Two initial failed builds: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=643987 > http://koji.fedoraproject.org/koji/taskinfo?taskID=644076 > > Build that succeeded after re-uploading the source portion: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=644117 > > Everything had built fine and error free in my local x86_64 rawhide > mock setup, so I was _pretty_ sure my package wasn't bad. Mine also only failed on x86_64 rawhide, as are the other failures I've seen. Interesting... Since it is cp failing I can't help but notice that coreutils was just upgraded to a new upstream version today... coincidence? -Eric From pemboa at gmail.com Wed Jun 4 04:52:31 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 3 Jun 2008 23:52:31 -0500 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> Message-ID: <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> On Tue, Jun 3, 2008 at 10:36 PM, Jeff Spaleta wrote: > 2008/6/3 Callum Lerwick : >> (Personally I'm a bit paranoid of Microsoft/C#/Mono myself, but I ? Tomboy. >> I just wish I could sync my Tomboy notes with Google somehow...) > > > I'm sure i'm not alone in saying that I would be interested in seeing > an application that fills the role that tomboy currently does written > in a language that has less of a legal cloud hanging over it which > could be held up as a candidate to include in a default desktop > install making tomboy less relevant to Fedora users who don't have a > an existing preference for mono based apps. KNote? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rayvd at bludgeon.org Wed Jun 4 04:56:18 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 3 Jun 2008 21:56:18 -0700 Subject: strange koji build failures...? In-Reply-To: <48461D4F.9010000@redhat.com> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> Message-ID: <20080604045618.GA29800@bludgeon.org> On Tue, Jun 03, 2008 at 11:42:55PM -0500, Eric Sandeen wrote: > Ray Van Dolson wrote: > > > I had some weird build issues today. Seemed to fail only on the > > rawhide build and only with x86_64. It seemed to be erroring out in > > %doc trying to copy the README.txt file -- kind of like it was missing. > > I re-uploaded the source file and ran the build again and it worked > > fine at last... > > > > Two initial failed builds: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=643987 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=644076 > > > > Build that succeeded after re-uploading the source portion: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=644117 > > > > Everything had built fine and error free in my local x86_64 rawhide > > mock setup, so I was _pretty_ sure my package wasn't bad. > > Mine also only failed on x86_64 rawhide, as are the other failures I've > seen. Interesting... > > Since it is cp failing I can't help but notice that coreutils was just > upgraded to a new upstream version today... coincidence? Is the mock setup on koji different from the one my mock syncs up again? My mock is querying the "default" Fedora mirrors setup for the latest rawhide stuff. Perhaps the coreutils on Koji's mock pulls from somewhere else... Ray From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jun 4 05:18:56 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 04 Jun 2008 14:18:56 +0900 Subject: strange koji build failures...? In-Reply-To: <20080604045618.GA29800@bludgeon.org> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> Message-ID: <484625C0.1000401@ioa.s.u-tokyo.ac.jp> Ray Van Dolson wrote, at 06/04/2008 01:56 PM +9:00: > On Tue, Jun 03, 2008 at 11:42:55PM -0500, Eric Sandeen wrote: >> Ray Van Dolson wrote: >> >>> I had some weird build issues today. Seemed to fail only on the >>> rawhide build and only with x86_64. It seemed to be erroring out in >>> %doc trying to copy the README.txt file -- kind of like it was missing. >>> I re-uploaded the source file and ran the build again and it worked >>> fine at last... >>> >>> Two initial failed builds: >>> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=643987 >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=644076 >>> >>> Build that succeeded after re-uploading the source portion: >>> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=644117 >>> >>> Everything had built fine and error free in my local x86_64 rawhide >>> mock setup, so I was _pretty_ sure my package wasn't bad. >> Mine also only failed on x86_64 rawhide, as are the other failures I've >> seen. Interesting... >> >> Since it is cp failing I can't help but notice that coreutils was just >> upgraded to a new upstream version today... coincidence? Maybe coreutils-6.12-1.fc10 should be untagged? > > Is the mock setup on koji different from the one my mock syncs up > again? My mock is querying the "default" Fedora mirrors setup for the > latest rawhide stuff. > > Perhaps the coreutils on Koji's mock pulls from somewhere else... > > Ray Yes, rawhide coreutils is still 6.11-4.fc10, where koji dist-f10 coreutils is already coreutils-6.12-1.fc10. You can enable [local] repo in /etc/mock/fedora-rawhide-XXX.cfg Mamoru From alexl at users.sourceforge.net Wed Jun 4 05:55:00 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 03 Jun 2008 22:55:00 -0700 Subject: rpm spec syntax change? (was Re: Fedora i386 rawhide rebuild in mock status 2008-06-01) In-Reply-To: <20080602085838.A5948@humbolt.us.dell.com> (Matt Domsch's message of "Mon\, 2 Jun 2008 08\:58\:38 -0500") References: <20080602085838.A5948@humbolt.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> Fedora Rawhide-in-Mock Build Results for i386 based on rawhide as MD> of 01-June-2008. [...] MD> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Some of these are my Perl packages: perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig All of these builds fail during %check: Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.54169 + umask 022 + cd /builddir/build/BUILD + cd GD-SVG-0.28 + unset DISPLAY /var/tmp/rpm-tmp.54169: line 26: syntax error near unexpected token `||' because of the following construct in the .spec file: %check || : make test Was there a change made in rpm that makes builds fail with this syntax? I didn't see any announcement and, at least at one point in time, I seem to recall that this was a legal and sometimes recommended form. (Although I should note that I did inherit the original .spec files from an earlier contributor). I assume that the solution is to just drop the "|| :" part? Alex From tsmetana at redhat.com Wed Jun 4 06:00:17 2008 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Wed, 4 Jun 2008 08:00:17 +0200 Subject: Heads up: file-4.24 missing magic.mime Message-ID: <20080604080017.3c27cd0c@dhcp-lab-165.englab.brq.redhat.com> Hello everyone, I have upgraded file package in rawhide to the latest version. Unfortunately the changes the upstream made break compatibility with the previous version. The plaintext magic file and magic.mime are not build anymore. I added the plaintext file "manually" by concatenating the definition files but the script that would create magic.mime is missing from the sources. I don't know of any package that would require magic.mime but if there exist some, please let me know. -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel From rc040203 at freenet.de Wed Jun 4 06:20:07 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Jun 2008 08:20:07 +0200 Subject: rpm spec syntax change? (was Re: Fedora i386 rawhide rebuild in mock status 2008-06-01) In-Reply-To: References: <20080602085838.A5948@humbolt.us.dell.com> Message-ID: <1212560408.3589.56.camel@beck.corsepiu.local> On Tue, 2008-06-03 at 22:55 -0700, Alex Lancaster wrote: > >>>>> "MD" == Matt Domsch writes: > > MD> Fedora Rawhide-in-Mock Build Results for i386 based on rawhide as > MD> of 01-June-2008. > > [...] > > MD> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Some of these are my Perl packages: > > perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig > perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig > perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig > perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig > > All of these builds fail during %check: > > Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.54169 > + umask 022 > + cd /builddir/build/BUILD > + cd GD-SVG-0.28 > + unset DISPLAY > /var/tmp/rpm-tmp.54169: line 26: syntax error near unexpected token `||' > > because of the following construct in the .spec file: > > %check || : > make test > > Was there a change made in rpm that makes builds fail with this > syntax? I didn't see any announcement and, at least at one point in > time, I seem to recall that this was a legal and sometimes recommended > form. (Although I should note that I did inherit the original .spec > files from an earlier contributor). > > I assume that the solution is to just drop the "|| :" part? Cf.: https://bugzilla.redhat.com/show_bug.cgi?id=449717 Ralf From jamatos at fc.up.pt Wed Jun 4 06:13:55 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Wed, 4 Jun 2008 07:13:55 +0100 Subject: rpm spec syntax change? (was Re: Fedora i386 rawhide rebuild in mock status 2008-06-01) In-Reply-To: References: <20080602085838.A5948@humbolt.us.dell.com> Message-ID: <200806040713.56100.jamatos@fc.up.pt> On Wednesday 04 June 2008 06:55:00 Alex Lancaster wrote: > Some of these are my Perl packages: > > perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig > perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig > perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig > perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig The same happened to python-imaging FWIW. -- Jos? Ab?lio From pmatilai at laiskiainen.org Wed Jun 4 06:55:19 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 4 Jun 2008 09:55:19 +0300 (EEST) Subject: rpmreaper In-Reply-To: <200806031956.56968.sgrubb@redhat.com> References: <20080603154111.GA24155@localhost> <200806031744.49706.sgrubb@redhat.com> <200806040000.41128.opensource@till.name> <200806031956.56968.sgrubb@redhat.com> Message-ID: On Tue, 3 Jun 2008, Steve Grubb wrote: > On Tuesday 03 June 2008 18:00:35 Till Maas wrote: >> On Tue June 3 2008, Steve Grubb wrote: >>> Did we ever fix rpmbuild to gather shell script interdependencies? If >>> not, a tool like this might think you can remove a package without >>> realizing that a shell script calls a program in it. >> >> The dependencies need to be specified manually in the spec as Requires:, >> then this won't happen. > > Not really. Bash has been patched to to spit out the programs it calls > (/bin/bash --rpm-requires). So, its a matter of overriding %__find_requires > to run a program that gathers the information for shell scripts and falls > back to the old way for others. > > No one should have to specify this, it can be automated easily. Without > taking shell scripts into account, you run the risk of breaking > unspecified requirements. I wish it were that simple. "bash --rpm-requires" does a fair job for the impossible task, but it produces way too much bogus information and false positives to be generally usable as is. A quick check at various scripts found on a stock F9 system shows at least these problems: 1) It mistakes functions declared in sourced scripts as executables 2) It mistakes functions used before declared as executables 3) It thinks of sourced scripts as executables 4) It produces hard dependencies for conditional items 5) For most executables, path is unknown I suppose fixing 1-3) in bash would be possible by scanning all involved scripts (sourced or otherwise) for functions before trying to produce the dependencies, but I haven't looked at how it does it's business. 4) is pretty much the showstopper. Multiplatform scripts have things like [ -x /sbin/solaris-specific ] && /sbin/solaris-specific which turn into executable(/sbin/solaris-specific), which can never be satisfied on a linux system. It doesn't have to be even multiplatform, or even cross-distro thing, there's more than enough of these kind of problems just from dealing with different hardware, compatibility with older systems etc. And there's no way to solve this programmatically, you'd need to manually filter any bogosities out. Assuming 1-3) are fixed and ignoring 4), 5) could be dealt with, at least to some extent, but it's a big can of worms too. For the dependencies to be discoverable by yum & friends, there would have to be matching provides for all executable(foo) items bash --rpm-requires produces. Rpm could automatically add Provides: executable(foo) for any file with executable bits on, but it would cause *enormous* bloat of metadata. Rpm could be taught to implicitly provide executable(basename) for files that have executable bits on, but that won't help yum (or other depsolvers) which don't use actual rpm headers but some other metadata that doesn't even have the executable information. If the file permission bits were added to the metadata, then depsolvers could fairly reliably figure out how to map executable(foo) requires into actual packages, without the hideous bloat of "physically" added executable(foo) provides in packages (assuming rpm is taught to deal with them too). So solving 5) should be possible if 1-3) were fixed, but it'd still be pretty moot because 4) can't generally be solved (apart from manually filtering bogus dependencies, at which point it's hardly "easily automated" :) - Panu - From jnovy at redhat.com Wed Jun 4 07:17:21 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 4 Jun 2008 09:17:21 +0200 Subject: rpmreaper In-Reply-To: <20080603211831.GA2598@free.fr> References: <1212508269.3774.21.camel@cutter> <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> Message-ID: <20080604071721.GA17317@dhcp-lab-186.brq.redhat.com> On Tue, Jun 03, 2008 at 11:18:31PM +0200, Patrice Dumas wrote: > On Tue, Jun 03, 2008 at 04:27:40PM -0400, seth vidal wrote: > > > > It is very hard to remove python from a fedora system and have a > > functional (or even quasi-functional system) so why don't we start with > > that given. > > Nothing really important requires python (though a lot of packages > indeed requires it, including some that I wouldn't have thought they > required it, like tex vim-enhanced, subversion), while the libc and > ncurse are essential (required by bash for instance) so it is perfectly > right to code basic tasks in C and avoid python. > Right, we should mainly focus on functionality. I was able to remove ~200 packages from my system saving ~3G of space without breaking of my system. The minimal dependency overhead is just a kind bonus as soon as embedding all of the depsolving machinery is not needed here. ...and it was kind of funny to hunt for useless packages as rpmreaper allows to see immediatelly which packages could be removed after removing a particular one. That was especially funny when checking the perl-* and mono-* stuff :) It would be nice to see an upstream of it somewhere. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From valent.turkovic at gmail.com Wed Jun 4 07:42:22 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jun 2008 09:42:22 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212321464.25062.2.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> Message-ID: <4846475E.5040804@gmail.com> Dan Williams wrote: > On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: >> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: >> >>> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: >>>> Dan Williams (dcbw at redhat.com) said: >>>>> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: >>>>>> During the boot I have some samba shares mounted because I have them >>>>>> configured to mount via fstab file. >>>>>> >>>>>> When I shutdown or reboot I get a screen for 2-3 minutes that shows >>>>>> smbfs service trying to unmount samba shares but NM service has >>>>>> already shutdown and there is no working network connection :( >>>>>> >>>>>> I have seen this "bad" behaviour in F8 and have reported it on this >>>>>> mailinglist, but I hoped that the new and smarter NM would take care >>>>>> of it, but unfortunately it didn't :( >>>>> Probably need to adjust the stop priorities of NM and haldaemon to be >>>>> right after messagebus (K85) rather than where they currently are... >>>>> The problem is that NM is being stopped to early. >>>> 'After netfs' should be good enough. Although netfs stop should possibly >>>> do lazy umounts. >>> Ok, just need to bump NM a few bits later it looks like; might as well >>> be K84 to be right after messagebus. >> Why not go all the way to 90 as network to be on the safe side? With a >> quick look I can see some scripts that might not be happy if the network >> is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. > > NM depend on messagebus at least, so we should stop NM right before > messagebus. But the same issues with startup are theoretically present > with shutdown, meaning that since messagebus depends on rsyslog, and > rsyslog depends on network. Standard installs don't use networked > syslog, so standard installs don't actually need rsyslog to depend on > network, but because rsyslog isn't smart enough to know when it does or > does not depend on network, we can't just re-order the chain... :( > > Dan > Dan what is the conclusion about this bug? This is a looong thread but nothing is updated on bugzilla page so is there some consensus on what needs to be done? Cheers, Valent. From mzerqung at 0pointer.de Wed Jun 4 08:05:54 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 4 Jun 2008 10:05:54 +0200 Subject: Rawhide: PulseAudio currently broken In-Reply-To: <4845EA6B.20007@gmail.com> References: <4845EA6B.20007@gmail.com> Message-ID: <20080604080553.GD6425@tango.0pointer.de> On Tue, 03.06.08 21:05, Kelly Miller (lightsolphoenix at gmail.com) wrote: > I've noticed that the Rawhide PulseAudio keeps throwing a floating point > exception when I try to connect to it. Please file bug reports on Bugzilla [1], that's why we have bz. Please don't spam fedora-devel, so that we don't decrease its signal-to-noise ratio further. Also, this bug report is relatively useless, since it doesn't include any information about the context you are experiencing this bug in. A stack trace [2] would be good too. [1] https://bugzilla.redhat.com/enter_bug.cgi [2] http://fedoraproject.org/wiki/StackTraces Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From alexl at users.sourceforge.net Wed Jun 4 08:26:23 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 04 Jun 2008 01:26:23 -0700 Subject: strange koji build failures...? In-Reply-To: <484625C0.1000401@ioa.s.u-tokyo.ac.jp> (Mamoru Tasaka's message of "Wed\, 04 Jun 2008 14\:18\:56 +0900") References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> <484625C0.1000401@ioa.s.u-tokyo.ac.jp> Message-ID: "MT" == Mamoru Tasaka writes: [...] MT> Maybe coreutils-6.12-1.fc10 should be untagged? > Is the mock setup on koji different from the one my mock syncs up > again? My mock is querying the "default" Fedora mirrors setup for the > latest rawhide stuff. > > Perhaps the coreutils on Koji's mock pulls from somewhere else... > > Ray MT> Yes, rawhide coreutils is still 6.11-4.fc10, where koji dist-f10 MT> coreutils is already coreutils-6.12-1.fc10. You can enable [local] MT> repo in /etc/mock/fedora-rawhide-XXX.cfg I can also confirm two similar build failures, both with "touch": f-spot: http://koji.fedoraproject.org/koji/getfile?taskID=644642&name=build.log perl-Convert-Binary-C: http://koji.fedoraproject.org/koji/getfile?taskID=644607&name=build.log Alex From alexl at users.sourceforge.net Wed Jun 4 08:41:03 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 04 Jun 2008 01:41:03 -0700 Subject: strange koji build failures...? In-Reply-To: (Alex Lancaster's message of "Wed\, 04 Jun 2008 01\:26\:23 -0700") References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> <484625C0.1000401@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "AL" == Alex Lancaster writes: AL> "MT" == Mamoru Tasaka writes: AL> [...] MT> Maybe coreutils-6.12-1.fc10 should be untagged? >> Is the mock setup on koji different from the one my mock syncs up >> again? My mock is querying the "default" Fedora mirrors setup for >> the latest rawhide stuff. >> >> Perhaps the coreutils on Koji's mock pulls from somewhere else... >> >> Ray MT> Yes, rawhide coreutils is still 6.11-4.fc10, where koji dist-f10 MT> coreutils is already coreutils-6.12-1.fc10. You can enable [local] MT> repo in /etc/mock/fedora-rawhide-XXX.cfg I filed a bug with infrastructure notifying them of the problem and requesting this (at least temporarily): https://fedorahosted.org/fedora-infrastructure/ticket/593 I couldn't find a corresponding bug on the actual underlying coreutils problem in bugzilla. If somebody files one, please link it from trac bug above and vice-versa. Alex From rmy at tigress.co.uk Wed Jun 4 08:01:27 2008 From: rmy at tigress.co.uk (Ron Yorston) Date: Wed, 04 Jun 2008 09:01:27 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> Message-ID: <200806040801.m5481SJM019003@tiffany.internal.tigress.co.uk> "Jeff Spaleta" wrote: >I'm sure i'm not alone in saying that I would be interested in seeing >an application that fills the role that tomboy currently does written >in a language that has less of a legal cloud hanging over it which >could be held up as a candidate to include in a default desktop >install making tomboy less relevant to Fedora users who don't have a >an existing preference for mono based apps. As it happens the Roundup feature in the latest issue of Linux Format covers note-taking applications. They speak highly of Basket and NoteCase, both of which are in Fedora Extras^WEverything. I wouldn't know, I use vi. Ron From ovasik at redhat.com Wed Jun 4 08:44:53 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 04 Jun 2008 10:44:53 +0200 Subject: strange koji build failures...? In-Reply-To: References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> <484625C0.1000401@ioa.s.u-tokyo.ac.jp> Message-ID: <1212569093.3957.11.camel@dhcp-lab-219.englab.brq.redhat.com> Alex Lancaster wrote: > MT> Maybe coreutils-6.12-1.fc10 should be untagged? > > Perhaps the coreutils on Koji's mock pulls from somewhere else... > I can also confirm two similar build failures, both with "touch": > > f-spot: > http://koji.fedoraproject.org/koji/getfile?taskID=644642&name=build.log Problem likely caused by gl_futimens() (which is used in install,cp,mv and touch) and quiet old koji xen kernel. I had issues with failures of touch test suite in the past - as futimensat call returned absolute nonsense number(filled as #442352). It seems to be changed - now kernel returns ENOSYS(at least it seemed so as coreutils-6.12 test suite was failing due this). I used recent patch from upstream which fixed test suite failures. Now it seems that the issue is not fully fixed and it still needs some improvement. Strace of the failure is on the way(building ;) ) and I hope it will help me to at least workaround the issue with koji build asap. Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From alexl at users.sourceforge.net Wed Jun 4 09:01:50 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 04 Jun 2008 02:01:50 -0700 Subject: strange koji build failures...? In-Reply-To: <1212569093.3957.11.camel@dhcp-lab-219.englab.brq.redhat.com> (=?utf-8?B?Ik9uZMWZZWogVmHFocOtayIncw==?= message of "Wed\, 04 Jun 2008 10\:44\:53 +0200") References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> <484625C0.1000401@ioa.s.u-tokyo.ac.jp> <1212569093.3957.11.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <53ej7d1sld.fsf@allele2.eebweb.arizona.edu> >>>>> "OV" == Ond?ej Va??k writes: OV> Alex Lancaster wrote: MT> Maybe coreutils-6.12-1.fc10 should be untagged? >> > Perhaps the coreutils on Koji's mock pulls from somewhere else... >> I can also confirm two similar build failures, both with "touch": >> >> f-spot: >> http://koji.fedoraproject.org/koji/getfile?taskID=644642&name=build.log OV> Problem likely caused by gl_futimens() (which is used in OV> install,cp,mv and touch) and quiet old koji xen kernel. I had OV> issues with failures of touch test suite in the past - as OV> futimensat call returned absolute nonsense number(filled as OV> #442352). It seems to be changed - now kernel returns ENOSYS(at OV> least it seemed so as coreutils-6.12 test suite was failing due OV> this). I used recent patch from upstream which fixed test suite OV> failures. Now it seems that the issue is not fully fixed and it OV> still needs some improvement. Strace of the failure is on the OV> way(building ;) ) and I hope it will help me to at least OV> workaround the issue with koji build asap. For others following this, I filed a bug against the actual coreutils component: https://bugzilla.redhat.com/show_bug.cgi?id=449910 Alex From rawhide at fedoraproject.org Wed Jun 4 09:43:51 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 4 Jun 2008 09:43:51 +0000 (UTC) Subject: rawhide report: 20080604 changes Message-ID: <20080604094352.0F0A6209CDA@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080603/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080604/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package fig2sxd A fig to sxd file converter New package file-browser-applet File Browser Applet for the GNOME Panel New package knetworkmanager KDE applet for Network Manager New package pyodbc Python DB API 2.0 Module for ODBC New package tuxcmd Tux Commander: file manager with 2 panels side by side using GTK2 Updated Packages: GConf2-2.22.0-10.fc10 --------------------- * Mon Jun 2 18:00:00 2008 Matthias Clasen - 2.22.0-10 - Make gconfd notice defaults changes Inventor-2.1.5-33.fc10 ---------------------- * Tue Jun 3 18:00:00 2008 Ralf Cors??pius - 2.1.5-33 - Add -fnostrict-aliasing to VCXXOPTS to work around GCC-4.3 breakage. * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 2.1.5-32 - Autorebuild for GCC 4.3 Pyrex-0.9.8.2-1.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Matthew Barnes - 0:0.9.8.2-1 - Update to 0.9.8.2 * Mon Jun 2 18:00:00 2008 Kyle VanderBeek - 0:0.9.6.4-3 - rpmlint cleanup WebKit-1.0.0-0.12.svn34279.fc10 ------------------------------- * Tue Jun 3 18:00:00 2008 Mamoru Tasaka - 1.0.0-0.11.svn34279 - Update to new upstream snapshot (SVN 34279) anyway - Add BR: libXt-devel * Tue Jun 3 18:00:00 2008 Caol??n McNamara - 1.0.0-0.12.svn34279 - rebuild for new icu adminutil-1.1.6-1.fc10 ---------------------- at-spi-1.23.3-1.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 1.23.3-1 - Update to 1.23.3 bash-3.2-25.fc10 ---------------- * Tue Jun 3 18:00:00 2008 Roman Rakus - 3.2-25 - #449512 - reverting back last change - don't use glob library boost-1.34.1-15.fc10 -------------------- * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 1.34.1-15 - fix license tag * Thu Mar 27 18:00:00 2008 Petr Machata - 1.34.1-14 - Change devel-static back to static. - Related: #225622 cairo-dock-1.5.6-2.svn1071_trunk.fc10 ------------------------------------- * Tue Jun 3 18:00:00 2008 Mamoru Tasaka - svn 1071 cobbler-1.0.1-2.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Michael DeHaan - 1.0.1-1 - Upstream changes (see CHANGELOG) - stop owning files in tftpboot - condrestart for Apache control-center-2.23.2-2.fc10 ---------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.2-2 - Make changing default backgrounds work better coreutils-6.12-1.fc10 --------------------- * Mon Jun 2 18:00:00 2008 Ondrej Vasik - 6.12-1 - New upstream release 6.12, adapted patches * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 6.11-5 - fix SHA256/SHA512 to work on sparc cpio-2.9.90-1.fc10 ------------------ * Mon Jun 2 18:00:00 2008 Ondrej Vasik 2.9.90-1 - new upstream alpha version 2.9.90 + removed applied patches crypto-utils-2.4-2 ------------------ * Tue Jun 3 18:00:00 2008 Elio Maldonado - 2.4-2 - removed unneeded declaration in pemutil * Tue Jun 3 18:00:00 2008 Elio Maldonado - 2.4-1 - crypto-utils ported to use NSS for cryptography (#346731) - updated documentation accordingly cups-1.3.7-6.fc10 ----------------- * Tue Jun 3 18:00:00 2008 Tim Waugh 1:1.3.7-6 - Applied patch to fix STR #2750 (IPP authentication). dbus-qt3-0.8.1-1.20080603svn.fc10 --------------------------------- * Tue Jun 3 18:00:00 2008 Rex Dieter 0.8.1-1.20080603svn - 20080603svn snapshot docbook-style-xsl-1.74.0-1.fc10 ------------------------------- * Tue Jun 3 18:00:00 2008 Ondrej Vasik 1.74.0-1 - New upstream release 1.74.0, adapted patches dovecot-1.0.14-1.fc10 --------------------- * Tue Jun 3 18:00:00 2008 Dan Horak - 1:1.0.14-1 - update to upstream version 1.0.14 - remove setcred patch (use of setcred must be explictly enabled in config) ecryptfs-utils-46-0.fc10 ------------------------ * Tue Jun 3 18:00:00 2008 Eric Sandeen 46-0 - New upstream version evolution-remove-duplicates-0.0.4-1.fc10 ---------------------------------------- * Tue Jun 3 18:00:00 2008 Michel Salim - 0.0.4-1 - Update to 0.0.4 fedora-ds-dsgw-1.1.0-1.fc10 --------------------------- file-4.24-3.fc10 ---------------- * Wed Jun 4 18:00:00 2008 Tomas Smetana - 4.24-3 - drop patches that do nothing in recent build system - create the text magic file during installation * Tue Jun 3 18:00:00 2008 Tomas Smetana - 4.24-2 - rebuild because of egg-info * Tue Jun 3 18:00:00 2008 Tomas Smetana - 4.24-1 - new upstream version file-roller-2.23.2-1.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 firstaidkit-0.2.0-1.fc10 ------------------------ * Tue Jun 3 18:00:00 2008 Joel Granados 0.2.0-1 - New upstream version - Fixup the spec file - Erase the unneeded patch files gbrainy-0.70-1.fc10 ------------------- * Tue Jun 3 18:00:00 2008 Beno??t Marcelin 0.70-1 - Update to 0.70 - 8 new puzzles - License included in the about box - The drawing area is now square and the application resizes better - Better score feedback - Player's history - Preferences persistence - Better game selection - Bug fixes gcstar-1.4.0-1.fc10 ------------------- * Tue Jun 3 18:00:00 2008 Tian - 1.4.0-1 - New upstream version gnome-sharp-2.16.1-2.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Xavier Lamien - 2.16.1-2 - Rebuild against new gtk-sharp2. gnome-subtitles-0.8-3.fc10 -------------------------- * Mon May 26 18:00:00 2008 Julian Sikorski - 0.8-3 - Rebuilt to fix broken deps gnome-terminal-2.23.3-1.fc10 ---------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.22.3-1 - Update to 2.23.3 * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 2.22.1-2 - fix license tag (GFDL+ is the same as GFDL) gnome-themes-2.23.3-1.fc10 -------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 * Sun May 4 18:00:00 2008 Matthias Clasen - 2.23.1-2 - Fix source url gstreamer-plugins-good-0.10.8-5.fc10 ------------------------------------ * Tue Jun 3 18:00:00 2008 - Bastien Nocera - 0.10.8-5 - Fix compilation of the v4l2 plugin with newer kernels * Mon Jun 2 18:00:00 2008 - Bastien Nocera - 0.10.8-4 - Work-around bug that would set the default audio output to "GOOM!" See http://bugzilla.gnome.org/show_bug.cgi?id=532295 * Wed May 21 18:00:00 2008 Tom "spot" Callaway 0.10.8-3 - fix license tag * Wed May 21 18:00:00 2008 Adam Jackson 0.10.8-2 - BR: libsoup-devel and package the soup http src plugin. (#447604) - s/Fedora Core/Fedora/ gtksourceview2-sharp-1.0-2.svn89788.2.fc10 ------------------------------------------ * Fri May 30 18:00:00 2008 Paul F. Johnson - 1.0-2.svn89877.2 - rebuild for new gtk-sharp2 * Thu May 1 18:00:00 2008 Paul F. Johnson - 1.0-2.svn89877.1 - rebuild guilt-0.30-2.fc10 ----------------- * Mon Jun 2 18:00:00 2008 Eric Sandeen 0.30-2 - Fix regression test output for new versions of git (#440169) hplip-2.8.5-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Tim Waugh 2.8.5-1 - 2.8.5. - Configure with --enable-dbus. Build requires dbus-devel. - Fix chmod 644 line. - Ship hp-systray in the gui sub-package, but don't ship the desktop launcher yet as the systray applet is quite broken. - Don't run autoconf. icu-4.0-0.1.d02.fc10 -------------------- * Sat May 31 18:00:00 2008 Caolan McNamara - 4.0-0.1.d02 - 4.0 release candidate - drop integrated icu.regexp.patch intltool-0.40.0-1.fc10 ---------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 0.40.0-1 - Update to 0.40.0 iputils-20071127-3.fc10 ----------------------- * Tue Jun 3 18:00:00 2008 Martin Nagy - 20071127-3 - major patch cleanup so it will be easier to get patches upstream - fix for #68212, previous fix actually didn't work for ping6 - renewed the ia64 align patches - update README.bonding - clear up the code from warnings - spec file cleanup java-1.6.0-openjdk-1.6.0.0-0.16.b09.fc10 ---------------------------------------- * Tue Jun 3 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.16.b09 - Add runtests define. - Provide Xvfb instance to jtreg. - Run test suites on JIT architectures only. - Clean up arch handling. * Fri May 30 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Remove makefile patch. - Update generate-fedora-zip.sh. * Fri May 30 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Remove jhat patch. * Fri May 30 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Group all Mauve commands. * Fri May 30 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Formatting cleanups. - Add jtreg_output to src subpackage. * Fri May 30 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Formatting cleanups. * Wed May 28 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.15.b09 - Updated icedteasnapshot for new release. * Tue May 27 18:00:00 2008 Thomas Fitzsimmons - 1:1.6.0.0-0.15.b09 - Require ca-certificates. - Symlink to ca-certificates cacerts. - Remove cacerts from files list. - Resolves: rhbz#444260 * Mon May 26 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.14.b09 - Added eclipse-ecj build requirement for mauve. - Updated icedteasnapshot. * Fri May 23 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.14.b09 - Updated icedteasnapshot. - Updated release. - Added jtreg testing. jd-2.0.0-0.6.svn2102_trunk.fc10.1 --------------------------------- * Wed Jun 4 18:00:00 2008 Mamoru Tasaka - svn 2102 * Mon Jun 2 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.6.beta20080601 - 2.0.0 beta 20080601 * Mon Jun 2 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.5.svn2081_trunk - Workarround for bug 449225 kdebase-workspace-4.0.80-3.fc10 ------------------------------- * Tue Jun 3 18:00:00 2008 Kevin Kofler 4.0.80-3 - enable NetworkManager support, now compatible with NM 0.7 kdelibs3-3.5.9-14.fc10 ---------------------- * Tue Jun 3 18:00:00 2008 Rex Dieter 3.5.9-14 - revert kdeui symlink hack (there be dragons) - unbreak -apidocs, add %check so this never ever happens again lcms-1.17-5.fc10 ---------------- * Tue Jun 3 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.17-5 - Fix Array indexing error in ReadCurve - #448066 libgsasl-0.2.26-1.fc10 ---------------------- * Tue Jun 3 18:00:00 2008 Nikolay Vladimirov 0.2.26-1 - new upstream * Sat Mar 29 18:00:00 2008 Nikolay Vladimirov - 0.2.25-1 - new upstream release meld-1.1.5-5.fc10 ----------------- * Tue Jun 3 18:00:00 2008 Brian Pepple - 1.1.5-5 - Backport git support (#449250). msort-8.46-2.fc10 ----------------- * Tue Jun 3 18:00:00 2008 Caol??n McNamara - 8.46-2 - rebuild for new icu openoffice.org-3.0.0-0.0.15.1.fc10 ---------------------------------- * Tue Jun 3 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.15-1 - next version - add openoffice.org-2.3.0.oooXXXXX.odk.3layer.patch for building against 3 layer OOo - drop integrated openoffice.org-3.0.0.ooo88260.decl-defi-mismatch.patch - drop integrated openoffice.org-3.0.0.ooo89172.filter.string.patch - filter out -fasynchronous-unwind-tables for the moment until its ok with -Os on i386 - Resolves: rhbz#448553 add openoffice.org-3.0.0.ooo90037.vcl.cairotransforms.patch * Wed May 28 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.14-1 - next version - Require new hunspell-ml for Malayalam langpack - drop integrated openoffice.org-2.3.1.ooo84621.sw.insertexcel.patch - drop integrated openoffice.org-2.4.0.ooo85097.desktop.pagein.patch - add openoffice.org-3.0.0.ooo89921.oox.parallel.patch - Resolves: rhbz#445588 add openoffice.org-3.0.0.ooo87970.vcl.samenamesubs.patch - add openoffice.org-3.0.0.ooo90055.swext.allowadmin.patch openssl-0.9.8g-10.fc10 ---------------------- * Mon Jun 2 18:00:00 2008 Joe Orton 0.9.8g-10 - move root CA bundle to ca-certificates package orca-2.23.3-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 pango-1.21.2-1.fc10 ------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 1.21.2-1 - Update to 1.21.2 * Mon May 26 18:00:00 2008 Tom "spot" Callaway - 1.21.1-2 - add sparc64 to multilib handling perl-Text-Kakasi-2.04-9.fc10 ---------------------------- * Tue Jun 3 18:00:00 2008 Akira TAGOH - 2.04-9 - Fix FTFBS. (#449405) powerman-2.0-1.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Jarod Wilson 2.0-1 - New upstream release psacct-6.3.2-51.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Ivana Varekova - 6.3.2-51 - remove unwanted file python-imaging-1.1.6-10.fc10 ---------------------------- * Tue Jun 3 18:00:00 2008 Joel Granados - 1.1.6-10 - Fix the build. selinux-policy-3.4.1-2.fc10 --------------------------- sword-1.5.11-2.fc10 ------------------- * Tue Jun 3 18:00:00 2008 Caol??n McNamara - 1.5.11-2 - rebuild for new icu system-config-printer-1.0.0-2.fc10 ---------------------------------- * Tue Jun 3 18:00:00 2008 Tim Waugh 1.0.0-2 - Applied patches from upstream (bug #449753). * Thu May 29 18:00:00 2008 Tim Waugh - Updated pycups to 1.9.39. - Updated libs summary. trousers-0.3.1-8.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Emily Ratliff - 0.3.1-8 - Fix cast issue preventing successful build on ppc64 and x86_64 * Tue Jun 3 18:00:00 2008 Emily Ratliff - 0.3.1-7 - Fix for BZ #434267 and #440733. Patch authored by Debora Velarde * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.3.1-6 - Autorebuild for GCC 4.3 udev-121-2.20080516git.fc10 --------------------------- * Tue Jun 3 18:00:00 2008 Jeremy Katz - 121-2.20080516git - Add lost F9 change to remove /dev/.udev in start_udev (#442827) vim-7.1.305-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Karsten Hopp 7.1.305-1 - patchlevel 305 - put /etc/vimrc autocmd's into fedora augroup (similar to #241308) yaz-3.0.26-2.fc10 ----------------- * Tue Jun 3 18:00:00 2008 Caol??n McNamara - 3.0.26-2 - rebuild for new icu Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 60 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicui18n.so.38()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From choeger at cs.tu-berlin.de Wed Jun 4 09:56:02 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 04 Jun 2008 11:56:02 +0200 Subject: Slightly Off Topic: mod_python performance Message-ID: <1212573362.3134.8.camel@choeger6> Hi folks, this message does not really handle fedora-devel stuff, but I thought there might be some apache/mod_python pros out here who could give me a hand. I'm having a severe performance issue with a cutom trac plugin I wrote on an ubuntu server. This plugins runs with mod_python on an apache, in the lates trac environment. Versions are 2.2.4 apache and 3.3.1 mod_python. This server has a 3Ghz PIV cpu and 512Megs of RAM. Here the complete request (tested with wget on that machine itself) takes 4-5 seconds to finish. When I run that plugin on my notebook which has an intel T8300 with 2,4Ghz I get a 1 second answer. Is that completely hardware driven (I mean a 3-4 times better performance on a notebook, WOW)? Or is there a magic "TURN_ON_FEDORA_PERFORMANCE" switch I missed? thanks christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From valent.turkovic at gmail.com Wed Jun 4 10:19:41 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jun 2008 12:19:41 +0200 Subject: Fedora 10 and flash? In-Reply-To: <604aa7910806031849n21f78edfw9c06fe1a1d66beb5@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> <604aa7910806031849n21f78edfw9c06fe1a1d66beb5@mail.gmail.com> Message-ID: <64b14b300806040319x5506b67bl50f6e2271abcb06e@mail.gmail.com> On Wed, Jun 4, 2008 at 3:49 AM, Jeff Spaleta wrote: > On Sat, May 31, 2008 at 12:14 PM, Valent Turkovic > wrote: >> https://wiki.ubuntu.com/FlashExperienceIntrepid >> >> Have you maybe also talked with Ubuntu devels that made Ubuntu "Plugin >> finder service" ? >> Maybe they are willing to contribute their code and expertise to >> upstream Mozilla for this ? > > > Have I asked? No.. because frankly this is not an issue I care about. > I personally do not care about flash because flash is not important > to me. > > But clearly its important to you. If you want to push this approach > as something Fedora should be doing then I need you to do two things > as a starting point for a discussion. > 1) I need you to point us specifically to the client side code that > Ubuntu is using to add capabilities to Firefox. > 2) I need you to point us specifically to the server side code that > Ubuntu is using to create a service. > > There really isn't a lot to talk about until we can specifically look > at the implementation they are using and whether its compatible with > our policies. I'm going to withhold judgement on whether we can do > something similar until I understand how their implementation works by > being able to play with the source code they've already put together. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'm talking with Alexander Sack (asac) on #ubuntu-mozillateam on freenode. They are talking that their implementation is thought to be an example how it can be done right in the end all this should go to the Tools -> Addons dialog of Firefox. That will be done upstream in a way that allows distributors to hook in new install methods So it looks like Fedora should talk with ubuntu mozilla team to make this happen. Alexander doesn't know you Jeff but he knows Caillon pretty well. I pointed him to https://fedoraproject.org/wiki/JefSpaleta but that page seams to have very little information on who you are and what you do in Fedora Project. All the code is in ubufox bzr branch link is here: http://code.launchpad.net/ubufox Cheers, 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 mlichvar at redhat.com Wed Jun 4 11:13:42 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 4 Jun 2008 13:13:42 +0200 Subject: rpmreaper In-Reply-To: <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> References: <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> Message-ID: <20080604111342.GB28608@localhost> On Tue, Jun 03, 2008 at 05:22:47PM -0800, Jeff Spaleta wrote: > Having a package hosted out of fedora people is probably not a good > idea. In fact its probably something we should forbid. There's a > big difference between setting up a project at fedora hosted and > throwing up a tarball on your fedora people space. Ok, I have filed a hosting request on fedorahosted. -- Miroslav Lichvar From jspaleta at gmail.com Wed Jun 4 12:14:59 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 04:14:59 -0800 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300806040319x5506b67bl50f6e2271abcb06e@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> <604aa7910806031849n21f78edfw9c06fe1a1d66beb5@mail.gmail.com> <64b14b300806040319x5506b67bl50f6e2271abcb06e@mail.gmail.com> Message-ID: <604aa7910806040514p4610b7c5t88a138d65179557b@mail.gmail.com> On Wed, Jun 4, 2008 at 2:19 AM, Valent Turkovic wrote: > Alexander doesn't know you Jeff but he knows Caillon pretty well. I > pointed him to https://fedoraproject.org/wiki/JefSpaleta but that page > seams to have very little information on who you are and what you do > in Fedora Project. Why on earth would you point someone to my wiki page...when the conversation is happening here..in an open list. What I do is not important.. no more important that what you do for this project. If you have the freedom to ask this list about implementing a flash service that mimics Ubuntu, then I have the freedom to request you bring technical specifics to the discussion instead of asking other people to do that work for you. You've brought this up for general discussion and I think its appropriate that you make the effort to address the concerns in public. What I do in the Fedora project is rather unimportant to the question at hand. The fact that I'm an elected representative on the Fedora Board and thus have been given a mandate by the Fedora community to guide overall project direction has absolutely no bearing on whether or not you provide the information I have asked for in this list in response to your interest. The question at hand is whether or not we can run a service in a way that is not in conflict to our policies concerning pointing people to 3rd party repositories. I continue to withhold judgment, until I can see the service code that Ubuntu uses to run their service. But I am skeptical we can do it via a service we ourselves host considering our current policy concerning not pointing our users to 3rd party repositories. Bastien has already hinted at the approach will probably end up making use of.. exposing mime types via rpm provides..which in turn can be resolved through repository metadata, which can all be done without a central service that we have to host. > All the code is in ubufox bzr branch link is here: > http://code.launchpad.net/ubufox Does that include the code for the service that ubuntu runs or is that just the client code that talks to the service? The client code isn't the issue... its the service we'd have to run centrally on Fedora project infrastructure that is going to be problematic. -jef From pertusus at free.fr Wed Jun 4 12:15:10 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 14:15:10 +0200 Subject: rpmreaper In-Reply-To: <1212529172.22357.66.camel@londonpacket.bos.redhat.com> References: <20080603162810.GA26319@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> <1212529172.22357.66.camel@londonpacket.bos.redhat.com> Message-ID: <20080604121510.GA2585@free.fr> On Tue, Jun 03, 2008 at 05:39:32PM -0400, Jon Masters wrote: > > I think that used to be true. FWIW, I agree with the notion that python > shouldn't have to be a fundamental dependency on Linux systems, but it's > gone that way long since, so we should live with it and embrace it :) That's untrue, and we don't need to do anything specific rpm handles dependencies right anyway. -- Pat From pertusus at free.fr Wed Jun 4 12:24:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 14:24:32 +0200 Subject: rpmreaper In-Reply-To: <200806031750.25368.konrad@tylerc.org> References: <20080603154111.GA24155@localhost> <1212524860.3774.42.camel@cutter> <20080603211831.GA2598@free.fr> <200806031750.25368.konrad@tylerc.org> Message-ID: <20080604122432.GB2585@free.fr> On Tue, Jun 03, 2008 at 05:50:25PM -0700, Konrad Meyer wrote: > Quoth Patrice Dumas: > > > > Nothing really important requires python > > yum isn't important, then? It is important for some use cases, but not really vital, for 2 reasons. First there are substitutes (apt, smart -- and urpmi would certainly work on fedora too), and second it is not really required, if one can use rpm directly. I would argue, however, that rpm is a vital part of fedora. To be more precise, it seems to me that rpm and its dependency is what defines a fedora system (with some additional bits like rootfiles), even though it is possible to install much less in chroots. -- Pat From jspaleta at gmail.com Wed Jun 4 12:26:51 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 04:26:51 -0800 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> Message-ID: <604aa7910806040526n17782900m960750ebc5ffccba@mail.gmail.com> 2008/6/3 Arthur Pemberton : > KNote? I think its pretty clear at this point that default applications for a given desktop environment should attempt to be native toolkit. We'd need a damn good reason to want to prefer a qt based app as a default app in GNOME... no matter what the functionality gap is between applications in the same space. So making knote a default installed application for a GNOME desktop would be less than optimal. But if KDE users want to use it as a default, fine by me. -jef From pertusus at free.fr Wed Jun 4 12:28:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 14:28:53 +0200 Subject: Help packaging some OLPC network status scripts? In-Reply-To: <20080604001517.GA30553@teach.media.mit.edu> References: <20080604001517.GA30553@teach.media.mit.edu> Message-ID: <20080604122853.GC2585@free.fr> On Tue, Jun 03, 2008 at 08:15:20PM -0400, Michael Stone wrote: > Friends, > > Yani Galanis has pieced together a variety of source code and > dependencies at > > http://dev.laptop.org/ticket/7171 > http://dev.laptop.org/ticket/7172 > http://dev.laptop.org/ticket/7174 > > archived in > > http://dev.laptop.org/git/projects/olpc-netutils I think that it should be better to do a proper release first. -- Pat From billcrawford1970 at gmail.com Wed Jun 4 13:49:02 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 4 Jun 2008 14:49:02 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <604aa7910806040526n17782900m960750ebc5ffccba@mail.gmail.com> References: <8g2ch5-52b.ln1@sky.matrix> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> <604aa7910806040526n17782900m960750ebc5ffccba@mail.gmail.com> Message-ID: <544eb990806040649y68c8ecbes3e45d5d2c7b9b09e@mail.gmail.com> 2008/6/4 Jeff Spaleta : > I think its pretty clear at this point that default applications for a > given desktop environment should attempt to be native toolkit. We'd > need a damn good reason to want to prefer a qt based app as a default > app in GNOME... no matter what the functionality gap is between > applications in the same space. So making knote a default installed > application for a GNOME desktop would be less than optimal. But if > KDE users want to use it as a default, fine by me. This is a good point, although I notice recently it's being brought up as an argument against using KDE apps in GNOME space, despite there being a number of cases where GNOME / Gtk apps are recommended as (and in some cases required, like package kit) for use in KDE space ;o) The issue here is, the two "best" note takers both appear to be qt/kde-centric, alas ... From dcbw at redhat.com Wed Jun 4 14:04:11 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 04 Jun 2008 10:04:11 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <4846475E.5040804@gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> Message-ID: <1212588251.13676.0.camel@localhost.localdomain> On Wed, 2008-06-04 at 09:42 +0200, Valent Turkovic wrote: > Dan Williams wrote: > > On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: > >> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: > >> > >>> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > >>>> Dan Williams (dcbw at redhat.com) said: > >>>>> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > >>>>>> During the boot I have some samba shares mounted because I have them > >>>>>> configured to mount via fstab file. > >>>>>> > >>>>>> When I shutdown or reboot I get a screen for 2-3 minutes that shows > >>>>>> smbfs service trying to unmount samba shares but NM service has > >>>>>> already shutdown and there is no working network connection :( > >>>>>> > >>>>>> I have seen this "bad" behaviour in F8 and have reported it on this > >>>>>> mailinglist, but I hoped that the new and smarter NM would take care > >>>>>> of it, but unfortunately it didn't :( > >>>>> Probably need to adjust the stop priorities of NM and haldaemon to be > >>>>> right after messagebus (K85) rather than where they currently are... > >>>>> The problem is that NM is being stopped to early. > >>>> 'After netfs' should be good enough. Although netfs stop should possibly > >>>> do lazy umounts. > >>> Ok, just need to bump NM a few bits later it looks like; might as well > >>> be K84 to be right after messagebus. > >> Why not go all the way to 90 as network to be on the safe side? With a > >> quick look I can see some scripts that might not be happy if the network > >> is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. > > > > NM depend on messagebus at least, so we should stop NM right before > > messagebus. But the same issues with startup are theoretically present > > with shutdown, meaning that since messagebus depends on rsyslog, and > > rsyslog depends on network. Standard installs don't use networked > > syslog, so standard installs don't actually need rsyslog to depend on > > network, but because rsyslog isn't smart enough to know when it does or > > does not depend on network, we can't just re-order the chain... :( > > > > Dan > > > > Dan what is the conclusion about this bug? This is a looong thread but > nothing is updated on bugzilla page so is there some consensus on what > needs to be done? I will move NetworkManager shutdown to be right before dbus. Dan From rjones at redhat.com Wed Jun 4 14:05:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 4 Jun 2008 15:05:02 +0100 Subject: strange koji build failures...? In-Reply-To: <4845763D.7000203@redhat.com> References: <4845763D.7000203@redhat.com> Message-ID: <20080604140502.GA3233@amd.home.annexia.org> Phew, not just me then! Failed build: http://koji.fedoraproject.org/koji/taskinfo?taskID=645188 Exactly the same successful scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=645144 and the error message is: cp -pf /builddir/build/BUILD/ocaml-3.10.2/stdlib/libcamlrun.a stdlib/libcamlrun.a cp: preserving times for `stdlib/libcamlrun.a' : No such file or directory Failure: Error during command `cp -pf /builddir/build/BUILD/ocaml-3.10.2/stdlib/libcamlrun.a stdlib/libcamlrun.a'. Exit code 1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jroth at linux.vnet.ibm.com Wed Jun 4 14:15:14 2008 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Wed, 04 Jun 2008 16:15:14 +0200 Subject: Fedora 9 Cell processor packages In-Reply-To: <20080603071616.53ea8b88@vader.jdub.homelinux.org> References: <1212431765.3687.5.camel@ScaryMonster> <20080603071616.53ea8b88@vader.jdub.homelinux.org> Message-ID: <4846A372.5060600@linux.vnet.ibm.com> Josh Boyer wrote: > On Mon, 02 Jun 2008 19:36:05 +0100 > A.J.Delaney at brighton.ac.uk wrote: > >> * libspe2 in order to control the SPUs >> (http://foss.it.brighton.ac.uk/~balor/rpm/libspe2-2.2.80-121.src.rpm), > > libspe2 is currently under review already: > > https://bugzilla.redhat.com/show_bug.cgi?id=442507 > > josh > Right, and we have plans to put spu-gcc, spu-binutils, spu-tools and spu-newlib there soon. Jochen From che666 at gmail.com Wed Jun 4 14:34:04 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Jun 2008 16:34:04 +0200 Subject: rpmreaper In-Reply-To: <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> References: <20080603154111.GA24155@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> Message-ID: 2008/6/4 Jeff Spaleta : > On Tue, Jun 3, 2008 at 1:22 PM, Michael Wiktowy > wrote: >> You could argue about the utility of such a tool and what programming >> language/libraries it uses (and I would agree with you for what its >> worth) but is that really relevant to reviewing it for acceptance into >> Extras? >> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines doesn't say >> anything about not reinventing the wheel and if it did we wouldn't >> have a lot of things people feel pretty passionately about (redundant >> desktop environments, search tools, editors ... you name the flamewar) >> and Fedora would be a pretty stagnant distro. > > We have yet to come to a point where we make a requirement on value. > > I would however state that I would very much like to see this tool > have its own upstream project space hosted somewhere, with a clear > upstream source release, that could be used beyond Fedora. I don't > need to see Suse packages..but if this is meant to be a generally > useful tool for rpm distributions..it should be handled that way as an > upstream project. If this is meant to be Fedora specific, well then I > think we might have a stronger case to be made that Fedora specific > tools should integrate well with the existing direction. > > Having a package hosted out of fedora people is probably not a good > idea. In fact its probably something we should forbid. There's a > big difference between setting up a project at fedora hosted and > throwing up a tarball on your fedora people space. *hint* *hint* rpm -qi mkinitrd *hint* *hint* you might notice the missing url line :) kind regards, Rudolf Kastl > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sergio.pasra at gmail.com Wed Jun 4 14:51:15 2008 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Wed, 4 Jun 2008 16:51:15 +0200 Subject: Bind mounts with fedora 9 Message-ID: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> Hello, with fedora < 9, I could make bind mounts adding a line like this in /etc/fstab /srv/db/mysql /var/lib/mysql bind defaults,bind 0 0 But this seems not to work in fedora == 9. During boot, "Mounting local filesystems" fails and "Mounting other filesystems" fails also and only mounts bind directories read-only. After boot, I can mount everything with mount -a Is this behavior intended? Regards, Sergio From jim at meyering.net Wed Jun 4 14:55:25 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 04 Jun 2008 16:55:25 +0200 Subject: strange koji build failures...? In-Reply-To: <20080604140502.GA3233@amd.home.annexia.org> (Richard W. M. Jones's message of "Wed, 4 Jun 2008 15:05:02 +0100") References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> Message-ID: <87y75lz1uq.fsf@rho.meyering.net> "Richard W.M. Jones" wrote: > Phew, not just me then! > > Failed build: http://koji.fedoraproject.org/koji/taskinfo?taskID=645188 > Exactly the same successful scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=645144 > > and the error message is: > > cp -pf /builddir/build/BUILD/ocaml-3.10.2/stdlib/libcamlrun.a stdlib/libcamlrun.a > cp: > preserving times for `stdlib/libcamlrun.a' > : No such file or directory > Failure: > Error during command `cp -pf /builddir/build/BUILD/ocaml-3.10.2/stdlib/libcamlrun.a stdlib/libcamlrun.a'. > Exit code 1. Hi Rich, Thanks for the details. This looks like the same problem reported in this thread: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/13684 Eric Blake fixed that with this change to gnulib's utimens.c: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93f08406537 Considering that this has already affected two distributions, I'm tempted to make a coreutils-6.13 release. We'll see. From rdieter at math.unl.edu Wed Jun 4 15:06:11 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 04 Jun 2008 10:06:11 -0500 Subject: Firefox and Moonlight (Mono) "Free Software" Status? References: <8g2ch5-52b.ln1@sky.matrix> <1212407815.7710.69.camel@localhost.localdomain> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> <604aa7910806040526n17782900m960750ebc5ffccba@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > ... making knote a default installed > application for a GNOME desktop would be less than optimal. offtopic warning: I thought it was just the "Fedora Desktop" spin, not "GNOME Desktop"? :) -- Rex From ovasik at redhat.com Wed Jun 4 15:10:54 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 04 Jun 2008 17:10:54 +0200 Subject: strange koji build failures...? In-Reply-To: <87y75lz1uq.fsf@rho.meyering.net> References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> <87y75lz1uq.fsf@rho.meyering.net> Message-ID: <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> Hi Jim, Jim Meyering wrote: > Eric Blake fixed that with this change to gnulib's utimens.c: > > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93f08406537 I know about the fix (was causing troubles with test-suite) - therefore that patch is already part of the coreutils-6.12-1.fc10 build - so it will not solve the troubles with koji. Problem seems to be in return code 280 from futimensat() call. So futimensat is available, but failing - the same problem as I had with the coreutils test suite few weeks ago (if you remember touch/create-no-missing issue). I would say koji xen kernel issue, but could be workarounded by Fedora coreutils. Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From valent.turkovic at gmail.com Wed Jun 4 15:20:26 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jun 2008 17:20:26 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212588251.13676.0.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> Message-ID: <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> On Wed, Jun 4, 2008 at 4:04 PM, Dan Williams wrote: > On Wed, 2008-06-04 at 09:42 +0200, Valent Turkovic wrote: >> Dan Williams wrote: >> > On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: >> >> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: >> >> >> >>> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: >> >>>> Dan Williams (dcbw at redhat.com) said: >> >>>>> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: >> >>>>>> During the boot I have some samba shares mounted because I have them >> >>>>>> configured to mount via fstab file. >> >>>>>> >> >>>>>> When I shutdown or reboot I get a screen for 2-3 minutes that shows >> >>>>>> smbfs service trying to unmount samba shares but NM service has >> >>>>>> already shutdown and there is no working network connection :( >> >>>>>> >> >>>>>> I have seen this "bad" behaviour in F8 and have reported it on this >> >>>>>> mailinglist, but I hoped that the new and smarter NM would take care >> >>>>>> of it, but unfortunately it didn't :( >> >>>>> Probably need to adjust the stop priorities of NM and haldaemon to be >> >>>>> right after messagebus (K85) rather than where they currently are... >> >>>>> The problem is that NM is being stopped to early. >> >>>> 'After netfs' should be good enough. Although netfs stop should possibly >> >>>> do lazy umounts. >> >>> Ok, just need to bump NM a few bits later it looks like; might as well >> >>> be K84 to be right after messagebus. >> >> Why not go all the way to 90 as network to be on the safe side? With a >> >> quick look I can see some scripts that might not be happy if the network >> >> is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. >> > >> > NM depend on messagebus at least, so we should stop NM right before >> > messagebus. But the same issues with startup are theoretically present >> > with shutdown, meaning that since messagebus depends on rsyslog, and >> > rsyslog depends on network. Standard installs don't use networked >> > syslog, so standard installs don't actually need rsyslog to depend on >> > network, but because rsyslog isn't smart enough to know when it does or >> > does not depend on network, we can't just re-order the chain... :( >> > >> > Dan >> > >> >> Dan what is the conclusion about this bug? This is a looong thread but >> nothing is updated on bugzilla page so is there some consensus on what >> needs to be done? > > I will move NetworkManager shutdown to be right before dbus. > > Dan Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? Cheers, 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 sgrubb at redhat.com Wed Jun 4 15:26:52 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 4 Jun 2008 11:26:52 -0400 Subject: rpmreaper In-Reply-To: References: <20080603154111.GA24155@localhost> <200806031956.56968.sgrubb@redhat.com> Message-ID: <200806041126.52859.sgrubb@redhat.com> On Wednesday 04 June 2008 02:55:19 Panu Matilainen wrote: > On Tue, 3 Jun 2008, Steve Grubb wrote: > > Not really. Bash has been patched to to spit out the programs it calls > > (/bin/bash --rpm-requires). So, its a matter of overriding > > %__find_requires to run a program that gathers the information for shell > > scripts and falls back to the old way for others. > > > > No one should have to specify this, it can be automated easily. Without > > taking shell scripts into account, you run the risk of breaking > > unspecified requirements. > > I wish it were that simple. > > "bash --rpm-requires" does a fair job for the impossible task, but it > produces way too much bogus information and false positives to be > generally usable as is. A quick check at various scripts found on a stock > F9 system shows at least these problems: > > 1) It mistakes functions declared in sourced scripts as executables > 2) It mistakes functions used before declared as executables In my opinion, these ^^ should be fixed. > 3) It thinks of sourced scripts as executables In a sense, they are. My init scripts source /etc/init.d/functions, so that is a real dependency. > 4) It produces hard dependencies for conditional items I agree this is a problem. I think it gets worse the further nested a program would be in if staements. But as a first pass, one could fix it to only check files not within a if statement and add logic later to go deeper. Something is better than nothing as right now we do not capture shell script dependencies and they *are* real. > 5) For most executables, path is unknown There is a standard PATH that the distribution expects. So there is some defined search order. I solved this in the build system I wrote by keeping a list of all files installed by rpm as packages were built. Then the find-requires script would resolve the name to full path based on the standard PATH. This is solvable. > Assuming 1-3) are fixed and ignoring 4), 5) could be dealt with, at least > to some extent, but it's a big can of worms too. For the dependencies to > be discoverable by yum & friends, there would have to be matching provides > for all executable(foo) items bash --rpm-requires produces. > > Rpm could automatically add Provides: executable(foo) for any file with > executable bits on, but it would cause *enormous* bloat of metadata. Bloat, to me, means something that would never be used. If the dependencies are real, they should be captured. Do you need to have the dependency at the file level or package level? Maybe that reduces some of the metadata? > So solving 5) should be possible if 1-3) were fixed, but it'd still be > pretty moot because 4) can't generally be solved (apart from manually > filtering bogus dependencies, at which point it's hardly "easily > automated" :) I don't think #4 is impossible. Its not easy either. But I think we could get a first pass that is pretty good and make it better over time. Right now, we capture nothing. So, a first pass solution that captures 25% accurately is better than where we are. In the build system I wrote, I lumped #4 and #5 together and solved them with a lookup table. It was good enough for my needs. If I resolved the path, the dependency was recorded. If not, I didn't record it. So, if /sbin/solaris-specific was not in my distribution's file list, it was quietly removed from the possible dependencies. -Steve From John.Mizell at tch.com Wed Jun 4 15:33:17 2008 From: John.Mizell at tch.com (John.Mizell at tch.com) Date: Wed, 4 Jun 2008 09:33:17 -0600 Subject: Sendmail error Message-ID: Does anyone know where I could find a list of the common sendmail errors and solutions? In the rpm that has sendmail docs the operation manual does not cover this. Mostly the errors after setup are needed. John Mizell Systems Administrator TCH 4185 Harrison Blvd. Suite 202 Ogden, Utah 84403 801-624-4604 From k.georgiou at imperial.ac.uk Wed Jun 4 15:43:16 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Wed, 4 Jun 2008 16:43:16 +0100 Subject: Bind mounts with fedora 9 In-Reply-To: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> References: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> Message-ID: <20080604154316.GB24661@imperial.ac.uk> On Wed, Jun 04, 2008 at 04:51:15PM +0200, Sergio Pascual wrote: > Hello, with fedora < 9, I could make bind mounts adding a line like > this in /etc/fstab > /srv/db/mysql /var/lib/mysql bind defaults,bind 0 0 > > But this seems not to work in fedora == 9. During boot, "Mounting > local filesystems" fails and "Mounting other filesystems" fails also > and only mounts bind directories read-only. After boot, I can mount > everything with mount -a > Is this behavior intended? I think it's selinux getting in the way, if it is the error messages will be in /var/log/messages since everything happens before auditd has started so they are easy to miss. Try with the allow_mount_anyfile boolean enabled for a fix. From paul at city-fan.org Wed Jun 4 15:48:35 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 04 Jun 2008 16:48:35 +0100 Subject: Bind mounts with fedora 9 In-Reply-To: <20080604154316.GB24661@imperial.ac.uk> References: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> <20080604154316.GB24661@imperial.ac.uk> Message-ID: <4846B953.4050800@city-fan.org> Kostas Georgiou wrote: > On Wed, Jun 04, 2008 at 04:51:15PM +0200, Sergio Pascual wrote: > >> Hello, with fedora < 9, I could make bind mounts adding a line like >> this in /etc/fstab >> /srv/db/mysql /var/lib/mysql bind defaults,bind 0 0 >> >> But this seems not to work in fedora == 9. During boot, "Mounting >> local filesystems" fails and "Mounting other filesystems" fails also >> and only mounts bind directories read-only. After boot, I can mount >> everything with mount -a >> Is this behavior intended? > > I think it's selinux getting in the way, if it is the error messages > will be in /var/log/messages since everything happens before auditd > has started so they are easy to miss. > Try with the allow_mount_anyfile boolean enabled for a fix. Or: # umount /var/lib/mysql # chcon -t mnt_t /var/lib/mysql # service netfs start (the last command does the mount whilst confined by selinux, whilst the "mount -a" run directly is not so confined). Paul. From valent.turkovic at gmail.com Wed Jun 4 16:12:53 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jun 2008 18:12:53 +0200 Subject: State of fedoratv.com? In-Reply-To: <64b14b300806031511i5594c248yed1b0b59078a1c41@mail.gmail.com> References: <64b14b300806031511i5594c248yed1b0b59078a1c41@mail.gmail.com> Message-ID: <64b14b300806040912w2fb4ec20r8ebf879e81c7c5b1@mail.gmail.com> On Wed, Jun 4, 2008 at 12:11 AM, Valent Turkovic wrote: > Hi, > I searched and haven't find any discussions regarding fedoratv.com and > what is going on with it because it looks as frontend hasn't had any > changes. How to get an account and upload videos to fedoratv? Why does > fedoratv have a .com instead of .org ? > > Cheers, > Valent. I tried creating an account and I can't. Is this project abandoned? If I would like to make fedora video podcasts and upload them where do you suggest and in what format? Cheers, 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 orion at cora.nwra.com Wed Jun 4 16:47:39 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Jun 2008 10:47:39 -0600 Subject: source file audit - 2008-06-03 In-Reply-To: <20080603172954.69b3bb51@ohm.scrye.com> References: <20080603172954.69b3bb51@ohm.scrye.com> Message-ID: <4846C72B.1090807@cora.nwra.com> Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. > orion:BADSOURCE:GSHHS1.10_coast.tar.bz2:GMT-coastlines > orion:BADSOURCE:GSHHS1.10_full.tar.bz2:GMT-coastlines > orion:BADSOURCE:GSHHS1.10_high.tar.bz2:GMT-coastlines Upstream seems to have repacked these. Uploaded new versions. > orion:BADURL:GMT4.3.0_pdf.tar.bz2:GMT-doc > orion:BADURL:GMT4.3.0_tut.tar.bz2:GMT-doc > orion:BADURL:GMT4.3.0_web.tar.bz2:GMT-doc Brought devel up to date. > orion:BADURL:ncarg_src-4.4.2.tar.gz:ncarg This is dead. There is "dead.package" in devel. rel-eng - do you need to do something? -- 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 mtasaka at ioa.s.u-tokyo.ac.jp Wed Jun 4 16:48:51 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 05 Jun 2008 01:48:51 +0900 Subject: strange koji build failures...? In-Reply-To: <484625C0.1000401@ioa.s.u-tokyo.ac.jp> References: <4845763D.7000203@redhat.com> <48458546.8050207@ioa.s.u-tokyo.ac.jp> <484587A2.6050102@redhat.com> <1212541788.4899.10.camel@localhost.localdomain> <20080604043605.GA29545@bludgeon.org> <48461D4F.9010000@redhat.com> <20080604045618.GA29800@bludgeon.org> <484625C0.1000401@ioa.s.u-tokyo.ac.jp> Message-ID: <4846C773.1050309@ioa.s.u-tokyo.ac.jp> By the way Mamoru Tasaka wrote, at 06/04/2008 02:18 PM +9:00: > Ray Van Dolson wrote, at 06/04/2008 01:56 PM +9:00: >> On Tue, Jun 03, 2008 at 11:42:55PM -0500, Eric Sandeen wrote: >>> Mine also only failed on x86_64 rawhide, as are the other failures I've >>> seen. Interesting... >>> >>> Since it is cp failing I can't help but notice that coreutils was just >>> upgraded to a new upstream version today... coincidence? > > Maybe coreutils-6.12-1.fc10 should be untagged? rel-eng team replied that now coreutils-6.12-1.fc10 is untagged. Mamoru From nicu_fedora at nicubunu.ro Wed Jun 4 16:52:20 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 04 Jun 2008 19:52:20 +0300 Subject: State of fedoratv.com? In-Reply-To: <64b14b300806040912w2fb4ec20r8ebf879e81c7c5b1@mail.gmail.com> References: <64b14b300806031511i5594c248yed1b0b59078a1c41@mail.gmail.com> <64b14b300806040912w2fb4ec20r8ebf879e81c7c5b1@mail.gmail.com> Message-ID: <4846C844.80000@nicubunu.ro> Valent Turkovic wrote: > On Wed, Jun 4, 2008 at 12:11 AM, Valent Turkovic >> I searched and haven't find any discussions regarding fedoratv.com and >> what is going on with it because it looks as frontend hasn't had any >> changes. How to get an account and upload videos to fedoratv? Why does >> fedoratv have a .com instead of .org ? > > I tried creating an account and I can't. > Is this project abandoned? If I would like to make fedora video > podcasts and upload them where do you suggest and in what format? Read this thread: https://www.redhat.com/archives/fedora-marketing-list/2008-May/msg00294.html -- 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 bpepple at fedoraproject.org Wed Jun 4 16:58:03 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jun 2008 12:58:03 -0400 Subject: Plan for tomorrows (20080605) FESCO meeting Message-ID: <1212598683.22896.1.camel@kennedy> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESC0-Meeting -- http://fedoraproject.org/wiki/FTBFS -- all /topic FESCO-Meeting -- FESCo Responsibilities/Role - Part Deux -- all /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. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. 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: 197 bytes Desc: This is a digitally signed message part URL: From jim at meyering.net Wed Jun 4 17:25:54 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 04 Jun 2008 19:25:54 +0200 Subject: strange koji build failures...? In-Reply-To: <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> (=?utf-8?B?Ik9uZMWZZWogVmHFocOtayIncw==?= message of "Wed, 04 Jun 2008 17:10:54 +0200") References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> <87y75lz1uq.fsf@rho.meyering.net> <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <87od6hxgbh.fsf@rho.meyering.net> Ond?ej Va??k wrote: > Hi Jim, > > Jim Meyering wrote: >> Eric Blake fixed that with this change to gnulib's utimens.c: >> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93f08406537 > > I know about the fix (was causing troubles with test-suite) - therefore > that patch is already part of the coreutils-6.12-1.fc10 build - so it > will not solve the troubles with koji. Problem seems to be in return > code 280 from futimensat() call. So futimensat is available, but failing > - the same problem as I had with the coreutils test suite few weeks ago > (if you remember touch/create-no-missing issue). I would say koji xen > kernel issue, but could be workarounded by Fedora coreutils. Hi Ond?ej, I think you're right that it's a kernel problem. I've proposed a patch attached to http://bugzilla.redhat.com/449910 as https://bugzilla.redhat.com/attachment.cgi?id=308374 that might suffice to work around the problem. Can you test it? Thanks, Jim From dcbw at redhat.com Wed Jun 4 17:28:03 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 04 Jun 2008 13:28:03 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> Message-ID: <1212600483.20764.4.camel@localhost.localdomain> On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > On Wed, Jun 4, 2008 at 4:04 PM, Dan Williams wrote: > > On Wed, 2008-06-04 at 09:42 +0200, Valent Turkovic wrote: > >> Dan Williams wrote: > >> > On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: > >> >> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: > >> >> > >> >>> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > >> >>>> Dan Williams (dcbw at redhat.com) said: > >> >>>>> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > >> >>>>>> During the boot I have some samba shares mounted because I have them > >> >>>>>> configured to mount via fstab file. > >> >>>>>> > >> >>>>>> When I shutdown or reboot I get a screen for 2-3 minutes that shows > >> >>>>>> smbfs service trying to unmount samba shares but NM service has > >> >>>>>> already shutdown and there is no working network connection :( > >> >>>>>> > >> >>>>>> I have seen this "bad" behaviour in F8 and have reported it on this > >> >>>>>> mailinglist, but I hoped that the new and smarter NM would take care > >> >>>>>> of it, but unfortunately it didn't :( > >> >>>>> Probably need to adjust the stop priorities of NM and haldaemon to be > >> >>>>> right after messagebus (K85) rather than where they currently are... > >> >>>>> The problem is that NM is being stopped to early. > >> >>>> 'After netfs' should be good enough. Although netfs stop should possibly > >> >>>> do lazy umounts. > >> >>> Ok, just need to bump NM a few bits later it looks like; might as well > >> >>> be K84 to be right after messagebus. > >> >> Why not go all the way to 90 as network to be on the safe side? With a > >> >> quick look I can see some scripts that might not be happy if the network > >> >> is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. > >> > > >> > NM depend on messagebus at least, so we should stop NM right before > >> > messagebus. But the same issues with startup are theoretically present > >> > with shutdown, meaning that since messagebus depends on rsyslog, and > >> > rsyslog depends on network. Standard installs don't use networked > >> > syslog, so standard installs don't actually need rsyslog to depend on > >> > network, but because rsyslog isn't smart enough to know when it does or > >> > does not depend on network, we can't just re-order the chain... :( > >> > > >> > Dan > >> > > >> > >> Dan what is the conclusion about this bug? This is a looong thread but > >> nothing is updated on bugzilla page so is there some consensus on what > >> needs to be done? > > > > I will move NetworkManager shutdown to be right before dbus. > > > > Dan > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? Definitely in the next F9 update. Dan From dominik at greysector.net Wed Jun 4 17:37:43 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 4 Jun 2008 19:37:43 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212600483.20764.4.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> Message-ID: <20080604173742.GA5399@mokona.greysector.net> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: [...] > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > > Definitely in the next F9 update. Will this update contain my patch which allows people to uninstall NetworkManager without losing pidgin and evolution (bug #351101)? You never gave a good reason why this bug has been left unfixed for over half a year, especially when the solution is trivial. Regards, R. -- Fedora http://fedoraproject.org/wiki/DominikMierzejewski Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Wed Jun 4 18:29:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 20:29:25 +0200 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <1212598683.22896.1.camel@kennedy> References: <1212598683.22896.1.camel@kennedy> Message-ID: <20080604182924.GA2662@free.fr> On Wed, Jun 04, 2008 at 12:58:03PM -0400, Brian Pepple wrote: > Hi all, > > 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. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. I propose that the following people become sponsors: Remi Collet (remi) Ignacio Vazquez-Abrams (ivazquez) Nicolas Mailhot (nim) Axel Thimm (athimm) G?rard Milmeister (gemi) -- Pat From amdunn at gmail.com Wed Jun 4 18:26:51 2008 From: amdunn at gmail.com (Alan Dunn) Date: Wed, 4 Jun 2008 14:26:51 -0400 Subject: Packaging issues with files section for my future coq package Message-ID: I'm trying to package the Coq theorem proving system. My goal is to create a main package with the system and then a subpackage for the (optional) IDE. I've written out a spec file, and it does compile (that is, I can generate rpms with "rpmbuild -bb SPECS/coq.spec"), but this process generates quite a number of "file listed twice" warnings that I would like to eliminate like: warning: File listed twice: /usr/lib/coq/contrib warning: File listed twice: /usr/lib/coq/contrib.cma warning: File listed twice: /usr/lib/coq/contrib.cmxa warning: File listed twice: /usr/lib/coq/contrib/field warning: File listed twice: /usr/lib/coq/contrib/field warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo ... (the duplicated warnings are listed multiple times in the output, as are many files) I thought that somehow things could've gone wrong in the files list that I generate to use in the %files section via: find %{buildroot}%{_libdir}/coq -fprint coqlibfiles sed -i -e "s|%{buildroot}||" coqlibfiles cat coqlibfiles >> coqfiles but none of the files are duplicated in the coqfiles file %files -f coqfiles %defattr(-,root,root) %doc CHANGES COMPATIBILITY COPYRIGHT CREDITS INSTALL INSTALL.ide KNOWN-BUGS LICENSE README %doc %{_mandir}/man1/coq* %doc %{_mandir}/man1/gallina.1.gz %doc %{_mandir}/man1/parser.1.gz %{_bindir}/coq* %{_bindir}/gallina %{_bindir}/parser # Parser.opt included seperately %exclude %{_bindir}/coqide* %exclude %{_libdir}/coq/ide/* %files coqide %defattr(-,root,root) %{_bindir}/coqide* %{_libdir}/coq/ide/* Anyone know what I'm doing wrong? From tibbs at math.uh.edu Wed Jun 4 19:00:05 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jun 2008 14:00:05 -0500 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <20080604182924.GA2662@free.fr> References: <1212598683.22896.1.camel@kennedy> <20080604182924.GA2662@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> I propose that the following people become sponsors: It's a little late to run that by all of the sponsors before tomorrow's meeting. Have you at least contacted these people to see if they're interested in being sponsors? - J< From jspaleta at gmail.com Wed Jun 4 19:11:12 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 11:11:12 -0800 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: References: <8g2ch5-52b.ln1@sky.matrix> <3adc77210806020720qbc97b78wec493c1c46d17678@mail.gmail.com> <0u9eh5-4vi.ln1@sky.matrix> <484482E0.2080108@fedoraproject.org> <4844D67F.7090307@slated.org> <1218b5bc0806031950y60f6d89fge138f30e74506916@mail.gmail.com> <604aa7910806032036h24acff34ge5ee7d28541112e9@mail.gmail.com> <16de708d0806032152s6d9ecaeal6beceb77a356bffa@mail.gmail.com> <604aa7910806040526n17782900m960750ebc5ffccba@mail.gmail.com> Message-ID: <604aa7910806041211s728eb144q35708399d78613d7@mail.gmail.com> On Wed, Jun 4, 2008 at 7:06 AM, Rex Dieter wrote: > offtopic warning: I thought it was just the "Fedora Desktop" spin, > not "GNOME Desktop"? :) It's okay to hedge your bets in the naming. We all know in the end we'll move back to an fvwm2 desktop environment as the default eventually. -jef From jkeating at redhat.com Wed Jun 4 19:12:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Jun 2008 15:12:31 -0400 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <1212598683.22896.1.camel@kennedy> References: <1212598683.22896.1.camel@kennedy> Message-ID: <1212606751.9688.39.camel@localhost.localdomain> On Wed, 2008-06-04 at 12:58 -0400, Brian Pepple wrote: > 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. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. I have a topic. Casey Dahlin has been doing some good work on making https://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment a reality. We're very close. One decision that I'd like to see discussed is what we use to prime the membership of the as of yet to be named elevated rights group. One suggestion has been to grandfather all of current cvsextras into said group, however I think this would make the later initiative https://fedoraproject.org/wiki/JesseKeating/PackageACLOpening less successful. Instead I suggest priming the group with current sponsors, and allow any existing sponsor to promote the people they sponsor into the elevated group. I'm also open to further ideals or discussions on this. I realize this is rather late notice and doesn't give a lot of time for discussion on this list, however Casey has been getting things done quicker than expected, which is a great thing. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Jun 4 19:20:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 21:20:20 +0200 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: References: <1212598683.22896.1.camel@kennedy> <20080604182924.GA2662@free.fr> Message-ID: <20080604192020.GC2662@free.fr> On Wed, Jun 04, 2008 at 02:00:05PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> I propose that the following people become sponsors: > > It's a little late to run that by all of the sponsors before > tomorrow's meeting. No problem. I didn't really understood when/how sponsors were proposed so I used the opportunity of the weekly fesco call. > Have you at least contacted these people to see if they're interested > in being sponsors? No. But I assumed that this was not needed, since it only opens possiblities for the sponsors, responsibilities come only when they sponsor somebody. And, unless I don't remember well nobody asked me first when I was nominated, and I don't think it is an issue. Maybe procedures changed, though, but I didn't saw anything like that on the wiki page. I don't find sponsor related pages in the wiki anymore, however so maybe I read it too fast. -- Pat From sgrubb at redhat.com Wed Jun 4 19:21:21 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 4 Jun 2008 15:21:21 -0400 Subject: Orphaned Packages Message-ID: <200806041521.22119.sgrubb@redhat.com> Hello, Just letting anyone interested know that these packages have been orphaned: gpsman -- GPS data manager nec2c -- a translation of the Numerical Electromagnetics Code (NEC2) splat -- Analyze point-to-point terrestrial RF communication links -Steve From a.badger at gmail.com Wed Jun 4 19:28:37 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jun 2008 12:28:37 -0700 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <1212606751.9688.39.camel@localhost.localdomain> References: <1212598683.22896.1.camel@kennedy> <1212606751.9688.39.camel@localhost.localdomain> Message-ID: <4846ECE5.5080202@gmail.com> Jesse Keating wrote: > I have a topic. Casey Dahlin has been doing some good work on making > https://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment a > reality. We're very close. One decision that I'd like to see discussed > is what we use to prime the membership of the as of yet to be named > elevated rights group. One suggestion has been to grandfather all of > current cvsextras into said group, however I think this would make the > later initiative > https://fedoraproject.org/wiki/JesseKeating/PackageACLOpening less > successful. Instead I suggest priming the group with current sponsors, > and allow any existing sponsor to promote the people they sponsor into > the elevated group. I'm also open to further ideals or discussions on > this. > Just a note: FAS has no way to enforce that a sponsor in Group A is the person who adds someone to Group B. So if this policy were to start off with sponsors from cvsextras, I'd rather that the sponsors could sponsor anyone for the new group (not just people they sponsored in cvsextras). I think this also maps better to the way we currently think of sponsors: they're people who are considered more knowledgable and capable of guiding other packagers' growth. They should be able to promote any other contributor not just people they've shown an interest in in the past. > I realize this is rather late notice and doesn't give a lot of time for > discussion on this list, however Casey has been getting things done > quicker than expected, which is a great thing. > Yeah, Casey is doing some great work this summer. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Wed Jun 4 19:32:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 11:32:29 -0800 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080601140435.GB27694@truch.net> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212324726.25062.53.camel@localhost.localdomain> <20080601140435.GB27694@truch.net> Message-ID: <604aa7910806041232i51f6aac8p4fa19d81df3248ea@mail.gmail.com> 2008/6/1 Matthew D Truch : > Not every box runs at sea level. Cosmic rays become a > significant issue at altitude. Think of people living up in the > mountains or astronomical observatories. Think of people on long-haul > flights using their laptops. And my personal usage case, high altitude > balloons (37km altitude). We can't afford RAD hardened boxes, so we > have redundant machines with watchdogs to switch between them, which > works great for the hard crashes (every couple days) but not so much for > the 'soft' crashes where systems go wonky. I'll add cosmic ray failover to my roadmap for Fedora on Mars funding proposal I'll be submitting to NASA. -jef From jspaleta at gmail.com Wed Jun 4 19:37:22 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 11:37:22 -0800 Subject: Orphaned Packages In-Reply-To: <200806041521.22119.sgrubb@redhat.com> References: <200806041521.22119.sgrubb@redhat.com> Message-ID: <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> On Wed, Jun 4, 2008 at 11:21 AM, Steve Grubb wrote: > Hello, > > Just letting anyone interested know that these packages have been orphaned: > > gpsman -- GPS data manager > nec2c -- a translation of the Numerical Electromagnetics Code (NEC2) > splat -- Analyze point-to-point terrestrial RF communication links reasons? Are these things still worth maintaining in your estimation? Somehow I doubt splat and nec2c are redundant compared to other functionality in the repo. -jef"too bad splat is 20 MHz or higher... I work in the 10 to 20 MHz range"spaleta From martin.sourada at gmail.com Wed Jun 4 19:38:13 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 04 Jun 2008 21:38:13 +0200 Subject: Packaging issues with files section for my future coq package In-Reply-To: References: Message-ID: <1212608293.2996.9.camel@pc-notebook> On Wed, 2008-06-04 at 14:26 -0400, Alan Dunn wrote: ... > find %{buildroot}%{_libdir}/coq -fprint coqlibfiles > sed -i -e "s|%{buildroot}||" coqlibfiles > cat coqlibfiles >> coqfiles ... > %files -f coqfiles ... > %exclude %{_bindir}/coqide* > %exclude %{_libdir}/coq/ide/* > > %files coqide ... > %{_bindir}/coqide* > %{_libdir}/coq/ide/* > ... Well actually it seems strange way of including files into (sub)packages... First you make a list of some of the files you'd like to include, then include it, but decide that some of the files should go into subpackage, so exclude them again and list them in the subpackage. Is there really need to use find and then include the results via -f? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Jun 4 19:16:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 11:16:02 -0800 Subject: rpmreaper In-Reply-To: References: <20080603154111.GA24155@localhost> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> Message-ID: <604aa7910806041216p54575f52gb807e0453440a042@mail.gmail.com> On Wed, Jun 4, 2008 at 6:34 AM, Rudolf Kastl wrote: > *hint* *hint* > > rpm -qi mkinitrd > > *hint* *hint* > > you might notice the missing url line :) Am I shocked? not really. I'm sure we have other examples of pre-merge packages that aren't following the full set of packaging guidance. But just because we have packages that still do it, does not me we should encourage or allow new package submission to do it. -jef From jkeating at redhat.com Wed Jun 4 19:44:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Jun 2008 15:44:35 -0400 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <4846ECE5.5080202@gmail.com> References: <1212598683.22896.1.camel@kennedy> <1212606751.9688.39.camel@localhost.localdomain> <4846ECE5.5080202@gmail.com> Message-ID: <1212608675.9688.51.camel@localhost.localdomain> On Wed, 2008-06-04 at 12:28 -0700, Toshio Kuratomi wrote: > Just a note: FAS has no way to enforce that a sponsor in Group A is the > person who adds someone to Group B. So if this policy were to start off > with sponsors from cvsextras, I'd rather that the sponsors could sponsor > anyone for the new group (not just people they sponsored in cvsextras). > > I think this also maps better to the way we currently think of sponsors: > they're people who are considered more knowledgable and capable of > guiding other packagers' growth. They should be able to promote any > other contributor not just people they've shown an interest in in the past. I don't see a problem with that at all. In fact, I rather like that (: -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Jun 4 19:55:55 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Jun 2008 21:55:55 +0200 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <20080604182924.GA2662@free.fr> References: <1212598683.22896.1.camel@kennedy> <20080604182924.GA2662@free.fr> Message-ID: <1212609355.9294.5.camel@rousalka.okg> Le mercredi 04 juin 2008 ? 20:29 +0200, Patrice Dumas a ?crit : > On Wed, Jun 04, 2008 at 12:58:03PM -0400, Brian Pepple wrote: > > Hi all, > > > > 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. You can also propose topics > > in the meeting while it is in the "Free discussion around Fedora" phase. > > I propose that the following people become sponsors: > Remi Collet (remi) > Ignacio Vazquez-Abrams (ivazquez) > Nicolas Mailhot (nim) Oh, great, another excuse to spend my free time elsewhere goes away. Now you've proposed it I suppose I have to went along :p Given that I'd have probably ended up asking for it myself someday anyway. > Axel Thimm (athimm) > G?rard Milmeister (gemi) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Wed Jun 4 20:00:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 22:00:25 +0200 Subject: rpmreaper In-Reply-To: References: <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> Message-ID: <20080604200025.GD2662@free.fr> On Wed, Jun 04, 2008 at 04:34:04PM +0200, Rudolf Kastl wrote: > > you might notice the missing url line :) You can report it in the merge review, if still under review, and otherwise report a bug. -- Pat From jspaleta at gmail.com Wed Jun 4 19:52:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jun 2008 11:52:47 -0800 Subject: Orphaned Packages In-Reply-To: <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> References: <200806041521.22119.sgrubb@redhat.com> <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> Message-ID: <604aa7910806041252n1f73c667kea01447172d199f3@mail.gmail.com> On Wed, Jun 4, 2008 at 11:37 AM, Jeff Spaleta wrote: >> nec2c -- a translation of the Numerical Electromagnetics Code (NEC2) I can definitely pick up nec2c. I'll adjust packagedb today to reflect that. -jef From opensource at till.name Wed Jun 4 20:22:40 2008 From: opensource at till.name (Till Maas) Date: Wed, 04 Jun 2008 22:22:40 +0200 Subject: State of fedoratv.com? In-Reply-To: <64b14b300806040912w2fb4ec20r8ebf879e81c7c5b1@mail.gmail.com> References: <64b14b300806031511i5594c248yed1b0b59078a1c41@mail.gmail.com> <64b14b300806040912w2fb4ec20r8ebf879e81c7c5b1@mail.gmail.com> Message-ID: <200806042222.58145.opensource@till.name> On Wed June 4 2008, Valent Turkovic wrote: > I tried creating an account and I can't. > Is this project abandoned? If I would like to make fedora video > podcasts and upload them where do you suggest and in what format? The video codec that fits best to Fedora is OGG Theora or Dirac with OGG Vorbis Audio. For OGG Theora there exists also a Java Applet that users can watch the video with. This is why I would prefer Theora over Dirac. I do not know a better place to upload them than your fedorapeople webspace. 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 Jun 4 20:23:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Jun 2008 16:23:42 -0400 Subject: Orphaned Packages In-Reply-To: <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> References: <200806041521.22119.sgrubb@redhat.com> <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> Message-ID: <1212611022.9688.55.camel@localhost.localdomain> On Wed, 2008-06-04 at 11:37 -0800, Jeff Spaleta wrote: > reasons? The person who previously owned them is no longer with the project. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Wed Jun 4 20:57:29 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 4 Jun 2008 22:57:29 +0200 Subject: Packaging issues with files section for my future coq package In-Reply-To: References: Message-ID: <20080604225729.1f3ea4fc.mschwendt@gmail.com> On Wed, 4 Jun 2008 14:26:51 -0400, Alan Dunn wrote: > I'm trying to package the Coq theorem proving system. > > My goal is to create a main package with the system and then a > subpackage for the (optional) IDE. I've written out a spec file, and > it does compile (that is, I can generate rpms with "rpmbuild -bb > SPECS/coq.spec"), but this process generates quite a number of "file > listed twice" warnings that I would like to eliminate like: > > warning: File listed twice: /usr/lib/coq/contrib > warning: File listed twice: /usr/lib/coq/contrib.cma > warning: File listed twice: /usr/lib/coq/contrib.cmxa > warning: File listed twice: /usr/lib/coq/contrib/field > warning: File listed twice: /usr/lib/coq/contrib/field > warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo > warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo > warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo > ... > > (the duplicated warnings are listed multiple times in the output, as > are many files) > > I thought that somehow things could've gone wrong in the files list > that I generate to use in the %files section via: > > find %{buildroot}%{_libdir}/coq -fprint coqlibfiles > sed -i -e "s|%{buildroot}||" coqlibfiles What is in "coqfiles" at this point? > cat coqlibfiles >> coqfiles > > but none of the files are duplicated in the coqfiles file Post the full spec file, because your quoted fragment is incomplete. You create "coqlibfiles", then append it to "coqfiles", but whether "coqfiles" is empty or set up with other contents is unknown. If empty, you could use "-f coqlibiles" directly instead of creating a copy. > %files -f coqfiles > %defattr(-,root,root) > %doc CHANGES COMPATIBILITY COPYRIGHT CREDITS INSTALL INSTALL.ide > KNOWN-BUGS LICENSE README > %doc %{_mandir}/man1/coq* > %doc %{_mandir}/man1/gallina.1.gz > %doc %{_mandir}/man1/parser.1.gz > %{_bindir}/coq* > %{_bindir}/gallina > %{_bindir}/parser > # Parser.opt included seperately > %exclude %{_bindir}/coqide* > %exclude %{_libdir}/coq/ide/* > > %files coqide > %defattr(-,root,root) > %{_bindir}/coqide* > %{_libdir}/coq/ide/* > > Anyone know what I'm doing wrong? Why don't you include and exclude the directories directly in the %files sections? -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.00 1.04 1.12 From wart at kobold.org Wed Jun 4 21:36:30 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 04 Jun 2008 14:36:30 -0700 Subject: obsoleting -selinux subpackages In-Reply-To: <20080522095620.GB2640@free.fr> References: <4834D502.1090209@kobold.org> <20080522073232.GA2640@free.fr> <48353C77.8010504@city-fan.org> <20080522095620.GB2640@free.fr> Message-ID: <48470ADE.6060208@kobold.org> Patrice Dumas wrote: > On Thu, May 22, 2008 at 10:27:19AM +0100, Paul Howarth wrote: >>>> Is (a) an acceptable solution? >>> I think so. >> I think so too but it might be worth adding: >> >> Conflicts: selinux-policy < first-VR-including-cyphesis-policy > > I am not sure that it is really needed. Better have the obsolete in > selinux-policy and a corresponding provides in that case. Why would the Provides: be necessary? The Obsoletes: should make sure that the cyphesis-selinux package gets removed, and later attempts to install/upgrade the no-longer-valid cyphesis-selinux package should fail. --Wart From skvidal at fedoraproject.org Wed Jun 4 21:37:32 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 04 Jun 2008 17:37:32 -0400 Subject: Outage Notification: PHX 2008-06-05 15:00 UTC Message-ID: <1212615452.4229.5.camel@cutter> There will be an outage starting at 2008-06-05 15: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-06-05 15:00 UTC' Affected Services: Wiki CVS / Source Control Buildsystem Database Mail Any system requiring web-based authentication Unaffected Services: fedorapeople.org Torrent main website Ticket Link: Reason for Outage: Rebooting a switch as part of an upgrade and adding of new systems. 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 pertusus at free.fr Wed Jun 4 21:44:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jun 2008 23:44:43 +0200 Subject: obsoleting -selinux subpackages In-Reply-To: <48470ADE.6060208@kobold.org> References: <4834D502.1090209@kobold.org> <20080522073232.GA2640@free.fr> <48353C77.8010504@city-fan.org> <20080522095620.GB2640@free.fr> <48470ADE.6060208@kobold.org> Message-ID: <20080604214442.GE2662@free.fr> On Wed, Jun 04, 2008 at 02:36:30PM -0700, Michael Thomas wrote: > > Why would the Provides: be necessary? The Obsoletes: should make sure > that the cyphesis-selinux package gets removed, and later attempts to > install/upgrade the no-longer-valid cyphesis-selinux package should fail. If you prefer. -- Pat From dcbw at redhat.com Wed Jun 4 21:54:29 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 04 Jun 2008 17:54:29 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080604173742.GA5399@mokona.greysector.net> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> Message-ID: <1212616469.6159.0.camel@localhost.localdomain> On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > [...] > > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > > > > Definitely in the next F9 update. > > Will this update contain my patch which allows people to uninstall > NetworkManager without losing pidgin and evolution (bug #351101)? > > You never gave a good reason why this bug has been left unfixed > for over half a year, especially when the solution is trivial. Can you try out http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 when it gets done? Thanks, Dan > Regards, > R. > > -- > Fedora http://fedoraproject.org/wiki/DominikMierzejewski > Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > "Faith manages." > -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > From dcbw at redhat.com Wed Jun 4 21:54:54 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 04 Jun 2008 17:54:54 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <4846475E.5040804@gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> Message-ID: <1212616494.6159.2.camel@localhost.localdomain> On Wed, 2008-06-04 at 09:42 +0200, Valent Turkovic wrote: > Dan Williams wrote: > > On Fri, 2008-05-30 at 19:47 +0100, Kostas Georgiou wrote: > >> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: > >> > >>> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > >>>> Dan Williams (dcbw at redhat.com) said: > >>>>> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > >>>>>> During the boot I have some samba shares mounted because I have them > >>>>>> configured to mount via fstab file. > >>>>>> > >>>>>> When I shutdown or reboot I get a screen for 2-3 minutes that shows > >>>>>> smbfs service trying to unmount samba shares but NM service has > >>>>>> already shutdown and there is no working network connection :( > >>>>>> > >>>>>> I have seen this "bad" behaviour in F8 and have reported it on this > >>>>>> mailinglist, but I hoped that the new and smarter NM would take care > >>>>>> of it, but unfortunately it didn't :( > >>>>> Probably need to adjust the stop priorities of NM and haldaemon to be > >>>>> right after messagebus (K85) rather than where they currently are... > >>>>> The problem is that NM is being stopped to early. > >>>> 'After netfs' should be good enough. Although netfs stop should possibly > >>>> do lazy umounts. > >>> Ok, just need to bump NM a few bits later it looks like; might as well > >>> be K84 to be right after messagebus. > >> Why not go all the way to 90 as network to be on the safe side? With a > >> quick look I can see some scripts that might not be happy if the network > >> is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. > > > > NM depend on messagebus at least, so we should stop NM right before > > messagebus. But the same issues with startup are theoretically present > > with shutdown, meaning that since messagebus depends on rsyslog, and > > rsyslog depends on network. Standard installs don't use networked > > syslog, so standard installs don't actually need rsyslog to depend on > > network, but because rsyslog isn't smart enough to know when it does or > > does not depend on network, we can't just re-order the chain... :( > > > > Dan > > > > Dan what is the conclusion about this bug? This is a looong thread but > nothing is updated on bugzilla page so is there some consensus on what > needs to be done? Can you test out: http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 when it's done? Thanks! Dan From sgrubb at redhat.com Wed Jun 4 21:56:26 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 4 Jun 2008 17:56:26 -0400 Subject: Orphaned Packages In-Reply-To: <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> References: <200806041521.22119.sgrubb@redhat.com> <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> Message-ID: <200806041756.27569.sgrubb@redhat.com> On Wednesday 04 June 2008 15:37:22 Jeff Spaleta wrote: > > Just letting anyone interested know that these packages have been > > orphaned: > > > > gpsman -- GPS data manager > > nec2c -- a translation of the Numerical Electromagnetics Code (NEC2) > > splat -- Analyze point-to-point terrestrial RF communication links > > reasons? ?Are these things still worth maintaining in your estimation? As Jesse mentioned the previous maintainer (not me) is no longer working on Fedora software. I have no idea if these are worth maintaining. My team focuses on security features and I was unaware that we even had these packages. So, they don't fit our mission, but others might find them useful. TIA to anyone picking up these packages. -Steve From mclasen at redhat.com Wed Jun 4 22:26:57 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 04 Jun 2008 18:26:57 -0400 Subject: strange koji build failures...? In-Reply-To: <87od6hxgbh.fsf@rho.meyering.net> References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> <87y75lz1uq.fsf@rho.meyering.net> <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> <87od6hxgbh.fsf@rho.meyering.net> Message-ID: <1212618417.5000.2.camel@localhost.localdomain> On Wed, 2008-06-04 at 19:25 +0200, Jim Meyering wrote: > Ond?ej Va??k wrote: > > Hi Jim, > > > > Jim Meyering wrote: > >> Eric Blake fixed that with this change to gnulib's utimens.c: > >> > >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93f08406537 > > > > I know about the fix (was causing troubles with test-suite) - therefore > > that patch is already part of the coreutils-6.12-1.fc10 build - so it > > will not solve the troubles with koji. Problem seems to be in return > > code 280 from futimensat() call. So futimensat is available, but failing > > - the same problem as I had with the coreutils test suite few weeks ago > > (if you remember touch/create-no-missing issue). I would say koji xen > > kernel issue, but could be workarounded by Fedora coreutils. > > Hi Ond?ej, > > I think you're right that it's a kernel problem. > I've proposed a patch attached to http://bugzilla.redhat.com/449910 > as https://bugzilla.redhat.com/attachment.cgi?id=308374 > that might suffice to work around the problem. > > Can you test it? > Hmm, I see that coreutils 6.12 is back in rawhide, and the build failures are back, too: http://koji.fedoraproject.org/koji/buildinfo?buildID=51679 From michael at laptop.org Wed Jun 4 22:39:28 2008 From: michael at laptop.org (Michael Stone) Date: Wed, 4 Jun 2008 18:39:28 -0400 Subject: Help packaging some OLPC network status scripts? In-Reply-To: <20080604122853.GC2585@free.fr> Message-ID: <20080604223927.GA3278@teach.media.mit.edu> On Wed, 4 Jun 2008 at 14:28:53 +0200, Patrice Dumas wrote: > I think that it should be better to do a proper release first. Done. License info, README, and tarball-creation Makefile added. See the stub homepage at http://wiki.laptop.org/go/Olpc-netutils for the gory details. Thanks again, Michael home: http://wiki.laptop.org/go/Olpc-netutils src: http://dev.laptop.org/git/projects/olpc-netutils git: git://dev.laptop.org/projects/olpc-netutils tar: http://dev.laptop.org/~mstone/releases/SOURCES/olpc-netutils-0.1.tar.bz2 sig: http://dev.laptop.org/~mstone/releases/SOURCES/olpc-netutils-0.1.tar.bz2.asc From amdunn at gmail.com Thu Jun 5 00:32:29 2008 From: amdunn at gmail.com (Alan Dunn) Date: Wed, 4 Jun 2008 20:32:29 -0400 Subject: Packaging issues with files section for my future coq package In-Reply-To: <20080604225729.1f3ea4fc.mschwendt@gmail.com> References: <20080604225729.1f3ea4fc.mschwendt@gmail.com> Message-ID: The full spec file is below - My motivation for doing things the way I did was that I wanted to incorporate arbitrarily deep (admittedly I know the depth for this particular version in advance, but one can imagine this changing between versions and it didn't seem like a good solution to create something that would have to be fixed with each upgrade) directory structures instead of including /usr/lib/coq/* /usr/lib/coq/*/* (etc) so instead I just took the directory structure as it was created with find. That's why some files are excluded in the main package and included in the subpackage. Of course, I suppose I could also just change the find query to do the exclusion as well... perhaps that's better? Or perhaps it's considered poor practice to do what I've done here, is that so? (I don't really know what tradition is as this is my first package, but I didn't see anything guiding advice in docs and I've seen other packages do this.) The full spec file: Name: coq Version: 8.1pl3 Release: 1%{?dist} Summary: Coq proof management system Group: Applications/Engineering License: LGPLv2 URL: http://coq.inria.fr/ Source0: http://coq.inria.fr/V%{version}/files/coq-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: ocaml >= 3.08, ocaml-camlp5-devel %description Coq is a formal proof management system. It allows for the development of theorems through first order logic that are mechanically checked by the machine. Sets of definitions and theorems can be saved as compiled modules and loaded into the system. This package provides the main Coq binary without an optional IDE, Coqide. %package coqide Group: Applications/Engineering Summary: Coqide IDE for Coq proof system. Requires: coq BuildRequires: ocaml >= 3.08, ocaml-camlp5-devel, gtk+-devel, ocaml-lablgtk-devel %description coqide Coq is a formal proof management system. It allows for the development of theorems through first order logic that are mechanically checked by the machine. Sets of definitions and theorems can be saved as compiled modules and loaded into the system. This package provides Coqide, a lightweight IDE for Coq. %prep %setup -q rm -f coqlibfiles coqfiles rm -f install-emacs install-tex # Test for emacs site_lisp directory, if so, add relevant files to roster, else, don't try and install %define emacsdir %{_datadir}/emacs/site-lisp %if %(test -e %{emacsdir} && echo 1 || echo 0) %define emacsopt -emacs %{emacsdir} echo '%{emacsdir}/coq*' >> coqfiles %else %define emacsopt touch install-emacs %endif # Test for tex directory, if so, add relevant files to roster, else, don't try and install %define texdir %{_datadir}/texmf/tex/latex/misc %if %(test -e %{texdir} && echo 1 || echo 0) %define texopt -coqdocdir %{texdir} echo "%{texdir}/coqdoc.sty" >> coqfiles %else %define texopt touch install-latex %endif %build ./configure -prefix %{_prefix} -bindir %{_bindir} -mandir %{_mandir} %{emacsopt} %{texopt} -reals all > /dev/null make world # Test if we built an optimized parser %if %(test -e %{buildroot}%{_bindir}/parser.opt && echo 1 || echo 0) echo "%{_bindir}/parser.opt" >> coqfiles %endif %install rm -rf %{buildroot} make COQINSTALLPREFIX="%{buildroot}" install # Build file list for ones that are hard to account for otherwise find %{buildroot}%{_libdir}/coq -fprint coqlibfiles sed -i -e "s|%{buildroot}||" coqlibfiles cat coqlibfiles >> coqfiles %clean rm -rf %{buildroot} make clean %files -f coqfiles %defattr(-,root,root) %doc CHANGES COMPATIBILITY COPYRIGHT CREDITS INSTALL INSTALL.ide KNOWN-BUGS LICENSE README %doc %{_mandir}/man1/coq* %doc %{_mandir}/man1/gallina.1.gz %doc %{_mandir}/man1/parser.1.gz %{_bindir}/coq* %{_bindir}/gallina %{_bindir}/parser # Parser.opt included seperately %exclude %{_bindir}/coqide* %exclude %{_libdir}/coq/ide/* %files coqide %defattr(-,root,root) %{_bindir}/coqide* %{_libdir}/coq/ide/* %changelog * Wed Jun 14 2008 Alan Dunn 8.1pl3-1 - Initial version. Thanks, - Alan On Wed, Jun 4, 2008 at 4:57 PM, Michael Schwendt wrote: > On Wed, 4 Jun 2008 14:26:51 -0400, Alan Dunn wrote: > >> I'm trying to package the Coq theorem proving system. >> >> My goal is to create a main package with the system and then a >> subpackage for the (optional) IDE. I've written out a spec file, and >> it does compile (that is, I can generate rpms with "rpmbuild -bb >> SPECS/coq.spec"), but this process generates quite a number of "file >> listed twice" warnings that I would like to eliminate like: >> >> warning: File listed twice: /usr/lib/coq/contrib >> warning: File listed twice: /usr/lib/coq/contrib.cma >> warning: File listed twice: /usr/lib/coq/contrib.cmxa >> warning: File listed twice: /usr/lib/coq/contrib/field >> warning: File listed twice: /usr/lib/coq/contrib/field >> warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo >> warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo >> warning: File listed twice: /usr/lib/coq/contrib/field/LegacyField.vo >> ... >> >> (the duplicated warnings are listed multiple times in the output, as >> are many files) >> >> I thought that somehow things could've gone wrong in the files list >> that I generate to use in the %files section via: >> >> find %{buildroot}%{_libdir}/coq -fprint coqlibfiles >> sed -i -e "s|%{buildroot}||" coqlibfiles > > What is in "coqfiles" at this point? > >> cat coqlibfiles >> coqfiles >> >> but none of the files are duplicated in the coqfiles file > > Post the full spec file, because your quoted fragment is incomplete. > You create "coqlibfiles", then append it to "coqfiles", but whether > "coqfiles" is empty or set up with other contents is unknown. If > empty, you could use "-f coqlibiles" directly instead of creating > a copy. > >> %files -f coqfiles >> %defattr(-,root,root) >> %doc CHANGES COMPATIBILITY COPYRIGHT CREDITS INSTALL INSTALL.ide >> KNOWN-BUGS LICENSE README >> %doc %{_mandir}/man1/coq* >> %doc %{_mandir}/man1/gallina.1.gz >> %doc %{_mandir}/man1/parser.1.gz >> %{_bindir}/coq* >> %{_bindir}/gallina >> %{_bindir}/parser >> # Parser.opt included seperately >> %exclude %{_bindir}/coqide* >> %exclude %{_libdir}/coq/ide/* >> >> %files coqide >> %defattr(-,root,root) >> %{_bindir}/coqide* >> %{_libdir}/coq/ide/* >> >> Anyone know what I'm doing wrong? > > Why don't you include and exclude the directories directly > in the %files sections? > > -- > Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 > loadavg: 1.00 1.04 1.12 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From bpepple at fedoraproject.org Thu Jun 5 00:36:46 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jun 2008 20:36:46 -0400 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <1212606751.9688.39.camel@localhost.localdomain> References: <1212598683.22896.1.camel@kennedy> <1212606751.9688.39.camel@localhost.localdomain> Message-ID: <1212626206.28894.1.camel@kennedy> On Wed, 2008-06-04 at 15:12 -0400, Jesse Keating wrote: > I have a topic. Casey Dahlin has been doing some good work on making > https://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment a > reality. We're very close. One decision that I'd like to see discussed > is what we use to prime the membership of the as of yet to be named > elevated rights group. One suggestion has been to grandfather all of > current cvsextras into said group, however I think this would make the > later initiative > https://fedoraproject.org/wiki/JesseKeating/PackageACLOpening less > successful. Instead I suggest priming the group with current sponsors, > and allow any existing sponsor to promote the people they sponsor into > the elevated group. I'm also open to further ideals or discussions on > this. I'll add it to the schedule. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Thu Jun 5 00:42:47 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jun 2008 20:42:47 -0400 Subject: Plan for tomorrows (20080605) FESCO meeting In-Reply-To: <20080604192020.GC2662@free.fr> References: <1212598683.22896.1.camel@kennedy> <20080604182924.GA2662@free.fr> <20080604192020.GC2662@free.fr> Message-ID: <1212626567.28894.3.camel@kennedy> On Wed, 2008-06-04 at 21:20 +0200, Patrice Dumas wrote: > No. But I assumed that this was not needed, since it only opens > possiblities for the sponsors, responsibilities come only when they > sponsor somebody. And, unless I don't remember well nobody asked me > first when I was nominated, and I don't think it is an issue. Maybe > procedures changed, though, but I didn't saw anything like that on the > wiki page. I don't find sponsor related pages in the wiki anymore, > however so maybe I read it too fast. Here's a link to the page: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors 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: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Thu Jun 5 04:14:00 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 4 Jun 2008 22:14:00 -0600 Subject: Xfce SIG meeting! In-Reply-To: <1211721302.3386.8.camel@wicktop.localdomain> References: <20080523162955.7677c1a3@ohm.scrye.com> <1211721302.3386.8.camel@wicktop.localdomain> Message-ID: <20080604221400.75187fa6@ohm.scrye.com> On Sun, 25 May 2008 15:15:02 +0200 christoph.wickert at googlemail.com (Christoph Wickert) wrote: > Am Freitag, den 23.05.2008, 16:29 -0600 schrieb Kevin Fenzi: > > Greetings. > > > > We would like to try and get together interested folks for the first > > Xfce SIG meeting, sometime next week on irc.freenode.net in the > > #fedora-meeting channel. > > > > Please see: > > http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > > for when available times are for the #fedora-meeting channel. > > > > If interested parties could mail me their preferred times for > > meeting, I can schedule a meeting time for next week. > > For me every free slot between 20.00-23.00 UTC should be okay, not > sure if this suitable for others, so I'm open to more suggestions. > > > Note that I will be out on > > vacation next week, but should have net and be able to meet anyhow. > > I will be attending Linuxtag at Berlin next week, so my time and net > access is limited. I think I should be able to do it in the evenings, > otherwise is suggest we start a week later. Yeah, and I was traveling last week as well, so I guess it didn't work after all. ;( How about we try next week? Would tuesday work? 21:00 UTC? > Christoph kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From cooly at gnome.eu.org Thu Jun 5 05:34:39 2008 From: cooly at gnome.eu.org (Lucian Langa) Date: Thu, 05 Jun 2008 08:34:39 +0300 Subject: Orphaned Packages In-Reply-To: <200806041756.27569.sgrubb@redhat.com> References: <200806041521.22119.sgrubb@redhat.com> <604aa7910806041237s39b8ba81u9fcc3b93b45315a@mail.gmail.com> <200806041756.27569.sgrubb@redhat.com> Message-ID: <1212644079.3258.159.camel@mayday> On Wed, 2008-06-04 at 17:56 -0400, Steve Grubb wrote: > On Wednesday 04 June 2008 15:37:22 Jeff Spaleta wrote: > > > Just letting anyone interested know that these packages have been > > > orphaned: > > > > > > gpsman -- GPS data manager > > > nec2c -- a translation of the Numerical Electromagnetics Code (NEC2) > > > splat -- Analyze point-to-point terrestrial RF communication links > > > > reasons? Are these things still worth maintaining in your estimation? I will take gpsman, as I have other package that depends on it. From dhaval at linux.vnet.ibm.com Thu Jun 5 05:28:21 2008 From: dhaval at linux.vnet.ibm.com (Dhaval Giani) Date: Thu, 5 Jun 2008 10:58:21 +0530 Subject: koji broken? Message-ID: <20080605052821.GA28377@linux.vnet.ibm.com> Hi, I just checked out my package, checked in the srpm, tagged it and built it. The build is for dist-f10 as my koji screen says, but it gets tagged as dist-fc7. Expected? More details at http://koji.fedoraproject.org/koji/packageinfo?packageID=6291 A side question, how long does it take from build for it to propogate into rawhide? Thanks -- regards, Dhaval From dennis at ausil.us Thu Jun 5 05:46:23 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 5 Jun 2008 00:46:23 -0500 Subject: koji broken? In-Reply-To: <20080605052821.GA28377@linux.vnet.ibm.com> References: <20080605052821.GA28377@linux.vnet.ibm.com> Message-ID: <200806050046.32648.dennis@ausil.us> On Thursday 05 June 2008, Dhaval Giani wrote: > Hi, > > I just checked out my package, checked in the srpm, tagged it and built > it. The build is for dist-f10 as my koji screen says, but it gets tagged > as dist-fc7. Expected? > > More details at > http://koji.fedoraproject.org/koji/packageinfo?packageID=6291 > > A side question, how long does it take from build for it to propogate > into rawhide? its in rawhide and it will show up tomorrow. the dist-fc7 on that page is the starting tag that all packages get added to koji. due to inheritance it propagates everywhere. Dennis From stickster at gmail.com Thu Jun 5 06:28:54 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 5 Jun 2008 08:28:54 +0200 Subject: Board IRC meeting Message-ID: <01f101c8c6d5$6d52b650$ba00000a@grecom.local> In the past few months, the Board has scheduled a public IRC meeting on the first meeting of the month. Because of the timing of LinuxTag last week, however, there will not be a public Board IRC meeting on Tuesday, June 3. We will announce the next public IRC meeting well in advance so community members can attend if desired. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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: -------------- next part -------------- -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From stickster at gmail.com Thu Jun 5 06:29:04 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 5 Jun 2008 08:29:04 +0200 Subject: Board IRC meeting Message-ID: <01f501c8c6d5$734d5240$ba00000a@grecom.local> In the past few months, the Board has scheduled a public IRC meeting on the first meeting of the month. Because of the timing of LinuxTag last week, however, there will not be a public Board IRC meeting on Tuesday, June 3. We will announce the next public IRC meeting well in advance so community members can attend if desired. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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: -------------- next part -------------- -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From hliu at redhat.com Thu Jun 5 06:55:00 2008 From: hliu at redhat.com (Hao Liu) Date: Thu, 05 Jun 2008 14:55:00 +0800 Subject: [Help] About check out package from CVS Message-ID: <48478DC4.9010801@redhat.com> Hi, I'm running into a problem when I tried to check out package from the repository, I followed the steps given in http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools, no luck. I tried: $cvs co /package-name/ / /error messages: *Permission denied (publickey,keyboard-interactive).** cvs [checkout aborted]: end of file from server (consult above messages if any) * were given out. Additional info: 1. rpm -q cvs cvs-1.11.22-13.fc9.i386 2. echo $CVSROOT :ext:hliu at cvs.fedoraproject.org:/cvs/package-name 3. echo $CVS_RSH ssh Any help will be greatly appreciated, :-) All the best, Hao Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Thu Jun 5 07:15:43 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 5 Jun 2008 10:15:43 +0300 (EEST) Subject: rpmreaper In-Reply-To: <200806041126.52859.sgrubb@redhat.com> References: <20080603154111.GA24155@localhost> <200806031956.56968.sgrubb@redhat.com> <200806041126.52859.sgrubb@redhat.com> Message-ID: On Wed, 4 Jun 2008, Steve Grubb wrote: > On Wednesday 04 June 2008 02:55:19 Panu Matilainen wrote: >> On Tue, 3 Jun 2008, Steve Grubb wrote: >>> Not really. Bash has been patched to to spit out the programs it calls >>> (/bin/bash --rpm-requires). So, its a matter of overriding >>> %__find_requires to run a program that gathers the information for shell >>> scripts and falls back to the old way for others. >>> >>> No one should have to specify this, it can be automated easily. Without >>> taking shell scripts into account, you run the risk of breaking >>> unspecified requirements. >> >> I wish it were that simple. >> >> "bash --rpm-requires" does a fair job for the impossible task, but it >> produces way too much bogus information and false positives to be >> generally usable as is. A quick check at various scripts found on a stock >> F9 system shows at least these problems: >> >> 1) It mistakes functions declared in sourced scripts as executables >> 2) It mistakes functions used before declared as executables > > In my opinion, these ^^ should be fixed. Yup, that'd be the first step in making --rpm-requires actually usable beyond just curiosity. >> 3) It thinks of sourced scripts as executables > > In a sense, they are. My init scripts source /etc/init.d/functions, so that is > a real dependency. It's a real dependency yes, but sourced files need not be *executable*, they just need to be there. Whether the difference matters depends on later implementation details: if PATH or executable bits of files are involved, sourced files need to be separated from executables, file(/some/path) notation or such. >> 4) It produces hard dependencies for conditional items > > I agree this is a problem. I think it gets worse the further nested a program > would be in if staements. But as a first pass, one could fix it to only check > files not within a if statement and add logic later to go deeper. Something > is better than nothing as right now we do not capture shell script > dependencies and they *are* real. Ignoring dependencies from all conditional execution paths (except constant conditions like "while [ 1 -eq 1 ]") is the only 100% correct and safe thing you can do. Beyond that, bash simply cannot know whether something is a hard dependency or not at package build time. So either the conditional paths are ignored, or you live with the fact that you WILL need to filter out dependencies manually. If bash could classify it's findings into conditional and unconditional, that'd at least make life easier for the human filtering the deps. Initscripts (and mkinitrd) might well be about the worst case you can get for this, as they do a whole lot of things like "if x happens to be installed then enable/do something with it, otherwise it doesn't matter" which should not be turned into hard dependencies. A good example is rhgb-client - you can bet that lot of folks would be upset if that was made into hard dependency of initscripts :) >> 5) For most executables, path is unknown > > There is a standard PATH that the distribution expects. So there is some > defined search order. I solved this in the build system I wrote by keeping a > list of all files installed by rpm as packages were built. Then the > find-requires script would resolve the name to full path based on the > standard PATH. This is solvable. It's solvable by various means, yes. Anything requiring rpm to be aware of distribution contents at build time is not really a generic solution though. >> Assuming 1-3) are fixed and ignoring 4), 5) could be dealt with, at least >> to some extent, but it's a big can of worms too. For the dependencies to >> be discoverable by yum & friends, there would have to be matching provides >> for all executable(foo) items bash --rpm-requires produces. >> >> Rpm could automatically add Provides: executable(foo) for any file with >> executable bits on, but it would cause *enormous* bloat of metadata. > > Bloat, to me, means something that would never be used. If the dependencies > are real, they should be captured. Do you need to have the dependency at the > file level or package level? Maybe that reduces some of the metadata? Note that I wasn't speaking of requires, but provides to satisfy the requires IF automatically added as Provides: executable() for all executable files (in system PATH or otherwise). Most of those provides would never be used by anything so they would be nothing but bloat. Resolving file dependencies into packages at build time would require rpm to be aware of "outside world", ie what's available in repositories, and would require unnecessary rebuilds on package splits and renames (the good old "file dependencies considered harmful or not" issue) >> So solving 5) should be possible if 1-3) were fixed, but it'd still be >> pretty moot because 4) can't generally be solved (apart from manually >> filtering bogus dependencies, at which point it's hardly "easily >> automated" :) > > I don't think #4 is impossible. Its not easy either. But I think we could get > a first pass that is pretty good and make it better over time. Right now, we > capture nothing. So, a first pass solution that captures 25% accurately is > better than where we are. Except for unconditional execution, #4 is impossible to solve programmatically. The moment you start down the conditional paths, it's just blind poking around in the dark - heuristics based on no knowledge at all. Even if you assume access to the distributions file list, there's no way to tell if something is intentionally optional (in which case making it a hard requirement would be an error) or not, or if a given condition is supposed to ever occur on the target platform and version. > In the build system I wrote, I lumped #4 and #5 together and solved them with > a lookup table. It was good enough for my needs. If I resolved the path, the > dependency was recorded. If not, I didn't record it. So, > if /sbin/solaris-specific was not in my distribution's file list, it was > quietly removed from the possible dependencies. See above, this still catches all sorts of things that should not be hard dependencies. Mind you, I don't disagree with the goal at all: automatically recording unconditional script dependencies would be a very good thing if it can be made reliable - fixing 1-2) would be a start. - Panu - From dan at danny.cz Thu Jun 5 07:27:47 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 05 Jun 2008 09:27:47 +0200 Subject: [Help] About check out package from CVS In-Reply-To: <48478DC4.9010801@redhat.com> References: <48478DC4.9010801@redhat.com> Message-ID: <1212650867.26252.7.camel@eagle.danny.cz> Hao Liu p??e v ?t 05. 06. 2008 v 14:55 +0800: > Hi, > I'm running into a problem when I tried to check out package from > the repository, > I followed the steps given in > http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools, no luck. > I tried: > $cvs co package-name > error messages: > Permission denied (publickey,keyboard-interactive). > cvs [checkout aborted]: end of file from server (consult > above messages if any) > were given out. > > Additional info: > 1. rpm -q cvs > cvs-1.11.22-13.fc9.i386 > 2. echo $CVSROOT > :ext:hliu at cvs.fedoraproject.org:/cvs/package-name export CVSROOT=:ext:hliu at cvs.fedoraproject.org:/cvs/pkgs and then do "cvs co your-package" > 3. echo $CVS_RSH > ssh > > Any help will be greatly appreciated, :-) Dan From hliu at redhat.com Thu Jun 5 07:34:32 2008 From: hliu at redhat.com (Hao Liu) Date: Thu, 05 Jun 2008 15:34:32 +0800 Subject: [Help] About check out package from CVS In-Reply-To: <1212650867.26252.7.camel@eagle.danny.cz> References: <48478DC4.9010801@redhat.com> <1212650867.26252.7.camel@eagle.danny.cz> Message-ID: <48479708.7090404@redhat.com> Dan Hor?k wrote: > Hao Liu p??e v ?t 05. 06. 2008 v 14:55 +0800: > >> Hi, >> I'm running into a problem when I tried to check out package from >> the repository, >> I followed the steps given in >> http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools, no luck. >> I tried: >> $cvs co package-name >> error messages: >> Permission denied (publickey,keyboard-interactive). >> cvs [checkout aborted]: end of file from server (consult >> above messages if any) >> were given out. >> >> Additional info: >> 1. rpm -q cvs >> cvs-1.11.22-13.fc9.i386 >> 2. echo $CVSROOT >> :ext:hliu at cvs.fedoraproject.org:/cvs/package-name >> > > export CVSROOT=:ext:hliu at cvs.fedoraproject.org:/cvs/pkgs > > and then do "cvs co your-package" > > >> 3. echo $CVS_RSH >> ssh >> >> Any help will be greatly appreciated, :-) >> > > > Dan > > > hey, Dan, Thank u for ur prompt response, :-) But I really can't tell there's any diff, though I tried according to ur instructions, still no luck All the best, Hao Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at danny.cz Thu Jun 5 07:45:19 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 05 Jun 2008 09:45:19 +0200 Subject: [Help] About check out package from CVS In-Reply-To: <48479708.7090404@redhat.com> References: <48478DC4.9010801@redhat.com> <1212650867.26252.7.camel@eagle.danny.cz> <48479708.7090404@redhat.com> Message-ID: <1212651919.26252.13.camel@eagle.danny.cz> Hao Liu p??e v ?t 05. 06. 2008 v 15:34 +0800: > Dan Hor?k wrote: > > Hao Liu p??e v ?t 05. 06. 2008 v 14:55 +0800: > > > > > Hi, > > > I'm running into a problem when I tried to check out package from > > > the repository, > > > I followed the steps given in > > > http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools, no luck. > > > I tried: > > > $cvs co package-name > > > error messages: > > > Permission denied (publickey,keyboard-interactive). > > > cvs [checkout aborted]: end of file from server (consult > > > above messages if any) > > > were given out. > > > > > > Additional info: > > > 1. rpm -q cvs > > > cvs-1.11.22-13.fc9.i386 > > > 2. echo $CVSROOT > > > :ext:hliu at cvs.fedoraproject.org:/cvs/package-name > > > > > > > export CVSROOT=:ext:hliu at cvs.fedoraproject.org:/cvs/pkgs > > > > and then do "cvs co your-package" > > > > > > > 3. echo $CVS_RSH > > > ssh > > > > > > Any help will be greatly appreciated, :-) > > > > > > > > > Dan > > > > > > > hey, Dan, > Thank u for ur prompt response, :-) > But I really can't tell there's any diff, though I tried according > to ur instructions, still no luck Is your ssh public key uploaded into Fedora Accounts System (https://admin.fedoraproject.org/accounts/user/view/hliu)? And from what I can see, you are not sponsored yet (not approved for cvsextras group). Dan From mschwendt at gmail.com Thu Jun 5 09:10:59 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Jun 2008 11:10:59 +0200 Subject: Locale codeset UTF-8 vs. utf8 Message-ID: <20080605111059.6570af0f.mschwendt@gmail.com> Default GNOME user in Fedora 9: $ env|grep LANG LANG=en_US.utf8 GDM_LANG=en_US.utf8 Logging in as superuser: $ su - # env|grep LANG LANG=en_US.UTF-8 Switching back to normal user: # su - user $ env|grep LANG LANG=en_US.UTF-8 The difference in the spelling of the codeset breaks Sylpheed (#450063) which only looks for codeset "UTF-8". Now where again is it defined that both are valid spellings for the codeset? $ locale -a|grep utf8|wc -l 230 $ locale -a|grep UTF-8|wc -l 2 From jakub at redhat.com Thu Jun 5 09:22:51 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 5 Jun 2008 05:22:51 -0400 Subject: Locale codeset UTF-8 vs. utf8 In-Reply-To: <20080605111059.6570af0f.mschwendt@gmail.com> References: <20080605111059.6570af0f.mschwendt@gmail.com> Message-ID: <20080605092251.GM13386@devserv.devel.redhat.com> On Thu, Jun 05, 2008 at 11:10:59AM +0200, Michael Schwendt wrote: > The difference in the spelling of the codeset breaks Sylpheed (#450063) > which only looks for codeset "UTF-8". Now where again is it defined > that both are valid spellings for the codeset? Then Sylpheed is just broken. It shouldn't look at the locale name, but instead at nl_langinfo (CODESET) (the same can be queried from locale -k LC_CTYPE | grep ^charmap= ). And, no matter what spelling you use in the .* part of locale name in environment, CODESET is the same: LC_ALL=en_US.UTF-8 locale -k LC_CTYPE | grep charmap charmap="UTF-8" LC_ALL=en_US.utf8 locale -k LC_CTYPE | grep charmap charmap="UTF-8" LC_ALL=en_US.utf-8 locale -k LC_CTYPE | grep charmap charmap="UTF-8" LC_ALL=en_US.UTF_8 locale -k LC_CTYPE | grep charmap charmap="UTF-8" Jakub From martin.sourada at gmail.com Thu Jun 5 09:32:03 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Thu, 05 Jun 2008 11:32:03 +0200 Subject: Locale codeset UTF-8 vs. utf8 In-Reply-To: <20080605092251.GM13386@devserv.devel.redhat.com> References: <20080605111059.6570af0f.mschwendt@gmail.com> <20080605092251.GM13386@devserv.devel.redhat.com> Message-ID: <1212658323.2996.14.camel@pc-notebook> On Thu, 2008-06-05 at 05:22 -0400, Jakub Jelinek wrote: > On Thu, Jun 05, 2008 at 11:10:59AM +0200, Michael Schwendt wrote: > > The difference in the spelling of the codeset breaks Sylpheed (#450063) > > which only looks for codeset "UTF-8". Now where again is it defined > > that both are valid spellings for the codeset? > > Then Sylpheed is just broken. It shouldn't look at the locale name, > but instead at nl_langinfo (CODESET) (the same can be queried from > locale -k LC_CTYPE | grep ^charmap= > ). > And, no matter what spelling you use in the .* part of locale name > in environment, CODESET is the same: > > LC_ALL=en_US.UTF-8 locale -k LC_CTYPE | grep charmap > charmap="UTF-8" > LC_ALL=en_US.utf8 locale -k LC_CTYPE | grep charmap > charmap="UTF-8" > LC_ALL=en_US.utf-8 locale -k LC_CTYPE | grep charmap > charmap="UTF-8" > LC_ALL=en_US.UTF_8 locale -k LC_CTYPE | grep charmap > charmap="UTF-8" > > Jakub > Sounds sane, though I faced very similar problem with Evolution some time back, when my e-mail written in Czech (with diacritic marks) was delivered broken - because only Evolution was able to tell what utf8 charset actually is... Of course, manually setting it to UTF-8 fixed the issue... I wondered whether the problem was due to wrong setting after upgrading to Fedora 9 or something else, but I didn't pursued the issue further. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Thu Jun 5 09:34:21 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Jun 2008 11:34:21 +0200 Subject: Locale codeset UTF-8 vs. utf8 In-Reply-To: <20080605092251.GM13386@devserv.devel.redhat.com> References: <20080605111059.6570af0f.mschwendt@gmail.com> <20080605092251.GM13386@devserv.devel.redhat.com> Message-ID: <20080605113421.d37f72c2.mschwendt@gmail.com> On Thu, 5 Jun 2008 05:22:51 -0400, Jakub Jelinek wrote: > On Thu, Jun 05, 2008 at 11:10:59AM +0200, Michael Schwendt wrote: > > The difference in the spelling of the codeset breaks Sylpheed (#450063) > > which only looks for codeset "UTF-8". Now where again is it defined > > that both are valid spellings for the codeset? > > Then Sylpheed is just broken. It shouldn't look at the locale name, > but instead at nl_langinfo (CODESET) (the same can be queried from > locale -k LC_CTYPE | grep ^charmap= > ). Thanks. Found it already while skimming over setlocale(3). From rawhide at fedoraproject.org Thu Jun 5 09:42:42 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 5 Jun 2008 09:42:42 +0000 (UTC) Subject: rawhide report: 20080605 changes Message-ID: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080604/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080605/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package libcgroup Tools and libraries to control and monitor control groups Removed package python-urljr Removed package python-yadis Updated Packages: GConf2-2.23.1-1.fc10 -------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Upodate to 2.23.1 ORBit2-2.14.13-1.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.14.13-1 - Update to 2.14.13 Pyrex-0.9.8.2-2.fc10 -------------------- anaconda-11.4.1.3-1 ------------------- * Wed Jun 4 18:00:00 2008 Chris Lumens - 11.4.1.3-1 - Can't reference iutil.whatever from inside iutil.py. (clumens) - When using the boot.iso and URL installs, download the .treeinfo file. (clumens) - Fix a couple typos in the getArch commit. (clumens) - Be consistent with data type. (dcantrell) - Replace rhpl.getArch() calls with iutil calls. (dcantrell) - Expand iutil.isX86() and added iutil.getArch() (dcantrell) - Add isAlpha() test function to iutil. (dcantrell) - Create architecture test functions in iutil (dcantrell) - Removed mystrstr() function in loader2/init.c (dcantrell) - Don't support Arabic in text mode installs since we don't even do RTL. (clumens) - Removed old strace debugging in loader2/init (dcantrell) - Keep only one copy of this code for group sorting/display around (katzj) - Stop using rhpl.translate and use gettext directly (katzj) - Add a descriptive comment to the top of /etc/fstab (#448966). (clumens) - Use "message" instead of "value" on errors, and stringify on the front side. (pjones) - Translate package descriptions (#449455). (clumens) - Translate password error messages (#439981). (clumens) - Fix traceback starting vnc (#449295) (katzj) - Add Hewbrew to lang-table (oron) - Fix errors in python string formatting (#449130). (clumens) avahi-0.6.22-11.fc10 -------------------- * Wed Jun 4 18:00:00 2008 Rex Deiter - 0.6.22-11 - qt4 bindings (#446904) - devel: BR: pkgconfig - nuke rpaths bug-buddy-2.22.0-4.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 1:2.22.0-4 - Rebuild cheese-2.23.3-1.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen 2.23.3-1 - Update to 2.23.3 control-center-2.23.3-1.fc10 ---------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 coreutils-6.11-4.fc10 --------------------- cronie-1.1-2.fc10 ----------------- * Wed Jun 4 18:00:00 2008 Marcela Maslanova - 1.1-2 - 49864 upgrade/update problem. Syntax error in spec. curl-7.18.2-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Jindrich Novy 7.18.2-1 - update to 7.18.2 e2fsprogs-1.40.10-3.fc10 ------------------------ * Wed Jun 4 18:00:00 2008 Eric Sandeen 1.40.10-3 - Tidy up multilib hack for non-multilib arches (#446016) - Fix up %postun script (#449868) * Wed Jun 4 18:00:00 2008 Dennis Gilmore 1.40.10-2 - setup header support for sparc edrip-fonts-20080523-2.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 - 20080523-2 ??? Fix URL ??? Register in new fantasy generic eel2-2.23.2-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Tomas Bzatek - 2.23.2-1 - Update to 2.23.2 eog-2.23.3-3.fc10 ----------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 2.23.2-2 - fix license tag evolution-2.23.3.1-2.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Matthew Barnes - 2.23.3.1-2.fc10 - Add patches for RH bug #449925 (buffer overflow vulnerabilities). f-spot-0.4.3.1-2.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Caol??n McNamara - 0.4.3.1-2 - rebuild for dependancies freedoom-0.6.2-1.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Wart 0.6.2-1 - Update to 0.6.2 freedoom-freedm-0.6.2-1.fc10 ---------------------------- * Wed Jun 4 18:00:00 2008 Wart 0.6.2-1 - Update to 0.6.2 galculator-1.3.1-1.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Tomas Mraz - 1.3.1-1 - upgrade to latest upstream gcalctool-5.23.3-1.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 5.23.3-1 - Up'date to 5.23.3 gecko-sharp2-0.13-1.fc10 ------------------------ * Wed Jun 4 18:00:00 2008 Tom "spot" Callaway - 0.13-1 - update to 2.0-0.13 gnome-applet-music-2.3.1-3.fc10 ------------------------------- * Wed Jun 4 18:00:00 2008 Peter Gordon - 2.3.1-3 - Apply proper fix from upstream, adding a pyexecdir setting to the 'make install' invocation (following the automake manual for it) instead of reverting the BZR change. Drop the now-unnecessary patch: - fix-widgets-destdir.patch * Wed Jun 4 18:00:00 2008 Peter Gordon - 2.3.1-2 - Add patch to correct the widgets.so location, which fixes import errors on adding/initializing the applet. Resolves bug 449105 (Music Applet Crash): + fix-widgets-destdir.patch gnome-applets-2.23.2-2.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 1:2.23.2-2 - Rebuild gnome-desktop-2.23.3-1.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Tomas Bzatek - 2.23.3-1 - Update to 2.23.3 - Removed patches that are upstream gnome-do-0.4.2.0-2.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Caol??n McNamara - 0.4.2.0-2 - rebuild for dependancies gnome-games-2.23.3-1.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 1:2.23.3-1 - Update to 2.23.3 gnome-media-2.23.3-1.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 gnome-menus-2.23.3-1.fc10 ------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 gnome-panel-2.23.3-1.fc10 ------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - 2.23.3 gnome-python2-desktop-2.22.0-5.fc10 ----------------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.22.0-5 - Rebuild gnome-screensaver-2.23.3-0.2008.05.29.2.fc10 -------------------------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-0.2008.05.29.2 - Rebuild gnome-session-2.23.3-1.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 gnome-settings-daemon-2.23.3-1.fc10 ----------------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 gnome-sharp-2.16.1-3.fc10 ------------------------- * Wed Jun 4 18:00:00 2008 Tom "spot" Callaway - 2.16.1-3 - fix license, fix libdir patch (gconf-sharp-peditors-2.0.pc) gnome-system-monitor-2.23.3-1.fc10 ---------------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 gnome-terminal-2.23.3.1-1.fc10 ------------------------------ * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.22.3.1-1 - Update to 2.23.3.1 gnome-utils-2.20.0.1-7.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 1:2.20.0.0.1-7 - Rebuild * Thu May 22 18:00:00 2008 Matthias Clasen - 1:2.20.0.0.1-6 - Fix a directory ownership bug gpm-1.20.3-2.fc10 ----------------- * Wed Jun 4 18:00:00 2008 Zdenek Prikryl - 1.20.3-2 - Enable gpm in runlevel 5 gsf-sharp-0.8.1-7.fc10 ---------------------- gtk2-2.13.2-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.13.2-1 - Update to 2.13.2, drop upstreamed patches gtksourceview-sharp-2.0.12-3.fc10 --------------------------------- * Wed Jun 4 18:00:00 2008 Tom "spot" Callaway - 2.0.12-3 - fix deps (uses gtksourceview1, not 2) * Wed Jun 4 18:00:00 2008 Tom "spot" Callaway - 2.0.12-2 - rebuild against new mono bits - fix license tag * Fri May 30 18:00:00 2008 Paul F. Johnson - 2.0-0.12-1.1 - rebuild for new gtk-sharp2 * Mon Apr 21 18:00:00 2008 Paul F. Johnson - 2.0-0.12-1 - bump - removed the debug package * Wed Dec 19 17:00:00 2007 Paul F. Johnson - 2.0-0.11-3.1 - excludearch ppc64 * Wed Dec 19 17:00:00 2007 Paul F. Johnson - 2.0-0.11-3 - darned epoch * Wed Dec 19 17:00:00 2007 Paul F. Johnson - 2.0-0.11-2 - fix for version, addition of epoch - now uses gtksourceview2 rather than the old version * Sun Dec 16 17:00:00 2007 Paul F. Johnson - 2.0-0.11-1 - bump - url fix - removal of support for older versions of FC - include BR monodoc-devel irqbalance-0.55-10.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Neil Horman - 2:0.55-10 - Update man page to explain why irqbalance exits on single cache (bz 449949) js-1.70-3.fc10 -------------- * Wed Jun 4 18:00:00 2008 Jon McCann - 1.70-3 - Add two missing files (#449715) kdeartwork-4.0.80-2.fc10 ------------------------ * Wed Jun 4 18:00:00 2008 Kevin Kofler 4.0.80-2 - omit crystalsvg icons for now kdebase-workspace-4.0.80-4.fc10 ------------------------------- * Wed Jun 4 18:00:00 2008 Than Ngo 4.0.80-4 - fix #449881, ksysguard OnlyShowIn=KDE kdebase3-3.5.9-15.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Kevin Kofler - 3.5.9-15 - reinclude crystalsvg icons also on f9+ (no longer using crystalsvg from KDE 4) * Fri May 16 18:00:00 2008 Rex Dieter - 3.5.9-14 - f9+: omit extraneous kcontrol modules (#446575) * Wed May 14 18:00:00 2008 Rex Dieter - 3.5.9-12 - kcontrol modules appearing in gnome "Other" menu (#446466) * Mon Apr 14 18:00:00 2008 Rex Dieter - 3.5.9-10.1 - create/own: /var/lib/kdm (#442081) kdegames3-3.5.9-2.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Kevin Kofler - 3.5.9-2 - reinclude crystalsvg icons also on f9+ (no longer using crystalsvg from KDE 4) kdelibs3-3.5.9-15.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Kevin Kofler 3.5.9-15 - set include_crystalsvg to 1 everywhere - use Epoch 1 for crystalsvg-icon-theme, add Obsoletes kdewebdev-3.5.9-4.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Kevin Kofler - 6:3.5.9-4 - reinclude crystalsvg icons also on f9+ (no longer using crystalsvg from KDE 4) kernel-2.6.26-0.54.rc4.git5.fc10 -------------------------------- * Tue Jun 3 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-06-03 (http://marc.info/?l=linux-wireless&m=121252137324941&w=2) - Upstream wireless updates from 2008-06-03 (http://marc.info/?l=linux-wireless&m=121252503832192&w=2) * Tue Jun 3 18:00:00 2008 Dave Jones - 2.6.26-rc4-git5 libapreq2-2.09-0.17.rc2.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 Bojan Smojver - 2.09-0.17.rc2 - bump to re-tag * Thu Jun 5 18:00:00 2008 Bojan Smojver - 2.09-0.16.rc2 - new autoconf changed the format of config.status libgnome-2.23.3-1.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Tomas Bzatek - 2.23.3-1 - Update to 2.23.3 libgnomeui-2.23.3-1.fc10 ------------------------ * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 libgphoto2-2.4.1-2.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Jindrich Novy 2.4.1-2 - fix obsoletes - workaround problem with coreutils-6.12 and RHEL5-xen kernels what prevents libgphoto2 koji build libgweather-2.23.3-1.fc10 ------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen 2.23.3-1 - Update to 2.23.3 libvirt-0.4.2-6.fc10 -------------------- * Wed Jun 4 18:00:00 2008 Mark McLoughlin - 0.4.2-6.fc10 - Disable lokkit support again (#449996, #447633) - Ensure 10 is evaluated correctly mail-notification-5.4-1.fc10 ---------------------------- * Wed Jun 4 18:00:00 2008 Dmitry Butskoy - 5.4-1 - update to 5.4 (#445345) mousetweaks-2.23.3-1.fc10 ------------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 nautilus-2.23.3-1.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Tomas Bzatek - 2.23.3-1 - Update to 2.23.3 nautilus-open-terminal-0.9-4.fc10 --------------------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 0.9-4 - Rebuild against latest gnome-desktop - Remove the support for Fedora < 6, since "10" < "6" * Fri May 9 18:00:00 2008 Paul W. Frields - 0.9-3 - Use latest automake in spec ocaml-3.10.2-3.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Richard W.M. Jones - 3.10.2-3 - ocaml-ocamldoc provides ocamldoc (bz #449931). - REMOVED provides of labltk, camlp4. Those are libraries and all packages should now depend on ocaml-labltk / ocaml-camlp4 / -devel as appropriate. openarena-0.7.7-1.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Micha?? Bentkowski - 0.7.7-1 - Add patch - Get rid of macros from Sources openoffice.org-3.0.0-0.0.16.1.fc10 ---------------------------------- * Wed Jun 4 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.16-1 - next version - add openoffice.org-3.0.0.ooo90178.tools.fixmacro.patch - add openoffice.org-3.0.0.oooXXXXX.vcl.cairomaxclip.patch - Resolves: rhbz#449804 fix Requires perl-Convert-Binary-C-0.71-1.fc10 --------------------------------- * Wed Jun 4 18:00:00 2008 Alex Lancaster - 0.71-1 - Update to latest upstream (0.71) perl-GD-SVG-0.28-5.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Alex Lancaster - 0.28-5 - Remove old check construct that prevents build in F-10+ (#449503) perl-Graph-0.84-3.fc10 ---------------------- * Wed Jun 4 18:00:00 2008 Alex Lancaster - 0.84-3 - Remove old check construct that prevents build in F-10+ (#449571) perl-Module-Install-0.75-1.fc10 ------------------------------- * Wed Jun 4 18:00:00 2008 Steven Pritchard 0.75-1 - Update to 0.75. perl-SVG-2.44-1.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Alex Lancaster - 2.44-1 - Update to latest upstream (2.44) - Fix spec file syntax (#449663) - Add BR: perl(Test::More) perl-Test-CPAN-Meta-0.11-1.fc10 ------------------------------- * Wed Jun 4 18:00:00 2008 Steven Pritchard 0.11-1 - Update to 0.11. perl-Test-Deep-0.103-1.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Steven Pritchard 0.103-1 - Update to 0.103. perl-Text-Shellwords-1.08-5.fc10 -------------------------------- * Wed Jun 4 18:00:00 2008 Alex Lancaster - 1.08-5 - Remove old check construct that prevents F-10+ build (#449489) perl-XML-DOM-XPath-0.14-1.fc10 ------------------------------ * Wed Jun 4 18:00:00 2008 Alex Lancaster - 0.14-1 - Update to latest upstream (0.14) - Bump minimum BR for perl(XML::XPathEngine) to 0.10 perl-XML-XPathEngine-0.11-1.fc10 -------------------------------- * Wed Jun 4 18:00:00 2008 Alex Lancaster - 0.11-1 - Update to latest upstream (0.11) pgadmin3-1.8.4-1.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Devrim GUNDUZ 1.8.4-1 - Update to 1.8.4 * Tue Jun 3 18:00:00 2008 Devrim GUNDUZ 1.8.3-1 - Update to 1.8.3 poppler-0.8.3-1.fc10 -------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 0.8.3-1 - Update to 0.8.3 powerman-2.0-2.fc10 ------------------- pybluez-0.15-1.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Will Woods - 0.15-1 - New upstream version python-virtinst-0.300.3-7.fc10 ------------------------------ * Wed Jun 4 18:00:00 2008 Daniel P. Berrange - 0.300.3-7.fc10 - Fix fetching of HVM kernels (rhbz #450032) rrdtool-1.3-0.19.rc7.fc10 ------------------------- * Wed Jun 4 18:00:00 2008 Chris Ricker 1.3-0.19.rc7 - Update to rrdtool 1.3 rc7 seekwatcher-0.12-1.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Eric Sandeen - 0.12-1 - New upstream version, fixes IO plots for high block ranges. * Fri Mar 14 18:00:00 2008 Eric Sandeen - 0.11-1 - New upstream version, includes support for multiple devices. selinux-policy-3.4.1-4.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Dan Walsh 3.4.1-4 - Add livecd policy * Wed Jun 4 18:00:00 2008 Dan Walsh 3.4.1-3 - Dontaudit search of admin_home for init_system_domain - Rewrite of xace interfaces - Lots of new fs_list_inotify - Allow livecd to transition to setfiles_mac tclchecker-1.4-5.20061030cvs.fc10 --------------------------------- * Wed Jun 4 18:00:00 2008 Wart 1.4-5.20061030cvs - Update autoconf support files to known working versions (BZ #449573) tcldebugger-1.4-7.20061030cvs.fc10 ---------------------------------- * Wed Jun 4 18:00:00 2008 Wart 1.4-7.20061030cvs - Update autoconf support files to known working versions (BZ #449464) tdom-0.8.2-4.fc10 ----------------- * Wed Jun 4 18:00:00 2008 Wart - 0.8.2-4 - Change installation directory for faster loading texmaker-1.7.1-1.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Deji Akingunola - 1.7.1-1 - A bug-fix release tog-pegasus-2.7.0-8.fc10 ------------------------ * Tue Jun 3 18:00:00 2008 Vitezslav Crhonek - 2:2.7.0-8 - Add cimsub to package Resolves: #447823 tomboy-0.11.0-3.fc10 -------------------- * Wed Jun 4 18:00:00 2008 Tom "spot" Callaway - 0.11.0-3 - Add error messages instead of empty lines. Resolves "warning CS0642: Possible mistaken empty statement" errors. * Wed Jun 4 18:00:00 2008 Caol??n McNamara - 0.11.0-2 - rebuild for mono dependancies * Tue May 13 18:00:00 2008 Matthias Clasen - 0.11.0-1 - Update to 0.11.0 vala-0.3.3-1.fc10 ----------------- * Wed Jun 4 18:00:00 2008 Michel Alexandre Salim - 0.3.3-1 - Update to 0.3.3 vim-7.1.309-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Karsten Hopp 7.1.309-1 - Patchlevel 309 * Wed Jun 4 18:00:00 2008 Karsten Hopp 7.1.306-1 - patchlevel 306, fixes some unicode characters vinagre-2.23.3.1-1.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Matthias Clasen - 2.23.3.1-1 - Update to 2.23.3.1 vte-0.16.14-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Matthias Clasen - 0.16.14-1 - Update to 0.16.14 wget-1.11.3-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Karsten Hopp 1.11.3-1 - wget-1.11.3, downgrades the combination of the -N and -O options to a warning instead of an error wxPython-2.8.7.1-3.fc10 ----------------------- * Wed Jun 4 18:00:00 2008 Matthew Miller - 2.8.7.1-3 - gratuitously bump package release number to work around build system glitch xfsprogs-2.9.8-3.fc10 --------------------- xorg-x11-drivers-7.3-5.fc10 --------------------------- * Wed Jun 4 18:00:00 2008 Dennis Gilmore 7.3-5 - add sparc drivers zenity-2.23.2-1.fc10 -------------------- * Tue Jun 3 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 Summary: Added Packages: 1 Removed Packages: 2 Modified Packages: 97 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avant-window-navigator-0.2.6-8.fc9.i386 requires libgnome-desktop-2.so.2 awn-extras-applets-0.2.6-4.fc9.i386 requires libgnome-desktop-2.so.2 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 bigboard-0.5.33-2.fc10.i386 requires libgnome-desktop-2.so.2 compiz-gnome-0.7.2-5.fc10.i386 requires libgnome-desktop-2.so.2 deskbar-applet-2.23.2-1.fc10.i386 requires libgnome-desktop-2.so.2 desktop-data-model-1.2.4-1.fc10.i386 requires libgnome-desktop-2.so.2 epiphany-2.22.1.1-1.fc9.i386 requires libgnome-desktop-2.so.2 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 file-browser-applet-0.5.6-2.fc10.i386 requires libgnome-desktop-2.so.2 galeon-2.0.5-1.fc9.i386 requires libgnome-desktop-2.so.2 gnome-compiz-manager-0.10.4-4.fc9.i386 requires libgnome-desktop-2.so.2 gnome-launch-box-0.4-9.fc10.i386 requires libgnome-desktop-2.so.2 icewm-gnome-1.2.35-4.fc9.i386 requires libgnome-desktop-2.so.2 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 nautilus-search-tool-0.2.2-3.fc9.i386 requires libgnome-desktop-2.so.2 orpie-1.4.3-5.fc6.i386 requires camlp4 padevchooser-0.9.4-0.4.svn20070925.fc9.i386 requires libgnome-desktop-2.so.2 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tracker-search-tool-0.6.6-2.fc9.i386 requires libgnome-desktop-2.so.2 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avant-window-navigator-0.2.6-8.fc9.i386 requires libgnome-desktop-2.so.2 avant-window-navigator-0.2.6-8.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) awn-extras-applets-0.2.6-4.fc9.i386 requires libgnome-desktop-2.so.2 awn-extras-applets-0.2.6-4.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 bigboard-0.5.33-2.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) compiz-gnome-0.7.2-5.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) deskbar-applet-2.23.2-1.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) desktop-data-model-1.2.4-1.fc10.i386 requires libgnome-desktop-2.so.2 desktop-data-model-1.2.4-1.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) epiphany-2.22.1.1-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicui18n.so.38()(64bit) file-browser-applet-0.5.6-2.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx galeon-2.0.5-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) gnome-compiz-manager-0.10.4-4.fc9.i386 requires libgnome-desktop-2.so.2 gnome-compiz-manager-0.10.4-4.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) gnome-launch-box-0.4-9.fc10.x86_64 requires libgnome-desktop-2.so.2()(64bit) icewm-gnome-1.2.35-4.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 nautilus-search-tool-0.2.2-3.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) orpie-1.4.3-5.fc6.x86_64 requires camlp4 padevchooser-0.9.4-0.4.svn20070925.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tracker-search-tool-0.6.6-2.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avant-window-navigator-0.2.6-8.fc9.ppc requires libgnome-desktop-2.so.2 avant-window-navigator-0.2.6-8.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) awn-extras-applets-0.2.6-4.fc9.ppc requires libgnome-desktop-2.so.2 awn-extras-applets-0.2.6-4.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 bigboard-0.5.33-2.fc10.ppc requires libgnome-desktop-2.so.2 compiz-gnome-0.7.2-5.fc10.ppc requires libgnome-desktop-2.so.2 deskbar-applet-2.23.2-1.fc10.ppc requires libgnome-desktop-2.so.2 desktop-data-model-1.2.4-1.fc10.ppc requires libgnome-desktop-2.so.2 desktop-data-model-1.2.4-1.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) epiphany-2.22.1.1-1.fc9.ppc requires libgnome-desktop-2.so.2 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) file-browser-applet-0.5.6-2.fc10.ppc requires libgnome-desktop-2.so.2 galeon-2.0.5-1.fc9.ppc requires libgnome-desktop-2.so.2 gnome-compiz-manager-0.10.4-4.fc9.ppc requires libgnome-desktop-2.so.2 gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) gnome-launch-box-0.4-9.fc10.ppc requires libgnome-desktop-2.so.2 icewm-gnome-1.2.35-4.fc9.ppc requires libgnome-desktop-2.so.2 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 nautilus-search-tool-0.2.2-3.fc9.ppc requires libgnome-desktop-2.so.2 orpie-1.4.3-5.fc6.ppc requires camlp4 padevchooser-0.9.4-0.4.svn20070925.fc9.ppc requires libgnome-desktop-2.so.2 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tracker-search-tool-0.6.6-2.fc9.ppc requires libgnome-desktop-2.so.2 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- avant-window-navigator-0.2.6-8.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) awn-extras-applets-0.2.6-4.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) bigboard-0.5.33-2.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) deskbar-applet-2.23.2-1.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) desktop-data-model-1.2.4-1.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 epiphany-2.22.1.1-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) file-browser-applet-0.5.6-2.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) galeon-2.0.5-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) gnome-launch-box-0.4-9.fc10.ppc64 requires libgnome-desktop-2.so.2()(64bit) icewm-gnome-1.2.35-4.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) nautilus-search-tool-0.2.2-3.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) padevchooser-0.9.4-0.4.svn20070925.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tracker-search-tool-0.6.6-2.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) From mschwendt at gmail.com Thu Jun 5 09:57:09 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Jun 2008 11:57:09 +0200 Subject: Locale codeset UTF-8 vs. utf8 In-Reply-To: <1212658323.2996.14.camel@pc-notebook> References: <20080605111059.6570af0f.mschwendt@gmail.com> <20080605092251.GM13386@devserv.devel.redhat.com> <1212658323.2996.14.camel@pc-notebook> Message-ID: <20080605115709.f102bab9.mschwendt@gmail.com> On Thu, 05 Jun 2008 11:32:03 +0200, Martin Sourada wrote: > Sounds sane, though I faced very similar problem with Evolution some > time back, when my e-mail written in Czech (with diacritic marks) was > delivered broken - because only Evolution was able to tell what utf8 > charset actually is... Of course, manually setting it to UTF-8 fixed the > issue... I wondered whether the problem was due to wrong setting after > upgrading to Fedora 9 or something else, but I didn't pursued the issue > further. What I remember is that "utf8" and "UTF-8" are equivalent when setting the locale, but internally the codeset is "UTF-8" only. The list of supported values is returned by $ locale -m|grep -i utf UTF-8 which is what to use in string-comparison after querying nl_langinfo(CODESET). From dominik at greysector.net Thu Jun 5 10:02:06 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 5 Jun 2008 12:02:06 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212616469.6159.0.camel@localhost.localdomain> References: <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> Message-ID: <20080605100205.GA2102@mokona.greysector.net> On Wednesday, 04 June 2008 at 23:54, Dan Williams wrote: > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > > > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > > [...] > > > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > > > > > > Definitely in the next F9 update. > > > > Will this update contain my patch which allows people to uninstall > > NetworkManager without losing pidgin and evolution (bug #351101)? > > > > You never gave a good reason why this bug has been left unfixed > > for over half a year, especially when the solution is trivial. > > Can you try out > > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 > > when it gets done? Well, all I cared about was the ability to uninstall NetworkManager without losing pidgin in the process. This can be done with the new build, so thank you. I wish it had taken a bit less time to implement. Please implement this solution in F-8 branch, too. Regards, R. -- Fedora http://fedoraproject.org/wiki/DominikMierzejewski Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From sgrubb at redhat.com Thu Jun 5 12:40:56 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 5 Jun 2008 08:40:56 -0400 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> Message-ID: <200806050840.56826.sgrubb@redhat.com> On Thursday 05 June 2008 05:42:42 Rawhide wrote: > gpm-1.20.3-2.fc10 > ----------------- > * Wed Jun ?4 18:00:00 2008 Zdenek Prikryl - 1.20.3-2 > - Enable gpm in runlevel 5 I have to ask why? From rpm -qi: Description : Gpm provides mouse support to text-based Linux applications like the Emacs editor and the Midnight Commander file management system. That would be runlevel 4 and lower. -Steve From skvidal at fedoraproject.org Thu Jun 5 12:53:30 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 05 Jun 2008 08:53:30 -0400 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <200806050840.56826.sgrubb@redhat.com> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> Message-ID: <1212670410.1876.2.camel@cutter> On Thu, 2008-06-05 at 08:40 -0400, Steve Grubb wrote: > On Thursday 05 June 2008 05:42:42 Rawhide wrote: > > gpm-1.20.3-2.fc10 > > ----------------- > > * Wed Jun 4 18:00:00 2008 Zdenek Prikryl - 1.20.3-2 > > - Enable gpm in runlevel 5 > > I have to ask why? From rpm -qi: > > Description : > Gpm provides mouse support to text-based Linux applications like the > Emacs editor and the Midnight Commander file management system. > > That would be runlevel 4 and lower. > So when you kick to a console to fix something you can cut and paste w/your mouse. not that I necessarily agree but that's probably why -sv From kanarip at kanarip.com Thu Jun 5 12:54:27 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 05 Jun 2008 14:54:27 +0200 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <200806050840.56826.sgrubb@redhat.com> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> Message-ID: <4847E203.9020607@kanarip.com> Steve Grubb wrote: > On Thursday 05 June 2008 05:42:42 Rawhide wrote: >> gpm-1.20.3-2.fc10 >> ----------------- >> * Wed Jun ? 4 18:00:00 2008 Zdenek Prikryl - 1.20.3-2 >> - Enable gpm in runlevel 5 > > I have to ask why? From rpm -qi: > > Description : > Gpm provides mouse support to text-based Linux applications like the > Emacs editor and the Midnight Commander file management system. > > That would be runlevel 4 and lower. > Pressing ctrl-alt-f{1,2,3,4,5,6} might get you to appreciate gpm in runlevel 5 -Jeroen From dtimms at iinet.net.au Thu Jun 5 13:22:40 2008 From: dtimms at iinet.net.au (David Timms) Date: Thu, 05 Jun 2008 23:22:40 +1000 Subject: reviewer requested for pyvnc2swf Message-ID: <4847E8A0.3070900@iinet.net.au> Anyone interested in reviewing a fairly simple python package ? https://bugzilla.redhat.com/show_bug.cgi?id=448201 Use it to create swf movies from vnc sessions. DaveT. From ajax at redhat.com Thu Jun 5 13:22:00 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 05 Jun 2008 09:22:00 -0400 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <4847E203.9020607@kanarip.com> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> <4847E203.9020607@kanarip.com> Message-ID: <1212672120.29467.644.camel@localhost.localdomain> On Thu, 2008-06-05 at 14:54 +0200, Jeroen van Meeuwen wrote: > Steve Grubb wrote: > > On Thursday 05 June 2008 05:42:42 Rawhide wrote: > >> gpm-1.20.3-2.fc10 > >> ----------------- > >> * Wed Jun ? 4 18:00:00 2008 Zdenek Prikryl - 1.20.3-2 > >> - Enable gpm in runlevel 5 > > > > I have to ask why? From rpm -qi: > > > > Description : > > Gpm provides mouse support to text-based Linux applications like the > > Emacs editor and the Midnight Commander file management system. > > > > That would be runlevel 4 and lower. > > Pressing ctrl-alt-f{1,2,3,4,5,6} might get you to appreciate gpm in > runlevel 5 * Tue Oct 10 2006 Petr Rockai - 1.20-1-76 - align sleeps to tick boundary, should reduce cpu wakeups on laptops, fixes #205064 (patch by Arjan van de Ven) - disable gpm altogether in runlevel 5, it is probably not worth the overhead considering it is barely used at all Sigh. The constant struggle. Please turn it off again, thanks. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Jun 5 14:02:53 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 05 Jun 2008 10:02:53 -0400 Subject: strange koji build failures...? In-Reply-To: <1212618417.5000.2.camel@localhost.localdomain> References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> <87y75lz1uq.fsf@rho.meyering.net> <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> <87od6hxgbh.fsf@rho.meyering.net> <1212618417.5000.2.camel@localhost.localdomain> Message-ID: <1212674573.9688.70.camel@localhost.localdomain> On Wed, 2008-06-04 at 18:26 -0400, Matthias Clasen wrote: > On Wed, 2008-06-04 at 19:25 +0200, Jim Meyering wrote: > > Ond?ej Va??k wrote: > > > Hi Jim, > > > > > > Jim Meyering wrote: > > >> Eric Blake fixed that with this change to gnulib's utimens.c: > > >> > > >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93f08406537 > > > > > > I know about the fix (was causing troubles with test-suite) - therefore > > > that patch is already part of the coreutils-6.12-1.fc10 build - so it > > > will not solve the troubles with koji. Problem seems to be in return > > > code 280 from futimensat() call. So futimensat is available, but failing > > > - the same problem as I had with the coreutils test suite few weeks ago > > > (if you remember touch/create-no-missing issue). I would say koji xen > > > kernel issue, but could be workarounded by Fedora coreutils. > > > > Hi Ond?ej, > > > > I think you're right that it's a kernel problem. > > I've proposed a patch attached to http://bugzilla.redhat.com/449910 > > as https://bugzilla.redhat.com/attachment.cgi?id=308374 > > that might suffice to work around the problem. > > > > Can you test it? > > > > Hmm, I see that coreutils 6.12 is back in rawhide, and the build > failures are back, too: > http://koji.fedoraproject.org/koji/buildinfo?buildID=51679 > To prevent future fallout, can you (Ond?ej) coordinate with somebody from release engineering before you do another coreutils build? We'll want to keep an eye on it and make sure it doesn't break the buildsystem for everybody. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Thu Jun 5 14:10:10 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 05 Jun 2008 10:10:10 -0400 Subject: cdparanoia III 10 license change Message-ID: <1212675010.29467.659.camel@localhost.localdomain> cdparanoia 10 is GPLv3 and LGPLv3. This is a change from 9.8. Affected components: atropine:~% rpm -q --provides cdparanoia-libs | while read i junk ; do repoquery --qf="%{name}\n" --whatrequires $i ; done | sort -u bmpx cdparanoia cdparanoia-debuginfo cdparanoia-devel cdparanoia-libs grip gstreamer-plugins-base kaffeine kdemultimedia-libs Of these, bmpx and kdemultimedia-libs claim to be v2-only. My reading of the compatibility matrix is that you can't link to a LGPLv3 library from GPLv2 code. gstreamer-plugins-base only claims to be LGPL in the License tag. It appears to be LGPLv2.1 accordig to the license text, and my reading of the compat matrix is that linking to LGPLv3 from LGPLv2 is okay. The cdparanoia source plugin is explicitly LGPLv2+. whoowns bmpx bmpx is owned by akahl whoowns kdemultimedia kdemultimedia is owned by than fas akahl akahl 'Alexander Kahl' fas than at redhat.com than 'Than Ngo' If this is you, either your License tag is broken, or your package is about to be. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ovasik at redhat.com Thu Jun 5 14:18:19 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Thu, 05 Jun 2008 16:18:19 +0200 Subject: strange koji build failures...? In-Reply-To: <1212674573.9688.70.camel@localhost.localdomain> References: <4845763D.7000203@redhat.com> <20080604140502.GA3233@amd.home.annexia.org> <87y75lz1uq.fsf@rho.meyering.net> <1212592254.3957.23.camel@dhcp-lab-219.englab.brq.redhat.com> <87od6hxgbh.fsf@rho.meyering.net> <1212618417.5000.2.camel@localhost.localdomain> <1212674573.9688.70.camel@localhost.localdomain> Message-ID: <1212675499.4179.5.camel@dhcp-lab-219.englab.brq.redhat.com> Jesse Keating wrote: > To prevent future fallout, can you (Ond?ej) coordinate with somebody > from release engineering before you do another coreutils build? We'll > want to keep an eye on it and make sure it doesn't break the buildsystem > for everybody. I added a few tests into coreutils test-suite, so I'm working on the problem with scratch build - hopefully no need of dist-f10 untag for coreutils in near future. Unfortunately it seems that the workaround for gnulib/utimens.c utimensat() system call was not enough as I'm still able to get errors(sometimes test suite passes, sometimes generates errors). Of course extended workaround is possible, but I'm not sure if this is propper solution. Greetings, Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From rdieter at math.unl.edu Thu Jun 5 14:58:21 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Jun 2008 09:58:21 -0500 Subject: cdparanoia III 10 license change References: <1212675010.29467.659.camel@localhost.localdomain> Message-ID: Adam Jackson wrote: > cdparanoia 10 is GPLv3 and LGPLv3. This is a change from 9.8. > > Affected components: > > atropine:~% rpm -q --provides cdparanoia-libs | while read i junk ; do > repoquery --qf="%{name}\n" --whatrequires $i ; done | sort -u ... > kdemultimedia-libs > > Of these, bmpx and kdemultimedia-libs claim to be v2-only. kdemm fixed, verified (at least) GPLv2+ (with some parts LGPLv2+) -- Rex From jreiser at BitWagon.com Thu Jun 5 14:59:40 2008 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 05 Jun 2008 07:59:40 -0700 Subject: gpm in runlevel 5 In-Reply-To: <1212672120.29467.644.camel@localhost.localdomain> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> <4847E203.9020607@kanarip.com> <1212672120.29467.644.camel@localhost.localdomain> Message-ID: <4847FF5C.5040006@BitWagon.com> Why isn't there a simple, easy-to-remember way for users of text console in runlevel 5 to turn on the services of gpm? (This would require not disrupting the mouse on graphics console for more than an instant.) -- From tcallawa at redhat.com Thu Jun 5 15:14:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 05 Jun 2008 11:14:36 -0400 Subject: cdparanoia III 10 license change In-Reply-To: <1212675010.29467.659.camel@localhost.localdomain> References: <1212675010.29467.659.camel@localhost.localdomain> Message-ID: <1212678876.6772.10.camel@localhost.localdomain> On Thu, 2008-06-05 at 10:10 -0400, Adam Jackson wrote: > cdparanoia 10 is GPLv3 and LGPLv3. This is a change from 9.8. > > Affected components: > > atropine:~% rpm -q --provides cdparanoia-libs | while read i junk ; do > repoquery --qf="%{name}\n" --whatrequires $i ; done | sort -u > bmpx > cdparanoia > cdparanoia-debuginfo > cdparanoia-devel > cdparanoia-libs > grip > gstreamer-plugins-base > kaffeine > kdemultimedia-libs > > Of these, bmpx and kdemultimedia-libs claim to be v2-only. My reading > of the compatibility matrix is that you can't link to a LGPLv3 library > from GPLv2 code. This is a correct assessment. Fortunately, bmpx had an incorrect license tag (GPLv2) when it is actually GPLv2+. I've corrected that in rawhide. kdemultimedia also had an incorrect license tag (GPLv2), when it is actually GPLv2+ for the binaries, LGPLv2+ and GPLv2+ for its libraries. Rex and I have corrected the license tags in rawhide. There should be no problem moving forward with cdparanoia 10. :) This is a big reason why it is important to ensure that your license tags in the spec file are correct, it helps us to quickly identify areas of possible license conflict. Thanks, ~spot From ville.skytta at iki.fi Thu Jun 5 15:16:47 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Jun 2008 18:16:47 +0300 Subject: obsoleting -selinux subpackages In-Reply-To: <48470ADE.6060208@kobold.org> References: <4834D502.1090209@kobold.org> <20080522095620.GB2640@free.fr> <48470ADE.6060208@kobold.org> Message-ID: <200806051816.48136.ville.skytta@iki.fi> On Thursday 05 June 2008, Michael Thomas wrote: > Why would the Provides: be necessary? The Obsoletes: should make sure > that the cyphesis-selinux package gets removed, and later attempts to > install/upgrade the no-longer-valid cyphesis-selinux package should fail. That would break scripts etc that assume the cyphesis-selinux package is still available (either as a real package, or a Provides somewhere else). Why would it be a good thing to intentionally cause this breakage? We have documented procedures how to handle case like this, see https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages From pertusus at free.fr Thu Jun 5 15:22:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 5 Jun 2008 17:22:28 +0200 Subject: obsoleting -selinux subpackages In-Reply-To: <200806051816.48136.ville.skytta@iki.fi> References: <4834D502.1090209@kobold.org> <20080522095620.GB2640@free.fr> <48470ADE.6060208@kobold.org> <200806051816.48136.ville.skytta@iki.fi> Message-ID: <20080605152228.GD2614@free.fr> On Thu, Jun 05, 2008 at 06:16:47PM +0300, Ville Skytt? wrote: > > That would break scripts etc that assume the cyphesis-selinux package is still > available (either as a real package, or a Provides somewhere else). Why > would it be a good thing to intentionally cause this breakage? It seems to me that in some case (and here it could be such a case) it is acceptable not to be backward compatible, here in order to have the stand-alone cyphesis-selinux package completly disappear, and avoid inflating the number of provides. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jun 5 15:27:19 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 06 Jun 2008 00:27:19 +0900 Subject: cdparanoia III 10 license change In-Reply-To: <1212678876.6772.10.camel@localhost.localdomain> References: <1212675010.29467.659.camel@localhost.localdomain> <1212678876.6772.10.camel@localhost.localdomain> Message-ID: <484805D7.1000806@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote, at 06/06/2008 12:14 AM +9:00: > On Thu, 2008-06-05 at 10:10 -0400, Adam Jackson wrote: >> cdparanoia 10 is GPLv3 and LGPLv3. This is a change from 9.8. >> >> Affected components: >> >> atropine:~% rpm -q --provides cdparanoia-libs | while read i junk ; do >> repoquery --qf="%{name}\n" --whatrequires $i ; done | sort -u >> bmpx >> cdparanoia >> cdparanoia-debuginfo >> cdparanoia-devel >> cdparanoia-libs >> grip >> gstreamer-plugins-base >> kaffeine >> kdemultimedia-libs >> >> Of these, bmpx and kdemultimedia-libs claim to be v2-only. My reading >> of the compatibility matrix is that you can't link to a LGPLv3 library >> from GPLv2 code. > > This is a correct assessment. Fortunately, bmpx had an incorrect license > tag (GPLv2) when it is actually GPLv2+. I've corrected that in rawhide. No. I reviewed this package and actually some files in src/ are actually licensed under strict GPLv2, which renders the license of bmpx to be strict GPLv2. Mamoru From a.badger at gmail.com Thu Jun 5 15:35:20 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 05 Jun 2008 08:35:20 -0700 Subject: cdparanoia III 10 license change In-Reply-To: <1212678876.6772.10.camel@localhost.localdomain> References: <1212675010.29467.659.camel@localhost.localdomain> <1212678876.6772.10.camel@localhost.localdomain> Message-ID: <484807B8.3090501@gmail.com> Tom "spot" Callaway wrote: > On Thu, 2008-06-05 at 10:10 -0400, Adam Jackson wrote: >> Of these, bmpx and kdemultimedia-libs claim to be v2-only. My reading >> of the compatibility matrix is that you can't link to a LGPLv3 library >> from GPLv2 code. > > This is a correct assessment. Fortunately, bmpx had an incorrect license > tag (GPLv2) when it is actually GPLv2+. I've corrected that in rawhide. > > kdemultimedia also had an incorrect license tag (GPLv2), when it is > actually GPLv2+ for the binaries, LGPLv2+ and GPLv2+ for its libraries. > Rex and I have corrected the license tags in rawhide. > Quick question: How do changes like this affect the licenses and license tags of the dependent programs? Does this change the license of the shipped binary? Does the license tag need to be changed to reflect that? (Wondering as I can see GPLv2(only) code and GPLv3[+] code extending through a chain of other packages to cause problems if this is correct. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Thu Jun 5 15:35:39 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 05 Jun 2008 08:35:39 -0700 Subject: Packaging issues with files section for my future coq package In-Reply-To: References: <20080604225729.1f3ea4fc.mschwendt@gmail.com> Message-ID: <484807CB.10203@gmail.com> Alan Dunn wrote: > The full spec file is below - > > My motivation for doing things the way I did was that I wanted to > incorporate arbitrarily deep (admittedly I know the depth for this > particular version in advance, but one can imagine this changing > between versions and it didn't seem like a good solution to create > something that would have to be fixed with each upgrade) directory > structures instead of including > > /usr/lib/coq/* > /usr/lib/coq/*/* > (etc) > Things listed in %files can be directories and do work recursively. So what do you think of these changes: > > %files -f coqfiles %files > %defattr(-,root,root) > %doc CHANGES COMPATIBILITY COPYRIGHT CREDITS INSTALL INSTALL.ide > KNOWN-BUGS LICENSE README > %doc %{_mandir}/man1/coq* > %doc %{_mandir}/man1/gallina.1.gz > %doc %{_mandir}/man1/parser.1.gz > %{_bindir}/coq* > %{_bindir}/gallina > %{_bindir}/parser %{_bindir}/parser* > # Parser.opt included seperately > %exclude %{_bindir}/coqide* > %exclude %{_libdir}/coq/ide/* %exclude %{_libdir}/coq/ide/ > > %files coqide > %defattr(-,root,root) > %{_bindir}/coqide* > %{_libdir}/coq/ide/* > %{_libdir}/coq/ide/ > %changelog > * Wed Jun 14 2008 Alan Dunn 8.1pl3-1 > - Initial version. > And then clean out your find invocations in %build as they aren't needed. %exclude -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mschwendt at gmail.com Thu Jun 5 15:53:11 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Jun 2008 17:53:11 +0200 Subject: Packaging issues with files section for my future coq package In-Reply-To: References: <20080604225729.1f3ea4fc.mschwendt@gmail.com> Message-ID: <20080605175311.9d583a43.mschwendt@gmail.com> On Wed, 4 Jun 2008 20:32:29 -0400, Alan Dunn wrote: > The full spec file is below - Thanks. In the context of the full spec I could rule out side-effects. The reason for the "File listed twice" warnings simply is because the "find" commands returns directories _and_ files, and by default, directories are included recursively. Your generated "coqfiles" list would include a tree recursively and additionally all found files a second time. > /usr/lib/coq/* > /usr/lib/coq/*/* > (etc) Better: %{_libdir}/coq/ That includes the directory and the entire tree below it. Feel free to %exclude specific directories if that's necessary. -- Fedora release 9.90 (Rawhide) - Linux 2.6.26-0.46.rc4.git2.fc10.i686 loadavg: 1.50 1.36 1.39 From tcallawa at redhat.com Thu Jun 5 16:01:37 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 05 Jun 2008 12:01:37 -0400 Subject: cdparanoia III 10 license change In-Reply-To: <484805D7.1000806@ioa.s.u-tokyo.ac.jp> References: <1212675010.29467.659.camel@localhost.localdomain> <1212678876.6772.10.camel@localhost.localdomain> <484805D7.1000806@ioa.s.u-tokyo.ac.jp> Message-ID: <1212681697.6772.12.camel@localhost.localdomain> On Fri, 2008-06-06 at 00:27 +0900, Mamoru Tasaka wrote: > No. I reviewed this package and actually some files in src/ are > actually licensed > under strict GPLv2, which renders the license of bmpx to be strict > GPLv2. You were right, I was wrong. bmpx is going to be a concern for cdparanoia. ~spot From tibbs at math.uh.edu Thu Jun 5 16:19:42 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jun 2008 11:19:42 -0500 Subject: cdparanoia III 10 license change In-Reply-To: <484805D7.1000806@ioa.s.u-tokyo.ac.jp> References: <1212675010.29467.659.camel@localhost.localdomain> <1212678876.6772.10.camel@localhost.localdomain> <484805D7.1000806@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "MT" == Mamoru Tasaka writes: MT> No. I reviewed this package and actually some files in src/ are MT> actually licensed under strict GPLv2, which renders the license of MT> bmpx to be strict GPLv2. This is why it's important to document things like this in the specfile. - J< From ville.skytta at iki.fi Thu Jun 5 17:59:49 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 5 Jun 2008 20:59:49 +0300 Subject: cdparanoia III 10 license change In-Reply-To: <1212675010.29467.659.camel@localhost.localdomain> References: <1212675010.29467.659.camel@localhost.localdomain> Message-ID: <200806052059.49557.ville.skytta@iki.fi> On Thursday 05 June 2008, Adam Jackson wrote: > atropine:~% rpm -q --provides cdparanoia-libs | while read i junk ; do > repoquery --qf="%{name}\n" --whatrequires $i ; done | sort -u The same thing, faster and easier: --alldeps to repoquery. $ repoquery --qf="%{name}" --whatrequires --alldeps cdparanoia-libs | sort -u From ville.skytta at iki.fi Thu Jun 5 18:09:25 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Jun 2008 21:09:25 +0300 Subject: obsoleting -selinux subpackages In-Reply-To: <20080605152228.GD2614@free.fr> References: <4834D502.1090209@kobold.org> <200806051816.48136.ville.skytta@iki.fi> <20080605152228.GD2614@free.fr> Message-ID: <200806052109.26194.ville.skytta@iki.fi> On Thursday 05 June 2008, Patrice Dumas wrote: > On Thu, Jun 05, 2008 at 06:16:47PM +0300, Ville Skytt? wrote: > > That would break scripts etc that assume the cyphesis-selinux package is > > still available (either as a real package, or a Provides somewhere else). > > Why would it be a good thing to intentionally cause this breakage? > > It seems to me that in some case (and here it could be such a case) it > is acceptable not to be backward compatible, here in order to have the > stand-alone cyphesis-selinux package completly disappear, Which is taken care with Obsoletes. > and avoid inflating the number of provides. That's completely moot in the context of avoiding breakage. There's a very real, valid reason why the guideline for renaming/replacing packages exists and should be followed. From christoph.wickert at googlemail.com Thu Jun 5 18:18:27 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 05 Jun 2008 20:18:27 +0200 Subject: Xfce SIG meeting! In-Reply-To: <20080604221400.75187fa6@ohm.scrye.com> References: <20080523162955.7677c1a3@ohm.scrye.com> <1211721302.3386.8.camel@wicktop.localdomain> <20080604221400.75187fa6@ohm.scrye.com> Message-ID: <1212689907.3130.5.camel@wicktop.localdomain> Am Mittwoch, den 04.06.2008, 22:14 -0600 schrieb Kevin Fenzi: > On Sun, 25 May 2008 15:15:02 +0200 > christoph.wickert at googlemail.com (Christoph Wickert) wrote: > > > Am Freitag, den 23.05.2008, 16:29 -0600 schrieb Kevin Fenzi: > > > Greetings. > > > > > > We would like to try and get together interested folks for the first > > > Xfce SIG meeting, sometime next week on irc.freenode.net in the > > > #fedora-meeting channel. > > > > > > Please see: > > > http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > > > for when available times are for the #fedora-meeting channel. > > > > > > If interested parties could mail me their preferred times for > > > meeting, I can schedule a meeting time for next week. > > > > For me every free slot between 20.00-23.00 UTC should be okay, not > > sure if this suitable for others, so I'm open to more suggestions. > > > > > Note that I will be out on > > > vacation next week, but should have net and be able to meet anyhow. > > > > I will be attending Linuxtag at Berlin next week, so my time and net > > access is limited. I think I should be able to do it in the evenings, > > otherwise is suggest we start a week later. > > Yeah, and I was traveling last week as well, so I guess it didn't work > after all. ;( > > How about we try next week? Would tuesday work? 21:00 UTC? Perfectly fine with me but I suggest we also contact Rahul and John Babich directly, because they seem to have missed your mail. I have BCC'ed them now. > > > Christoph > > kevin > Christoph From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 5 19:39:27 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 05 Jun 2008 21:39:27 +0200 Subject: Locale codeset UTF-8 vs. utf8 In-Reply-To: <20080605111059.6570af0f.mschwendt@gmail.com> (Michael Schwendt's message of "Thu, 5 Jun 2008 11:10:59 +0200") References: <20080605111059.6570af0f.mschwendt@gmail.com> Message-ID: <87bq2fn028.fsf@sheridan.bigo.ensc.de> Michael Schwendt writes: > Default GNOME user in Fedora 9: > > $ env|grep LANG > LANG=en_US.utf8 > GDM_LANG=en_US.utf8 Session setup seems to be broken in F-9; e.g. compare output of | ssh `hostname` set on F-9 and F-8 host. A similar defect seems to happen when xfce4 is started from kdm: on F-9, profile settings ($LANG, $PATH) are missing for applications started by panel applets or by A-F2. Enrico From akahl at iconmobile.com Thu Jun 5 20:06:26 2008 From: akahl at iconmobile.com (Alexander Kahl) Date: Thu, 05 Jun 2008 22:06:26 +0200 Subject: How to handle subpackages with missing dependencies Message-ID: <1212696386.9544.23.camel@senator.homenet> I'm in the process of packaging Zend Framework for Fedora [1] with direct help from Zend's developers, all issues pointed out by me could be fixed ?but still one is remaining: After separating all components requiring non-standard dependencies from the base package, three of them remain with dependencies unresolvable; one subpackage needs php-sqlite which has been deactivated in favor of php-pdo's sqlite support, another one depends on php-pecl-ibm_db2 no one has packaged yet and the last one depends on php-oci8 which cannot be provided at all because it is proprietary software. It can still perfectly make sense to provide these packages and let the user take of the deps himself but "official" Fedora support is impossible this way. How to handle them? Simply exclude from the build? Comment them out in the build so users can build their own package using the spec? Provide them with unresolvable Requires:s? Provide them without the Require:s? Add a README.Fedora explaining how to handle them? Couldn't find anything in the docs about it. [1] https://bugzilla.redhat.com/show_bug.cgi?id=421241 - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hun at n-dimensional.de Thu Jun 5 20:12:17 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Thu, 05 Jun 2008 22:12:17 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <483BCE11.7060804@n-dimensional.de> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> Message-ID: <484848A1.2030600@n-dimensional.de> Hans Ulrich Niedermann wrote: > Log files for devel, F-9, F-8, F-7 branches: > > http://ndim.fedorapeople.org/stuff/rpm/string-comp-devel.log > http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-9.log > http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-8.log > http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-7.log > > To give a rough idea of the scale: > > devel: 85 string comparisons in 46 spec files > F-9: 90 string comparisons in 50 spec files > F-8: 117 string comparisons in 59 spec files > F-7: 121 string comparisons in 63 spec files Update from today's CVS: devel: 75 string comparisons in 41 spec files F-9: 83 string comparisons in 48 spec files F-8: 114 string comparisons in 58 spec files F-7: 118 string comparisons in 62 spec files It's going in the right direction. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From michel.sylvan at gmail.com Thu Jun 5 20:33:31 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 05 Jun 2008 16:33:31 -0400 Subject: reviewer requested for pyvnc2swf In-Reply-To: <4847E8A0.3070900@iinet.net.au> References: <4847E8A0.3070900@iinet.net.au> Message-ID: <48484D9B.2060903@gmail.com> David Timms wrote: > Anyone interested in reviewing a fairly simple python package ? > https://bugzilla.redhat.com/show_bug.cgi?id=448201 > Use it to create swf movies from vnc sessions. > > DaveT. > Certainly. Swap with python-storm? https://bugzilla.redhat.com/show_bug.cgi?id=430429 Thanks, -- Michel From snecklifter at gmail.com Thu Jun 5 21:41:10 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 5 Jun 2008 22:41:10 +0100 Subject: Looking for co-maintainers... Message-ID: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> Hi folks, Due to work and life commitments, I haven't been able to even c/o my packages from cvs to take a look at what needs updating. I recently got a FTBFS against one of my packages, log4net, and I'm fairly certain I won't have the time to look into this in the near future. So if anyone is interesting in either co-maintaining or even owning the following please let me know. Jokosher - a non linear audio editor written in python libflaim - Database engine, novell project, pretty much dead I think gnonlin - Non linear gstreamer stuff, mainly picked up as Jokosher uses it log4net - lazy logger from the apache project Only log4net has any real urgency given the FTBFS. Any help on this appreciated. I really didn't want to have to do this but I'm just crazy busy at the moment. Regards -- Christopher Brown http://www.chruz.com From paul at all-the-johnsons.co.uk Thu Jun 5 21:58:05 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 05 Jun 2008 22:58:05 +0100 Subject: koji build problem Message-ID: <1212703085.4537.14.camel@T7.Linux> Hi, I'm trying to get monodevelop-1.0 to build for F9, but it looks like something is snarled up somewhere with koji http://koji.fedoraproject.org/koji/taskinfo?taskID=648795 Koji is complaining that gtksourceview2-sharp-devel and mono-basic-devel don't exist despite them plainly being there. The build log is showing something really odd ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/monodevelop.spec'], False, '/var/lib/mock/dist-f9-build-201996-35034/root/', None, 0, True, 0, 423, 104, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/monodevelop.spec'] /etc/profile: line 38: /bin/hostname: No such file or directory sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found sh: gacutil: command not found warning: Could not canonicalize hostname: hammer2.fedora.redhat.com Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/monodevelop-1.0-6.fc9.src.rpm Any ideas on what is going wrong here? I've tried both a normal and scratch build with the same level of success. 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: 197 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Thu Jun 5 21:59:59 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 05 Jun 2008 22:59:59 +0100 Subject: Looking for co-maintainers... In-Reply-To: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> References: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> Message-ID: <1212703199.4537.15.camel@T7.Linux> Hi, > Only log4net has any real urgency given the FTBFS. Any help on this > appreciated. I really didn't want to have to do this but I'm just > crazy busy at the moment. What was the fail? 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: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Thu Jun 5 22:16:55 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 5 Jun 2008 23:16:55 +0100 Subject: Looking for co-maintainers... In-Reply-To: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> References: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> Message-ID: <20080605231655.5ac8c501@metropolis.intra.city-fan.org> On Thu, 5 Jun 2008 22:41:10 +0100 "Christopher Brown" wrote: > Hi folks, > > Due to work and life commitments, I haven't been able to even c/o my > packages from cvs to take a look at what needs updating. I recently > got a FTBFS bug against one of my packages, log4net, and I'm fairly > certain I won't have the time to look into this in the near future. So > if anyone is interesting in either co-maintaining or even owning the > following please let me know. > > Jokosher - a non linear audio editor written in python > libflaim - Database engine, novell project, pretty much dead I think > gnonlin - Non linear gstreamer stuff, mainly picked up as Jokosher > uses it log4net - lazy logger from the apache project > > Only log4net has any real urgency given the FTBFS. Any help on this > appreciated. I really didn't want to have to do this but I'm just > crazy busy at the moment. log4net is failing to build because one of its buildreqs, nant, has broken deps. When that's fixed, it'll probably be OK. http://koji.fedoraproject.org/koji/getfile?taskID=648852&name=root.log I suggest making the FTBFS bug on log4net depend on Bug #449507, which is the FTBFS bug for nant. Paul. From paul at city-fan.org Thu Jun 5 22:19:56 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 5 Jun 2008 23:19:56 +0100 Subject: koji build problem In-Reply-To: <1212703085.4537.14.camel@T7.Linux> References: <1212703085.4537.14.camel@T7.Linux> Message-ID: <20080605231956.3187f9a8@metropolis.intra.city-fan.org> On Thu, 05 Jun 2008 22:58:05 +0100 Paul wrote: > Hi, > > I'm trying to get monodevelop-1.0 to build for F9, but it looks like > something is snarled up somewhere with koji > > http://koji.fedoraproject.org/koji/taskinfo?taskID=648795 > > Koji is complaining that gtksourceview2-sharp-devel and > mono-basic-devel don't exist despite them plainly being there. Hmm, very odd, don't know what's going on there. > The build log is showing something really odd > > ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 > --nodeps builddir/build/SPECS/monodevelop.spec'], False, > '/var/lib/mock/dist-f9-build-201996-35034/root/', None, 0, True, 0, > 423, 104, None, logger= 0x2aaab0e8bf90>) > Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target > x86_64 --nodeps builddir/build/SPECS/monodevelop.spec'] /etc/profile: > line 38: /bin/hostname: No such file or directory sh: gacutil: > command not found sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > sh: gacutil: command not found > warning: Could not canonicalize hostname: hammer2.fedora.redhat.com > Building target platforms: x86_64 > Building for target x86_64 > Wrote: /builddir/build/SRPMS/monodevelop-1.0-6.fc9.src.rpm > > Any ideas on what is going wrong here? I've tried both a normal and > scratch build with the same level of success. That all looks like the normal output for a successful build of the SRPM in a mock chroot with gacutil and hostname not present. The SRPM build worked OK. The problem isn't here, it's the apparently missing buildreqs mentioned earlier. Paul. From poelstra at redhat.com Thu Jun 5 22:39:09 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 05 Jun 2008 15:39:09 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-06-02 Message-ID: <48486B0D.7020001@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jun-02 Please make corrections and clarifications to the wiki page. == Fedora 10 Schedule == * http://poelstra.fedorapeople.org/schedules/f-10/f-10-all-tasks.html * one possible concern is beta release is the day after labor day * move discussion to fedora-devel-list and give final schedule feedback next week == Custom Spins == * https://fedorahosted.org/projects/rel-eng/ticket/24 * need to determine how much space is available * DECISION: ** Once spins SIG bless games, XFCE, and FEL rel-eng will create beta i386/x86_64 versions of these spins from F9 GOLD content to be hosted on spins.fp.o. ** If necessary specific updates will be allowed for specific spins and sources for those updates will be hosted on torrent as well. == Fedora 10 Rawhide Milestone == * soliciting name * https://fedorahosted.org/projects/rel-eng/ticket/23 == IRC Transcript == From dev at nigelj.com Thu Jun 5 22:51:16 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 06 Jun 2008 10:51:16 +1200 Subject: koji build problem In-Reply-To: <1212703085.4537.14.camel@T7.Linux> References: <1212703085.4537.14.camel@T7.Linux> Message-ID: <48486DE4.1010100@nigelj.com> Paul wrote: > Hi, > > I'm trying to get monodevelop-1.0 to build for F9, but it looks like > something is snarled up somewhere with koji > > http://koji.fedoraproject.org/koji/taskinfo?taskID=648795 > > Koji is complaining that gtksourceview2-sharp-devel and mono-basic-devel > don't exist despite them plainly being there. > You need to ask for gtksourceview2-sharp-devel to bit flipped so you can pull these in as builddeps. I've never seen mono-basic-devel but if it got rebuild recently, and is not in updates-released then once again, you need some koji foo done. Rel-Eng can do this from memory. - Nigel (btw, the buildlog that you pasted, is a-typical of a Code 10 :)) From bpepple at fedoraproject.org Thu Jun 5 23:25:18 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 05 Jun 2008 19:25:18 -0400 Subject: FESCo Meeting Summary for 2008-06-05 Message-ID: <1212708318.7146.19.camel@kennedy> == Members Present == * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Christopher Aillon (caillon) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Tom Callaway (spot) * Christian Iseli (c4chris) == Absent == * Josh Boyer (jwb) == Summary == === Fails To Build From Source (FTBFS) Proposal === * Matt Domsch proposed that packages with unresolved FTBFS bugs immediately following the Alpha release would be removed from the distribution. FESCo agreed with this proposal, but had a couple of additional items (like tying this in with f13's automated MIA proposal) to add to it. f13 will get in contact with Matt on this. * http://fedoraproject.org/wiki/FTBFS#.28Proposed.29_Package_Removal_for_Long-standing_FTBFS_bugs * http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal === New Maintainer Containment Membership === * FESCo approved f13's proposal on how to prime the new 'supergroup'. The initial members will be current package sponsors, and then these sponsors would be able to sponsor anybody they choose (not just the people they've sponsored) into the supergroup. For more details, please refer to the IRC log. * http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment * http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-06-05.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: 197 bytes Desc: This is a digitally signed message part URL: From dtimms at iinet.net.au Thu Jun 5 23:45:23 2008 From: dtimms at iinet.net.au (David Timms) Date: Fri, 06 Jun 2008 09:45:23 +1000 Subject: reviewer requested for pyvnc2swf In-Reply-To: <48484D9B.2060903@gmail.com> References: <4847E8A0.3070900@iinet.net.au> <48484D9B.2060903@gmail.com> Message-ID: <48487A93.4000203@iinet.net.au> Michel Salim wrote: > Certainly. Swap with python-storm? > https://bugzilla.redhat.com/show_bug.cgi?id=430429 Thanks Michel, I'll take a look at python-storm over the next days. Cheers, DaveT. From jwboyer at gmail.com Fri Jun 6 02:23:17 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 5 Jun 2008 21:23:17 -0500 Subject: FESCo Meeting Summary for 2008-06-05 In-Reply-To: <1212708318.7146.19.camel@kennedy> References: <1212708318.7146.19.camel@kennedy> Message-ID: <20080605212317.76020c99@vader.jdub.homelinux.org> On Thu, 05 Jun 2008 19:25:18 -0400 Brian Pepple wrote: > == Members Present == > * Brian Pepple (bpepple) > * Jason Tibbitts (tibbs) > * Bill Nottingham (notting) > * Kevin Fenzi (nirik) > * Jeremy Katz (jeremy) > * Christopher Aillon (caillon) > * Dennis Gilmore (dgilmore) > * Warren Togami (warren) > * David Woodhouse (dwmw2) > * Jesse Keating (f13) > * Tom Callaway (spot) > * Christian Iseli (c4chris) > > == Absent == > * Josh Boyer (jwb) Real life got in the way. For what it's worth, I reviewed the logs and I agree with what was decided and discussed. josh From otto_rey at yahoo.com.ar Fri Jun 6 02:25:30 2008 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Thu, 5 Jun 2008 19:25:30 -0700 (PDT) Subject: Firefox and Moonlight (Mono) "Free Software" Status? Message-ID: <568556.62702.qm@web52407.mail.re2.yahoo.com> Mono is a free publicity of Microsoft languages.... More .net developers, more Microsoft $$$.... There is no reason to use .net having java (open source language, spec, implementations, multiplatform, etc, etc), ruby, php, python, c, c++, rails, etc, etc... There is no reason to include mono in Fedora ----- Mensaje original ---- De: Guido Ledermann Para: Development discussions related to Fedora ; Rui Miguel Silva Seabra Enviado: martes 3 de junio de 2008, 13:03:34 Asunto: Re: Firefox and Moonlight (Mono) "Free Software" Status? 2008/6/3 Rui Miguel Silva Seabra : > Yes, I did, no offense taken of course. My point is precisely that there are > *better* alternatives (both in the sense of Freedom and technical). Thank god and mainly a lot of people there are alternatives. For me Mono is one of them and it's free IMHO. And even if there are better alternatives in technical way it should also be the programmers choice which to use. Guido -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar From debarshi.ray at gmail.com Fri Jun 6 06:03:16 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 11:33:16 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> Message-ID: <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> Jason, Please don't close [2] since that is a consequence of the Non-Responsive Maintainer procedure initiated by [1]. As a result [1] depends on [2]. The review request is necessary since Zile was last built for Fedora Core 6 and has not been updated for a long time. Thanks, Debarshi [1] https://bugzilla.redhat.com/show_bug.cgi?id=447125 [2] https://bugzilla.redhat.com/show_bug.cgi?id=449879 From snecklifter at gmail.com Fri Jun 6 06:56:04 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 6 Jun 2008 07:56:04 +0100 Subject: Looking for co-maintainers... In-Reply-To: <20080605231655.5ac8c501@metropolis.intra.city-fan.org> References: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> <20080605231655.5ac8c501@metropolis.intra.city-fan.org> Message-ID: <364d303b0806052356o78c32f51ja9428fa85f59aabe@mail.gmail.com> 2008/6/5 Paul Howarth : > On Thu, 5 Jun 2008 22:41:10 +0100 > "Christopher Brown" wrote: > >> Hi folks, >> >> Due to work and life commitments, I haven't been able to even c/o my >> packages from cvs to take a look at what needs updating. I recently >> got a FTBFS bug against one of my packages, log4net, and I'm fairly >> certain I won't have the time to look into this in the near future. So >> if anyone is interesting in either co-maintaining or even owning the >> following please let me know. >> >> Jokosher - a non linear audio editor written in python >> libflaim - Database engine, novell project, pretty much dead I think >> gnonlin - Non linear gstreamer stuff, mainly picked up as Jokosher >> uses it log4net - lazy logger from the apache project >> >> Only log4net has any real urgency given the FTBFS. Any help on this >> appreciated. I really didn't want to have to do this but I'm just >> crazy busy at the moment. > > log4net is failing to build because one of its buildreqs, nant, has > broken deps. When that's fixed, it'll probably be OK. > > http://koji.fedoraproject.org/koji/getfile?taskID=648852&name=root.log > > I suggest making the FTBFS bug on log4net depend on Bug #449507, which > is the FTBFS bug for nant. > > Paul. Okay, thanks Paul, will do. -- Christopher Brown http://www.chruz.com From snecklifter at gmail.com Fri Jun 6 06:58:21 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 6 Jun 2008 07:58:21 +0100 Subject: Looking for co-maintainers... In-Reply-To: <1212703199.4537.15.camel@T7.Linux> References: <364d303b0806051441k7dc05f95i2d25f41d4b48e333@mail.gmail.com> <1212703199.4537.15.camel@T7.Linux> Message-ID: <364d303b0806052358r510a6079k61b42bece1fcebf1@mail.gmail.com> 2008/6/5 Paul : > Hi, > >> Only log4net has any real urgency given the FTBFS. Any help on this >> appreciated. I really didn't want to have to do this but I'm just >> crazy busy at the moment. > > What was the fail? It was during depsolving with nant I think. >From http://koji.fedoraproject.org/koji/getfile?taskID=648752&name=root.log DEBUG util.py:250: Error: Missing Dependency: mono(NDoc.Core) = 1.3.3023.0 is needed by package nant I've added this against your nant FTBFS. Regards -- Christopher Brown http://www.chruz.com From paul at city-fan.org Fri Jun 6 07:52:08 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Jun 2008 08:52:08 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <568556.62702.qm@web52407.mail.re2.yahoo.com> References: <568556.62702.qm@web52407.mail.re2.yahoo.com> Message-ID: <4848ECA8.8030505@city-fan.org> Otto Rey wrote: > Mono is a free publicity of Microsoft languages.... > More .net developers, more Microsoft $$$.... > There is no reason to use .net having java (open source language, spec, implementations, multiplatform, etc, etc), ruby, php, python, c, c++, rails, etc, etc... > There is no reason to include mono in Fedora And none of the above are reasons not to have it Fedora either. If people want it and it's legal, let them have it. Paul. From rjones at redhat.com Fri Jun 6 08:11:56 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 6 Jun 2008 09:11:56 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <568556.62702.qm@web52407.mail.re2.yahoo.com> References: <568556.62702.qm@web52407.mail.re2.yahoo.com> Message-ID: <20080606081156.GA15125@amd.home.annexia.org> On Thu, Jun 05, 2008 at 07:25:30PM -0700, Otto Rey wrote: > Mono is a free publicity of Microsoft languages.... > More .net developers, more Microsoft $$$.... > There is no reason to use .net having java (open source language, spec, implementations, multiplatform, etc, etc), ruby, php, python, c, c++, rails, etc, etc... > There is no reason to include mono in Fedora One major reason is that it allows languages to be mixed and to call easily from one language to another. Free software dropped the ball on this (Parrot), and Mono/.Net is the only widely available implementation of this idea. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From tibbs at math.uh.edu Fri Jun 6 08:44:17 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 03:44:17 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: DR> Jason, Please don't close [2] since that is a consequence of the DR> Non-Responsive Maintainer procedure initiated by [1]. Well, if you want to go making your own process.... DR> The review request is necessary since Zile was last built for DR> Fedora Core 6 and has not been updated for a long time. Zile is still in the repo and was last built for the GCC 4.3 rebuild. I'm not aware of any rule requiring re-reviews of packages which were have not been removed from the distro. What am I missing? - J< From debarshi.ray at gmail.com Fri Jun 6 09:48:53 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 15:18:53 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> Message-ID: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note that although I filed the initial bug (as required by the Non-Responsive Maintainer policy) against Zile, the person actually interested in taking it over (ie. Rakesh) is not an existing Fedora contributor. Even though the policy page (http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers) says "If the requester is a not an existing Fedora contributor, he may still take over a package", it does not mention how that would be possible. The usual way is to submit a review request and wait for a sponsor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFISQaBTMO+PGPUpacRAu3KAKC900K7Pbwtr1DsKyuvtbWl10f/XACdHj0d mnTHkDczqqxmCs0IJR3Ejco= =5cSU -----END PGP SIGNATURE----- > DR> Jason, Please don't close [2] since that is a consequence of the > DR> Non-Responsive Maintainer procedure initiated by [1]. > Well, if you want to go making your own process.... See "Old becomes new" on http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages Now, although the package has not been orphaned, the maintainer has simply disappeared. I managed to get hold of two email IDs associated with him (one of them was his FAS ID) and none of them are working any more. > DR> The review request is necessary since Zile was last built for > DR> Fedora Core 6 and has not been updated for a long time. > Zile is still in the repo and was last built for the GCC 4.3 rebuild. > I'm not aware of any rule requiring re-reviews of packages which were > have not been removed from the distro. If a maintainer disappears without orphaning any of his packages, I fail to see how the situation is different from this one. The presence of Zile in the repository is simply an accident as none of us noticed that the maintainer has disappeared, and possibly Zile did not have any major bugs filed against it. On Fedora 8, the most recent build available was tagged .fc6. Even if it was built for GCC 4.3 during the Fedora 9 cycle, it only means that the package still builds from source. That is of little value here because the entity performing the rebuild did not notice the fact that no human had touched the package sources for such a long time, and that the maintainer was AWOL. Regards, Debarshi From rawhide at fedoraproject.org Fri Jun 6 10:05:20 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 6 Jun 2008 10:05:20 +0000 (UTC) Subject: rawhide report: 20080606 changes Message-ID: <20080606100520.C42FE209CE6@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080605/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080606/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gkrellm-timestamp UNIX timestamp clock plugin for GKrellM New package pywebkitgtk Python Bindings for WebKit-gtk New package rpmreaper A tool for removing packages from system Removed package gnome-spell Updated Packages: NetworkManager-0.7.0-0.9.4.svn3675.fc10 --------------------------------------- * Wed Jun 4 18:00:00 2008 Dan Williams - 1:0.7.0-0.9.4.svn3675 - Move NM later in the shutdown process (rh #449070) - Move libnm-util into a subpackage to allow NM to be removed more easily (rh #351101) anaconda-11.4.1.4-1 ------------------- * Thu Jun 5 18:00:00 2008 Chris Lumens - 11.4.1.4-1 - Fix text mode button translations (#450176). (clumens) - Remove a rogue call to textdomain. (clumens) - Make "upd-updates /tmp/updates.img" update everything newer in the current (pjones) - _xmltrans is undefined. Try xmltrans instead. (clumens) - Fix reference to cost vs. priority (#450168). (clumens) - Don't do the "exec shell on tty1" thing in vnc if we've got virtual terminals. (pjones) - Import N_ (#450163). (clumens) - raise "NotImplementedError", not "NotImplemented" (pjones) - Need to import iutil before we use it. (clumens) - Don't reference PartitioningError.value . (pjones) augeas-0.2.0-1.fc10 ------------------- * Thu Jun 5 18:00:00 2008 David Lutterkort - 0.2.0-1 - New version avant-window-navigator-0.2.6-8.fc10 ----------------------------------- awn-extras-applets-0.2.6-5.fc10 ------------------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 0.2.6-5 - rebuild for dependancies axis-1.2.1-3jpp.9.fc10 ---------------------- * Thu Jun 5 18:00:00 2008 Permaine Cheung 0:1.2.1-3jpp.9 - Add javac.source=1.4 to the ant command for the build banshee-0.99.3-2.fc10 --------------------- * Wed Jun 4 18:00:00 2008 Nigel Jones - 0.99.3-2 - Disable boo (again) - Broken dependencies and 'issues' * Fri May 30 18:00:00 2008 Nigel Jones - 0.99.3-1 - New Upstream Release (0.99.3) - RC 1 * Tue May 27 18:00:00 2008 Nigel Jones - 0.99.2-3 - Rebuild for new gtk-sharp2 bash-3.2-26.fc10 ---------------- * Thu Jun 5 18:00:00 2008 Roman Rakus - 3.2-26 - Patchlevel 39 bigboard-0.5.33-3.fc10 ---------------------- * Mon May 5 18:00:00 2008 Caol??n McNamara - 0.5.33-3 - rebuild for dependancies blobby-0.6-0.9.a.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Aurelien Bompard 0.6-0.9.a - fix build with gcc 4.3 (patch1) * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.6-0.8.a - Autorebuild for GCC 4.3 cairo-dock-1.6.0-0.1.svn1080_trunk.fc10 --------------------------------------- * Thu Jun 5 18:00:00 2008 Mamoru Tasaka - 1.6.0-0.1.svn1080_trunk - Prepare for using unified configure script on plug-ins directory - Install desktop icon * Thu Jun 5 18:00:00 2008 Mamoru Tasaka - svn 1080 cdcollect-0.6.0-5.fc10 ---------------------- compiz-0.7.6-2.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 0.7.2-6 - rebuild for dependancies * Thu Jun 5 18:00:00 2008 Adel Gadllah - 0.7.6-2 - Don't require compiz-fusion in the main package * Thu Jun 5 18:00:00 2008 Adel Gadllah - 0.7.6-1 - Update to 0.7.6 - Install all gconf schemas at once - Drop unneeded patches - Use wall instead of plane compiz-bcop-0.7.6-1.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Adel Gadllah 0.7.6-1 - Update to 0.7.6 compiz-fusion-0.7.6-1.fc10 -------------------------- * Thu Jun 5 18:00:00 2008 Adel Gadllah 0.7.6-1 - Update to 0.7.6 - Install all gconf schemas at once compiz-fusion-extras-0.7.6-1.fc10 --------------------------------- * Thu Jun 5 18:00:00 2008 Adel Gadllah 0.7.6-1 - Update to 0.7.6 - Install all gconf schemas at once cpdup-1.11-1.fc10 ----------------- * Thu Jun 5 18:00:00 2008 Michel Alexandre Salim - 1.11-1 - Update to 1.11 cvs-1.11.23-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Jiri Moskovcak 1.11.23.1 - updated to new version 1.11.23 - fixed build on x86_64 - rewritten sanity.sh patch to match current version - Resolves: #449424 cyphesis-0.5.15-7.fc10 ---------------------- * Thu Apr 10 18:00:00 2008 Wart 0.5.15-7 - Remove selinux subpackage; it's been merged into the main selinux-policy package. - Add patch for using a full socket path in cyphesis.vconf dbus-glib-0.76-1.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Colin Walters - 0.76-1 - New upstream 0.76 - Drop all upstreamed patches deskbar-applet-2.23.2-2.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 2.23.2-2 - rebuild for dependancies desktop-data-model-1.2.4-2.fc10 ------------------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 1.2.4-2 - rebuild for dependancies dovecot-1.0.14-2.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Dan Horak - 1:1.0.14-2 - install convert-tool (Resolves: #450010) epiphany-2.22.1.1-3.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Matthias Clasen - .22.1.1-3 - Fix the build * Wed Jun 4 18:00:00 2008 Matthias Clasen - .22.1.1-2 - Rebuild evolution-zimbra-0.1.1-1.fc10 ----------------------------- * Thu Jun 5 18:00:00 2008 Matthew Barnes - 0.1.1-1 - Update to 0.1.1 - Remove upstreamed patch. - Require evo/eds >= 2.23.1. * Mon Mar 17 18:00:00 2008 Matthew Barnes - 0.1.0-6.fc9 - Chain up in dispose() and finalize() methods. file-browser-applet-0.5.6-3.fc10 -------------------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 0.5.6-3 - rebuild for dependancies gnet2-2.0.8-1.fc10 ------------------ * Thu Jun 5 18:00:00 2008 Tomas Mraz 2.0.8-1 - upgrade to new upstream release gnome-compiz-manager-0.10.4-4.fc10 ---------------------------------- gnome-launch-box-0.4-10.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 - Bastien Nocera - 0.4-10 - Rebuild gnome-system-monitor-2.23.3-2.fc10 ---------------------------------- * Thu Jun 5 18:00:00 2008 Than Ngo 2.23.3-2 - don't show it in KDE menu gstreamer-plugins-farsight-0.12.8-2.fc10 ---------------------------------------- * Thu Jun 5 18:00:00 2008 Brian Pepple - 0.12.8-2 - Disable jrtplib support, so plugin will work. (#450149) hdf5-1.8.1-1.fc10 ----------------- * Thu Jun 5 18:00:00 2008 Orion Poplawski 1.8.1-1 - Update to 1.8.1 icewm-1.2.35-4.fc10 ------------------- iptraf-3.0.1-5.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Zdenek Prikryl - 3.0.1-5 - Added support for ipv6 (#200503) - Fixed vlan support (#219772) - Added support for bond interfaces * Tue Apr 15 18:00:00 2008 Zdenek Prikryl - 3.0.1-4 - Length of iface name is increased - Resolves #439201 kdebase-runtime-4.0.80-2.fc10 ----------------------------- * Thu Jun 5 18:00:00 2008 Than Ngo 4.0.80-2 - add searchproviders-shortcuts for redhat bugzilla kdeedu-4.0.80-4.fc10 -------------------- * Thu Jun 5 18:00:00 2008 Kevin Kofler 4.0.80-4 - backport upstream fix for Step build * Tue Jun 3 18:00:00 2008 Kevin Kofler 4.0.80-3 - add BR gmm-devel, libqalculate-devel and gsl-devel for Step kdiff3-0.9.92-14.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Manuel Wolfshant - 0.9.92-14 - add a conditional BR, allowing build in EPEL-5 kexec-tools-1.102pre-11.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 Neil Horman - 1.102pre-11 - Update to latest makedumpfile from upstream - Mass import of RHEL fixes missing in rawhide lib765-0.4.1-4.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Lucian Langa - 0.4.1-4 - Fix for x86_64 builds #449513 - Misc cleanups libcdio-0.80-2.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Tomas Bzatek - 0.80-2 - added patch enabling libcdio_paranoia.pc libcmpiutil-0.4-1.fc9 --------------------- * Tue May 20 18:00:00 2008 Dan Smith - 0.4-1 - Updated to official 0.4 source release libtasn1-1.4-1.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Tomas Mraz - 1.4-1 - updated to new upstream version libvirt-cim-0.4-2.fc9 --------------------- * Fri May 30 18:00:00 2008 Dan Smith - 0.4-2 - Fixed schema registration to pick up ECTP in root/virt properly - Fixed schema registration to include ReferencedProfile in interop - Added RASD namespace fix * Wed May 21 18:00:00 2008 Dan Smith - 0.4-1 - Updated to latest upstream source - Added default disk pool configuration patch mono-ndoc-1.3.1-3.fc10 ---------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 1.3.1-3 - rebuild against new mono bits mono-nunit22-2.2.10-6.fc10 -------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 2.2.10-6 - rebuild for new mono bits * Tue Apr 22 18:00:00 2008 Tom "spot" Callaway 2.2.10-5 - fix sed invocation * Tue Apr 22 18:00:00 2008 Paul F. Johnson 2.2.10-4 - fix for incorrect libdir in pc file mono-sharpcvslib-0.35-3.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 0.35-3 - rebuild for new mono bits nautilus-search-tool-0.2.2-4.fc10 --------------------------------- * Fri Jun 6 18:00:00 2008 Caol??n McNamara - 0.2.2-4 - rebuild for dependancies ocaml-libvirt-0.4.2.3-1.fc10 ---------------------------- * Thu Jun 5 18:00:00 2008 Richard W.M. Jones - 0.4.2.3-1 - New upstream version. * Thu Jun 5 18:00:00 2008 Richard W.M. Jones - 0.4.2.2-1 - New upstream version. - Removed virt-ctrl, virt-df, virt-top subpackages, since these are now separate Fedora packages. ogdi-3.2.0-0.12.beta2.fc10 -------------------------- openobex-1.3-12.fc10 -------------------- * Mon Jun 2 18:00:00 2008 Jiri Moskovcak - 1.3-12 - improved utf(non ascii) support - Resolves: #430128 openoffice.org-3.0.0-0.0.17.1.fc10 ---------------------------------- * Thu Jun 5 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.17-1 - next version - drop integrated openoffice.org-2.3.1.ooo84676.ucb.davprotocol.patch * Thu Jun 5 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.16-2 - still fighting the sdk openoffice.org-voikko-2.2-5.fc10 -------------------------------- * Tue Jun 3 18:00:00 2008 Caol??n McNamara - 2.2-5 - add openoffice.org-voikko-2.2-3layer.patch to build against 3 layer OOo orpie-1.5.1-3.fc10 ------------------ * Thu Jun 5 18:00:00 2008 Richard W.M. Jones - 1.5.1-3 - BR camlp4 -> ocaml-camlp4-devel * Wed Feb 20 17:00:00 2008 Fedora Release Engineering - 1.5.1-2 - Autorebuild for GCC 4.3 * Sun Sep 16 18:00:00 2007 Chris Petersen 1.5.1-1 - Update to version 1.5.1 padevchooser-0.9.4-0.5.svn20070925.fc10 --------------------------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 0.9.4-0.5.svn20070925 - rebuild for dependancies pam_passwdqc-1.0.5-1 -------------------- * Thu Jun 5 18:00:00 2008 Tomas Mraz - 1.0.5-1 - upgrade to a latest upstream version parted-1.8.8-8.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Peter Jones - 1.8.8-8 - Fix some of the atvrecv code (and the msftres code) so that the flags actually stick. * Thu Jun 5 18:00:00 2008 Peter Jones - 1.8.8-7 - Added "atvrecv" flag patch from atv-bootloader project. pcsc-tools-1.4.14-1.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Tomas Mraz - 1.4.14-1 - upgrade to a latest upstream version perl-Mail-Box-2.082-1.fc10 -------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 2.082-1 - update to 2.082 perl-Net-Netmask-1.9015-2.fc9 ----------------------------- * Fri Jun 6 18:00:00 2008 Douglas E. Warner - 1.9015-2 - rebuild for F9 perl-OLE-Storage_Lite-0.17-1.fc10 --------------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 0.17-1 - update to 0.17 perl-Pod-POM-0.17-10.fc10 ------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 0.17-10 - fix FTBFS perl-Spreadsheet-WriteExcel-2.21-1.fc10 --------------------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 2.21-1 - update to 2.21 perl-Unicode-Map8-0.12-18.fc10 ------------------------------ * Thu Jun 5 18:00:00 2008 Aurelien Bompard 0.12-18 - fix build perl-Unicode-String-2.09-9.fc10 ------------------------------- * Thu Jun 5 18:00:00 2008 Aurelien Bompard 2.09-9 - fix build photoml-0.26-1.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Brendt Wohlberg - 0.26-1 - New release version. pure-ftpd-1.0.21-16.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Aurelien Bompard 1.0.21-16 - Rebuild for libcap.so.2 (bug 450086) python-dialog-2.7-8.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Aurelien Bompard 2.7-8 - add egg info python-pycurl-7.18.1-1.fc10 --------------------------- * Thu Jun 5 18:00:00 2008 Jeffrey C. Ollie - 7.18.1-1 - Update to 7.18.1 - Disable tests because it's not testing the built library, it's trying to test an installed library. qca-1.0-11.fc10 --------------- * Thu Jun 5 18:00:00 2008 Aurelien Bompard 1.0-11 - fix build qca-tls-1.0-14.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Aurelien Bompard 1.0-14 - fix build roundcubemail-0.1.1-5.fc9 ------------------------- * Fri Apr 18 18:00:00 2008 Jon Ciesla = 0.1.1-5 - Added php-pecl-Fileinfo Reqires. BZ 442728. * Wed Apr 16 18:00:00 2008 Jon Ciesla = 0.1.1-4 - Added mcrypt, MDB2 Requires. BZ 442728. * Thu Apr 10 18:00:00 2008 Jon Ciesla = 0.1.1-3 - Patch to fix PEAR path issue, drop symlinks. * Thu Apr 10 18:00:00 2008 Jon Ciesla = 0.1.1-2 - Drop %pre script that was breaking pear packages. * Wed Apr 9 18:00:00 2008 Jon Ciesla = 0.1.1-1 - New upstream release. - Added patch to fix mysql update. setup-2.6.15-1.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Phil Knirsch 2.6.15-1 - Added prelude-manager and snortd to uidgid list supybot-0.83.3-7.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Ricky Zhou - 0.83.3-7 - Uncomment python-dictclient requirement. sweep-0.9.3-1.fc9 ----------------- * Mon Apr 14 18:00:00 2008 Gerard Milmeister - 0.9.3-1 - new release 0.9.3 system-config-printer-1.0.0-3.fc10 ---------------------------------- * Thu Jun 5 18:00:00 2008 Tim Waugh 1.0.0-3 - Applied patches from upstream (bug #450120). taglib-sharp-2.0.3.0-6.fc10 --------------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 2.0.3.0-6 - fix docs generation * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 2.0.3.0-5 - Rebuild against new mono bits texinfo-4.12-4.fc10 ------------------- * Wed Jun 4 18:00:00 2008 Vitezslav Crhonek - 4.12-4 - Remove sed Requires (dependency loop) Resolves: #449705 tracker-0.6.6-3.fc10 -------------------- * Thu Jun 5 18:00:00 2008 Caol??n McNamara - 0.6.6-3 - rebuild for dependancies tree-1.5.1.2-1.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Tim Waugh 1.5.1.2-1 - 1.5.1.2. uim-1.5.0-2.fc10 ---------------- * Wed Jun 4 18:00:00 2008 Akira TAGOH - 1.5.0-2 - Obsoletes uim-el and uim-el-common. wavbreaker-0.10-1.fc10 ---------------------- * Thu Jun 5 18:00:00 2008 Homer - 0.10-1 - move to latest upstream release * Fri May 23 18:00:00 2008 Todd Zullinger - 0.9-4 - fix license tag wlassistant-0.5.7-8.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 0.5.7-8 - fix scons chmod error (resolve FTBFS) xbase-2.0.0-13.fc10 ------------------- * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 2.0.0-13 - add ppc64 detection in configure (it's in the x86_64 patch) * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 2.0.0-12 - fix x86_64 detection in configure (FTBFS) xsupplicant-1.2.8-7.fc10 ------------------------ * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway - 1.2.8-7 - rebuild against fixed kernel headers Summary: Added Packages: 3 Removed Packages: 1 Modified Packages: 84 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-2.23.3.1-2.fc10.i386 requires gnome-spell >= 0:1.0.2 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 galeon-2.0.5-1.fc9.i386 requires libgnome-desktop-2.so.2 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:nant-0.85-21.fc9.i386 requires mono(NDoc.Core) = 0:1.3.3023.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-2.23.3.1-2.fc10.i386 requires gnome-spell >= 0:1.0.2 evolution-2.23.3.1-2.fc10.x86_64 requires gnome-spell >= 0:1.0.2 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.i386 requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.i386 requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.x86_64 requires libicui18n.so.38()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx galeon-2.0.5-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:nant-0.85-21.fc9.x86_64 requires mono(NDoc.Core) = 0:1.3.3023.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-2.23.3.1-2.fc10.ppc requires gnome-spell >= 0:1.0.2 evolution-2.23.3.1-2.fc10.ppc64 requires gnome-spell >= 0:1.0.2 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc requires libicudata.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicuuc.so.38 fedora-ds-base-1.1.1-1.fc10.ppc requires libicui18n.so.38 fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) galeon-2.0.5-1.fc9.ppc requires libgnome-desktop-2.so.2 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-2.23.3.1-2.fc10.ppc64 requires gnome-spell >= 0:1.0.2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicuuc.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicudata.so.38()(64bit) fedora-ds-base-1.1.1-1.fc10.ppc64 requires libicui18n.so.38()(64bit) galeon-2.0.5-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From mschwendt at gmail.com Fri Jun 6 10:21:28 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 6 Jun 2008 12:21:28 +0200 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> Message-ID: <20080606122128.d35452fa.mschwendt@gmail.com> On Fri, 6 Jun 2008 15:18:53 +0530, Debarshi Ray wrote: > Please note that although I filed the initial bug (as required by the > Non-Responsive Maintainer policy) against Zile, the person actually > interested in taking it over (ie. Rakesh) is not an existing Fedora > contributor. Even though the policy page > (http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers) > says "If the requester is a not an existing Fedora contributor, he may > still take over a package", it does not mention how that would be > possible. The usual way is to submit a review request and wait for a > sponsor. No, the usual way for new contributors is to find a sponsor. It doesn't matter how they do it. Submitting packages for review is just one way to look for sponsors. From debarshi.ray at gmail.com Fri Jun 6 10:24:34 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 15:54:34 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <20080606122128.d35452fa.mschwendt@gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <20080606122128.d35452fa.mschwendt@gmail.com> Message-ID: <3170f42f0806060324ldd77096je38d784a30c21c7e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > No, the usual way for new contributors is to find a sponsor. > It doesn't matter how they do it. > > Submitting packages for review is just one way to look for sponsors. What are the other ways? Cheers, Debarshi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFISQ7eTMO+PGPUpacRAsxLAKCrk2/sZb5HK8/Ys5FwPpZfNeNl8gCeMrdy 1X9NNW4SjDhIeNk0RW9AQGI= =SbBi -----END PGP SIGNATURE----- From opensource at till.name Fri Jun 6 10:48:34 2008 From: opensource at till.name (Till Maas) Date: Fri, 6 Jun 2008 12:48:34 +0200 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> Message-ID: <200806061248.43469.opensource@till.name> On Friday 06 June 2008 11:48:53 Debarshi Ray wrote: > Please note that although I filed the initial bug (as required by the > Non-Responsive Maintainer policy) against Zile, the person actually > interested in taking it over (ie. Rakesh) is not an existing Fedora > contributor. Even though the policy page > (http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaint >ainers) says "If the requester is a not an existing Fedora contributor, he > may still take over a package", it does not mention how that would be > possible. The usual way is to submit a review request and wait for a > sponsor. In the outline section of this wikipage it is explained how to do this: | If you are a not an existing Fedora contributor, you can still take over a | package. All of the above must be followed. When you seek approval for the | takeover, you, again, must provide a bugzilla report as if it were a new | Fedora package review. [...] 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 colin at colina.demon.co.uk Fri Jun 6 10:53:59 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri, 06 Jun 2008 11:53:59 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080606081156.GA15125@amd.home.annexia.org> (Richard W. M. Jones's message of "Fri\, 6 Jun 2008 09\:11\:56 +0100") References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> Message-ID: >>>>> "Richard" == Richard W M Jones writes: Richard> On Thu, Jun 05, 2008 at 07:25:30PM -0700, Otto Rey wrote: >> Mono is a free publicity of Microsoft languages.... More .net >> developers, more Microsoft $$$.... There is no reason to use >> .net having java (open source language, spec, implementations, >> multiplatform, etc, etc), ruby, php, python, c, c++, rails, >> etc, etc... There is no reason to include mono in Fedora Richard> One major reason is that it allows languages to be mixed Richard> and to call easily from one language to another. Yeah, sure. Every language is supported as long as it's C#. -- Colin Adams Preston Lancashire From rakesh.pandit at gmail.com Fri Jun 6 11:09:21 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Fri, 6 Jun 2008 16:39:21 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <200806061248.43469.opensource@till.name> References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> Message-ID: 2008/6/6 Till Maas : [..] > In the outline section of this wikipage it is explained how to do this: > > | If you are a not an existing Fedora contributor, you can still take over a > | package. All of the above must be followed. When you seek approval for the > | takeover, you, again, must provide a bugzilla report as if it were a new > | Fedora package review. > [...] > > Regards, > Till > If I follow those points, along with review, I should wait for at least one FESco member approval before taking over and I am waiting. -- Regards, Rakesh Pandit From fedora at matbooth.co.uk Fri Jun 6 11:42:51 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 6 Jun 2008 12:42:51 +0100 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060324ldd77096je38d784a30c21c7e@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <20080606122128.d35452fa.mschwendt@gmail.com> <3170f42f0806060324ldd77096je38d784a30c21c7e@mail.gmail.com> Message-ID: <9497e9990806060442k180695e6nb54b8029cdc3a4e6@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jun 6, 2008 at 11:24 AM, Debarshi Ray wrote: >> No, the usual way for new contributors is to find a sponsor. >> It doesn't matter how they do it. >> >> Submitting packages for review is just one way to look for sponsors. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkhJIw0ACgkQKfdzh3zDrvAlDQCfcWV6DnKKL+aHiB19baPxyl6O Bv8An0LiDizsfW0keW73eQeVUSnjzFUC =LzHv -----END PGP SIGNATURE----- > > What are the other ways? > > Cheers, > Debarshi > I was sponsored originally because I submitted a patch for something. -- Mat Booth www.matbooth.co.uk From mail at robertoragusa.it Fri Jun 6 11:52:07 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Fri, 06 Jun 2008 13:52:07 +0200 Subject: Successfully upgraded to F9 while keeping KDE 3 In-Reply-To: <200806031223.05791.jamatos@fc.up.pt> References: <484323CD.1080308@robertoragusa.it> <200806020818.37534.jamatos@fc.up.pt> <4843BE98.6060905@robertoragusa.it> <200806031223.05791.jamatos@fc.up.pt> Message-ID: <484924E7.3060205@robertoragusa.it> Jos? Matos wrote: > I have no problems with providing PIL = %{version}-%{release} in the > python-imaging spec file. I think it would be a good idea. Best regards. -- Roberto Ragusa mail at robertoragusa.it From mbarnes at redhat.com Fri Jun 6 12:13:35 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Fri, 06 Jun 2008 08:13:35 -0400 Subject: gnome-spell retired Message-ID: <1212754415.9754.3.camel@localhost.localdomain> Just a quick announcement that I have retired the gnome-spell package from Fedora 10. repoquery tells me Evolution was the last user of gnome-spell, but that's been fixed now in Rawhide. Hopefully no one else cares. Matthew Barnes From email.ahmedkamal at googlemail.com Fri Jun 6 13:06:40 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 6 Jun 2008 16:06:40 +0300 Subject: NFSv4 style ACLs on F10 ? Message-ID: <3da3b5b40806060606w54632431j7d8f140cec35a6a7@mail.gmail.com> Hi, Reading this blog entry http://cuddletech.com/blog/pivot/entry.php?id=939 got me excited about NFSv4 style ACL entries. The NFSv4/ZFS combo of the solaris world both understand and implement this well it seems. My question is does Fedora support NFSv4 style ACLs on ext3 ?! If not is this planned? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at conklinhouse.com Fri Jun 6 14:16:42 2008 From: steve at conklinhouse.com (Steve Conklin) Date: Fri, 06 Jun 2008 09:16:42 -0500 Subject: Orphaned packages not! (splat, gpsman, nec2c) Message-ID: <484946CA.6040605@conklinhouse.com> This is seriously screwed up. I only gave up maintaining some security packages when I left Red Hat, and I'm certainly still involved in Fedora and never intended to give up these packages. I didn't remove myself from these packages - someone else did it without checking with me. It was an accident, and I have no hard feelings toward anyone over this, but I'm not happy that the package ownership process (or lack of one) allowed this to happen so easily. Having said that, if people are passionate about some of these and want to pick them up, that's ok. If you don't really want them, I'll take them back. I've taken splat back, no one else got to it first. I'm not terribly passionate about gpsman, it makes sense for Lucian to have it, since he has another package that uses it. I don't even use that package myself. I'm interested in nec2c, I've also been working on xnec2c. Jeff, if you want to keep that, I'd like to help maintain it. Lastly, if you have an interest in amateur radio packages for fedora, please check out and/or join the Fedora Ham SIG: http://fedoraproject.org/wiki/SIGs/AmateurRadio Steve Conklin AI4QR From pertusus at free.fr Fri Jun 6 14:41:07 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 16:41:07 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <484946CA.6040605@conklinhouse.com> References: <484946CA.6040605@conklinhouse.com> Message-ID: <20080606144107.GA2833@free.fr> On Fri, Jun 06, 2008 at 09:16:42AM -0500, Steve Conklin wrote: > > It was an accident, and I have no hard feelings toward anyone over this, > but I'm not happy that the package ownership process (or lack of one) > allowed this to happen so easily. The policy here is the non responsive maintainer policy. Otherwise the primary maintainer should not be changed. However the redhat folks don't seem to follow this procedure and instead it seems that change in package maintainers owned by people @redhat is done by other procedures, including with more sharing of responsibility over package among groups. I am not sure that there is something that can be done in fedora about that issue. Maybe the exception should be written down explicitly such that people like you who is at redhat and in the community knows who to contact @redhat to follow the fedora rules. Also maybe I am mistaken and there are no specific rules for redhat people, only remnants from the past (like the many agg co-maintainer I have who are certainly not interested). -- Pat From pertusus at free.fr Fri Jun 6 14:42:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 16:42:53 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <20080606144107.GA2833@free.fr> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> Message-ID: <20080606144253.GB2833@free.fr> On Fri, Jun 06, 2008 at 04:41:07PM +0200, Patrice Dumas wrote: > On Fri, Jun 06, 2008 at 09:16:42AM -0500, Steve Conklin wrote: > > > > It was an accident, and I have no hard feelings toward anyone over this, > > but I'm not happy that the package ownership process (or lack of one) > > allowed this to happen so easily. > > The policy here is the non responsive maintainer policy. Otherwise the http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers From mschwendt at gmail.com Fri Jun 6 15:10:11 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 6 Jun 2008 17:10:11 +0200 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060324ldd77096je38d784a30c21c7e@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <20080606122128.d35452fa.mschwendt@gmail.com> <3170f42f0806060324ldd77096je38d784a30c21c7e@mail.gmail.com> Message-ID: <20080606171011.31f6570b.mschwendt@gmail.com> On Fri, 6 Jun 2008 15:54:34 +0530, Debarshi Ray wrote: > > No, the usual way for new contributors is to find a sponsor. > > It doesn't matter how they do it. > > > > Submitting packages for review is just one way to look for sponsors. > > What are the other ways? Anything you could think of. For example, an upstream developer/contributor might want to become a package maintainer or co-maintainer. A Fedora package heavy-user might want to become a maintainer or co-maintainer. Orphans are a good opportunity for new contributors to shout "Hey, I'm a heavy-user of this package and willing to maintain it! Who sponsors me?". You wouldn't ask them to first submit other packages for review, would you? From tibbs at math.uh.edu Fri Jun 6 15:11:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 10:11:53 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: DR> Please note that although I filed the initial bug (as required by DR> the Non-Responsive Maintainer policy) against Zile, the person DR> actually interested in taking it over (ie. Rakesh) is not an DR> existing Fedora contributor. Yes, I know; I told him that I'd look over the two packages he's submitted for review and look at getting him sponsored. The zile package itself is immaterial to that. - J< From walters at verbum.org Fri Jun 6 15:34:04 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 6 Jun 2008 11:34:04 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080606081156.GA15125@amd.home.annexia.org> References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> Message-ID: On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones wrote: > > One major reason is that it allows languages to be mixed and to call > easily from one language to another. Free software dropped the ball > on this (Parrot), and Mono/.Net is the only widely available > implementation of this idea. > It was *marketed* as such, but in fact many different languages have run on the JVM for a long time: http://www.robert-tolksdorf.de/vmlanguages.html Some of them date to 1996. Practically speaking there are many modern languages available such as Objective Caml: http://ocamljava.x9c.fr/ Ruby: http://jruby.codehaus.org/ Python: http://jython.org/Project/ Scala: http://www.scala-lang.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgrubb at redhat.com Fri Jun 6 15:39:20 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 6 Jun 2008 11:39:20 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <484946CA.6040605@conklinhouse.com> References: <484946CA.6040605@conklinhouse.com> Message-ID: <200806061139.21257.sgrubb@redhat.com> On Friday 06 June 2008 10:16:42 Steve Conklin wrote: > I only gave up maintaining some security packages when I left Red Hat, > and I'm certainly still involved in Fedora and never intended to give up > these packages. This seems to be the crux of the problem. No built in orphaning process and we needed to start getting some updates on certain security packages. > I didn't remove myself from these packages - someone else did it without > checking with me. > > It was an accident, and I have no hard feelings toward anyone over this, Yes, if you were still wanting to maintain a few of these, it was an accident and this would be my fault. I apologize for this. I checked a couple security packages that needs work and they had your old redhat address. So, I asked for your packages to be released so that we could continue working on them. I guess the moral of the story to anyone else is if you leave Red Hat, please orphan your packages before you leave and/or add your external email address if you still want to be involved with certain packages. Thanks, -Steve From a.badger at gmail.com Fri Jun 6 15:38:30 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 06 Jun 2008 08:38:30 -0700 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <20080606144107.GA2833@free.fr> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> Message-ID: <484959F6.70102@gmail.com> Patrice Dumas wrote: > On Fri, Jun 06, 2008 at 09:16:42AM -0500, Steve Conklin wrote: >> It was an accident, and I have no hard feelings toward anyone over this, >> but I'm not happy that the package ownership process (or lack of one) >> allowed this to happen so easily. > > The policy here is the non responsive maintainer policy. Otherwise the > primary maintainer should not be changed. However the redhat folks don't > seem to follow this procedure and instead it seems that change in package > maintainers owned by people @redhat is done by other procedures, > including with more sharing of responsibility over package among groups. > > I am not sure that there is something that can be done in fedora about > that issue. Maybe the exception should be written down explicitly such > that people like you who is at redhat and in the community knows who > to contact @redhat to follow the fedora rules. > Maybe what could be done is to mark packages a person as maintaining a package as part of Red Hat employment (or employment in general) then it would be simpler to say no longer working for Company Foo, therefore no longer a maintainer of Package Bar. However, even that's not perfect as other people will leave and maintain packages they were paid to work on as part of the greater community. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri Jun 6 15:55:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Jun 2008 11:55:19 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <20080606144107.GA2833@free.fr> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> Message-ID: <1212767719.9688.94.camel@localhost.localdomain> On Fri, 2008-06-06 at 16:41 +0200, Patrice Dumas wrote: > > The policy here is the non responsive maintainer policy. Otherwise the > primary maintainer should not be changed. However the redhat folks don't > seem to follow this procedure and instead it seems that change in package > maintainers owned by people @redhat is done by other procedures, > including with more sharing of responsibility over package among groups. > > I am not sure that there is something that can be done in fedora about > that issue. Maybe the exception should be written down explicitly such > that people like you who is at redhat and in the community knows who > to contact @redhat to follow the fedora rules. > > Also maybe I am mistaken and there are no specific rules for redhat > people, only remnants from the past (like the many agg co-maintainer I > have who are certainly not interested). > Part of the problem is the CLA entry. Many Red Hat employees have a CLA attached to their account through the redhat_cla, that is part of their employment contract. When they leave Red Hat, that contract is no longer valid, nor is their CLA status. In actuality, this is true of any Fedora contributor that changes employers, we just have less visibility into that and assume the maintainer is doing the right thing wrt to their CLA status. I've asked Casey to put some thought into a process we can use when we become aware of somebody changing their CLA status, like leaving Red Hat, especially if we know ahead of time that they are leaving Fedora at the same time. Waiting for bugzilla entries to be replied to when they're assigned to a non-valid email address seems like a bit of a waste. All in all, there is definitely some room for better process here. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri Jun 6 16:01:33 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 18:01:33 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <200806061139.21257.sgrubb@redhat.com> References: <484946CA.6040605@conklinhouse.com> <200806061139.21257.sgrubb@redhat.com> Message-ID: <20080606160133.GG2833@free.fr> On Fri, Jun 06, 2008 at 11:39:20AM -0400, Steve Grubb wrote: > On Friday 06 June 2008 10:16:42 Steve Conklin wrote: > > I only gave up maintaining some security packages when I left Red Hat, > > and I'm certainly still involved in Fedora and never intended to give up > > these packages. > > This seems to be the crux of the problem. No built in orphaning process and we > needed to start getting some updates on certain security packages. There is http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers (and http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages ) > Yes, if you were still wanting to maintain a few of these, it was an accident > and this would be my fault. I apologize for this. I checked a couple security > packages that needs work and they had your old redhat address. So, I asked > for your packages to be released so that we could continue working on them. Why didn't you go through the process outlined in the policy? Is it because you didn't know about it? > I guess the moral of the story to anyone else is if you leave Red Hat, please > orphan your packages before you leave and/or add your external email address > if you still want to be involved with certain packages. This would be nice, and it could also be possible that th enon responsive maintainer policy is also done ofr redhat people. If it is not th ecase, it would be nice to have it written in the wiki. -- Pat From pertusus at free.fr Fri Jun 6 16:10:12 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 18:10:12 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <1212767719.9688.94.camel@localhost.localdomain> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> Message-ID: <20080606161012.GH2833@free.fr> On Fri, Jun 06, 2008 at 11:55:19AM -0400, Jesse Keating wrote: > > Part of the problem is the CLA entry. Many Red Hat employees have a CLA > attached to their account through the redhat_cla, that is part of their > employment contract. When they leave Red Hat, that contract is no > longer valid, nor is their CLA status. In actuality, this is true of > any Fedora contributor that changes employers, we just have less > visibility into that and assume the maintainer is doing the right thing > wrt to their CLA status. Maybe it could also be possible for some employees to go through regular sponsorship and use the regular CLA. I understand that it is not always possible, sometime redhat wants to hire somebody to work on packages without going through the fedora formal process, but I think that @redhat people interested in being part of the fedora community are likely to be able to go through the fedora process (even though not when they have just arrived). -- Pat From sgrubb at redhat.com Fri Jun 6 16:22:04 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 6 Jun 2008 12:22:04 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <20080606160133.GG2833@free.fr> References: <484946CA.6040605@conklinhouse.com> <200806061139.21257.sgrubb@redhat.com> <20080606160133.GG2833@free.fr> Message-ID: <200806061222.04742.sgrubb@redhat.com> On Friday 06 June 2008 12:01:33 Patrice Dumas wrote: > There is > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMainta >iners (and > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > ) > > > Yes, if you were still wanting to maintain a few of these, it was an > > accident and this would be my fault. I apologize for this. I checked a > > couple security packages that needs work and they had your old redhat > > address. So, I asked for your packages to be released so that we could > > continue working on them. > > Why didn't you go through the process outlined in the policy? Is it > because you didn't know about it? This is not a typical non-responsive maintainer problem. His email account listed on the package db entry is closed for a fact. So, why follow a proceedure that will take a few weeks when I know for a fact that I need to reassign some packages? :) I suspect the orphaning process should be followed in cases like this - but before its too late. -Steve From debarshi.ray at gmail.com Fri Jun 6 16:28:09 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 21:58:09 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806012245y2f57968co68caa8ea010b525f@mail.gmail.com> <3170f42f0806052303s53776e87kb2d0593caa4ea831@mail.gmail.com> <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> Message-ID: <3170f42f0806060928p35adce0kfc4fb39c6579f7d1@mail.gmail.com> > Yes, I know; I told him that I'd look over the two packages he's > submitted for review and look at getting him sponsored. The zile > package itself is immaterial to that. I know you have said that, but fact remains that the review was submitted before you said something. So according to [1] the review was part of the existing process, nothing new is being invented here, and it is definitely not immaterial enough for someone to close it as CLOSED_NOTABUG. Regards, Debarshi [1] https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline From mike at miketc.com Fri Jun 6 16:30:20 2008 From: mike at miketc.com (Mike Chambers) Date: Fri, 06 Jun 2008 11:30:20 -0500 Subject: rhgb vs ? Message-ID: <1212769820.5234.5.camel@scrappy.miketc.com> I know rhgb is being removed and a quicker gdm login process is taking over, or at least something is? I updated my system to rawhide and saw something replace rhgb? What package is that and can it be involved in the kernel options in grub like rhgb used to? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From opensource at till.name Fri Jun 6 16:30:56 2008 From: opensource at till.name (Till Maas) Date: Fri, 06 Jun 2008 18:30:56 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <200806061222.04742.sgrubb@redhat.com> References: <484946CA.6040605@conklinhouse.com> <20080606160133.GG2833@free.fr> <200806061222.04742.sgrubb@redhat.com> Message-ID: <200806061831.07780.opensource@till.name> On Fri June 6 2008, Steve Grubb wrote: > This is not a typical non-responsive maintainer problem. His email account > listed on the package db entry is closed for a fact. So, why follow a > proceedure that will take a few weeks when I know for a fact that I need to > reassign some packages? :) Did he also loose his FAS account? If not, then he could have updated his email address in FAS. 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 tibbs at math.uh.edu Fri Jun 6 16:34:50 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 11:34:50 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> Message-ID: >>>>> "RP" == Rakesh Pandit writes: RP> If I follow those points, along with review, I should wait for at RP> least one FESco member approval before taking over and I am RP> waiting. Well, according to the procedure he gets seven days from the second ping. The ticket indicates that the second ping happened on 2008-06-03, so he gets four more days, I guess, unless you have other public records of him being contacted earlier. I'll happily give you the approval (after I look at the two review tickets you submitted) but even though it's obvious that he'll never respond because his mail is bouncing, I don't want to cause problems due to not following the policy as written. Unless other FESCo folks want to pile on here and absolve me with cries of "just do it". - J< From katzj at redhat.com Fri Jun 6 16:37:08 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 06 Jun 2008 12:37:08 -0400 Subject: rhgb vs ? In-Reply-To: <1212769820.5234.5.camel@scrappy.miketc.com> References: <1212769820.5234.5.camel@scrappy.miketc.com> Message-ID: <1212770228.32560.7.camel@aglarond.local> On Fri, 2008-06-06 at 11:30 -0500, Mike Chambers wrote: > I know rhgb is being removed and a quicker gdm login process is taking > over, or at least something is? I updated my system to rawhide and saw > something replace rhgb? What package is that and can it be involved in > the kernel options in grub like rhgb used to? The new package is plymouth[1] but all of the integration pieces haven't quite landed yet. But starting to land bits in rawhide helps to make that easier, so the staging has begun. rhgb or not in the kernel command line will likely continue to have an effect, although there's some hand-waving on my part right now with that :-) Jeremy [1] http://fedoraproject.org/wiki/Releases/FeatureBetterStartup has more details From mclasen at redhat.com Fri Jun 6 16:42:21 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 06 Jun 2008 12:42:21 -0400 Subject: rhgb vs ? In-Reply-To: <1212770228.32560.7.camel@aglarond.local> References: <1212769820.5234.5.camel@scrappy.miketc.com> <1212770228.32560.7.camel@aglarond.local> Message-ID: <1212770541.4772.9.camel@localhost.localdomain> On Fri, 2008-06-06 at 12:37 -0400, Jeremy Katz wrote: > On Fri, 2008-06-06 at 11:30 -0500, Mike Chambers wrote: > > I know rhgb is being removed and a quicker gdm login process is taking > > over, or at least something is? I updated my system to rawhide and saw > > something replace rhgb? What package is that and can it be involved in > > the kernel options in grub like rhgb used to? > > The new package is plymouth[1] but all of the integration pieces haven't > quite landed yet. But starting to land bits in rawhide helps to make > that easier, so the staging has begun. rhgb or not in the kernel > command line will likely continue to have an effect, although there's > some hand-waving on my part right now with that :-) > Plymouth is actually in rawhide already. We just missing the mkinitrd bits to make use of it. That will hopefully fall in place soon. We are aiming for a demoable new bootsequence by Fudcon. From debarshi.ray at gmail.com Fri Jun 6 16:50:40 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 22:20:40 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> Message-ID: <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> Funny how you keep on arguing this. > RP> If I follow those points, along with review, I should wait for at > RP> least one FESco member approval before taking over and I am > RP> waiting. > > Well, according to the procedure he gets seven days from the second > ping. The ticket indicates that the second ping happened on > 2008-06-03, so he gets four more days, I guess, unless you have other > public records of him being contacted earlier. The policy says: "After 2 attempts (2 weeks) of no response from the maintainer, the reporter posts to the fedora-devel list with a url to the bug report and asks if anyone knows how to contact the maintainer." The first public attempt was by me on 17th May and the second on 25th May. A weeks after this the review was submitted on 3rd June. In the meantime Rakesh had expressed his desire to take over the package so I let him continue with the process. > I don't want to cause problems > due to not following the policy as written. The _only_ part which was not followed was waiting for approval from a FESCo member before submitting the review. Since there was a message submitted on this list on 1st June and no one responded for the next 6 days, I do not think that can be the fault of anyone else apart from the FESCo members. So kindly refrain from saying things like "not following the policy as written". Regards, Debarshi From jkeating at redhat.com Fri Jun 6 17:01:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Jun 2008 13:01:37 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <20080606161012.GH2833@free.fr> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> <20080606161012.GH2833@free.fr> Message-ID: <1212771697.9688.98.camel@localhost.localdomain> On Fri, 2008-06-06 at 18:10 +0200, Patrice Dumas wrote: > Maybe it could also be possible for some employees to go through regular > sponsorship and use the regular CLA. I understand that it is not always > possible, sometime redhat wants to hire somebody to work on packages > without going through the fedora formal process, but I think that > @redhat people interested in being part of the fedora community are > likely to be able to go through the fedora process (even though not when > they have just arrived). Regardless if which method they obtain CLA, once they end their employment with Red Hat that CLA is technically no longer valid, particularly if they take employment with somebody else. Sadly this is a pretty big gaping hole in our system. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Fri Jun 6 17:03:07 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 06 Jun 2008 13:03:07 -0400 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> Message-ID: <1212771787.5913.3.camel@truman> On Fri, 2008-06-06 at 11:34 -0500, Jason L Tibbitts III wrote: > > I'll happily give you the approval (after I look at the two review > tickets you submitted) but even though it's obvious that he'll never > respond because his mail is bouncing, I don't want to cause problems > due to not following the policy as written. Unless other FESCo folks > want to pile on here and absolve me with cries of "just do it". IMO if the mail is bouncing, I think it's fine to do it. 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: 197 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Jun 6 17:03:49 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 12:03:49 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: DR> The first public attempt was by me on 17th May and the second on DR> 25th May. Well, great, all I have to go on is the ticket. DR> So kindly refrain from saying things like "not following the DR> policy as written". Kindly take your indignation elsewhere; was referring to my actions only, not anything related to you. I am simply trying to help here. I had a nice conversation on IRC last night with Rakesh wherein we worked out the details and how I was going to help him; we left the zile ticket closed since it's unnecessary and he'll simply take the package over once I sponsor him, etc. and now I get up this morning and find you getting in the middle and confusing things and making me wonder if it was worth trying to help at all. Could you kindly just step out of the process and let me work with Rakesh here? - J< From dennis at ausil.us Fri Jun 6 17:10:22 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 6 Jun 2008 12:10:22 -0500 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <1212767719.9688.94.camel@localhost.localdomain> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> Message-ID: <200806061210.32243.dennis@ausil.us> On Friday 06 June 2008, Jesse Keating wrote: > On Fri, 2008-06-06 at 16:41 +0200, Patrice Dumas wrote: > > The policy here is the non responsive maintainer policy. Otherwise the > > primary maintainer should not be changed. However the redhat folks don't > > seem to follow this procedure and instead it seems that change in package > > maintainers owned by people @redhat is done by other procedures, > > including with more sharing of responsibility over package among groups. > > > > I am not sure that there is something that can be done in fedora about > > that issue. Maybe the exception should be written down explicitly such > > that people like you who is at redhat and in the community knows who > > to contact @redhat to follow the fedora rules. > > > > Also maybe I am mistaken and there are no specific rules for redhat > > people, only remnants from the past (like the many agg co-maintainer I > > have who are certainly not interested). > > Part of the problem is the CLA entry. Many Red Hat employees have a CLA > attached to their account through the redhat_cla, that is part of their > employment contract. When they leave Red Hat, that contract is no > longer valid, nor is their CLA status. In actuality, this is true of > any Fedora contributor that changes employers, we just have less > visibility into that and assume the maintainer is doing the right thing > wrt to their CLA status. This is only true if they are doing fedora work on company time. If they are doing fedora work on there own time then there is zero change. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Fri Jun 6 17:14:24 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Jun 2008 13:14:24 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <200806061210.32243.dennis@ausil.us> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> <200806061210.32243.dennis@ausil.us> Message-ID: <1212772464.9688.100.camel@localhost.localdomain> On Fri, 2008-06-06 at 12:10 -0500, Dennis Gilmore wrote: > This is only true if they are doing fedora work on company time. If they are > doing fedora work on there own time then there is zero change. That's entirely specific to the company. Not every company clearly separates company time vs non company time, particularly for software contributions and things like inventions. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Fri Jun 6 17:15:16 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 22:45:16 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> Message-ID: <3170f42f0806061015j6bb0aaf6h1a08d64562d7765f@mail.gmail.com> > Could you kindly just step out of the process and let me work with > Rakesh here? Unfortunately no. I filed the initial bug and made it block against the review, which you suddenly closed. You subsequently commented on this thread: "...if you want to go making your own process....", which was wrong. Is it so difficult to accept your mistake politely? Regards, Debarshi From tibbs at math.uh.edu Fri Jun 6 17:24:40 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 12:24:40 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <3170f42f0806061015j6bb0aaf6h1a08d64562d7765f@mail.gmail.com> References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> <3170f42f0806061015j6bb0aaf6h1a08d64562d7765f@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: >> Could you kindly just step out of the process and let me work with >> Rakesh here? DR> Unfortunately no. I guess I'll try to help Rakesh as much as I can and just try to ignore your interference, then. I've no idea why you don't just want to let me work with him. - J< From debarshi.ray at gmail.com Fri Jun 6 17:29:04 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 6 Jun 2008 22:59:04 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <3170f42f0806060950o18933bf1u6418b762b1d944dd@mail.gmail.com> <3170f42f0806061015j6bb0aaf6h1a08d64562d7765f@mail.gmail.com> Message-ID: <3170f42f0806061029j564f4e05s3f7ecf9874d03ad7@mail.gmail.com> > I guess I'll try to help Rakesh as much as I can and just try to > ignore your interference, then. I've no idea why you don't just want > to let me work with him. Wonderful. First you wrongfully accuse others of inventing processes and go on modifying bugs without correct reason, and yet dictate what others should do. Regards, Debarshi From tibbs at math.uh.edu Fri Jun 6 17:39:50 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 12:39:50 -0500 Subject: Request for ownership: zile maintainer not responding In-Reply-To: <1212771787.5913.3.camel@truman> References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <1212771787.5913.3.camel@truman> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> IMO if the mail is bouncing, I think it's fine to do it. Thanks, Brian; anyone disagree with this? - J< From SteveD at redhat.com Fri Jun 6 17:40:54 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 06 Jun 2008 13:40:54 -0400 Subject: NFSv4 style ACLs on F10 ? In-Reply-To: <3da3b5b40806060606w54632431j7d8f140cec35a6a7@mail.gmail.com> References: <3da3b5b40806060606w54632431j7d8f140cec35a6a7@mail.gmail.com> Message-ID: <484976A6.4080906@RedHat.com> Ahmed Kamal wrote: > Hi, > Reading this blog entry > http://cuddletech.com/blog/pivot/entry.php?id=939 > got me excited about NFSv4 style ACL entries. The NFSv4/ZFS combo of the > solaris world both understand and implement this well it seems. My > question is does Fedora support NFSv4 style ACLs on ext3 ?! If not is > this planned? If I'm understanding your quetion... the answer is yes. See nfs4-acl-tools for details. steved. From dwmw2 at infradead.org Fri Jun 6 18:00:08 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 06 Jun 2008 19:00:08 +0100 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <1212771697.9688.98.camel@localhost.localdomain> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> <20080606161012.GH2833@free.fr> <1212771697.9688.98.camel@localhost.localdomain> Message-ID: <1212775208.32207.395.camel@pmac.infradead.org> On Fri, 2008-06-06 at 13:01 -0400, Jesse Keating wrote: > On Fri, 2008-06-06 at 18:10 +0200, Patrice Dumas wrote: > > Maybe it could also be possible for some employees to go through regular > > sponsorship and use the regular CLA. I understand that it is not always > > possible, sometime redhat wants to hire somebody to work on packages > > without going through the fedora formal process, but I think that > > @redhat people interested in being part of the fedora community are > > likely to be able to go through the fedora process (even though not when > > they have just arrived). > > Regardless if which method they obtain CLA, once they end their > employment with Red Hat that CLA is technically no longer valid, > particularly if they take employment with somebody else. Sadly this > is a pretty big gaping hole in our system. Do I need to execute the CLA now? I certainly don't intend to stop maintaining any of my packages (except RHEL glibc-kernheaders! Yay!). -- dwmw2 From jwboyer at gmail.com Fri Jun 6 18:05:48 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 6 Jun 2008 13:05:48 -0500 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <1212775208.32207.395.camel@pmac.infradead.org> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> <20080606161012.GH2833@free.fr> <1212771697.9688.98.camel@localhost.localdomain> <1212775208.32207.395.camel@pmac.infradead.org> Message-ID: <20080606130548.0d7623e3@vader.jdub.homelinux.org> On Fri, 06 Jun 2008 19:00:08 +0100 David Woodhouse wrote: > On Fri, 2008-06-06 at 13:01 -0400, Jesse Keating wrote: > > On Fri, 2008-06-06 at 18:10 +0200, Patrice Dumas wrote: > > > Maybe it could also be possible for some employees to go through regular > > > sponsorship and use the regular CLA. I understand that it is not always > > > possible, sometime redhat wants to hire somebody to work on packages > > > without going through the fedora formal process, but I think that > > > @redhat people interested in being part of the fedora community are > > > likely to be able to go through the fedora process (even though not when > > > they have just arrived). > > > > Regardless if which method they obtain CLA, once they end their > > employment with Red Hat that CLA is technically no longer valid, > > particularly if they take employment with somebody else. Sadly this > > is a pretty big gaping hole in our system. > > Do I need to execute the CLA now? I certainly don't intend to stop > maintaining any of my packages (except RHEL glibc-kernheaders! Yay!). Yes. But your new employer might be interested in having a company-wide CLA as Dell and IBM do. josh From jkeating at redhat.com Fri Jun 6 18:12:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Jun 2008 14:12:49 -0400 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <1212771787.5913.3.camel@truman> Message-ID: <1212775969.9688.102.camel@localhost.localdomain> On Fri, 2008-06-06 at 12:39 -0500, Jason L Tibbitts III wrote: > >>>>> "BP" == Brian Pepple writes: > > BP> IMO if the mail is bouncing, I think it's fine to do it. > > Thanks, Brian; anyone disagree with this? > > - J< I agree with it. Of course, I'm guilty of cheating the policy myself recently... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Fri Jun 6 18:13:26 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 6 Jun 2008 13:13:26 -0500 (CDT) Subject: Fedora i386 rawhide rebuild in mock status 2008-06-01 In-Reply-To: <20080602190021.GB27019@auslistsprd01.us.dell.com> References: <20080602085838.A5948@humbolt.us.dell.com> <62188.198.175.55.5.1212424640.squirrel@mail.jcomserv.net> <63456.198.175.55.5.1212426062.squirrel@mail.jcomserv.net> <20080602181709.GA27019@auslistsprd01.us.dell.com> <33057.198.175.55.5.1212432491.squirrel@mail.jcomserv.net> <20080602190021.GB27019@auslistsprd01.us.dell.com> Message-ID: <51384.198.175.55.5.1212776006.squirrel@mail.jcomserv.net> > On Mon, Jun 02, 2008 at 01:48:11PM -0500, Jon Ciesla wrote: >> >> > On Mon, Jun 02, 2008 at 12:01:02PM -0500, Jon Ciesla wrote: >> >> >> >> > >> >> >> astromenace-1.2-8.fc9 (build/make) limb >> >> > >> >> > Already foxed qof. astromenace builds fine locally, but it looks >> like >> >> > this build failed because it was missing sdl-config, which is in >> >> > SDL-devel, an explicit BR, which mock pulled. Running my own mock >> >> build >> >> > against devel now as a test. . . >> >> >> >> Finished. Same error. Builds just fine oon fc9 local. >> > >> > There's something wrong with $PATH for the build user inside the >> > buildroot when it fails for me. I built it inside mock again, and see >> > the same failure. However, if I edit the makefiles to point at >> > /usr/bin/sdl-config instead of simply sdl-config, it succeeds. >> >> Could this be causing other problems/failures as well? > > Turns out it's not quite that simple... I just didn't let it run > long enough. > >>From sitting inside the chroot, as the building user, I run: > $ make > Linking CXX executable AstroMenace > c++: `/usr/bin/sdl-config: No such file or directory > make[2]: *** [AstroMenace] Error 1 > make[1]: *** [CMakeFiles/AstroMenace.dir/all] Error 2 > make: *** [all] Error 2 > > but of course it's present. > > CMakeFiles/AstroMenace.dir/link.txt > is our culprit. > > If you look at that file, the line length is huge (>10k characters). > The `sdl-config --libs` is not getting evaluated in a shell, like the > code expects, it's being evaluated by /usr/bin/c++, which of course > fails. > > Short story is, the invocations of sdl-config --libs and sdl-config > --cflags should happen not quite as late as they are, but earlier, > where they can be evaluated and expanded by Makefile and not by c++. Fixed by new upstream release. Built successfully for rawhide. > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > -- novus ordo absurdum From jkeating at redhat.com Fri Jun 6 18:22:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Jun 2008 14:22:47 -0400 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <1212775208.32207.395.camel@pmac.infradead.org> References: <484946CA.6040605@conklinhouse.com> <20080606144107.GA2833@free.fr> <1212767719.9688.94.camel@localhost.localdomain> <20080606161012.GH2833@free.fr> <1212771697.9688.98.camel@localhost.localdomain> <1212775208.32207.395.camel@pmac.infradead.org> Message-ID: <1212776567.9688.104.camel@localhost.localdomain> On Fri, 2008-06-06 at 19:00 +0100, David Woodhouse wrote: > > Do I need to execute the CLA now? I certainly don't intend to stop > maintaining any of my packages (except RHEL glibc-kernheaders! Yay!). If you have just a plain Fedora CLA and not a redhat_cla, then I think that's a question between you and your employer. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri Jun 6 18:33:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 20:33:59 +0200 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <200806061222.04742.sgrubb@redhat.com> References: <484946CA.6040605@conklinhouse.com> <200806061139.21257.sgrubb@redhat.com> <20080606160133.GG2833@free.fr> <200806061222.04742.sgrubb@redhat.com> Message-ID: <20080606183359.GB2760@free.fr> On Fri, Jun 06, 2008 at 12:22:04PM -0400, Steve Grubb wrote: > > This is not a typical non-responsive maintainer problem. His email account > listed on the package db entry is closed for a fact. So, why follow a > proceedure that will take a few weeks when I know for a fact that I need to > reassign some packages? :) It is true that it is not the typical non responsive policy, but I think that it is covered nevertheless, with a bit of interpretation. If you remove the reference to the bug which doesn't make sense, indeed one gets: Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (ie, alternative email, irc, etc). > I suspect the orphaning process should be followed in cases like this - but > before its too late. I don't think it makes much sense. I'll try to make a proposal soon to cover that in the Non-responsive Maintainer Policy. -- Pat From pertusus at free.fr Fri Jun 6 18:41:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 20:41:22 +0200 Subject: non responsive policy with invalid mail Message-ID: <20080606184122.GC2760@free.fr> Hello, I propose to add the following to the Non-responsive Maintainer Policy (at the beginning): If the mail of the maintainer has changed, anybody noticing it should attempt to contact the maintainer through another mean and ask him to take care of changing his information in the packagedb. If there is no known way of contacting the former maintainer, or he is not willing to make the required change in the packagedb, one should directly jump to the mail of the formal request to orphan all the packager packages to fedora-devel-list. -- Pat From debarshi.ray at gmail.com Fri Jun 6 18:41:53 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 7 Jun 2008 00:11:53 +0530 Subject: Retiring Opyum Message-ID: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> Since Pirut has been replaced with PackageKit, and we already have a GSoC student working on adding service pack support to PackageKit [1], it does not make sense to keep Opyum [2] anymore in the distribution. Therefore I would like to retire the package from Fedora 9 and Rawhide. Before someone jumps up and asks how Opyum made it into Fedora 9 when Pirut (a critical dependency) is missing, let me tell you what happened. Jeremy Katz had been nice enough to notify me during the Fedora 9 cycle about his plans of retiring Pirut. However none of the subsequent rawhide reports till date mentions opyum's missing dependency on pirut. This had led me to believe that for some reason Fedora 9 had still retained Pirut, until I got this: https://bugzilla.redhat.com/show_bug.cgi?id=448324 Since the rawhide reports are usually accurate, I fear I might have dropped the ball somewhere and made a fool of myself. Does anyone have any objections? Happy hacking, Debarshi [1] http://code.google.com/soc/2008/fedora/appinfo.html?csaid=58FD27FF194214DD [2] http://fedoraproject.org/wiki/DebarshiRay/Opyum From debarshi.ray at gmail.com Fri Jun 6 18:53:13 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 7 Jun 2008 00:23:13 +0530 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: <3170f42f0806061153r5c218a37n6f2936eae01a01f1@mail.gmail.com> > If the mail of the maintainer has changed, anybody noticing it should > attempt to contact the maintainer through another mean and ask him to > take care of changing his information in the packagedb. If there is no > known way of contacting the former maintainer, or he is not willing to > make the required change in the packagedb, one should directly jump to > the mail of the formal request to orphan all the packager packages to > fedora-devel-list. +1 Regards, Debarshi From notting at redhat.com Fri Jun 6 19:07:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 Jun 2008 15:07:03 -0400 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: <20080606190703.GA10321@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > If the mail of the maintainer has changed, anybody noticing it should > attempt to contact the maintainer through another mean and ask him to > take care of changing his information in the packagedb. If there is no > known way of contacting the former maintainer, or he is not willing to > make the required change in the packagedb, one should directly jump to > the mail of the formal request to orphan all the packager packages to > fedora-devel-list. As long as it's distinguishing between invalid no-longer existing e-mail addresses vs. temporarily bouncing ones, it sounds reasonable. Bill From rakesh.pandit at gmail.com Fri Jun 6 19:08:34 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sat, 7 Jun 2008 00:38:34 +0530 Subject: Request for ownership: zile maintainer not responding In-Reply-To: References: <3170f42f0806060248o40e85f8djb80941c36ff71b8f@mail.gmail.com> <200806061248.43469.opensource@till.name> <1212771787.5913.3.camel@truman> Message-ID: 2008/6/6 Jason L Tibbitts III : >>>>>> "DR" == Debarshi Ray writes: > > DR> Jason, Please don't close [2] since that is a consequence of the > DR> Non-Responsive Maintainer procedure initiated by [1]. > > Well, if you want to go making your own process.... > It would be unethical for not posting. I see no harm in DR's post above, it just informed about relationship between these two bugs and Non-Responsive Maintainer procedure in response to you closing the bug without specifing any proper reason neither in this thread nor in bug reports. 2008/6/6 Jason L Tibbitts III : [..] > Kindly take your indignation elsewhere; was referring to my actions > only, not anything related to you. I am simply trying to help here. It seemed to be ambiguous to me also at first glance. > I had a nice conversation on IRC last night with Rakesh wherein we > worked out the details and how I was going to help him; we left the > zile ticket closed since it's unnecessary and he'll simply take the > package over once I sponsor him, etc. and now I get up this morning > and find you getting in the middle and confusing things and making me > wonder if it was worth trying to help at all. > > Could you kindly just step out of the process and let me work with > Rakesh here? > IMHO nobody is coming in middle, it is just that you are not being polite in your first response. DR suggested me Zile package and he was first to file up 'maintainer not responding' bug. I showed my interest and accepted to continue the procedure he has started. So, he was always in picture and had intention of contributing. I regret my mistake for not waiting long enough and posting a bug, but I don't think this was the reason for closing the bug in first place. -- Rakesh Pandit *My poor net connection prevented me for mailing at appropriate time :( From steve at conklinhouse.com Fri Jun 6 19:10:23 2008 From: steve at conklinhouse.com (Steve Conklin) Date: Fri, 06 Jun 2008 14:10:23 -0500 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: <48498B9F.6030300@conklinhouse.com> Patrice Dumas wrote: > Hello, > > I propose to add the following to the Non-responsive Maintainer Policy > (at the beginning): > > > If the mail of the maintainer has changed, anybody noticing it should > attempt to contact the maintainer through another mean and ask him to > take care of changing his information in the packagedb. If there is no > known way of contacting the former maintainer, or he is not willing to > make the required change in the packagedb, one should directly jump to > the mail of the formal request to orphan all the packager packages to > fedora-devel-list. > > > -- > Pat > > Sounds great to me. It would have prevented this problem. I'm not hard to find, especially since the other maintainers on the packages (who are subscribed to the BZs) and I are all on IRC most of the time. Steve From tibbs at math.uh.edu Fri Jun 6 19:15:15 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 14:15:15 -0500 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> If the mail of the maintainer has changed, anybody noticing it PD> should attempt to contact the maintainer through another mean and PD> ask him to take care of changing his information in the PD> packagedb. Yeah, I have to agree, but even then we shouldn't need to go through a private investigator to track someone down. If all we have for someone is an email address, and mail to it bounces continuously for some period of time, then I'd suggest that we're done. On the other hand, I happily gave my telephone number in FAS and I'd hope to get a call in such an instance. - J< From pertusus at free.fr Fri Jun 6 19:23:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Jun 2008 21:23:14 +0200 Subject: non responsive policy with invalid mail In-Reply-To: References: <20080606184122.GC2760@free.fr> Message-ID: <20080606192314.GF2760@free.fr> On Fri, Jun 06, 2008 at 02:15:15PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> If the mail of the maintainer has changed, anybody noticing it > PD> should attempt to contact the maintainer through another mean and > PD> ask him to take care of changing his information in the > PD> packagedb. > > Yeah, I have to agree, but even then we shouldn't need to go through a > private investigator to track someone down. If all we have for > someone is an email address, and mail to it bounces continuously for > some period of time, then I'd suggest that we're done. I agree. Maybe it could be stated more precisely. Anybody can propose something better, especially in term of language. -- Pat From walters at verbum.org Fri Jun 6 20:06:25 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 6 Jun 2008 16:06:25 -0400 Subject: nscd by default? Message-ID: Per discussion here: http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00355.html and followup here: http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00409.html Is there a reason we aren't using nscd by default? I would say the current DNS situation is the most annoying desktop networking-related bug in the OS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Fri Jun 6 20:22:05 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2008 15:22:05 -0500 Subject: nscd by default? In-Reply-To: References: Message-ID: >>>>> "CW" == Colin Walters writes: CW> Is there a reason we aren't using nscd by default? I have to agree, but currently it crashes within half a hour of being started. nscd[2066]: segfault at 66de14cc ip b7fc821e sp addd0078 error 4 in nscd[b7fb8000+1e000] https://bugzilla.redhat.com/show_bug.cgi?id=430324 - J< From kevin.kofler at chello.at Fri Jun 6 20:34:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 6 Jun 2008 20:34:12 +0000 (UTC) Subject: Retiring Opyum References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> Message-ID: Debarshi Ray gmail.com> writes: > Therefore I would like to retire the package from Fedora 9 and > Rawhide. Well, the package can't be removed from the Fedora 9 Everything repository, that repository isn't allowed to change (because changing it would cause mirroring chaos). It can be blocked from Rawhide though, ask rel-eng for that. > Jeremy Katz had been nice enough to notify me during the Fedora 9 > cycle about his plans of retiring Pirut. However none of the > subsequent rawhide reports till date mentions opyum's missing > dependency on pirut. This had led me to believe that for some reason > Fedora 9 had still retained Pirut, until I got this: > https://bugzilla.redhat.com/show_bug.cgi?id=448324 Since the rawhide > reports are usually accurate, I fear I might have dropped the ball > somewhere and made a fool of myself. The problem there is that gnome-packagekit has: Provides: pirut = 1.3.30-3 without actually providing the Python modules pirut used to provide. So there's no broken dependency, Opyum just fails at runtime (and is thus completely useless), but the dependency checkers won't catch it. Kevin Kofler From jspaleta at gmail.com Fri Jun 6 21:18:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 6 Jun 2008 13:18:43 -0800 Subject: Orphaned packages not! (splat, gpsman, nec2c) In-Reply-To: <484946CA.6040605@conklinhouse.com> References: <484946CA.6040605@conklinhouse.com> Message-ID: <604aa7910806061418j4f4001b4t6d504bf7b164e759@mail.gmail.com> On Fri, Jun 6, 2008 at 6:16 AM, Steve Conklin wrote: > I'm interested in nec2c, I've also been working on xnec2c. Jeff, if you > want to keep that, I'd like to help maintain it. No I don't need to keep it. We'll clean up the maintainership on Monday I'm out of communication while I travel back to the states this weekend. But I will say, now that I know its in the distro I'll actually be using it. -jef From tcallawa at redhat.com Fri Jun 6 21:59:00 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 06 Jun 2008 17:59:00 -0400 Subject: gkrellm themes In-Reply-To: <200805231736.39470.gene@czarc.net> References: <200805201341.13276.gene@czarc.net> <1211308146.3801.286.camel@localhost.localdomain> <200805231736.39470.gene@czarc.net> Message-ID: <1212789540.15015.17.camel@localhost.localdomain> Gene, Apologies for the delayed reply. Please keep in mind that IANAL, I just play one on TV. On Fri, 2008-05-23 at 17:36 -0400, Gene Czarcinski wrote: > I assume all licenses in the "good" list are OK and all in the "bad" list are > not. Yes, this is correct. > Do you have a suggestion as to a "preferred" license for this kind of > stuff ... graphics and configuration files mostly. I would really like to > get most folks to all use the same license (see below). For graphics, you can safely use the licenses here: http://fedoraproject.org/wiki/Licensing#Good_Licenses_3 I would specifically recommend CC-BY or CC-BY-SA, as those provide the most flexibility and the opportunity for derived art. For configuration files, generally any permissive license should work. You might avoid any license that is too software specific, but MIT (http://fedoraproject.org/wiki/Licensing/MIT#Old_Style) might not be a bad fit. > Also, do you have any suggestions on how to handle cases where multiple > individuals have had their hand in things: A creates a theme. B then > modifies A's theme to create a new theme. C comes along and modifies B's > theme plus add some stuff from a theme created by D to create yet another > theme. That may sound convoluted but it appears to be the case for some of > these themes. Well, in such a scenario, A, B, C, and D probably have made copyrightable contributions to the work (the ABCD theme). Unless B, C, and D have agreed to assign copyright to A (or some other single party), they would all need to agree on the license for the work. This is a big reason why it is important for anyone generating copyrightable content to license that content. If A had put it under the CC-BY license, then when B, C, and D made changes, their changes would be automatically available under that license (note, this is not always true, but it is in this specific scenario). > I also assume that any theme citing Carsten Haitzler's (Rasterman's) > enlightenment window manager as a source is OK (I do not need that author's > blessing too). You should see what license that Carsten's source content is under. Assuming that the derived works do not have a license which conflicts with Carsten's license, there should not be a need to get his blessing. In the event where no license is defined on the new derived work, you can safely assume the derived work inherits Carsten's license (but it never hurts to ask the copyright holder who made the modifications for his intention). > I am not sure what will be needed in the SPEC file with respect to licensing > (since you are reviewing spec files). I sure do not want to see a bunch of > theme packages ... one for every license type. That is too much > over-achieving. No, this should not be necessary. When you get to that point, I can help you through it. ~spot From sgrubb at redhat.com Fri Jun 6 22:09:34 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 6 Jun 2008 18:09:34 -0400 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: <200806061809.34427.sgrubb@redhat.com> On Friday 06 June 2008 14:41:22 Patrice Dumas wrote: > If there is no known way of contacting the former maintainer, or he is not > willing to make the required change in the packagedb, one should directly > jump to the mail of the formal request to orphan all the packager packages > to fedora-devel-list. What about the case where someone was terminated (which was not the case that precipitated this thread)? Perhaps in that case the maintainer doesn't want the whole world to know. How is that taken into account with this policy? I think there are times when we have to respect that and have the ability to replace maintainers without shouting to the world. -Steve From mefoster at gmail.com Fri Jun 6 22:17:42 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Fri, 6 Jun 2008 23:17:42 +0100 Subject: non responsive policy with invalid mail In-Reply-To: <20080606192314.GF2760@free.fr> References: <20080606184122.GC2760@free.fr> <20080606192314.GF2760@free.fr> Message-ID: 2008/6/6 Patrice Dumas : > On Fri, Jun 06, 2008 at 02:15:15PM -0500, Jason L Tibbitts III wrote: >> >>>>> "PD" == Patrice Dumas writes: >> >> PD> If the mail of the maintainer has changed, anybody noticing it >> PD> should attempt to contact the maintainer through another mean and >> PD> ask him to take care of changing his information in the >> PD> packagedb. >> >> Yeah, I have to agree, but even then we shouldn't need to go through a >> private investigator to track someone down. If all we have for >> someone is an email address, and mail to it bounces continuously for >> some period of time, then I'd suggest that we're done. > > I agree. Maybe it could be stated more precisely. Anybody can > propose something better, especially in term of language. Okay, this is fairly petty, but if we're talking language, possibly we should make sure it's "he or she" and so on ... :) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From pertusus at free.fr Fri Jun 6 22:44:02 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jun 2008 00:44:02 +0200 Subject: non responsive policy with invalid mail In-Reply-To: <200806061809.34427.sgrubb@redhat.com> References: <20080606184122.GC2760@free.fr> <200806061809.34427.sgrubb@redhat.com> Message-ID: <20080606224402.GJ2760@free.fr> On Fri, Jun 06, 2008 at 06:09:34PM -0400, Steve Grubb wrote: > On Friday 06 June 2008 14:41:22 Patrice Dumas wrote: > > If there is no known way of contacting the former maintainer, or he is not > > willing to make the required change in the packagedb, one should directly > > jump to the mail of the formal request to orphan all the packager packages > > to fedora-devel-list. > > What about the case where someone was terminated (which was not the case that > precipitated this thread)? Perhaps in that case the maintainer doesn't want > the whole world to know. How is that taken into account with this policy? I > think there are times when we have to respect that and have the ability to > replace maintainers without shouting to the world. There is no reason to give for stopping being a maintainer in fedora. Everything regarding maintainership (inactivity, mail not reaching anymore) is public anyway. As a side note, I am not saying that this policy should be applied to people @redhat, but for other fedora contributors there is a need for a policy like this one, and things have to be public. -- Pat From pertusus at free.fr Fri Jun 6 22:50:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jun 2008 00:50:46 +0200 Subject: non responsive policy with invalid mail In-Reply-To: References: <20080606184122.GC2760@free.fr> <20080606192314.GF2760@free.fr> Message-ID: <20080606225045.GK2760@free.fr> On Fri, Jun 06, 2008 at 11:17:42PM +0100, Mary Ellen Foster wrote: > > Okay, this is fairly petty, but if we're talking language, possibly we > should make sure it's "he or she" and so on ... :) I use the french rule which is to use the 'he', but I don't know what is the rule in english. Anyway I edited https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Coverage so anybody may change it now. -- Pat From pertusus at free.fr Fri Jun 6 22:51:19 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jun 2008 00:51:19 +0200 Subject: non responsive policy with invalid mail In-Reply-To: References: <20080606184122.GC2760@free.fr> Message-ID: <20080606225119.GL2760@free.fr> On Fri, Jun 06, 2008 at 02:15:15PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> If the mail of the maintainer has changed, anybody noticing it > PD> should attempt to contact the maintainer through another mean and > PD> ask him to take care of changing his information in the > PD> packagedb. > > Yeah, I have to agree, but even then we shouldn't need to go through a > private investigator to track someone down. If all we have for > someone is an email address, and mail to it bounces continuously for > some period of time, then I'd suggest that we're done. I added a paragraph to https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Coverage please modify as you like. -- Pat From alan at redhat.com Sat Jun 7 00:06:10 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 6 Jun 2008 20:06:10 -0400 Subject: non responsive policy with invalid mail In-Reply-To: <20080606184122.GC2760@free.fr> References: <20080606184122.GC2760@free.fr> Message-ID: <20080607000610.GD20075@devserv.devel.redhat.com> On Fri, Jun 06, 2008 at 08:41:22PM +0200, Patrice Dumas wrote: > I propose to add the following to the Non-responsive Maintainer Policy > (at the beginning): > > > If the mail of the maintainer has changed, anybody noticing it should > attempt to contact the maintainer through another mean and ask him to > take care of changing his information in the packagedb. If there is no > known way of contacting the former maintainer, or he is not willing to > make the required change in the packagedb, one should directly jump to > the mail of the formal request to orphan all the packager packages to > fedora-devel-list. I would suggest you always get *two* people from differing locations at the least to check the address is working. One person could just be going via a site with problems or in a spam blacklist. Probably that is "common sense" not policy 8) Alan From seg at haxxed.com Sat Jun 7 03:18:21 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 6 Jun 2008 22:18:21 -0500 Subject: nscd by default? In-Reply-To: References: Message-ID: <1218b5bc0806062018m575a9591t25d30aa72bdddc5d@mail.gmail.com> 2008/6/6 Colin Walters : > Per discussion here: > > http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00355.html > and followup here: > http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00409.html > > Is there a reason we aren't using nscd by default? > > I would say the current DNS situation is the most annoying desktop > networking-related bug in the OS. Or, as I think I point out somewhere in that thread, use dnsmasq which is designed to solve exactly this problem. And it even has a D-BUS interface. The only objection was something about DNSSEC. Which can always be fixed... Incidentally, it appears OLPC has adopted it to support its connection sharing. Though the main consideration there seems to be the fact that it's a much lighter weight dhcp server than ISC dhcpd... :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Sat Jun 7 09:43:53 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 Jun 2008 10:43:53 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <1212402716.16924.81.camel@pmac.infradead.org> References: <1212401125.30350.17.camel@cookie.hadess.net> <1212402716.16924.81.camel@pmac.infradead.org> Message-ID: <1212831833.32207.414.camel@pmac.infradead.org> On Mon, 2008-06-02 at 11:31 +0100, David Woodhouse wrote: > On Mon, 2008-06-02 at 11:05 +0100, Bastien Nocera wrote: > > Heya, > > > > I'm having trouble compiling the GStreamer V4L2 plugin on F10, when it > > work perfectly for the exact same source in F9. > > > > F10: > > http://koji.fedoraproject.org/koji/getfile?taskID=640403&name=build.log > > F9: > > http://koji.fedoraproject.org/koji/getfile?taskID=640384&name=build.log > > > > Any changes somebody knows of? > > Rather than a link to a huge text file, it might have been useful to > include the failure mode, which is this: > > v4l2_calls.c:268: error: 'V4L2_CID_HCENTER' undeclared (first use in this function) > v4l2_calls.c:268: error: (Each undeclared identifier is reported only once > v4l2_calls.c:268: error: for each function it appears in.) > v4l2_calls.c:269: error: 'V4L2_CID_VCENTER' undeclared (first use in this function) > > A few moments with git-annotate showed that the missing ioctls were > removed in commit 26d507fcfef7f7d0cd2eec874a87169cc121c835 This is now fixed upstream, so should turn up in the rawhide kernel-headers package next time we build a kernel. http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=39028ec6 These constants _are_ deprecated though, so anything which was affected by this should be removing them anyway. But that's no excuse for just dropping them without warning from the header file. -- dwmw2 From kanarip at kanarip.com Sat Jun 7 09:55:21 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 07 Jun 2008 11:55:21 +0200 Subject: Retiring Opyum In-Reply-To: References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> Message-ID: <484A5B09.3000207@kanarip.com> Kevin Kofler wrote: > The problem there is that gnome-packagekit has: > Provides: pirut = 1.3.30-3 Would a "Obsoletes: pirut" have been more accurate and appropriate here? Just thinking about ways we could maybe prevent this from happening again. -Jeroen From kevin.kofler at chello.at Sat Jun 7 10:34:35 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 7 Jun 2008 10:34:35 +0000 (UTC) Subject: Retiring Opyum References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> <484A5B09.3000207@kanarip.com> Message-ID: Jeroen van Meeuwen kanarip.com> writes: > Would a "Obsoletes: pirut" have been more accurate and appropriate here? There's both an Obsoletes and a Provides, the Obsoletes makes sense, the Provides not really, and it causes issues like this. Kevin Kofler From rawhide at fedoraproject.org Sat Jun 7 10:38:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 7 Jun 2008 10:38:45 +0000 (UTC) Subject: rawhide report: 20080607 changes Message-ID: <20080607103845.E93CF209CE6@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080606/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080607/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package cluttermm C++ wrapper for clutter library New package lua-expat SAX XML parser based on the Expat library New package python-sphinx Python documentation generator New package tktray System Tray Icon Support for Tk on X11 Updated Packages: apcupsd-3.14.4-2.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Tomas Smetana - 3.14.4-2 - drop useless build requirements - fix #448637 - hosts.conf and multimon.conf should be in apcupsd-cgi - move binaries to /sbin (related #346271) astromenace-1.2-9.fc10 ---------------------- * Fri Jun 6 18:00:00 2008 Jon Ciesla - 1.2-9 - Update to 080519 source release. - updated programmdir patch. authconfig-5.4.3-1.fc10 ----------------------- * Fri Jun 6 18:00:00 2008 Tomas Mraz - 5.4.3-1 - remove the --enableldapssl alias and add some help to GUI tooltips to clear up some confusion (#220973) - add option --enablepreferdns to prefer DNS over NIS or WINS in hostname resolution autoconf-2.62-2.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Karsten Hopp 2.62-2 - add upstream fix from Eric Blake for #449973, m4_if releated error message from autotest beagle-0.3.7-6.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Adel Gadllah - 0.3.7-6 - Remove no longer needed hardcoded requires - Rebuild for mono breakage bzip2-1.0.5-2.fc9 ----------------- * Thu Apr 10 18:00:00 2008 Ivana Varekova 1.0.5-2 - Resolves: #441775 fix libs link compiz-0.7.6-3.fc10 ------------------- compiz-fusion-0.7.6-2.fc10 -------------------------- * Fri Jun 6 18:00:00 2008 Adel Gadllah 0.7.6-2 - Fix script typo compiz-fusion-extras-0.7.6-2.fc10 --------------------------------- * Fri Jun 6 18:00:00 2008 Adel Gadllah 0.7.6-2 - Fix script typo conduit-0.3.11.1-1.fc10 ----------------------- * Fri Jun 6 18:00:00 2008 Michel Alexandre Salim - 0.3.11.1-1 - Update to 0.3.11.1 - Detect Firefox install path properly on 64-bit systems - Temporarily remove iPod and N800 modules due to gnome-vfs2 breakage coreutils-6.12-3.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Ondrej Vasik - 6.12-3 - workaround for koji failures(#449910, #442352) now preserves timestamps correctly - fallback to supported functions, added test case - runuser binary is no longer doubled in /usr/bin/runuser * Wed Jun 4 18:00:00 2008 Ondrej Vasik - 6.12-2 - workaround for strange koji failures(#449910,#442352) - fixed ls -ZC segfault(#449866, introduced by 6.10-1 SELinux patch reworking) * Mon Jun 2 18:00:00 2008 Ondrej Vasik - 6.12-1 - New upstream release 6.12, adapted patches * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 6.11-5 - fix SHA256/SHA512 to work on sparc dbus-qt3-0.9-1.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Rex Dieter 0.9-1 - dbus-1-qt3-0.9 - Provides: dbus-1-qt3 dovecot-1.0.14-3.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Dan Horak - 1:1.0.14-3 - build devel subpackage (Resolves: #306881) evolution-2.23.3.1-3.fc10 ------------------------- * Fri Jun 6 18:00:00 2008 Matthew Barnes - 2.23.3.1-3.fc10 - Remove the gnome-spell requirement. * Wed Jun 4 18:00:00 2008 Matthew Barnes - 2.23.3.1-2.fc10 - Add patches for RH bug #449925 (buffer overflow vulnerabilities). fedora-ds-base-1.1.1-2.fc10 --------------------------- * Fri Jun 6 18:00:00 2008 Rich Megginson - 1.1.1-2 - bump rev to rebuild and pick up new version of ICU file-4.24-4.fc10 ---------------- * Fri Jun 6 18:00:00 2008 Tomas Smetana - 4.24-4 - add GFS2 filesystem magic; thanks to Eric Sandeen - add LVM snapshots magic (#449755); thanks to Jason Farrell flam3-2.7.13-1.fc10 ------------------- * Sat Jun 7 18:00:00 2008 Ian Weller 2.7.13-1 - Upstream updated fuse-s3fs-0.7-1.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Neil Horman 0.7-1 - Update to upstream (fixing potential zero size file error) fwbackups-1.43.2-0.2.rc2.fc10 ----------------------------- * Fri Jun 6 18:00:00 2008 Stewart Adam 1.43.2-0.2.rc2 - BR: python-paramiko galeon-2.0.5-3.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Denis Leroy - 2.0.5-2 - Rebuild for new gnome-desktop - Fixed gecko BR * Fri Jun 6 18:00:00 2008 Caol??n McNamara - 2.0.5-3 - add galeon-2.0.5-build-fix.patch like epiphany build-fix hplip-2.8.5-2.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Tim Waugh 2.8.5-2 - Make --qt4 the default for the systray applet, so that it appears in the right place. Requires PyQt4. kdeedu-4.0.80-5.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Kevin Kofler 4.0.80-5 - BR OpenBabel 2.2.0 beta5, drop build fix hack for beta 4 kdevelop-3.5.2-2.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Kevin Kofler - 9:3.5.2-2 - improve integration of the KDE 4 app template kernel-2.6.26-0.56.rc5.git2.fc10 -------------------------------- * Fri Jun 6 18:00:00 2008 Chuck Ebbert - 2.6.26-rc5-git2 * Thu Jun 5 18:00:00 2008 Dave Jones - 2.6.26-rc5 kismet-0.0.2007.10.R1-4.fc10 ---------------------------- * Fri Jun 6 18:00:00 2008 Caol??n McNamara - 0.0.2007.10.R1-4 - tweak configure to use -lMagickCore not -lMagick to rebuild for dependancies koan-1.0.1-1.fc10 ----------------- * Fri Jun 6 18:00:00 2008 Michael DeHaan - 1.0.1-1 - Upstream changes (see CHANGELOG) libaio-0.3.107-2 ---------------- * Thu Jun 5 18:00:00 2008 Jeff Moyer - 0.3.107-2 - Update to the latest upstream which adds eventfd support and fixes broken test cases. (Rusty Russell) libcap-2.10-2.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Karsten Hopp 2.10-2 - drop libcap.so.1 - fix buildrequires and path to pam security module * Thu Jun 5 18:00:00 2008 Karsten Hopp 2.10-1 - libcap-2.10 libmp4v2-1.5.0.1-6.fc10 ----------------------- lsvpd-1.6.4-2.fc10 ------------------ * Fri Jun 6 18:00:00 2008 - Caol??n McNamara - 1.6.4-2 - rebuild for dependancies m2crypto-0.18.2-5 ----------------- * Sat Jun 7 18:00:00 2008 Miloslav Trma?? - 0.18.2-5 - Use User-Agent in HTTP proxy CONNECT requests Related: #448858 mbuffer-20080507-2.fc10 ----------------------- * Fri Jun 6 18:00:00 2008 Dennis Gilmore - 20080507-2 - fix license tag * Fri Jun 6 18:00:00 2008 Dennis Gilmore - 20080507-1 - update to 20080507 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 20070502-2 - Autorebuild for GCC 4.3 mrtg-2.16.1-3.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Vitezslav Crhonek - 2.16.1-3 - Add gd graphic library to Requires Resolves: #446533 nant-0.85-21.fc10 ----------------- * Fri Jun 6 18:00:00 2008 Caol??n McNamara - 1:0.85-21 - rebuild for dependancies nfs-utils-1.1.2-6.fc10 ---------------------- * Fri Jun 6 18:00:00 2008 Steve Dickson 1.1.2-6 - Added 5 (111 thru 115) upstream patches that fixed things mostly in the text mounting code. nickle-2.67-1.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Michel Alexandre Salim - 2.67-1 - Update to 2.67 openarena-0.7.7-2.fc10 ---------------------- * Fri Jun 6 18:00:00 2008 Micha?? Bentkowski - 0.7.7-2 - Fix permissions... openbabel-2.2.0-0.5.b5.fc10 --------------------------- * Fri Jun 6 18:00:00 2008 Kevin Kofler 2.2.0-0.5.b5 - backport upstream patch to split Python binding (should fix #427700 for good) - drop no longer needed ppc64 SWIG/GCC flag hackery * Thu May 29 18:00:00 2008 Kevin Kofler 2.2.0-0.4.b5 - update to 2.2.0 beta5 * Fri May 9 18:00:00 2008 Kevin Kofler 2.2.0-0.3.b4 - generate Python binding with -fastdispatch on F9+ ppc64 (#427700) - add -mno-sum-in-toc to optflags on F9+ ppc64 (#427700) openswan-2.6.14-1.fc10 ---------------------- * Fri Jun 6 18:00:00 2008 Steve Grubb - 2.6.14-1 - new upstream release perl-5.10.0-25.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Marcela Maslanova 4:5.10.0-25 - 449577 rebuild for FTBFS perl-Math-GMP-2.04-10.fc10 -------------------------- * Fri Jun 6 18:00:00 2008 Paul Howarth 2.04-10 - Apply 64-bit testsuite-fixing patch on sparc64 too perl-Module-Depends-0.14-1.fc10 ------------------------------- * Fri Jun 6 18:00:00 2008 Ian Burrell - 0.14-1 - Update to 0.14 pkgconfig-0.23-3.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Colin Walters - 1:0.23-3 - Readd the requires.private fix that was dropped prematurely postgresql-odbcng-0.90.101-2.fc10 --------------------------------- * Fri Jun 6 18:00:00 2008 Devrim GUNDUZ - 0.90.101-2 - Fix debuginfo issue, per review. python-gasp-0.2.0beta1-1.fc10 ----------------------------- * Thu Jun 5 18:00:00 2008 Bernie Innocenti - 0.2.0beta1-1 - Rename "python-pygame" dependency to "pygame". * Sat Mar 22 18:00:00 2008 ffm - 0.2.0beta1-0 - Rewrote some of the api, broke backward compatability. - Speed increases - Removed wait() - end_graphics() no calls thread.isAlive() to make sure it does not quit intill the thread is dead. - Rewrote tests - See http://launchpad.net/gasp-code for the full list of changes qgis-0.10.0-2.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Caol??n McNamara - 0.10.0-2 - add openssl BuildDepend to rebuild for dependancies qt-4.4.0-6.fc10 --------------- * Fri Jun 6 18:00:00 2008 Rex Dieter 4.4.0-6 - qt-copy-patches-20080606 - drop BR: libungif-devel (not used) - move libQtXmlPatters, -x11 -> main - move qdbuscpp2xml, qdbusxml2cpp, xmlpatters, -x11 -> -devel rkward-0.5.0b-7.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Pingou 0.5.0b-7 - Correct a typo in files * Fri Jun 6 18:00:00 2008 Pingou 0.5.0b-6 - Correct the files section for the icons * Fri Jun 6 18:00:00 2008 Pingou 0.5.0b-5 - Correct version * Fri Jun 6 18:00:00 2008 Pingou 0.5.0b-4 - Correct typo in changelog * Fri Jun 6 18:00:00 2008 Pingou 0.5.0b-3 - Rebuild rlog-1.3.7-7.fc10 ----------------- * Fri Jun 6 18:00:00 2008 Peter Lemenkov 1.3.7-7 - Get rid of whitespaces (cosmetic) - Note about patch status (applied upstream) sectool-0.7.6-1.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Peter Vrabec - 0.7.6-1 - upgrade showimg-0.9.5-18.fc10 --------------------- * Thu Jun 5 18:00:00 2008 Aurelien Bompard 0.9.5-18 - fix build * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.9.5-17 - Autorebuild for GCC 4.3 star-1.5a84-6.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Dennis Gilmore 1.5a84-6 - add sparcv9 support syck-0.61-5.1.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Oliver Falk - 0.61-5.1 - Add syck.ini to files * Fri Jun 6 18:00:00 2008 Oliver Falk - 0.61-5 - Rebuild to fix bug #447561 - Add syck.ini telepathy-glib-0.7.10-1.fc10 ---------------------------- * Fri Jun 6 18:00:00 2008 Brian Pepple - 0.7.10-1 - Update 0.7.10. translate-toolkit-1.1.1-1.fc10 ------------------------------ * Fri Jun 6 18:00:00 2008 Roozbeh Pournader - 1.1.1-1 - update to 1.1.1 tuxcmd-0.6.36-2.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Tomas Bzatek 0.6.36-2 - Add modules (gnome-vfs2, libarchive) xastir-1.9.2-7.fc10 ------------------- * Fri Jun 6 18:00:00 2008 Lucian Langa - 1.9.2-7 - Rebuild against gpsman, festival, Berkley DB, gdal xenner-0.36-1.fc10 ------------------ * Fri Jun 6 18:00:00 2008 Gerd Hoffmann - 0.36-1.fc10 - update to version 0.36 - lots of little fixes and tweaks. xfce4-mailwatch-plugin-1.0.1-9.fc10 ----------------------------------- * Fri Jun 6 18:00:00 2008 Christoph Wickert - 1.0.1-9 - BuildRequire libXt-devel for all releases (#449496) Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 59 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From rjones at redhat.com Sat Jun 7 10:43:53 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 7 Jun 2008 11:43:53 +0100 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> Message-ID: <20080607104353.GA32483@amd.home.annexia.org> On Fri, Jun 06, 2008 at 11:34:04AM -0400, Colin Walters wrote: > On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones > wrote: > > One major reason is that it allows languages to be mixed and to call > > easily from one language to another. Free software dropped the ball > > on this (Parrot), and Mono/.Net is the only widely available > > implementation of this idea. > > It was *marketed* as such, but in fact many different languages have run on > the JVM for a long time: > http://www.robert-tolksdorf.de/vmlanguages.html > Some of them date to 1996. This is getting pretty tedious. In brief, the JVM has design issues that make implementing non-Java-like languages hard and/or slow. The particular issues are: lack of good support for closures, lack of polymorphic types (affects dynamically typed languages in particular, but also functional languages), maximum method size, inability to handle tail call optimization in mutually recursive functions (a serious concern in functional languages), large overhead per object and lack of unboxing, hideous native code interface, lack of dynamic method invocation, lack of eval, lack of efficient tuples, lack of continuations (eg for Scheme). Some of these are fixed in JSRs, but the process is incredibly slow and I'm not aware of any fixes that actually ship in a JVM. Of course the JVM is Turing complete, so it is possible to implement any programming language on the JVM, but that doesn't necessarily mean it's going to be fast or good or allow you to practically call from any language to any language. > Practically speaking there are many modern languages available such as > Objective Caml: http://ocamljava.x9c.fr/ ... if you give up all the native OCaml libraries, duck typing, multiple inheritence, 64 bit ints, immediate objects, and a bunch of other stuff. > Ruby: http://jruby.codehaus.org/ > Python: http://jython.org/Project/ Described here as "a slower slightly more out of date version of Python, with fewer libraries" / "At this moment, writing libraries in Jython that would be in an attempt to make them usable to Jruby and Groovy folks seems like a fools errand." http://compoundthinking.com/blog/index.php/2008/02/27/jvm-as-platform-for-dynamic-languages/ > Scala: http://www.scala-lang.org/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From bnocera at redhat.com Sat Jun 7 14:18:21 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 07 Jun 2008 15:18:21 +0100 Subject: Kernel headers changes in F10? In-Reply-To: <1212831833.32207.414.camel@pmac.infradead.org> References: <1212401125.30350.17.camel@cookie.hadess.net> <1212402716.16924.81.camel@pmac.infradead.org> <1212831833.32207.414.camel@pmac.infradead.org> Message-ID: <1212848301.5472.30.camel@cookie.hadess.net> On Sat, 2008-06-07 at 10:43 +0100, David Woodhouse wrote: > This is now fixed upstream, so should turn up in the rawhide > kernel-headers package next time we build a kernel. > > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=39028ec6 > > These constants _are_ deprecated though, so anything which was affected > by this should be removing them anyway. But that's no excuse for just > dropping them without warning from the header file. I fixed the uses of those deprecated defines in gstreamer-plugins-good in rawhide, as well as upstream: http://bugzilla.gnome.org/show_bug.cgi?id=536317 Cheers From walters at verbum.org Sat Jun 7 18:21:23 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 7 Jun 2008 14:21:23 -0400 Subject: Firefox and Moonlight (Mono) "Free Software" Status? In-Reply-To: <20080607104353.GA32483@amd.home.annexia.org> References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> <20080607104353.GA32483@amd.home.annexia.org> Message-ID: On Sat, Jun 7, 2008 at 6:43 AM, Richard W.M. Jones wrote: > On Fri, Jun 06, 2008 at 11:34:04AM -0400, Colin Walters wrote: > > On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones > > wrote: > > > One major reason is that it allows languages to be mixed and to call > > > easily from one language to another. Free software dropped the ball > > > on this (Parrot), and Mono/.Net is the only widely available > > > implementation of this idea. > > > > It was *marketed* as such, but in fact many different languages have run > on > > the JVM for a long time: > > http://www.robert-tolksdorf.de/vmlanguages.html > > Some of them date to 1996. > > This is getting pretty tedious. And offtopic for fedora-devel. But, it's a more interesting discussion than a complaint thread about nVidia drivers =) > In brief, the JVM has design issues > that make implementing non-Java-like languages hard and/or slow. That's a rather sweeping generalization, which seems to have Clojure ( http://clojure.sourceforge.net/), Scala, and JRuby all as counterexamples. Clojure in particular is wildly different from Java. Whether it was hard to implement is unknown, but the author is from what I've seen an incredibly smart person. > The > particular issues are: lack of good support for closures, Closures are a language level construct - once you have garbage collection in the runtime they're easy, and most of the new JVM languages do have nice syntax for anonymous inline closures. What exactly you mean by "good support" is hard to say. > lack of > polymorphic types (affects dynamically typed languages in particular, > but also functional languages), Er...isn't the object system polymorphic? Are you talking about multiple dispatch? inability to > handle tail call optimization in mutually recursive functions (a > serious concern in functional languages), This one is http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm I believe. hideous native code interface, Reaching out and touching libc from the JVM, interactively: Groovy Shell (1.5.6, JVM: 1.6.0-b09) Type 'help' or '\h' for help. ------------------------------------------------------------------------------------- groovy:000> import com.sun.jna.* groovy:000> CLibrary ===> interface CLibrary groovy:000> CLibrary.INSTANCE ===> Proxy interface to Native Library groovy:000> public interface CLibrary extends Library { groovy:001> CLibrary INSTANCE = (CLibrary)Native.loadLibrary("c", CLibrary.class); groovy:002> long clock(); groovy:003> } ===> true groovy:000> CLibrary.INSTANCE.clock() ===> 6420000 groovy:000> CLibrary.INSTANCE.clock() ===> 6460000 lack of dynamic > method invocation, What does that mean? > lack of eval, If any sane application relies on eval it's probably broken, but really once you have a language it's trivial to implement eval, because you probably already have an interactive toplevel which takes strings and turns them into code. Where are you getting this list from? > lack of efficient tuples, Right, I don't think this one is "soon" but it will likely happen; http://blogs.sun.com/jrose/entry/tuples_in_the_vm > lack of > continuations (eg for Scheme). Realistically, I doubt there are many real-world Scheme programs out there that actually make *full* use of call/cc, as opposed to indirectly using it by calling into a e.g. green threading library which is implemented with call/cc. Not that there aren't interesting things one can do with full continuations; the RIFE framework ( http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations) has some examples. That said, this one has a working prototype already: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/callcc.patch > Some of these are fixed in JSRs, but > the process is incredibly slow and I'm not aware of any fixes that > actually ship in a JVM. These things change slowly, that's true. Of course the JVM is Turing complete, so it is possible to implement > any programming language on the JVM, but that doesn't necessarily mean > it's going to be fast or good or allow you to practically call from > any language to any language. > > > Practically speaking there are many modern languages available such as > > Objective Caml: http://ocamljava.x9c.fr/ > > ... if you give up all the native OCaml libraries, Sure, but if we're talking about the JVM versus .NET, you also have to give those up. > duck typing, multiple inheritence, 64 bit ints, immediate objects, and a > bunch of other stuff. It's not clear to me those are fundamental tradeoffs vs just not implemented for some reason - e.g. what would blocking using "long" for 64 bit ints? Duck typing shouldn't be that hard. > > > Ruby: http://jruby.codehaus.org/ > > Python: http://jython.org/Project/ > > Described here as "a slower slightly more out of date version of > Python, with fewer libraries" / "At this moment, writing libraries in > Jython that would be in an attempt to make them usable to Jruby and > Groovy folks seems like a fools errand." > > http://compoundthinking.com/blog/index.php/2008/02/27/jvm-as-platform-for-dynamic-languages/ > There is largely never going to be a clean automatic way to do cross-nonnative language calls. Here by nonnative I mean languages which were designed to run on a custom runtime (not JVM/.NET). For example, Python strings are immutable, Ruby strings are mutable; if you were to pass a Python string into a Ruby function it couldn't act exactly like a Ruby string. The corner cases get even more bizarre once you start to look at more languages and more data types. The more compelling long-term direction behind the JVM and .NET is taking the *good* things from different languages (e.g. OCaml's type inference and pattern matching, Python's clean syntax, generators) and throwing out the bad stuff (non-Unicode strings, bizarre/broken class models) and creating new languages that are native to the runtime; Microsoft has done this to OCaml with F#, Groovy is a much nicer and more strongly integrated dynamic language than Python/Ruby, etc. Anyways, the point I wanted to refute is this: > > Free software dropped the ball > > on this (Parrot), and Mono/.Net is the only widely available > > implementation of this idea. And I believe that's been done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Sat Jun 7 20:05:04 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 7 Jun 2008 21:05:04 +0100 Subject: Mixing code in different languages (was: Re: Firefox and Moonlight (Mono) "Free Software" Status?) In-Reply-To: References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> <20080607104353.GA32483@amd.home.annexia.org> Message-ID: <20080607200504.GA2777@amd.home.annexia.org> On Sat, Jun 07, 2008 at 02:21:23PM -0400, Colin Walters wrote: > > lack of dynamic > > method invocation, > What does that mean? JSR 292 (http://jcp.org/en/jsr/detail?id=292) and the invokedynamic bytecode. If I understand it correctly, it lets you call a method where you don't know the method type until late at runtime. > Where are you getting this list from? Actually from Xavier Clerc, the extraordinarily talented author of ocamljava, and from looking at the codegen in ocamljava. > > duck typing, multiple inheritence, 64 bit ints, immediate objects, and a > > bunch of other stuff. > > It's not clear to me those are fundamental tradeoffs vs just not implemented > for some reason - e.g. what would blocking using "long" for 64 bit ints? OK, so that bit didn't come out right. Ocamljava implements OCaml as if it was running on a 32 bit processor. I admit I'm not entirely sure why this is, but it creates some annoying limitations (string length is limited to 16 MB in particular, which sucks). Of course there is an int64 type. > Anyways, the point I wanted to refute is this: > > > > Free software dropped the ball > > > on this (Parrot), and Mono/.Net is the only widely available > > > implementation of this idea. > > And I believe that's been done. Actually I think I stand by my original statement all the more. Free software _doesn't_ offer an alternative. OK, it's possible to run some mixed languages on the JVM. But it's not practical -- you can't practically write a Jython library called by an OCamljava main program [substitute your favorite languages here as appropriate]. Mono/.Net _is_ the only widely available practical implementation (unfortunately). On a more constructive note though, what would it take? I think your comment here was very insightful: > There is largely never going to be a clean automatic way to do > cross-nonnative language calls. Here by nonnative I mean languages which > were designed to run on a custom runtime (not JVM/.NET). For example, > Python strings are immutable, Ruby strings are mutable; if you were to pass > a Python string into a Ruby function it couldn't act exactly like a Ruby > string. The corner cases get even more bizarre once you start to look at > more languages and more data types. > > The more compelling long-term direction behind the JVM and .NET is taking > the *good* things from different languages (e.g. OCaml's type inference and > pattern matching, Python's clean syntax, generators) and throwing out the > bad stuff (non-Unicode strings, bizarre/broken class models) and creating > new languages that are native to the runtime; Microsoft has done this to > OCaml with F#, Groovy is a much nicer and more strongly integrated dynamic > language than Python/Ruby, etc. So what's the answer here? Do we: - Have a big effort to root out prior art for every patent MSFT has applied for in the past 17 years so we can prove Mono is non-infringing? - Work on ironing out all the practical problems with the JVM, perhaps _forking_ the JVM and adding our own bytecodes if Sun is slow or non-responsive? - Kick some resources towards making an open source project like Parrot work and then a huge amount more resources towards porting all the languages to it? - Define C as our "common runtime" and make language <-> C generators for everything that work really well (basically what I did when I wrote http://merjis.com/developers/perl4caml)? This is a serious question. Certain groups of users I've talked to like OCaml, but don't want to write whole programs in OCaml (or want to use their existing libraries with it). Unfortunately for everyone F# is being seen as a practical solution to their problem, which means they're locked into a proprietary language on a proprietary operating system. As a user of a minority language, I'm keenly aware of this problem and I've been thinking hard about it for many years now. Perl4caml was my initial answer to the problem (several years ago) that OCaml lacked lots of libraries [use perl4caml == access all of CPAN]. Wish I had a good answer to the general question though. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From walters at verbum.org Sat Jun 7 21:47:31 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 7 Jun 2008 17:47:31 -0400 Subject: Mixing code in different languages (was: Re: Firefox and Moonlight (Mono) "Free Software" Status?) In-Reply-To: <20080607200504.GA2777@amd.home.annexia.org> References: <568556.62702.qm@web52407.mail.re2.yahoo.com> <20080606081156.GA15125@amd.home.annexia.org> <20080607104353.GA32483@amd.home.annexia.org> <20080607200504.GA2777@amd.home.annexia.org> Message-ID: On Sat, Jun 7, 2008 at 4:05 PM, Richard W.M. Jones wrote: Actually I think I stand by my original statement all the more. Free > software _doesn't_ offer an alternative. OK, it's possible to run > some mixed languages on the JVM. But it's not practical -- you can't > practically write a Jython library called by an OCamljava main program > [substitute your favorite languages here as appropriate]. Mono/.Net > _is_ the only widely available practical implementation > (unfortunately). Ah, I think this discussion started from a misconception then. As far as I know, .NET does not easily let you consume arbitrary Python libraries from OCaml/F#, or vice versa. I don't see how it would. The two are wildly different - Python's object model is "everything is a hash table!", which is not the same as .NET's object. The way to think of this is that IronPython is really its own world on *top* of .NET; just the same for Jython and the JVM. Practically speaking in this case too, Python has no facility to declare types even around interface boundaries, so everything you pass in or out would have to be represented in OCaml as PythonValue or something, with methods like get_int(), get_attribute()...yuck! More generally the goal of .NET was not to somehow automagically make any arbitrary (particularly non-native as defined before) language X be able to use any language Y easily. The goal is more practical - sharing a garbage collector, JIT, and standard library. This enables a pattern where the core is programmed in the native system language (Java/C#), but those libraries can be consumed by other languages, for scripting, DSLs, templating, etc. And that's the exact same thing the JVM provides, and really that the bytecode/JVM model has provided for over a decade. Don't get me wrong, .NET added a few things like tuples and continuations, but the two systems are much closer than they are different; the main differentiator in my opinion has mostly just been marketing (which is admittedly very important). This is a good blog entry on this model: http://ola-bini.blogspot.com/2008/06/fractal-programming.html This is a serious question. Certain groups of users I've talkd to > like OCaml, but don't want to write whole programs in OCaml (or want > to use their existing libraries with it). Unfortunately for everyone > F# is being seen as a practical solution to their problem, which means > they're locked into a proprietary language on a proprietary operating > system. Sure. That was the motivating factor behind OCamlJava it appears from the web page. But again, there is no magic cross-language anything-can-call-anything now or in the future, and if you thought .NET provided that I believe you've been oversold. The forseeable future is multi-runtime. .NET and the JVM are both very widely deployed at this point and are key to major operating system vendors. CPython in particular is going to be around a long time; its age, liberal licensing, low barrier to entry, and ease of binding to C have made it pervasive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aoliva at redhat.com Sat Jun 7 22:22:56 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 07 Jun 2008 19:22:56 -0300 Subject: Fedora Freedom and linux-libre Message-ID: FYI and FTR -------------- next part -------------- An embedded message was scrubbed... From: Alexandre Oliva Subject: Re: [Ksummit-2008-discuss] RFC: Moving firmware blobs out of the kernel. Date: Sat, 07 Jun 2008 19:14:33 -0300 Size: 7904 URL: From giallu at gmail.com Sat Jun 7 22:30:00 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 8 Jun 2008 00:30:00 +0200 Subject: How to handle subpackages with missing dependencies In-Reply-To: <1212696386.9544.23.camel@senator.homenet> References: <1212696386.9544.23.camel@senator.homenet> Message-ID: 2008/6/5 Alexander Kahl : > one subpackage needs php-sqlite which has been deactivated in favor of > php-pdo's sqlite support, If that module has a reason for requiring php-sqlite and no upstream has no plans to move it to use php-pdo, then I guess it's better to not package it > another one depends on php-pecl-ibm_db2 no one > has packaged yet If it has an acceptable license you could submit that one for review as well. if you do not feel like maintaining one more package, do not package this > and the last one depends on php-oci8 which cannot be > provided at all because it is proprietary software. Well, it seems the php package is compiled with MSSQL support, which is no more open source than Oracle... I'm not sure why php-oci8 is not in packaged, but of course you can't activate this subpackage until the situation changes. All in all, I think that for all these three subpackages you can avoid building them without a significant impact on the framework feature set. You can provide a simple method for rebuilding the SRPM with those skipped parts, but that's really up to you. just my 0.02 From aoliva at redhat.com Sat Jun 7 22:31:47 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 07 Jun 2008 19:31:47 -0300 Subject: Fedora Freedom and Linux-libre (was: Re: Plan for tomorrows (20080522) FESCO meeting) In-Reply-To: <483C5EEA.6010200@redhat.com> (Peter Jones's message of "Tue\, 27 May 2008 15\:20\:10 -0400") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> <483C5EEA.6010200@redhat.com> Message-ID: On May 27, 2008, Peter Jones wrote: > Alexandre Oliva wrote: > You are largely ignoring the infrastructure around installation and > upgrades of multiple kernels. I realize there may be work in anaconda that's not as simple as the approach recently taken by BLAG (a kernel package that's empty, and only Requires: kernel-libre), but do you have anything else in mind? Maybe configuring yum to retain a sufficient number of kernel-libre packages installed and avoid removing the running version from under itself? grepping for PAE, debug, xen et al should make these quite easy to locate this and any others, and extend them to kernel-libre. Once it's done, I guess it's even more negligible than the effort I currently put into Linux-libre. No biggie. > If the goal is allowing users to > install and use a system without any of the non-free firmware > (assuming that's even plausible for our hypothetical user), http://www.blog.tdobson.net/node/172 may be quite enlightening for the FUD-slingers who oppose this kind of move. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From tcallawa at redhat.com Sat Jun 7 23:43:58 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 07 Jun 2008 19:43:58 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: Message-ID: <1212882238.3269.9.camel@localhost.localdomain> I know this is flame bait, and we're obviously missing some context, but it seems very much like you threw a temper tantrum at the first sign of trouble, screamed "I TOLD YOU NO ONE HERE WANTS TO BE FREE" and ran home. Did you put up your patches without the rhetoric (through whatever inane obfuscation you needed)? Were they rejected? ~spot From lemenkov at gmail.com Sun Jun 8 03:51:19 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 8 Jun 2008 07:51:19 +0400 Subject: Cannot login to Fedora Wiki Message-ID: Hello All! Seems that I forgot my login information - all my attempts to login were failed. But I can't find link to recover forgotten password. Maybe I missed something? -- With best regards! From lemenkov at gmail.com Sun Jun 8 03:55:25 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 8 Jun 2008 07:55:25 +0400 Subject: Cannot login to Fedora Wiki In-Reply-To: References: Message-ID: Oh, I'm just logging in. Sorry for noise. -- With best regards! From lemenkov at gmail.com Sun Jun 8 06:30:28 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 8 Jun 2008 10:30:28 +0400 Subject: Some highlights about MediaWiki for noobs :) Message-ID: Hello All! Seems that some folks didn't know yet about wolderful features, provided to us by MediaWiki. Some of them: * Redirection pages. Almost all of us already have old userpages, but after migrating to MediaWiki we all got new ones, named differently. For sake of simplicity, you don't need to copypaste text from old page to new (or vice versa) - just add redirection. For example, user Peter has old page [[PeterLemenkov]]. He wants to merge the former and the latter. For doint this he just edits page [[Peter]] and adds the only message: #REDIRECT [[PeterLemenkov]] Thats all - every visitor of page [[Peter]] will be redirected to [[PeterLemenkov]]. See latest edits - I already fixed som pages. * Rich set of special pages. https://fedoraproject.org/wiki/Special:Specialpages Feel free to explore them. Among them you may find List of users: https://fedoraproject.org/wiki/Special:Listusers Recent changes: https://fedoraproject.org/wiki/Special:Recentchanges Broken redirections: https://fedoraproject.org/wiki/Special:BrokenRedirects Wanted pages: https://fedoraproject.org/wiki/Special:Wantedpages (some of these wanted pages are made by mistakes, probably) Link: [[LinkInFedoraWiki|Human readable name]] [http://www.example.com external link] You may vary link labes in the following way [[FedoraLink]]s. (Note trailing 's'). As a adwanced mediawiki-user (since I'm an active contributor to http://anticopyright.ru wiki-project) I will hope that this my little post will be useful for those who has limited experience using Wiki :) -- With best regards! From lemenkov at gmail.com Sun Jun 8 06:36:18 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 8 Jun 2008 10:36:18 +0400 Subject: Some highlights about MediaWiki for noobs :) In-Reply-To: References: Message-ID: 2008/6/8 Peter Lemenkov : > * Redirection pages. Almost all of us already have old userpages, but > after migrating to MediaWiki we all got new ones, named differently. > For sake of simplicity, you don't need to copypaste text from old page > to new (or vice versa) - just add redirection. For example, user Peter > has old page [[PeterLemenkov]]. He wants to merge the former and the > latter. For doint this he just edits page [[Peter]] and adds the only > message: > > #REDIRECT [[PeterLemenkov]] > > Thats all - every visitor of page [[Peter]] will be redirected to > [[PeterLemenkov]]. See latest edits - I already fixed som pages. Pages, which are good candidates for merging, can be found there: List of users: https://fedoraproject.org/wiki/Special:Listusers List of lonely pages: https://fedoraproject.org/wiki/Special:Lonelypages I found that many users still didn't link their new login-name with their old personal pages. -- With best regards! From dtimms at iinet.net.au Sun Jun 8 08:40:46 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 08 Jun 2008 18:40:46 +1000 Subject: non responsive policy with invalid mail In-Reply-To: <20080606225119.GL2760@free.fr> References: <20080606184122.GC2760@free.fr> <20080606225119.GL2760@free.fr> Message-ID: <484B9B0E.8000000@iinet.net.au> Patrice Dumas wrote: > https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Coverage > please modify as you like. Pat: ==== What is the attempted meaning of this bit: "and cannot be joined (with reasonable effort)," is it _contacted_ ? ==== I wasn't sure what the following meant: ", one should directly jump to the mail of the formal request to orphan all the packager packages to fedora-devel-list." , until I read the whole page, so this might be tidier: ", one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4." I didn't want to repeat the content of the steps, yet there is no numbering or anchor? to link to. David Timms. From bbbush.yuan at gmail.com Sun Jun 8 08:55:54 2008 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 8 Jun 2008 16:55:54 +0800 Subject: Some highlights about MediaWiki for noobs :) In-Reply-To: References: Message-ID: <76e72f800806080155k9332523sb408457eb6ce9764@mail.gmail.com> 2008/6/8 Peter Lemenkov : > Hello All! > Seems that some folks didn't know yet about wolderful features, > provided to us by MediaWiki. > Hi, Then I'd thanks if you can solve my little problem here? http://bbbush.livejournal.com/268337.html -- bbbush ^_^ From dwmw2 at infradead.org Sun Jun 8 09:38:12 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jun 2008 10:38:12 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212882238.3269.9.camel@localhost.localdomain> References: <1212882238.3269.9.camel@localhost.localdomain> Message-ID: <1212917892.32207.488.camel@pmac.infradead.org> On Sat, 2008-06-07 at 19:43 -0400, Tom "spot" Callaway wrote: > I know this is flame bait, and we're obviously missing some context, > but it seems very much like you threw a temper tantrum at the first > sign of trouble, screamed "I TOLD YOU NO ONE HERE WANTS TO BE FREE" > and ran home. > > Did you put up your patches without the rhetoric (through whatever > inane obfuscation you needed)? Were they rejected? No, I did it all: git.infradead.org/users/dwmw2/firmware-2.6.git (well, not _all_ -- there are more drivers to convert. Help wanted!) It wasn't rejected -- it's in the linux-next tree and should be going in to 2.6.27. One we finish converting the drivers, we should have the capacity to rip _all_ the firmware blobs out of the kernel without permanently losing functionality. At that point, we can at least have the _discussion_ about removing those blobs from the kernel source tree and putting them in a separate repository, without it being pie-in-the-sky. Alex now says it isn't good enough, and is actually counter-productive. -- dwmw2 From rawhide at fedoraproject.org Sun Jun 8 09:53:15 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 8 Jun 2008 09:53:15 +0000 (UTC) Subject: rawhide report: 20080608 changes Message-ID: <20080608095315.4B8CE209CEE@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080607/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080608/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff Updated Packages: Falcon-0.8.10-1.fc10 -------------------- * Sat Jun 7 18:00:00 2008 Michel Alexandre Salim - 0.8.10-1 - Update to 0.8.10 afflib-3.2.1-1.fc10 ------------------- * Sat Jun 7 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.1-1 - Update to 3.2.1 audacious-1.5.1-1.fc10 ---------------------- * Sat Jun 7 18:00:00 2008 Ralf Ertzinger 1.5.1-1 - Update to 1.5.1 * Mon Apr 7 18:00:00 2008 Ralf Ertzinger 1.5.0-1 - Update to 1.5.0 basket-1.0.2-7.fc10 ------------------- * Sat Jun 7 18:00:00 2008 Kevin Kofler 1.0.2-7 - disable -kontact for F10+ (can't integrate KDE 3 app into KDE 4 Kontact) * Sun Jun 1 18:00:00 2008 Aurelien Bompard 1.0.2-6 - rebuild cairo-dock-1.6.0-0.1.svn1085_trunk.fc10 --------------------------------------- * Sun Jun 8 18:00:00 2008 Mamoru Tasaka - svn 1085 compizconfig-python-0.7.6-1.fc10 -------------------------------- * Sat Jun 7 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-1 - 0.7.6 update enblend-3.1-0.5.20080529cvs.fc10 -------------------------------- * Thu Jun 5 18:00:00 2008 Bruno Postle - 3.1-0.5.20080529cvs - Add OpenEXR-devel build dependency * Thu May 1 18:00:00 2008 Bruno Postle - 3.1-0.4.20080529cvs - CVS snapshot with GCC 4.3 upstream fix eric-4.1.5-1.fc10 ----------------- * Sat Jun 7 18:00:00 2008 Johan Cwiklinski 4.1.5-1 - 4.1.5 hal-info-20080607-1.fc10 ------------------------ * Sat Jun 7 18:00:00 2008 Dan Williams - 20080607-1 - Update to git snapshot hugin-0.7.0-0.3.20080528svn.fc10 -------------------------------- * Wed May 28 18:00:00 2008 Bruno Postle 0.7.0-0.3.20080528svn - SVN snapshot, 0.7 beta. New tools matchpoint tca_correct jd-2.0.0-0.6.svn2112_trunk.fc10 ------------------------------- * Sun Jun 8 18:00:00 2008 Mamoru Tasaka - svn 2112 libcompizconfig-0.7.6-1.fc10 ---------------------------- * Sat Jun 7 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-1 - 0.7.6 update libewf-20080501-2.fc10 ---------------------- * Sat Jun 7 18:00:00 2008 kwizart < kwizart at gmail.com > - 20080501-2 - Update mount_ewf to 20080513 libopensync-plugin-kdepim-0.36-1.fc10 ------------------------------------- * Sat Jun 7 18:00:00 2008 Kevin Kofler 0.36-1 - update to 0.36 (base for the KDE 4 port) - apply KDE 4 port patch on F10+ m2crypto-0.18.2-6 ----------------- * Sun Jun 8 18:00:00 2008 Miloslav Trma?? - 0.18.2-6 - Don't remove the User-Agent header from proxied requests Related: #448858 - Update m2urllib2.py to work with Python 2.5 man-pages-fr-2.80.0-2.fc10 -------------------------- * Fri Jun 6 18:00:00 2008 Alain Portal 2.80.0-2 - Bump release because wrong sources file * Fri Jun 6 18:00:00 2008 Alain Portal 2.80.0-1 - Update to 2.80.0 - New SOURCE1 tarball and url for download - New SOURCE2 tarball - groups.1, latex2rtf.1, linkchecker.1, rpc.statd.8 and vipw.8 are no more presents in man-pages-sup-fr. mcs-0.7.1-1.fc10 ---------------- * Sat Jun 7 18:00:00 2008 Ralf Ertzinger 0.7.1-1 - Update to 0.7.1 perl-Catalyst-Model-LDAP-0.16-4.fc10 ------------------------------------ * Sat Jun 7 18:00:00 2008 Caol??n McNamara 0.16-4 - rebuild for dependancies perl-Catalyst-Plugin-StackTrace-0.07-4.fc10 ------------------------------------------- * Sat Jun 7 18:00:00 2008 Caol??n McNamara 0.07-4 - rebuild for dependencies perl-Catalyst-View-JSON-0.24-2.fc10 ----------------------------------- * Sat Jun 7 18:00:00 2008 Caol??n McNamara 0.24-2 - rebuild for dependancies perl-Task-Weaken-1.02-3.fc10 ---------------------------- * Sat Jun 7 18:00:00 2008 Caol??n McNamara 1.02-3 - rebuild for dependancies piklab-0.15.3-1.fc10 -------------------- * Sat Jun 7 18:00:00 2008 Chitlesh Goorah - 0.15.3-1 - New upstream release - compiling with Qt 3.3 * Fri Jun 6 18:00:00 2008 Aanjhan Ranganathan 0.15.0-2 - Fixed build issues with Fedora 9 - Changed build dep from kdelibs-devel to kdelibs3-devel * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.15.0-2 - Autorebuild for GCC 4.3 stunnel-4.25-2 -------------- * Sun Jun 8 18:00:00 2008 Miloslav Trma?? - 4.25-2 - Use a clearer error message if the service name is unknown in "accept" Resolves: #450344 tailor-0.9.35-1.fc10 -------------------- * Sat Jun 7 18:00:00 2008 Dan Hor??k 0.9.35-1 - update to upstream version 0.9.35 wine-docs-1.0-0.4.rc4.fc10 -------------------------- * Sat Jun 7 18:00:00 2008 Andreas Bierfert - 1.0-0.4.rc4 - version upgrade wxPython-2.8.7.1-4.fc10 ----------------------- * Fri Jun 6 18:00:00 2008 Matthew Miller - 2.8.7.1-4 - gratuitously bump package release number to work around build system glitch. again, but it will work this time. Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 26 Broken deps for i386 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.i386 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 audacious-1.5.1-1.fc10.i386 requires audacious-plugins >= 0:1.5.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 Broken deps for x86_64 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.i386 requires /bin/falcon Falcon-devel-0.8.10-1.fc10.x86_64 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) audacious-1.5.1-1.fc10.x86_64 requires audacious-plugins >= 0:1.5.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.ppc requires /bin/falcon Falcon-devel-0.8.10-1.fc10.ppc64 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 audacious-1.5.1-1.fc10.ppc requires audacious-plugins >= 0:1.5.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.ppc64 requires /bin/falcon audacious-1.5.1-1.fc10.ppc64 requires audacious-plugins >= 0:1.5.0 emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 perl-Text-Smart-Plugin-1.0.1-2.fc10.noarch requires perl(Text::Smart) >= 0:1.0.0 perl-Text-Smart-Plugin-1.0.1-2.fc10.noarch requires perl(Text::Smart::HTML) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From pertusus at free.fr Sun Jun 8 09:57:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 8 Jun 2008 11:57:41 +0200 Subject: non responsive policy with invalid mail In-Reply-To: <484B9B0E.8000000@iinet.net.au> References: <20080606184122.GC2760@free.fr> <20080606225119.GL2760@free.fr> <484B9B0E.8000000@iinet.net.au> Message-ID: <20080608095741.GA4328@free.fr> On Sun, Jun 08, 2008 at 06:40:46PM +1000, David Timms wrote: > Patrice Dumas wrote: >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Coverage >> please modify as you like. > Pat: > ==== > What is the attempted meaning of this bit: > "and cannot be joined (with reasonable effort)," > > is it _contacted_ ? It is contacted. (in french joined also means contacted...) > ==== > I wasn't sure what the following meant: > ", one should directly jump to the mail of the formal request to orphan > all the packager packages to fedora-devel-list." > > , until I read the whole page, so this might be tidier: > ", one can short-circuit the normal 3 week interval required in the > Outline steps 1 to 3, and make the formal request to orphan mentioned in > step 4." > > I didn't want to repeat the content of the steps, yet there is no > numbering or anchor? to link to. Indeed, your formulation is much clearer. I edit the wiki. -- Pat From amdunn at gmail.com Sun Jun 8 11:20:43 2008 From: amdunn at gmail.com (Alan Dunn) Date: Sun, 8 Jun 2008 07:20:43 -0400 Subject: Anyone want to review and/or sponsor Coq package? Message-ID: Thanks to help the other day from the list, there is now a candidate Coq package for fedora: https://bugzilla.redhat.com/show_bug.cgi?id=450323 If anyone would like to review this and/or sponsor me (this is my first contribution) it would be much appreciated. It would probably also be good to note that, as mentioned at the bottom of the bugzilla listing, the URLs http://www.duke.edu/~amd34/coq/coq-8.1pl3-1.fc9.src.rpm http://www.duke.edu/~amd34/coq/coq.spec are probably one's best bet in retrieving the SRPM and spec file as the original server is flakier than I anticipated. - Alan From rjones at redhat.com Sun Jun 8 12:24:49 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 8 Jun 2008 13:24:49 +0100 Subject: Anyone want to review and/or sponsor Coq package? In-Reply-To: References: Message-ID: <20080608122449.GA27006@amd.home.annexia.org> On Sun, Jun 08, 2008 at 07:20:43AM -0400, Alan Dunn wrote: > Thanks to help the other day from the list, there is now a candidate > Coq package for fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=450323 I can have a look at this tomorrow if you don't find anyone in the meantime. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From promac at gmail.com Sun Jun 8 12:45:15 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 8 Jun 2008 09:45:15 -0300 Subject: rkhunter aborting Message-ID: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> Hi, the latest rkhunter is using the following tmp file (/etc/cron.dayly/rkhunter): # Get a secure tempfile TMPFILE1=`/bin/mktemp -p /var/rkhunter/tmp rkhcronlog.XXXXXXXXXX` || exit 1 However, /var/rkhunter/tmp is not create by the rpm, and of course, the script always stops. Previously, it was being used /var/run/rkhunter. My question is: what the new version is supposed to do? Maybe it wanted to use /var/tmp/rkhunter (not /var/rkhunter/tmp) instead of writing in /var/run/rkhunter. In this case, I also think the permission of this directory should 700. Another point, is that rkhunter always send messages even when there is no warning, and sometimes it complains that there is no copy of /etc/group and /etc/passwd. How can I fix that? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtimms at iinet.net.au Sun Jun 8 12:51:25 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 08 Jun 2008 22:51:25 +1000 Subject: Retiring Opyum In-Reply-To: References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> <484A5B09.3000207@kanarip.com> Message-ID: <484BD5CD.5080201@iinet.net.au> Kevin Kofler wrote: > Jeroen van Meeuwen kanarip.com> writes: >> Would a "Obsoletes: pirut" have been more accurate and appropriate here? > > There's both an Obsoletes and a Provides, the Obsoletes makes sense, the > Provides not really, and it causes issues like this. It would sort of make sense to be able say in a spec: Provides: pirut(functionality) ie equivalent functionality = gui package management rather than the pirut(api) ? From dtimms at iinet.net.au Sun Jun 8 12:54:21 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 08 Jun 2008 22:54:21 +1000 Subject: Anyone want to review and/or sponsor Coq package? In-Reply-To: References: Message-ID: <484BD67D.6010100@iinet.net.au> Alan Dunn wrote: > Thanks to help the other day from the list, there is now a candidate > Coq package for fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=450323 Description: Review Request: coq - Coq proof management system Coq is a formal proof management system. It allows for the determinations of alcohol percentage in moonshine distillations... ;-) From j.w.r.degoede at hhs.nl Sun Jun 8 16:39:37 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 08 Jun 2008 18:39:37 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212917892.32207.488.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> Message-ID: <484C0B49.5080600@hhs.nl> David Woodhouse wrote: > On Sat, 2008-06-07 at 19:43 -0400, Tom "spot" Callaway wrote: >> I know this is flame bait, and we're obviously missing some context, >> but it seems very much like you threw a temper tantrum at the first >> sign of trouble, screamed "I TOLD YOU NO ONE HERE WANTS TO BE FREE" >> and ran home. >> >> Did you put up your patches without the rhetoric (through whatever >> inane obfuscation you needed)? Were they rejected? > > No, I did it all: git.infradead.org/users/dwmw2/firmware-2.6.git > (well, not _all_ -- there are more drivers to convert. Help wanted!) > > It wasn't rejected -- it's in the linux-next tree and should be going in > to 2.6.27. One we finish converting the drivers, we should have the > capacity to rip _all_ the firmware blobs out of the kernel without > permanently losing functionality. > > At that point, we can at least have the _discussion_ about removing > those blobs from the kernel source tree and putting them in a separate > repository, without it being pie-in-the-sky. > > Alex now says it isn't good enough, and is actually counter-productive. If I get Alex correctly he is saying that, to his goal, which is 100% Free software everywhere (including in his toothbrush), this is counterproductive, as it may make it easier to distribute binary firmware along with the kernel, as it now could be put in a seperate tarbal removing GPL worries etc. As much as I admire Alex's goal's I'm very glad with the current pragmatic approach Fedora has taken with regards to firmware. And when combining both these perspectives, David, you patch is excellent and I'm very gratefull for all the work you've been doing on it. If the firmware truely gets put in a different tarbal (and thus eventually in a different srpm), then it will be feasible to do a no blobs included Fedora spin like gnewsense, which would be great. Now Alex worries about someone still slipping in some firmware into the kernel itself instead of into the firmware package, well as with the current situation with a completely seperate kernel, audits will still be necessary. But I hope that DaveJ will be willing to carry patches for any firmware sneaked in (if we ever get as far as the split), as once firmware and kernel are split, embedded firmware could be considered a bug. The carrying of these patches (which must be send upstream), will be the price we have to pay if we want a blob-free spin. Regards, Hans From dennis at ausil.us Sun Jun 8 18:34:43 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 8 Jun 2008 13:34:43 -0500 Subject: rpms/java-1.6.0-openjdk/F-9 java-1.6.0-openjdk-sparc-ptracefix.patch, NONE, 1.1 java-1.6.0-openjdk-sparc-trapsfix.patch, NONE, 1.1 java-1.6.0-openjdk-sparc64-INSTALL_ARCH_DIR.patch, NONE, 1.1 java-1.6.0-openjdk-sparc64-linux.patch, NONE, 1.1 java-1.6.0-openjdk.spec, 1.46, 1.47 In-Reply-To: <484C1C74.4060808@redhat.com> References: <200806081155.m58BtUQa008080@cvs-int.fedora.redhat.com> <484C1C74.4060808@redhat.com> Message-ID: <200806081334.51483.dennis@ausil.us> On Sunday 08 June 2008, Thomas Fitzsimmons wrote: > Hi Tom, > > Tom Callaway wrote: > > Author: spot > > > > Update of /cvs/pkgs/rpms/java-1.6.0-openjdk/F-9 > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8037 > > > > Modified Files: > > java-1.6.0-openjdk.spec > > Added Files: > > java-1.6.0-openjdk-sparc-ptracefix.patch > > java-1.6.0-openjdk-sparc-trapsfix.patch > > java-1.6.0-openjdk-sparc64-INSTALL_ARCH_DIR.patch > > java-1.6.0-openjdk-sparc64-linux.patch > > Log Message: > > enable sparc/sparc64 builds > > Please submit significant patches like this to Lillian and I for approval > before committing them, along with an explanation. I'd prefer to make this > change in Rawhide unless there's a compelling need for it in Fedora 9. > > This isn't the first time a cvsextras member has committed a non-trivial > patch to the OpenJDK packages without asking. This makes me second-guess > my decision to facilitate trivial patches by allowing cvsextras members > commit access. Maybe I misinterpreted the spirit of the "cvsextras group > members can commit" flag. I thought it was designed for checkin > convenience, but that non-trivial patches were still commit-after-approval. > If not, I'll just uncheck the flag and manually commit OpenJDK patches > after I've approved them. > > Tom Tom, Im assuming you are talking about my commit https://www.redhat.com/archives/fedora-extras-commits/2008-April/msg02319.html as the other cvsextras person to have touched java-1.6.0-openjdk package. I looked though the list archives and other than commits by lillian, lkundrak and yourself its the only other commit since the package was created. I worked with lillian as i was developing the changes to add support to the spec file to build using the zero engine it was done as part of Secondary Architectures as defined http://fedoraproject.org/wiki/Architectures This commit is part of the same effort. Fully integrating the asm that sun released to enable java to work natively on sparc architectures. These patches need to head upstream. I planned to work with Lillian this week to ensure that they do. We can now build openjdk for 32 and 64 bit sparc linux. previously the patches that went upstream only allowed 32 bit to be built. We are still getting F-9 completely built so we need these patches commited to F-9 so we can build the latest java-1.5.0-gcj since it uses the javadoc from openjdk to build the documentation which in turn will let us build the rest of the java applications. Regards Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From fitzsim at redhat.com Sun Jun 8 19:13:36 2008 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 08 Jun 2008 15:13:36 -0400 Subject: rpms/java-1.6.0-openjdk/F-9 java-1.6.0-openjdk-sparc-ptracefix.patch, NONE, 1.1 java-1.6.0-openjdk-sparc-trapsfix.patch, NONE, 1.1 java-1.6.0-openjdk-sparc64-INSTALL_ARCH_DIR.patch, NONE, 1.1 java-1.6.0-openjdk-sparc64-linux.patch, NONE, 1.1 java-1.6.0-openjdk.spec, 1.46, 1.47 In-Reply-To: <200806081334.51483.dennis@ausil.us> References: <200806081155.m58BtUQa008080@cvs-int.fedora.redhat.com> <484C1C74.4060808@redhat.com> <200806081334.51483.dennis@ausil.us> Message-ID: <484C2F60.4060800@redhat.com> Dennis Gilmore wrote: > On Sunday 08 June 2008, Thomas Fitzsimmons wrote: >> Hi Tom, >> >> Tom Callaway wrote: >>> Author: spot >>> >>> Update of /cvs/pkgs/rpms/java-1.6.0-openjdk/F-9 >>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8037 >>> >>> Modified Files: >>> java-1.6.0-openjdk.spec >>> Added Files: >>> java-1.6.0-openjdk-sparc-ptracefix.patch >>> java-1.6.0-openjdk-sparc-trapsfix.patch >>> java-1.6.0-openjdk-sparc64-INSTALL_ARCH_DIR.patch >>> java-1.6.0-openjdk-sparc64-linux.patch >>> Log Message: >>> enable sparc/sparc64 builds >> Please submit significant patches like this to Lillian and I for approval >> before committing them, along with an explanation. I'd prefer to make this >> change in Rawhide unless there's a compelling need for it in Fedora 9. >> >> This isn't the first time a cvsextras member has committed a non-trivial >> patch to the OpenJDK packages without asking. This makes me second-guess >> my decision to facilitate trivial patches by allowing cvsextras members >> commit access. Maybe I misinterpreted the spirit of the "cvsextras group >> members can commit" flag. I thought it was designed for checkin >> convenience, but that non-trivial patches were still commit-after-approval. >> If not, I'll just uncheck the flag and manually commit OpenJDK patches >> after I've approved them. >> >> Tom > > Tom, > > Im assuming you are talking about my commit > https://www.redhat.com/archives/fedora-extras-commits/2008-April/msg02319.html > as the other cvsextras person to have touched java-1.6.0-openjdk package. I > looked though the list archives and other than commits by lillian, lkundrak > and yourself its the only other commit since the package was created. Actually I was referring to lkundrak's merge of EPEL-specific changes to the Fedora packages which we've since reverted. I considered the SPARC ifarch changes trivial and they were applied to Rawhide. The latest change is more significant. > I > worked with lillian as i was developing the changes to add support to the > spec file to build using the zero engine it was done as part of Secondary > Architectures as defined http://fedoraproject.org/wiki/Architectures This > commit is part of the same effort. Fully integrating the asm that sun > released to enable java to work natively on sparc architectures. These > patches need to head upstream. I planned to work with Lillian this week to > ensure that they do. We can now build openjdk for 32 and 64 bit sparc linux. > previously the patches that went upstream only allowed 32 bit to be built. > We are still getting F-9 completely built so we need these patches commited > to F-9 so we can build the latest java-1.5.0-gcj since it uses the javadoc > from openjdk to build the documentation which in turn will let us build the > rest of the java applications. OK. At least for patches against released branches (and hopefully for all significant patches) I would appreciate if people would ask for approval from Lillian and I before committing. In most cases I like to limit churn on stable branches to security fixes so that we don't risk breaking something in an update. This patch is fine to stay committed, but please do not start a package build yet. We're in the middle of testing java-1.6.0-openjdk-1.6.0.0-0.15.b09.fc9 from dist-f9-updates-candidate extensively for an update release and we don't want to restart the testing. Note: I do appreciate the SPARC efforts, it's just important that lines of communication (other than CVS commit messages) stay open. Tom From michel.sylvan at gmail.com Sun Jun 8 21:06:54 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 08 Jun 2008 17:06:54 -0400 Subject: Packaging question: /usr/share/gnome/help ownership Message-ID: <484C49EE.6040506@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 /usr/share/gnome/help is owned by yelp. According to the packaging guidelines, section 1.35: File and Directory Ownership, use case 2: "there are several instances where it's desirable for multiple packages to own a directory. Examples of this are: ... 2) Multiple packages have files in a common directory but none of them requires others. ... In all cases we are guarding against unowned directories being present on a system. Unowned directories are affected by the umask of the user installing the package and thus can be a security risk or lead to packages which won't run." For GNOME packages, the consensus as expressed in existing packages seems to be to assume that yelp is installed, and so individual packages neither Requires: yelp (since the basic functionality does not depend on it) nor own /usr/share/gnome/help. Is this not dangerous, though? For instance, someone running an alternative desktop, and using yum to install selected GTK/GNOME packages might end up with a dangling /usr/share/gnome/help if yelp is never installed. Should applications that put files under /usr/share/gnome/help be required to own it (or depend on yelp)? In that case, there's a lot of clean-up to do w.r.t. GNOME packages. Thanks, - -- Michel Salim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhMSekACgkQWt0J3fd+7ZBYcgCghcJmnX6cKMOIetlA46GuWmpK AM8An1cxYMZlLF/TaJi8fC/URrE0R0wF =oV21 -----END PGP SIGNATURE----- From dwmw2 at infradead.org Sun Jun 8 21:12:06 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jun 2008 22:12:06 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <484C0B49.5080600@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> Message-ID: <1212959526.2534.62.camel@shinybook.infradead.org> On Sun, 2008-06-08 at 18:39 +0200, Hans de Goede wrote: > > Alex now says it isn't good enough, and is actually counter-productive. > > If I get Alex correctly he is saying that, to his goal, which is 100% Free > software everywhere (including in his toothbrush), this is counterproductive, > as it may make it easier to distribute binary firmware along with the kernel, > as it now could be put in a seperate tarbal removing GPL worries etc. If it's a GPL violation to ship the non-GPL'd firmware in the source tarball, it's also a GPL violation to distribute it as part of a vmlinux. So yes, putting it in a separate source tarball removes the GPL worries there -- but if you're then going to use the CONFIG_BUILTIN_FIRMWARE feature and build non-GPL'd firmware into your vmlinux, that brings exactlly those same worries right back again. If you build non-GPL'd firmware into your kernel, you may not distribute that kernel image (although currently we do just that; we shouldn't). > If the firmware truely gets put in a different tarbal (and thus eventually in a > different srpm), then it will be feasible to do a no blobs included Fedora spin > like gnewsense, which would be great. Fedora already uses 'doctored' tarballs for stuff like openssh; I think it would be reasonable enough to do that with a firmware-less kernel source tarball too. It's easy enough to build the firmware package separately (although first, I'm going to make the kernel srpm spit out a 'kernel-firmware' subpackage; we can talk about splitting it later). > Now Alex worries about someone still slipping in some firmware into the kernel > itself instead of into the firmware package, well as with the current situation > with a completely seperate kernel, audits will still be necessary. That's nothing special -- it's just the same as we should always be vigilant for someone slipping non-GPL'd _code_ into the kernel. Should we just give up, just because people slip up occasionally? -- dwmw2 From kevin.kofler at chello.at Sun Jun 8 21:14:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 8 Jun 2008 21:14:30 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> Message-ID: Michel Salim gmail.com> writes: > Should applications that put files under /usr/share/gnome/help be > required to own it (or depend on yelp)? Own it maybe, depend on yelp definitely not, at least not in anything which ends up on the KDE spin (e.g. the system-config-* tools required by Anaconda). We don't want the whole xulrunner stack on the KDE spin, we don't have room for it. (We use Konqueror as the browser on the KDE spin, not Firefox.) Kevin Kofler From rjones at redhat.com Sun Jun 8 21:26:24 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 8 Jun 2008 22:26:24 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212917892.32207.488.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> Message-ID: <20080608212624.GA28456@amd.home.annexia.org> On Sun, Jun 08, 2008 at 10:38:12AM +0100, David Woodhouse wrote: > No, I did it all: git.infradead.org/users/dwmw2/firmware-2.6.git > (well, not _all_ -- there are more drivers to convert. Help wanted!) > > It wasn't rejected -- it's in the linux-next tree and should be going in > to 2.6.27. One we finish converting the drivers, we should have the > capacity to rip _all_ the firmware blobs out of the kernel without > permanently losing functionality. In case anyone, like me, was wondering what the heck this is all about, lwn.net has a good article summarising what David's been doing: Subscriber-only link: http://lwn.net/Articles/284932/ Free link: http://lwn.net/SubscriberLink/284932/f332cb16db1c6257/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jspaleta at gmail.com Sun Jun 8 21:38:05 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Jun 2008 13:38:05 -0800 Subject: non responsive policy with invalid mail In-Reply-To: References: <20080606184122.GC2760@free.fr> Message-ID: <604aa7910806081438g243f1801x300fba3ecee214d3@mail.gmail.com> On Fri, Jun 6, 2008 at 11:15 AM, Jason L Tibbitts III wrote: > On the other hand, I happily gave my telephone number in FAS and I'd > hope to get a call in such an instance. I'm not sure FAS exposes phone numbers to all contributors, but it maybe only available to FAS admins. So if we want to incorporate a phone ping of a missing maintainer into missing maintainer workflow we might have to make a request to the correct group with access to the phone numbers. -jef"allowing contributors to optionally exposing phone numbers to co-maintainers or specific groups would be something to consider"spaleta From lesmikesell at gmail.com Sun Jun 8 21:48:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 08 Jun 2008 16:48:08 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212959526.2534.62.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> Message-ID: <484C5398.10800@gmail.com> David Woodhouse wrote: > >>> Alex now says it isn't good enough, and is actually counter-productive. >> If I get Alex correctly he is saying that, to his goal, which is 100% Free >> software everywhere (including in his toothbrush), this is counterproductive, >> as it may make it easier to distribute binary firmware along with the kernel, >> as it now could be put in a seperate tarbal removing GPL worries etc. > > If it's a GPL violation to ship the non-GPL'd firmware in the source > tarball, it's also a GPL violation to distribute it as part of a > vmlinux. I don't recall ever seeing tarballs mentioned in copyright laws. Tar is just a way of aggregating files that may not have any other relationship. > That's nothing special -- it's just the same as we should always be > vigilant for someone slipping non-GPL'd _code_ into the kernel. > Should we just give up, just because people slip up occasionally? There has never been an issue with aggregating GPL and non-GPL items for distribution - and there would be no legal basis for such a restriction. The question is whether the parts are derivative works. If you could establish that the firmware code is derived from GPL'd code (which seems pretty unlikely if the same firmware would be used with other OS's), then the restriction against distribution under other terms would apply. -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Sun Jun 8 22:01:22 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jun 2008 23:01:22 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <484C5398.10800@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> Message-ID: <1212962483.2534.72.camel@shinybook.infradead.org> On Sun, 2008-06-08 at 16:48 -0500, Les Mikesell wrote: > There has never been an issue with aggregating GPL and non-GPL items for > distribution - and there would be no legal basis for such a restriction. > The question is whether the parts are derivative works. You are mistaken. Read ?2 of the GPL again. -- dwmw2 From kevin at scrye.com Sun Jun 8 22:20:49 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 8 Jun 2008 16:20:49 -0600 Subject: rkhunter aborting In-Reply-To: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> References: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> Message-ID: <20080608162049.69fd9120@ohm.scrye.com> On Sun, 8 Jun 2008 09:45:15 -0300 promac at gmail.com ("Paulo Cavalcanti") wrote: > Hi, > > the latest rkhunter is using the following tmp file > (/etc/cron.dayly/rkhunter): > > # Get a secure tempfile > TMPFILE1=`/bin/mktemp -p /var/rkhunter/tmp rkhcronlog.XXXXXXXXXX` || > exit 1 > > However, /var/rkhunter/tmp is not create by the rpm, and of course, > the script always stops. > > Previously, it was being used /var/run/rkhunter. > > My question is: what the new version is supposed to do? It should be using /var/run/rkhunter. What version is this? Output of: rpm -q rkhunter rpm -V rkhunter ? > > Maybe it wanted to use /var/tmp/rkhunter (not /var/rkhunter/tmp) > instead of writing in /var/run/rkhunter. > In this case, I also think the permission of this directory should > 700. No, it should be using /var/run/rkhunter > Another point, is that rkhunter always send messages even when there > is no warning, Correct. This is due to the idea that an email sent at run time is harder for an intruder to be able to later modify when they compromise the machine. Changing /var/log/rkhunter.log files is easy... > and sometimes it complains that there is no copy of /etc/group and > /etc/passwd. > How can I fix that? As the cron email says, confirm your machine is clean and do: rkhunter --propupd > > Thanks. > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lesmikesell at gmail.com Sun Jun 8 22:29:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 08 Jun 2008 17:29:13 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212962483.2534.72.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> Message-ID: <484C5D39.5000308@gmail.com> David Woodhouse wrote: > On Sun, 2008-06-08 at 16:48 -0500, Les Mikesell wrote: >> There has never been an issue with aggregating GPL and non-GPL items for >> distribution - and there would be no legal basis for such a restriction. >> The question is whether the parts are derivative works. > > You are mistaken. Read ?2 of the GPL again. > Do you mean the part about identifiable sections that are not derived from the program and can be reasonably considered independent and separate works? That would seem the only possible interpretation for firmware blobs. -- Les Mikesell lesmikesell at gmail.com From alan at redhat.com Sun Jun 8 22:34:36 2008 From: alan at redhat.com (Alan Cox) Date: Sun, 8 Jun 2008 18:34:36 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212962483.2534.72.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> Message-ID: <20080608223436.GA26726@devserv.devel.redhat.com> On Sun, Jun 08, 2008 at 11:01:22PM +0100, David Woodhouse wrote: > On Sun, 2008-06-08 at 16:48 -0500, Les Mikesell wrote: > > There has never been an issue with aggregating GPL and non-GPL items for > > distribution - and there would be no legal basis for such a restriction. > > The question is whether the parts are derivative works. > > You are mistaken. Read ?2 of the GPL again. Actually Dave I continue to think you are the mistaken one in the case of firmware files. I would suggest you read up on derivative works rather than your pet interpretation of the GPL. Alan From promac at gmail.com Mon Jun 9 00:04:18 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 8 Jun 2008 21:04:18 -0300 Subject: rkhunter aborting In-Reply-To: <20080608162049.69fd9120@ohm.scrye.com> References: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> <20080608162049.69fd9120@ohm.scrye.com> Message-ID: <68720af30806081704peb61760j888358bbbd5626e3@mail.gmail.com> 2008/6/8 Kevin Fenzi : > On Sun, 8 Jun 2008 09:45:15 -0300 > promac at gmail.com ("Paulo Cavalcanti") wrote: > > > Hi, > > > > the latest rkhunter is using the following tmp file > > (/etc/cron.dayly/rkhunter): > > > > # Get a secure tempfile > > TMPFILE1=`/bin/mktemp -p /var/rkhunter/tmp rkhcronlog.XXXXXXXXXX` || > > exit 1 > > > > However, /var/rkhunter/tmp is not create by the rpm, and of course, > > the script always stops. > > > > Previously, it was being used /var/run/rkhunter. > > > > My question is: what the new version is supposed to do? > > It should be using /var/run/rkhunter. > > What version is this? Output of: > > rpm -q rkhunter > rpm -V rkhunter > [lua:~] rpm -q rkhunter rkhunter-1.3.2-3.fc8.noarch [lua:~] rpm -V rkhunter S.?....T c /etc/rkhunter.conf ..?..... c /etc/sysconfig/rkhunter -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Mon Jun 9 00:33:14 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 8 Jun 2008 18:33:14 -0600 Subject: rkhunter aborting In-Reply-To: <68720af30806081704peb61760j888358bbbd5626e3@mail.gmail.com> References: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> <20080608162049.69fd9120@ohm.scrye.com> <68720af30806081704peb61760j888358bbbd5626e3@mail.gmail.com> Message-ID: <20080608183314.586ea673@ohm.scrye.com> > > What version is this? Output of: > > > > rpm -q rkhunter > > rpm -V rkhunter > > [lua:~] rpm -q rkhunter > rkhunter-1.3.2-3.fc8.noarch > [lua:~] rpm -V rkhunter > S.?....T c /etc/rkhunter.conf > ..?..... c /etc/sysconfig/rkhunter Rats. I see the problem, the updated cron script didn't get copied right into F-7 and F-8 branches. ;( My fault entirely... Can you try putting this one: http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/rkhunter/01-rkhunter in /etc/cron.daily/rkhunter ? I'll try and get this fixed in the next few days... I am planning updates for that script anyhow. Thanks for pointing this out! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dtimms at iinet.net.au Mon Jun 9 01:00:47 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 09 Jun 2008 11:00:47 +1000 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: References: <484C49EE.6040506@gmail.com> Message-ID: <484C80BF.7000807@iinet.net.au> Kevin Kofler wrote: > Michel Salim gmail.com> writes: >> Should applications that put files under /usr/share/gnome/help be >> required to own it (or depend on yelp)? > > Own it maybe, depend on yelp definitely not, at least not in anything which > ends up on the KDE spin (e.g. the system-config-* tools required by Anaconda). > We don't want the whole xulrunner stack on the KDE spin, we don't have room for > it. (We use Konqueror as the browser on the KDE spin, not Firefox.) Would a "yelp-not" package that provides yelp, makes the dirs, but puts nothing into them solve the issue in a general way ? From kagesenshi.87 at gmail.com Mon Jun 9 02:02:00 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Mon, 9 Jun 2008 10:02:00 +0800 Subject: Retiring Opyum In-Reply-To: <484BD5CD.5080201@iinet.net.au> References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> <484A5B09.3000207@kanarip.com> <484BD5CD.5080201@iinet.net.au> Message-ID: On Sun, Jun 8, 2008 at 8:51 PM, David Timms wrote: > Kevin Kofler wrote: >> >> Jeroen van Meeuwen kanarip.com> writes: >>> >>> Would a "Obsoletes: pirut" have been more accurate and appropriate here? >> >> There's both an Obsoletes and a Provides, the Obsoletes makes sense, the >> Provides not really, and it causes issues like this. > > It would sort of make sense to be able say in a spec: > Provides: pirut(functionality) > ie equivalent functionality = gui package management > rather than the pirut(api) ? Obsolete: pirut -> pirut is dead, this replace pirut, other apps that depends on pirut - break their dependencies Provides: pirut -> pirut is still alive, this package now include pirut, other apps that depend on pirut - retain dependencies > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From aoliva at redhat.com Mon Jun 9 03:47:36 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 09 Jun 2008 00:47:36 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212882238.3269.9.camel@localhost.localdomain> (Tom Callaway's message of "Sat\, 07 Jun 2008 19\:43\:58 -0400") References: <1212882238.3269.9.camel@localhost.localdomain> Message-ID: On Jun 7, 2008, "Tom \"spot\" Callaway" wrote: > it seems very much like you threw a temper tantrum at the first sign > of trouble, screamed "I TOLD YOU NO ONE HERE WANTS TO BE FREE" and > ran home. > Did you put up your patches This makes it very clear that you didn't even read what I wrote before jumping to this conclusion. In my e-mail, I explained why working on those patches would be detrimental to my goals, so I wouldn't do it. FTR, there's no sign of trouble. In fact, there's absolutely nothing new. David's patches are being considered for adoption because they make technical sense, Fedora and Debian keep on privileging the short term over the long term, and Linux-libre remains essential for distros/users who don't want to distribute/install non-Free Software. Now, could you please do me a favor and spend the time to read before gratuitously flaming again? And, if it's not asking for too much, would you please save to yourself the name-calling attacks on others' positions and arguments as 'rhetoric', especially when you show obvious signs that you haven't taken even the trouble of reading them? It's quite disrespectful and unproductive. Please go look up 'rhetoric' and realize that it doesn't mean "arguments I'm not interested in hearing/reading" nor "arguments I don't agree with", or even "consequences of premises I don't agree with". Thanks, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From a.badger at gmail.com Mon Jun 9 05:20:58 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 08 Jun 2008 22:20:58 -0700 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: References: <484C49EE.6040506@gmail.com> Message-ID: <484CBDBA.9030405@gmail.com> Kevin Kofler wrote: > Michel Salim gmail.com> writes: >> Should applications that put files under /usr/share/gnome/help be >> required to own it (or depend on yelp)? > > Own it maybe, depend on yelp definitely not, at least not in anything which > ends up on the KDE spin (e.g. the system-config-* tools required by Anaconda). > We don't want the whole xulrunner stack on the KDE spin, we don't have room for > it. (We use Konqueror as the browser on the KDE spin, not Firefox.) > Err... the last time this came up it was successfully argued that having "Help" fail to work was a bug. The initial idea was to have something within the GNOME stack require yelp but I believe that failed because of circular dependencies. So if this will cause problems because of system-config-* dragging in xulrunner we need to come up with some other way of solving the help-won't-display bug. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From valent.turkovic at gmail.com Mon Jun 9 06:52:21 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jun 2008 08:52:21 +0200 Subject: "Fedora Project summary and awards" - end of RedHat support? Message-ID: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> Hi, I read a really disturbing message on local news group. One person has posted a question why is RedHat stopping support for Fedora Project. He clamis that he read that on RedHat press [1] page. That page is 404 now, but he swears that it was up. The summary was that RedHat is stopping support for Fedora Project after Fedora 10 and that it is giving awards for best contributers. I know that there is no page there now, but still I had to ask if anybody knows anything. Is this just FUD? Cheers, Valent. [1] http://www.press.redhat.com/2008/06/06/fedora-project-summary-and-awards -- 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 atkac at redhat.com Mon Jun 9 07:06:04 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 9 Jun 2008 09:06:04 +0200 Subject: nscd by default? In-Reply-To: <1218b5bc0806062018m575a9591t25d30aa72bdddc5d@mail.gmail.com> References: <1218b5bc0806062018m575a9591t25d30aa72bdddc5d@mail.gmail.com> Message-ID: <20080609070604.GA13178@evileye.atkac.englab.brq.redhat.com> On Fri, Jun 06, 2008 at 10:18:21PM -0500, Callum Lerwick wrote: > 2008/6/6 Colin Walters : > > > Per discussion here: > > > > http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00355.html > > and followup here: > > http://www.redhat.com/archives/rhl-devel-list/2007-December/msg00409.html > > > > Is there a reason we aren't using nscd by default? > > > > I would say the current DNS situation is the most annoying desktop > > networking-related bug in the OS. > > > Or, as I think I point out somewhere in that thread, use dnsmasq which is > designed to solve exactly this problem. And it even has a D-BUS interface. > The only objection was something about DNSSEC. Which can always be fixed... I'm not sure. As far as I know dnsmasq doesn't support recursion and caching so you don't get any advantage when you enable it. (btw recursion has to be supported to have DNSSEC-aware resolver) Adam -- Adam Tkac, Red Hat, Inc. From dwmw2 at infradead.org Mon Jun 9 07:29:28 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 08:29:28 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <484C5D39.5000308@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> Message-ID: <1212996568.32207.572.camel@pmac.infradead.org> On Sun, 2008-06-08 at 17:29 -0500, Les Mikesell wrote: > Do you mean the part about identifiable sections that are not derived > from the program and can be reasonably considered independent and > separate works? That would seem the only possible interpretation for > firmware blobs. Exactly that part, yes. Where it says that the GPL applies to them anyway. Specifically, the bit where where it says that the GPL (obviously) doesn't "apply to those sections when you distribute them as separate works. But when you distribute those _same_ sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions to other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." I agree with you that that seems to be the only possible interpretation for firmware blobs. And when we take them and include them in the bzImage and distribute that, the only possible interpretation is that they are 'part of a whole which is a work based on the Program'. You do get an exception for 'mere aggregation on a volume of a storage or distribution medium', which covers stuff like shareware/freeware CDs on the covers of magazines -- so unrelated stuff which happens to be shipped together in _that_ form doesn't get infected by the GPL. But it's extremely hard to argue that combining non-GPL'd firmware into the kernel image is 'mere aggregation on a volume of a storage or distribution medium'. I know some people like to conveniently abbreviate that to 'mere aggregation' -- since "mere" doesn't really mean much, so then they like to claim it actually excuses _all_ forms of aggregation, effectively cancelling out the previous two paragraphs of the GPL in their entirety. I don't find that interpretation particularly realistic, though -- although nobody is right or wrong about it until/unless a court rules on it, of course. To claim that there is no _legal_ basis for such a restriction is also incorrect. Nothing but the GPL gives you the right to distribute the Linux kernel. If the GPL has conditions with which you fail to comply, then you may not distribute the Linux kernel. -- dwmw2 From pmatilai at laiskiainen.org Mon Jun 9 07:35:01 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 9 Jun 2008 10:35:01 +0300 (EEST) Subject: Retiring Opyum In-Reply-To: <484BD5CD.5080201@iinet.net.au> References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> <484A5B09.3000207@kanarip.com> <484BD5CD.5080201@iinet.net.au> Message-ID: On Sun, 8 Jun 2008, David Timms wrote: > Kevin Kofler wrote: >> Jeroen van Meeuwen kanarip.com> writes: >>> Would a "Obsoletes: pirut" have been more accurate and appropriate here? >> >> There's both an Obsoletes and a Provides, the Obsoletes makes sense, the >> Provides not really, and it causes issues like this. > > It would sort of make sense to be able say in a spec: > Provides: pirut(functionality) > ie equivalent functionality = gui package management > rather than the pirut(api) ? "Pirut" is just a name and an implementation detail, you'd want something along the lines of "Provides: package-manager-gui" similarly to httpd providing "webserver" etc, that apps just wanting a GUI package manager can depend on. Blindly adding provides for everything obsoleted is just BAD, unless they actually provide a compatible interface (be it API or command names). - Panu - From dwmw2 at infradead.org Mon Jun 9 07:40:33 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 08:40:33 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080608223436.GA26726@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <20080608223436.GA26726@devserv.devel.redhat.com> Message-ID: <1212997233.32207.584.camel@pmac.infradead.org> On Sun, 2008-06-08 at 18:34 -0400, Alan Cox wrote: > Actually Dave I continue to think you are the mistaken one in the case > of firmware files. I would suggest you read up on derivative works > rather than your pet interpretation of the GPL. Are you suggesting that the bzImage we ship is not derived from the kernel source? Or that to distribute it, you don't need the permission which is granted by the GPL? It is a common mistake to think that because the firmware itself is not derived from the kernel, it therefore _cannot_ be touched by the GPL whatever the GPL actually says. This is not so. A software licence can make whatever restrictions it likes (within reason). If you are required to pay money, you cannot refuse on the basis that the money is not a derived work of the software. If you are required to send a postcard, you cannot refuse on the basis that the postcard is not a derived work of the software. If you are required to place some of your own work under GPL, you cannot refuse on the basis that your own work is not a derived work of the software. If you are required to sacrifice your first-born child, one would sincerely hope that your reason for refusal is _not_ the fact that your first-born child is not a derived work of the software. Of course you _can_ refuse, in all of the above cases -- for whatever reasons you like. But if you do refuse, then you have no permission to distribute the software in question. (In the latter case, the person who released software under that licence may get in trouble for promoting an attitude of violence, but you still wouldn't be permitted to use his software). -- dwmw2 From berrange at redhat.com Mon Jun 9 07:41:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 9 Jun 2008 08:41:22 +0100 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> Message-ID: <20080609074122.GA14855@redhat.com> On Mon, Jun 09, 2008 at 08:52:21AM +0200, Valent Turkovic wrote: > Hi, > I read a really disturbing message on local news group. One person has > posted a question why is RedHat stopping support for Fedora Project. > He clamis that he read that on RedHat press [1] page. That page is 404 > now, but he swears that it was up. The summary was that RedHat is > stopping support for Fedora Project after Fedora 10 and that it is > giving awards for best contributers. I know that there is no page > there now, but still I had to ask if anybody knows anything. Is this > just FUD? That is complete & utter garbage & FUD. Regards, Daniel. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pertusus at free.fr Mon Jun 9 07:41:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 9 Jun 2008 09:41:28 +0200 Subject: many things disappeared from the wiki? Message-ID: <20080609074128.GB2566@free.fr> Hello, Maybe I missed an annoucement, but there are things thtat were in the old wiki that are not there anymore, or that cannot be found through the search. Is it normal? -- Pat From pertusus at free.fr Mon Jun 9 07:49:09 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 9 Jun 2008 09:49:09 +0200 Subject: many things disappeared from the wiki? In-Reply-To: <20080609074128.GB2566@free.fr> References: <20080609074128.GB2566@free.fr> Message-ID: <20080609074909.GC2566@free.fr> On Mon, Jun 09, 2008 at 09:41:28AM +0200, Patrice Dumas wrote: > Hello, > > Maybe I missed an annoucement, but there are things thtat were in the > old wiki that are not there anymore, or that cannot be found through the > search. > > Is it normal? Looks like, unless previous search, the new search can only look at complet element of a title, not part of the word, for example PackagingDraft will return nothing while PackagingDrafts is right. Is there a possibility to match substrings? -- Pat From nicolas.mailhot at laposte.net Mon Jun 9 08:15:39 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 9 Jun 2008 10:15:39 +0200 (CEST) Subject: many things disappeared from the wiki? In-Reply-To: <20080609074128.GB2566@free.fr> References: <20080609074128.GB2566@free.fr> Message-ID: <2449.192.54.193.59.1212999339.squirrel@rousalka.dyndns.org> Le Lun 9 juin 2008 09:41, Patrice Dumas a ?crit : > Hello, > > Maybe I missed an annoucement, but there are things thtat were in the > old wiki that are not there anymore, or that cannot be found through > the search. > > Is it normal? The wiki conversion was far from perfect or complete. I've been looking at my SIG pages this weekend and they needed many manual fixups (not all done despite many hours of work). I don't think most Fedora contributors have realised what the remaining volume of wiki cleanup is. -- Nicolas Mailhot From pertusus at free.fr Mon Jun 9 08:18:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 9 Jun 2008 10:18:17 +0200 Subject: many things disappeared from the wiki? In-Reply-To: <2449.192.54.193.59.1212999339.squirrel@rousalka.dyndns.org> References: <20080609074128.GB2566@free.fr> <2449.192.54.193.59.1212999339.squirrel@rousalka.dyndns.org> Message-ID: <20080609081817.GE2566@free.fr> On Mon, Jun 09, 2008 at 10:15:39AM +0200, Nicolas Mailhot wrote: > > The wiki conversion was far from perfect or complete. I've been > looking at my SIG pages this weekend and they needed many manual > fixups (not all done despite many hours of work). > > I don't think most Fedora contributors have realised what the > remaining volume of wiki cleanup is. I noticed that too. Many links have changed syntax, for example. But the way search is performed is not likned with edition of the wiki, but some kind of configuration. -- Pat From mcepl at redhat.com Fri Jun 6 14:49:42 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 06 Jun 2008 16:49:42 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> Message-ID: <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> On Mon, 02 Jun 2008 21:15:33 -0400, Ignacio Vazquez-Abrams scripst: > On Mon, 2008-06-02 at 22:58 +0200, Christoph H?ger wrote: >> could you point out why exactly there is "something to do"? >> >> I mean, python3000 is a new language and no replacement so if someone >> is willing to package it (or a package that depends on py3k) she/he >> should make sure its a python2.x compatible installation (especially in >> the naming of the package). That should be all, right? > > Python 2.x *will* be discontinued at some time in the future. It may be > a few years, but it will happen. Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let one or two Rawhide cycles to make all warnings disappear? 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 stlwrt at gmail.com Mon Jun 9 09:05:02 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 9 Jun 2008 12:05:02 +0300 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> Message-ID: There was some talk about RH shifting priorities to do best at what they are best already - servers, but abandoning fedora - definitely not. Fedora is what they make RHEL from and they need open system to test-drive technologies On Mon, Jun 9, 2008 at 9:52 AM, Valent Turkovic wrote: > Hi, > I read a really disturbing message on local news group. One person has > posted a question why is RedHat stopping support for Fedora Project. > He clamis that he read that on RedHat press [1] page. That page is 404 > now, but he swears that it was up. The summary was that RedHat is > stopping support for Fedora Project after Fedora 10 and that it is > giving awards for best contributers. I know that there is no page > there now, but still I had to ask if anybody knows anything. Is this > just FUD? > > Cheers, > Valent. > > [1] http://www.press.redhat.com/2008/06/06/fedora-project-summary-and-awards > -- > 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 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From loupgaroublond at gmail.com Mon Jun 9 09:08:54 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 9 Jun 2008 11:08:54 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> Message-ID: <7f692fec0806090208j65f92222v953a9e2791bbdb03@mail.gmail.com> On Fri, Jun 6, 2008 at 4:49 PM, Matej Cepl wrote: > On Mon, 02 Jun 2008 21:15:33 -0400, Ignacio Vazquez-Abrams scripst: >> On Mon, 2008-06-02 at 22:58 +0200, Christoph H?ger wrote: >>> could you point out why exactly there is "something to do"? >>> >>> I mean, python3000 is a new language and no replacement so if someone >>> is willing to package it (or a package that depends on py3k) she/he >>> should make sure its a python2.x compatible installation (especially in >>> the naming of the package). That should be all, right? >> >> Python 2.x *will* be discontinued at some time in the future. It may be >> a few years, but it will happen. > > Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let > one or two Rawhide cycles to make all warnings disappear? Theoretically, probably. I'm not sure we have enough eyeballs that could make that happen though. -Yaakov From dev at nigelj.com Mon Jun 9 09:12:17 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 09 Jun 2008 21:12:17 +1200 Subject: many things disappeared from the wiki? In-Reply-To: <20080609081817.GE2566@free.fr> References: <20080609074128.GB2566@free.fr> <2449.192.54.193.59.1212999339.squirrel@rousalka.dyndns.org> <20080609081817.GE2566@free.fr> Message-ID: <484CF3F1.4040603@nigelj.com> Patrice Dumas wrote: > On Mon, Jun 09, 2008 at 10:15:39AM +0200, Nicolas Mailhot wrote: > >> The wiki conversion was far from perfect or complete. I've been >> looking at my SIG pages this weekend and they needed many manual >> fixups (not all done despite many hours of work). >> >> I don't think most Fedora contributors have realised what the >> remaining volume of wiki cleanup is. >> > > I noticed that too. Many links have changed syntax, for example. But the > way search is performed is not likned with edition of the wiki, but some > kind of configuration. > The 'broken' search is not actually broken... All new pages _should_ be created with spaces between major words (i.e. what would have been 'CVSAdminProcedure' should now be 'CVS Admin Procedure'), now while we can't do all that right now (cleaning up the formatting is more important really) it's something to keep in mind today onwards. Also, with Mediawiki user pages SHOULD be located as User:fasname, not RealName like moin did (redirecting the other direction just makes this harder/more annoying), in addition any subpages RealName/* should be moved to User:fasname/* too. When this is done, it will have the end effect of search working properly again. -- Nigel (For those that want to argue about the correct way, just look at any other busy MediaWiki installation (wikipedia,wikia etc) From alan at redhat.com Mon Jun 9 09:18:31 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jun 2008 05:18:31 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212997233.32207.584.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <20080608223436.GA26726@devserv.devel.redhat.com> <1212997233.32207.584.camel@pmac.infradead.org> Message-ID: <20080609091831.GA13454@devserv.devel.redhat.com> On Mon, Jun 09, 2008 at 08:40:33AM +0100, David Woodhouse wrote: > Are you suggesting that the bzImage we ship is not derived from the > kernel source? Or that to distribute it, you don't need the permission > which is granted by the GPL? Nothing of the sort. I'm suggesting conventional interpretations of copyright law might apply. The ones the lawyers seem to consider conventional From alan at redhat.com Mon Jun 9 09:20:41 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jun 2008 05:20:41 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212996568.32207.572.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> Message-ID: <20080609092041.GB13454@devserv.devel.redhat.com> On Mon, Jun 09, 2008 at 08:29:28AM +0100, David Woodhouse wrote: > I agree with you that that seems to be the only possible interpretation > for firmware blobs. And when we take them and include them in the > bzImage and distribute that, the only possible interpretation is that > they are 'part of a whole which is a work based on the Program'. Disagree. > But it's extremely hard to argue that combining non-GPL'd firmware into > the kernel image is 'mere aggregation on a volume of a storage or > distribution medium'. Disagree. You are trying to think computer about matters which are not computing. I would suggest you go and learn about the actual legal caselaw in the case things like books, and also on the boundaries of contract created by copyright. From mschwendt at gmail.com Mon Jun 9 09:21:47 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 9 Jun 2008 11:21:47 +0200 Subject: Fedora's GtkSpell -> Enchant customisation Message-ID: <20080609112147.0fbb7b04.mschwendt@gmail.com> Bugzilla Bug 245888: Make gtkspell support Enchant/Hunspell https://bugzilla.redhat.com/245888 This patch is from December 2007 and is not included in the new GtkSpell 2.0.12 upstream update from May 2008. Has anything been done to get this accepted upstream? -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.60 1.25 0.92 From rawhide at fedoraproject.org Mon Jun 9 09:24:24 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 9 Jun 2008 09:24:24 +0000 (UTC) Subject: rawhide report: 20080609 changes Message-ID: <20080609092424.B49A1209D03@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080608/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080609/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gamazons GNOME Amazons Updated Packages: audacious-plugins-1.5.1-1.fc10 ------------------------------ * Sun Jun 8 18:00:00 2008 Ralf Ertzinger 1.5.1-1 - Update to 1.5.1 audacity-1.3.5-0.5.beta.fc10 ---------------------------- * Sun Jun 8 18:00:00 2008 Michael Schwendt - 1.3.5-0.5.beta - fix bad fr.po that makes Fichier>Open dialog too wide banshee-1.0.0-1.fc10 -------------------- * Fri Jun 6 18:00:00 2008 Nigel Jones - 1.0.0-1 - Banshee goes GOLD! compizconfig-backend-gconf-0.7.6-1.fc10 --------------------------------------- * Mon Jun 9 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-1 - 0.7.6 update compizconfig-backend-kconfig-0.7.6-1.fc10 ----------------------------------------- * Mon Jun 9 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-1 - 0.7.6 update driconf-0.9.1-8.fc10 -------------------- * Sun Jun 8 18:00:00 2008 Kevin Fenzi - 0.9.1-8 - Improve unicode support (fixes bug #450083) ez-ipupdate-3.0.11-0.18.b8.fc10 ------------------------------- * Sun Jun 8 18:00:00 2008 Jeff Layton - 3.0.11-0.18.b8 - default server for zoneedit has changed to dynamic.zoneedit.com (BZ#449375) gnu-smalltalk-3.0.3-2.fc10 -------------------------- * Sun Jun 8 18:00:00 2008 Jochen Schmitt 3.0.3-2 - Disable 'make check' * Wed May 14 18:00:00 2008 Jochen Schmitt 3.0.3-1 - New upstream release * Thu Apr 17 18:00:00 2008 Jochen Schmitt 3.0.2-4 - Patch configure.ac to make version independency from libffi * Sat Mar 8 17:00:00 2008 Xavier Lamien 3.0.2-2 - Updated release. - Disable x86_64 arch, because 'make test' fails on this arch jd-2.0.0-0.6.svn2116_trunk.fc10 ------------------------------- * Mon Jun 9 18:00:00 2008 Mamoru Tasaka - svn 2116 kleansweep-0.2.9-8.fc10 ----------------------- * Sun Jun 8 18:00:00 2008 Chitlesh Goorah - 0.2.9-8 - bugfix #449631 pykickstart-1.37-1.fc10 ----------------------- * Sun Jun 8 18:00:00 2008 Chris Lumens - 1.37-1 - XConfig is still used by other projects, so just deprecate some options. (clumens) rrdtool-1.3-0.20.rc9.fc10 ------------------------- * Sun Jun 8 18:00:00 2008 Jarod Wilson 1.3-0.20.rc9 - Update to rrdtool 1.3 rc9 - Minor spec tweaks to permit building on older EL ruby-RMagick-2.4.0-1.fc10 ------------------------- * Sun Jun 8 18:00:00 2008 Mamoru Tasaka - 2.4.0-1 - 2.4.0 ruby-marc-0.1.9-1.fc10 ---------------------- * Sun Jun 8 18:00:00 2008 Mamoru Tasaka - 0.1.9-1 - 0.1.9 xorg-x11-drv-radeonhd-1.2.1-2.20080605git.fc10 ---------------------------------------------- * Thu Jun 5 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-2.20080605git - New snapshot (upstream commit 26ccf1177465beb2db5a2c972dd7adc17c3f457b): - DRI support on R5xx (X1000 series) - Lots of other updates, too many to list them all. Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 15 Broken deps for i386 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.i386 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 collectd-4.3.2-9.fc10.i386 requires librrd_th.so.2 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 ganglia-gmetad-3.0.7-1.fc9.i386 requires librrd.so.2 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 Broken deps for x86_64 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.i386 requires /bin/falcon Falcon-devel-0.8.10-1.fc10.x86_64 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) collectd-4.3.2-9.fc10.x86_64 requires librrd_th.so.2()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.i386 requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.i386 requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.x86_64 requires libicuuc.so.38()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ganglia-gmetad-3.0.7-1.fc9.x86_64 requires librrd.so.2()(64bit) lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.ppc requires /bin/falcon Falcon-devel-0.8.10-1.fc10.ppc64 requires /bin/falcon LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 collectd-4.3.2-9.fc10.ppc requires librrd_th.so.2 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc requires libicuuc.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicudata.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc requires libicui18n.so.38 fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) ganglia-gmetad-3.0.7-1.fc9.ppc requires librrd.so.2 lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- Falcon-devel-0.8.10-1.fc10.ppc64 requires /bin/falcon collectd-4.3.2-9.fc10.ppc64 requires librrd_th.so.2()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicudata.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicui18n.so.38()(64bit) fedora-ds-admin-1.1.4-1.fc9.ppc64 requires libicuuc.so.38()(64bit) ganglia-gmetad-3.0.7-1.fc9.ppc64 requires librrd.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From promac at gmail.com Mon Jun 9 09:30:35 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Mon, 9 Jun 2008 06:30:35 -0300 Subject: rkhunter aborting In-Reply-To: <20080608183314.586ea673@ohm.scrye.com> References: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> <20080608162049.69fd9120@ohm.scrye.com> <68720af30806081704peb61760j888358bbbd5626e3@mail.gmail.com> <20080608183314.586ea673@ohm.scrye.com> Message-ID: <68720af30806090230m6ee03587g24fbdcafe3f2305f@mail.gmail.com> 2008/6/8 Kevin Fenzi : > > > > What version is this? Output of: > > > > > > rpm -q rkhunter > > > rpm -V rkhunter > > > > [lua:~] rpm -q rkhunter > > rkhunter-1.3.2-3.fc8.noarch > > [lua:~] rpm -V rkhunter > > S.?....T c /etc/rkhunter.conf > > ..?..... c /etc/sysconfig/rkhunter > > Rats. I see the problem, the updated cron script didn't get copied > right into F-7 and F-8 branches. ;( My fault entirely... > > Can you try putting this one: > http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/rkhunter/01-rkhunter > in /etc/cron.daily/rkhunter ? > > I'll try and get this fixed in the next few days... I am planning > updates for that script anyhow. > > It worked. The only thing is that /var/run/rhhunter is 775. Since the copy of /etc/passwd and /etc/group is saved there after executing --propupd should not it be 700? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Mon Jun 9 10:13:44 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 9 Jun 2008 12:13:44 +0200 Subject: many things disappeared from the wiki? In-Reply-To: <484CF3F1.4040603@nigelj.com> References: <20080609074128.GB2566@free.fr> <2449.192.54.193.59.1212999339.squirrel@rousalka.dyndns.org> <20080609081817.GE2566@free.fr> <484CF3F1.4040603@nigelj.com> Message-ID: <20080609101344.GB23174@free.fr> On Mon, Jun 09, 2008 at 09:12:17PM +1200, Nigel Jones wrote: > > All new pages _should_ be created with spaces between major words (i.e. > what would have been 'CVSAdminProcedure' should now be 'CVS Admin > Procedure'), now while we can't do all that right now (cleaning up the > formatting is more important really) it's something to keep in mind > today onwards. Ok, makes sense. -- Pat From mbarnes at redhat.com Mon Jun 9 10:15:43 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Mon, 09 Jun 2008 06:15:43 -0400 Subject: Fedora's GtkSpell -> Enchant customisation In-Reply-To: <20080609112147.0fbb7b04.mschwendt@gmail.com> References: <20080609112147.0fbb7b04.mschwendt@gmail.com> Message-ID: <1213006544.18740.6.camel@localhost.localdomain> On Mon, 2008-06-09 at 11:21 +0200, Michael Schwendt wrote: > Bugzilla Bug 245888: Make gtkspell support Enchant/Hunspell > https://bugzilla.redhat.com/245888 > > This patch is from December 2007 and is not included in the new GtkSpell 2.0.12 > upstream update from May 2008. Has anything been done to get this accepted > upstream? >From GtkSpell's ChangeLog it looks like upstream suddenly sprang to life last month after three years of dormancy. I had assumed the project was abandoned. I'll try to contact the current maintainer (again) and see if he's interested in merging our patches. Matthew Barnes From dev at nigelj.com Mon Jun 9 10:27:57 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 09 Jun 2008 22:27:57 +1200 Subject: non responsive policy with invalid mail In-Reply-To: <604aa7910806081438g243f1801x300fba3ecee214d3@mail.gmail.com> References: <20080606184122.GC2760@free.fr> <604aa7910806081438g243f1801x300fba3ecee214d3@mail.gmail.com> Message-ID: <484D05AD.3080808@nigelj.com> Jeff Spaleta wrote: > On Fri, Jun 6, 2008 at 11:15 AM, Jason L Tibbitts III wrote: > >> On the other hand, I happily gave my telephone number in FAS and I'd >> hope to get a call in such an instance. >> > > > I'm not sure FAS exposes phone numbers to all contributors, but it > maybe only available to FAS admins. So if we want to incorporate a > phone ping of a missing maintainer into missing maintainer workflow we > might have to make a request to the correct group with access to the > phone numbers. > > -jef"allowing contributors to optionally exposing phone numbers to > co-maintainers or specific groups would be something to > consider"spaleta > I believe phone numbers are exposed to the FAS admins, maybe FESCo & Board might need to be considered for cvsextras and cla_done respectively. OTOH some people may 'disapprove' but I'd be accepting of such a setup. - Nigel From mbarnes at redhat.com Mon Jun 9 10:28:36 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Mon, 09 Jun 2008 06:28:36 -0400 Subject: Fedora's GtkSpell -> Enchant customisation In-Reply-To: <1213006544.18740.6.camel@localhost.localdomain> References: <20080609112147.0fbb7b04.mschwendt@gmail.com> <1213006544.18740.6.camel@localhost.localdomain> Message-ID: <1213007316.18740.9.camel@localhost.localdomain> On Mon, 2008-06-09 at 06:15 -0400, Matthew Barnes wrote: > I'll try to contact the current maintainer (again) and see if he's > interested in merging our patches. Actually, having just downloaded the source and taken a closer look, it appears the upstream author has already merged all our patches. So the 2.0.13 Rawhide package is patch-free. Matthew Barnes From valent.turkovic at gmail.com Mon Jun 9 10:28:39 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jun 2008 12:28:39 +0200 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <20080609074122.GA14855@redhat.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> <20080609074122.GA14855@redhat.com> Message-ID: <64b14b300806090328m6e16c720l8833adfb9d67a68d@mail.gmail.com> On Mon, Jun 9, 2008 at 9:41 AM, Daniel P. Berrange wrote: > On Mon, Jun 09, 2008 at 08:52:21AM +0200, Valent Turkovic wrote: >> Hi, >> I read a really disturbing message on local news group. One person has >> posted a question why is RedHat stopping support for Fedora Project. >> He clamis that he read that on RedHat press [1] page. That page is 404 >> now, but he swears that it was up. The summary was that RedHat is >> stopping support for Fedora Project after Fedora 10 and that it is >> giving awards for best contributers. I know that there is no page >> there now, but still I had to ask if anybody knows anything. Is this >> just FUD? > > That is complete & utter garbage & FUD. > > Regards, > Daniel. This is really nice to hear! Cheers, 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 jspaleta at gmail.com Mon Jun 9 10:40:31 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 9 Jun 2008 02:40:31 -0800 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> Message-ID: <604aa7910806090340v52f95c28v35dbd4aa0683989e@mail.gmail.com> On Mon, Jun 9, 2008 at 1:05 AM, Pavel Shevchuk wrote: > There was some talk about RH shifting priorities to do best at what > they are best already - servers, but abandoning fedora - definitely > not. Fedora is what they make RHEL from and they need open system to > test-drive technologies I humbly ask you to refrain from rumor mongering of any sort. 'Some talk' with regard to RH shifting priorities isn't a particular useful thing to say without a citable reference that I can follow up on with the Red Hat employee who made the statement. It's no more useful than the comments that started this thread. Let me put this to rest. As a Fedora Board member I have absolutely no information nor even a glimmer of feeling as to Red Hat taking any steps away from this community whatsoever. And all I do as a Board member is walk the back alleys and wander in out out of smoke-filled rooms doing under the table deals with shadowy figures using codenames like 'mongoose' and 'iceman' while exchanging packets of insider information in unsuspecting manila envelopes. I live and breath rumor and unspoken truths. And if Red Hat was about to take a step away from this community, it would take me completely by surprise. >From all accounts from LinuxTAG its clear that in the future its in everyone's best interest to expand Red Hat's involvement with Fedora globally. Frankly I think its only a matter of time before Red Hat has a Fedora community employee like Max on every continent, including Antarctica. If anything 'we'.. the community members and the Red Hat employees engaged in board level discussions are doing what we can to identify a long term strategy to grow the available resources. The Community Architecture team, which is our primary means through which Red Hat support is generated has a transparent budgeting process in our wiki, and is continually engaged in resource planning with members of the Fedora community. If Red Hat wasn't serious about Fedora, we wouldn't be in a position to even talk about budgets and long term growth. We are in this for the long haul, and I'm confident that as long as we continue to show the value in the community contribution model, Red Hat will make strategic investments to enable Fedora's growth. I take the issue of long term project sustainability quite seriously. To be quite honest, I am extremely disappointed that Valent decided that this was worth bringing to the attention of a general mailing list without a credible reference to refer to. I certainly wouldn't have made such a sensational posting such as this without making some discreet inquiries as to the validity of what I had heard. There isn't much in the original post to comment on, and the central argument of the original post runs counter to everything thing I know, and every personal interaction I've had in the last six months. -jef From ivazqueznet at gmail.com Mon Jun 9 11:34:34 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 09 Jun 2008 07:34:34 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <7f692fec0806090208j65f92222v953a9e2791bbdb03@mail.gmail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <7f692fec0806090208j65f92222v953a9e2791bbdb03@mail.gmail.com> Message-ID: <1213011274.17913.9.camel@ignacio.lan> On Mon, 2008-06-09 at 11:08 +0200, Yaakov Nemoy wrote: > On Fri, Jun 6, 2008 at 4:49 PM, Matej Cepl wrote: > > Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let > > one or two Rawhide cycles to make all warnings disappear? > > Theoretically, probably. I'm not sure we have enough eyeballs that > could make that happen though. Then we'll just have to be meticulous about it. -- 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 katzj at redhat.com Mon Jun 9 11:35:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Jun 2008 07:35:53 -0400 Subject: Retiring Opyum In-Reply-To: References: <3170f42f0806061141q5ca5d043sa8be129d35a4d341@mail.gmail.com> <484A5B09.3000207@kanarip.com> <484BD5CD.5080201@iinet.net.au> Message-ID: <1213011353.32560.24.camel@aglarond.local> On Mon, 2008-06-09 at 10:35 +0300, Panu Matilainen wrote: > On Sun, 8 Jun 2008, David Timms wrote: > > It would sort of make sense to be able say in a spec: > > Provides: pirut(functionality) > > ie equivalent functionality = gui package management > > rather than the pirut(api) ? > > "Pirut" is just a name and an implementation detail, you'd want something > along the lines of "Provides: package-manager-gui" similarly to httpd > providing "webserver" etc, that apps just wanting a GUI package manager > can depend on. Blindly adding provides for everything obsoleted is just > BAD, unless they actually provide a compatible interface (be it API or > command names). Although it does make the point that we should dig out the python auto-provides/requires and see about enabling them again. That would then add the fact that pirut had provided a certain API which was required by things. Jeremy From katzj at redhat.com Mon Jun 9 11:36:58 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Jun 2008 07:36:58 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <7f692fec0806090208j65f92222v953a9e2791bbdb03@mail.gmail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <7f692fec0806090208j65f92222v953a9e2791bbdb03@mail.gmail.com> Message-ID: <1213011418.32560.25.camel@aglarond.local> On Mon, 2008-06-09 at 11:08 +0200, Yaakov Nemoy wrote: > On Fri, Jun 6, 2008 at 4:49 PM, Matej Cepl wrote: > > On Mon, 02 Jun 2008 21:15:33 -0400, Ignacio Vazquez-Abrams scripst: > >> On Mon, 2008-06-02 at 22:58 +0200, Christoph H?ger wrote: > >>> could you point out why exactly there is "something to do"? > >>> > >>> I mean, python3000 is a new language and no replacement so if someone > >>> is willing to package it (or a package that depends on py3k) she/he > >>> should make sure its a python2.x compatible installation (especially in > >>> the naming of the package). That should be all, right? > >> > >> Python 2.x *will* be discontinued at some time in the future. It may be > >> a few years, but it will happen. > > > > Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let > > one or two Rawhide cycles to make all warnings disappear? > > Theoretically, probably. I'm not sure we have enough eyeballs that > could make that happen though. I suspect it will. And we won't have to do all of it, either. Upstreams will start looking at the move as well as other distros which should help to make it more practical. Jeremy From ivazqueznet at gmail.com Mon Jun 9 11:37:36 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 09 Jun 2008 07:37:36 -0400 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: <484CBDBA.9030405@gmail.com> References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> Message-ID: <1213011456.17913.11.camel@ignacio.lan> On Sun, 2008-06-08 at 22:20 -0700, Toshio Kuratomi wrote: > Kevin Kofler wrote: > > Michel Salim gmail.com> writes: > >> Should applications that put files under /usr/share/gnome/help be > >> required to own it (or depend on yelp)? > > > > Own it maybe, depend on yelp definitely not, at least not in anything which > > ends up on the KDE spin (e.g. the system-config-* tools required by Anaconda). > > We don't want the whole xulrunner stack on the KDE spin, we don't have room for > > it. (We use Konqueror as the browser on the KDE spin, not Firefox.) > > > Err... the last time this came up it was successfully argued that having > "Help" fail to work was a bug. The initial idea was to have something > within the GNOME stack require yelp but I believe that failed because of > circular dependencies. > > So if this will cause problems because of system-config-* dragging in > xulrunner we need to come up with some other way of solving the > help-won't-display bug. What about migrating yelp to WebKit-gtk? -- 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 aph at redhat.com Mon Jun 9 11:42:43 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 09 Jun 2008 12:42:43 +0100 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> Message-ID: <484D1733.6050200@redhat.com> Valent Turkovic wrote: > Hi, > I read a really disturbing message on local news group. One person has > posted a question why is RedHat stopping support for Fedora Project. > He clamis that he read that on RedHat press [1] page. Which local news group? When did he see it? Andrew. > [1] http://www.press.redhat.com/2008/06/06/fedora-project-summary-and-awards From kevin.kofler at chello.at Mon Jun 9 11:50:18 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 11:50:18 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> Message-ID: Toshio Kuratomi gmail.com> writes: > Err... the last time this came up it was successfully argued that having > "Help" fail to work was a bug. The initial idea was to have something > within the GNOME stack require yelp but I believe that failed because of > circular dependencies. > > So if this will cause problems because of system-config-* dragging in > xulrunner we need to come up with some other way of solving the > help-won't-display bug. IMHO it is not a bug, help is an optional feature, and we have tight size constraints on the live images. We also faced a similar issue with KDE 3 apps dragging in all the KDE 4 stack because khelpcenter is now from KDE 4, there too (even though this probably doesn't affect any of the live images) we decided to not put a dependency in and to simply have help in KDE 3 apps only work if the KDE 4 kdebase-runtime is installed (which will always be the case in a KDE installation anyway). Kevin Kofler From kevin.kofler at chello.at Mon Jun 9 12:05:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 12:05:24 +0000 (UTC) Subject: Fedora Freedom and linux-libre References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <20080608223436.GA26726@devserv.devel.redhat.com> <1212997233.32207.584.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > (In the latter case, the person who released software under that licence > may get in trouble for promoting an attitude of violence, but you still > wouldn't be permitted to use his software). Actually, as far as I know (but I am not a lawyer!), in most European countries you can, because the clause requiring murder is obviously invalid/unacceptable ("unzul?ssig" in German-speaking countries) and thus unenforcible. Kevin Kofler From linville at redhat.com Mon Jun 9 14:26:13 2008 From: linville at redhat.com (John W. Linville) Date: Mon, 9 Jun 2008 10:26:13 -0400 Subject: Kernel headers changes in F10? In-Reply-To: <20080603134725.GA12485@redhat.com> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> <20080602172853.GB27063@redhat.com> <484431A3.6010706@hhs.nl> <20080603134725.GA12485@redhat.com> Message-ID: <20080609142612.GA6336@redhat.com> On Tue, Jun 03, 2008 at 09:47:25AM -0400, John W. Linville wrote: > On Mon, Jun 02, 2008 at 07:45:07PM +0200, Hans de Goede wrote: > > John W. Linville wrote: > > >On Mon, Jun 02, 2008 at 07:13:27PM +0200, Hans de Goede wrote: > > >>John W. Linville wrote: > > > >>>Almost certainly because of this commit: > > >>> > > >>>commit 2218228392080f0ca2fc2974604e79f57b12c436 > > >>>Author: Kirill A. Shutemov > > >>>Date: Tue Apr 22 16:38:55 2008 +0300 > > >>> > > >>> Make linux/wireless.h be able to compile > > >>> > > >>> Signed-off-by: Kirill A. Shutemov > > >>> Signed-off-by: John W. Linville > > >>> > > >>>I may have let this slip by due to the "able to compile" bit -- > > >>>should I not have merged it? I don't have a record or recollection > > >>>of what motivated the patch originally. > > > >As I said, I have no record or memory of why this patch was needed. > > >It looks like it was a mistake for me to let it though in the first > > >place. My guess is that he wanted to include linux/wireless.h from > > >userland without including other kernel headers...? > > > > Looks like a good candidate for reverting. I see little arguments to keep > > this patch in, it will probably break compilation of other users of > > linux/wireless.h too, as those probably also already include to > > get the necessary stuff from there. > > I have reverted that patch in rawhide, and I'm working with Kirill > for a more permanent solution. FWIW, Dave M. NAKed the partial-revert attempt upstream. Can the userland packages cope? John -- John W. Linville linville at redhat.com From valent.turkovic at gmail.com Mon Jun 9 14:55:40 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jun 2008 16:55:40 +0200 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <604aa7910806090340v52f95c28v35dbd4aa0683989e@mail.gmail.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> <604aa7910806090340v52f95c28v35dbd4aa0683989e@mail.gmail.com> Message-ID: <64b14b300806090755v389a6c59r1f7f606e7ac6b5fa@mail.gmail.com> On Mon, Jun 9, 2008 at 12:40 PM, Jeff Spaleta wrote: > On Mon, Jun 9, 2008 at 1:05 AM, Pavel Shevchuk wrote: >> There was some talk about RH shifting priorities to do best at what >> they are best already - servers, but abandoning fedora - definitely >> not. Fedora is what they make RHEL from and they need open system to >> test-drive technologies > > I humbly ask you to refrain from rumor mongering of any sort. 'Some > talk' with regard to RH shifting priorities isn't a particular useful > thing to say without a citable reference that I can follow up on with > the Red Hat employee who made the statement. It's no more useful than > the comments that started this thread. > > Let me put this to rest. As a Fedora Board member I have absolutely no > information nor even a glimmer of feeling as to Red Hat taking any > steps away from this community whatsoever. > > And all I do as a Board member is walk the back alleys and wander in > out out of smoke-filled rooms doing under the table deals with shadowy > figures using codenames like 'mongoose' and 'iceman' while exchanging > packets of insider information in unsuspecting manila envelopes. I > live and breath rumor and unspoken truths. And if Red Hat was about > to take a step away from this community, it would take me completely > by surprise. > > >From all accounts from LinuxTAG its clear that in the future its in > everyone's best interest to expand Red Hat's involvement with Fedora > globally. Frankly I think its only a matter of time before Red Hat > has a Fedora community employee like Max on every continent, including > Antarctica. > > If anything 'we'.. the community members and the Red Hat employees > engaged in board level discussions are doing what we can to identify a > long term strategy to grow the available resources. The Community > Architecture team, which is our primary means through which Red Hat > support is generated has a transparent budgeting process in our wiki, > and is continually engaged in resource planning with members of the > Fedora community. If Red Hat wasn't serious about Fedora, we wouldn't > be in a position to even talk about budgets and long term growth. We > are in this for the long haul, and I'm confident that as long as we > continue to show the value in the community contribution model, Red > Hat will make strategic investments to enable Fedora's growth. > > I take the issue of long term project sustainability quite seriously. > To be quite honest, I am extremely disappointed that Valent decided > that this was worth bringing to the attention of a general mailing > list without a credible reference to refer to. I certainly wouldn't > have made such a sensational posting such as this without making some > discreet inquiries as to the validity of what I had heard. There > isn't much in the original post to comment on, and the central > argument of the original post runs counter to everything thing I know, > and every personal interaction I've had in the last six months. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I know that the rumor was 99% FUD but the rummors on the local news groups just wouldn't die off and they continued continuously sinte it was posted 3 days ago so I believed that my only option is to go directly to the source and then point people to that "official" resonse in the future. I know that people don't like geting private mails and that they usually like things to be open and in open discusion and because of all those reasons I postet my question here. Not becuase I believed it but because others believed it and starder doubting Fedora as a project. There already were few people who said that they thought to join Fedora Project in Croatia but becaus of that news post they changed their mind. Please tell me what would be better way to deal this issue? Cheers, 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 Mon Jun 9 14:56:51 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jun 2008 16:56:51 +0200 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <484D1733.6050200@redhat.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> <484D1733.6050200@redhat.com> Message-ID: <64b14b300806090756r4c0c5286m30ccaf4334012a55@mail.gmail.com> On Mon, Jun 9, 2008 at 1:42 PM, Andrew Haley wrote: > Valent Turkovic wrote: >> Hi, >> I read a really disturbing message on local news group. One person has >> posted a question why is RedHat stopping support for Fedora Project. >> He clamis that he read that on RedHat press [1] page. > > Which local news group? When did he see it? > > Andrew. > > >> [1] http://www.press.redhat.com/2008/06/06/fedora-project-summary-and-awards > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > http://groups.google.com/group/hr.comp.os.linux/browse_thread/thread/0d48919016555421/92b06ba88fe7d314#92b06ba88fe7d314 it is Croatian linux news group. Cheers, 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 Mon Jun 9 15:01:02 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jun 2008 17:01:02 +0200 Subject: "Fedora Project summary and awards" - end of RedHat support? In-Reply-To: <64b14b300806090756r4c0c5286m30ccaf4334012a55@mail.gmail.com> References: <64b14b300806082352r64a54813j42c623ba4eb69bb7@mail.gmail.com> <484D1733.6050200@redhat.com> <64b14b300806090756r4c0c5286m30ccaf4334012a55@mail.gmail.com> Message-ID: <64b14b300806090801j5c9b789bi611e83de4e4860aa@mail.gmail.com> On Mon, Jun 9, 2008 at 4:56 PM, Valent Turkovic wrote: > On Mon, Jun 9, 2008 at 1:42 PM, Andrew Haley wrote: >> Valent Turkovic wrote: >>> Hi, >>> I read a really disturbing message on local news group. One person has >>> posted a question why is RedHat stopping support for Fedora Project. >>> He clamis that he read that on RedHat press [1] page. >> >> Which local news group? When did he see it? >> >> Andrew. >> >> >>> [1] http://www.press.redhat.com/2008/06/06/fedora-project-summary-and-awards >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > http://groups.google.com/group/hr.comp.os.linux/browse_thread/thread/0d48919016555421/92b06ba88fe7d314#92b06ba88fe7d314 > > it is Croatian linux news group. > > Cheers, > 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 > This is the start of the thread: http://groups.google.com/group/hr.comp.os.linux/browse_thread/thread/d48919016555421/9ce85fc4131b3d88 -- 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 loganjerry at gmail.com Mon Jun 9 15:49:29 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 9 Jun 2008 09:49:29 -0600 Subject: Some highlights about MediaWiki for noobs :) In-Reply-To: References: Message-ID: <870180fe0806090849m352ad8a6u18948d4a80805b53@mail.gmail.com> On Sun, Jun 8, 2008 at 12:36 AM, Peter Lemenkov wrote: > Pages, which are good candidates for merging, can be found there: > > List of users: https://fedoraproject.org/wiki/Special:Listusers > List of lonely pages: https://fedoraproject.org/wiki/Special:Lonelypages > > I found that many users still didn't link their new login-name with > their old personal pages. > My page has very little content, so I just created my new page and copied the content over. Now I can't figure out how to delete the old page. Is there a good site where a mediawiki newbie like me can learn how to get around? -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Mon Jun 9 15:52:56 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 9 Jun 2008 09:52:56 -0600 Subject: rkhunter aborting In-Reply-To: <68720af30806090230m6ee03587g24fbdcafe3f2305f@mail.gmail.com> References: <68720af30806080545v7a9c15acq300530f7a161f495@mail.gmail.com> <20080608162049.69fd9120@ohm.scrye.com> <68720af30806081704peb61760j888358bbbd5626e3@mail.gmail.com> <20080608183314.586ea673@ohm.scrye.com> <68720af30806090230m6ee03587g24fbdcafe3f2305f@mail.gmail.com> Message-ID: <20080609095256.71313f2a@ohm.scrye.com> On Mon, 9 Jun 2008 06:30:35 -0300 promac at gmail.com ("Paulo Cavalcanti") wrote: > 2008/6/8 Kevin Fenzi : > > > > > > > What version is this? Output of: > > > > > > > > rpm -q rkhunter > > > > rpm -V rkhunter > > > > > > [lua:~] rpm -q rkhunter > > > rkhunter-1.3.2-3.fc8.noarch > > > [lua:~] rpm -V rkhunter > > > S.?....T c /etc/rkhunter.conf > > > ..?..... c /etc/sysconfig/rkhunter > > > > Rats. I see the problem, the updated cron script didn't get copied > > right into F-7 and F-8 branches. ;( My fault entirely... > > > > Can you try putting this one: > > http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/rkhunter/01-rkhunter > > in /etc/cron.daily/rkhunter ? > > > > I'll try and get this fixed in the next few days... I am planning > > updates for that script anyhow. > > > > > > > It worked. Excellent. > The only thing is that /var/run/rhhunter is 775. > Since the copy of /etc/passwd and /etc/group is saved there after > executing --propupd > should not it be 700? Well, anyone can read /etc/passwd and /etc/group directly right? > Thanks. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lesmikesell at gmail.com Mon Jun 9 16:36:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 11:36:59 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212996568.32207.572.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> Message-ID: <484D5C2B.4010700@gmail.com> David Woodhouse wrote: > On Sun, 2008-06-08 at 17:29 -0500, Les Mikesell wrote: >> Do you mean the part about identifiable sections that are not derived >> from the program and can be reasonably considered independent and >> separate works? That would seem the only possible interpretation for >> firmware blobs. > > Exactly that part, yes. Where it says that the GPL applies to them > anyway. Can you quote that? My copies all say it doesn't. > Specifically, the bit where where it says that the GPL (obviously) > doesn't "apply to those sections when you distribute them as separate > works. But when you distribute those _same_ sections as part of a whole > which is a work based on the Program, the distribution of the whole must > be on the terms of this License, whose permissions to other licensees > extend to the entire whole, and thus to each and every part regardless > of who wrote it." Firmware that happens to be aggregated for convenient delivery and installation is no more a part of the GPL'd work than firmware that is already in your machine or than it would be if someone sent you a handful of new ROMs to plug in, or if you had a separate pre-run initialization program that downloaded all these separate components and registry initializers. > I agree with you that that seems to be the only possible interpretation > for firmware blobs. Aggregation is the only possible interpretation since it is just a delivery mechanism for something no more related than ROM contents would be. > And when we take them and include them in the > bzImage and distribute that, the only possible interpretation is that > they are 'part of a whole which is a work based on the Program'. No, _how_ you aggregate something is irrelevant. You are talking about file formats and containers here. > You do get an exception for 'mere aggregation on a volume of a storage > or distribution medium', which covers stuff like shareware/freeware CDs > on the covers of magazines -- so unrelated stuff which happens to be > shipped together in _that_ form doesn't get infected by the GPL. Form has nothing to do with it - the terms apply to the content, not the intermediate storage. > But it's extremely hard to argue that combining non-GPL'd firmware into > the kernel image is 'mere aggregation on a volume of a storage or > distribution medium'. It is exactly as much a part of the kernel as firmware that is already in ROM is - that is, not at all. > I know some people like to conveniently abbreviate that to 'mere > aggregation' -- since "mere" doesn't really mean much, so then they like > to claim it actually excuses _all_ forms of aggregation, effectively > cancelling out the previous two paragraphs of the GPL in their entirety. No, the GPL applies to components that actually are parts of a work as whole or derivatives. Firmware is something separate, just carried along for the ride. It could clearly be already present in ROM or pre-loaded by something other than the kernel. > I don't find that interpretation particularly realistic, though -- > although nobody is right or wrong about it until/unless a court rules on > it, of course. Exactly - until a court says that the file format used to carry a separate component is relevant, it is just as much a separate entity as equivalent ROM contents. > To claim that there is no _legal_ basis for such a restriction is also > incorrect. Nothing but the GPL gives you the right to distribute the > Linux kernel. If the GPL has conditions with which you fail to comply, > then you may not distribute the Linux kernel. I'm not sure why you'd consider being unable to distribute the Linux kernel to be a desirable thing, but the point here is that the GPL explicitly allows aggregation and nothing in copyright law or any court decisions that I've heard of have excluded bzImage or any other specific file formats as delivery containers for such aggregation. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Mon Jun 9 16:54:42 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 09 Jun 2008 13:54:42 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609092041.GB13454@devserv.devel.redhat.com> (Alan Cox's message of "Mon\, 9 Jun 2008 05\:20\:41 -0400") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> Message-ID: On Jun 9, 2008, Alan Cox wrote: > On Mon, Jun 09, 2008 at 08:29:28AM +0100, David Woodhouse wrote: >> I agree with you that that seems to be the only possible interpretation >> for firmware blobs. And when we take them and include them in the >> bzImage and distribute that, the only possible interpretation is that >> they are 'part of a whole which is a work based on the Program'. > Disagree. Please elaborate. Do you disagree he agrees with you? :-) Do you see other interpretations? Do you disagree we take them and include them in the bzImage and distribute that (or any of these individually)? Do you disagree it's part of a whole? Do you disagree this whole it is part of is a work based on the Program? >> But it's extremely hard to argue that combining non-GPL'd firmware into >> the kernel image is 'mere aggregation on a volume of a storage or >> distribution medium'. > Disagree. Three bytes: tg3 Same source file, even. Mere aggregation? Where can I get the separate works, then? > learn about the actual legal caselaw in the case things like books, Since you appear to have done your homework, could you please help me find any case in which a book was published containing an article whose authors wrote something like 'I will only permit the publication of this article if all the articles in the book, and the whole of the book, are under a copyleft license', the book was published with of non-copyleft material, and the author of the article sued for copyright infringement? > and also on the boundaries of contract created by copyright. ?!?!? Copyright does not create contracts. Copyright creates restrictions that a copyright holder may selectively enforce on third parties. Licenses relieve third parties from such restrictions. Contracts often include provisions for licensing, but a mere grant of permissions is not a contract because there's no reciprocation, no mutual obligations. The GPL, for example, is a mere grant of permissions. It does not require or prohibit anything, it just grants bounded permissions. Whatever is forbidden even in the presence of the GPL is forbidden because the law forbids such actions without a license that permits them, not because the GPL prohibits them. Example: a law is passed that prohibits people from walking on their feet. The king grants permission for you to walk on a single foot. You still can't walk on both feet, but that's not because the grant of permissions forbids you from walking normally, it's because the law does. The permission you got just doesn't go as far as granting you permission to walk that way. On Jun 9, 2008, Alan Cox wrote: > On Mon, Jun 09, 2008 at 08:40:33AM +0100, David Woodhouse wrote: >> Are you suggesting that the bzImage we ship is not derived from the >> kernel source? Or that to distribute it, you don't need the permission >> which is granted by the GPL? > Nothing of the sort. I'm suggesting conventional interpretations of copyright > law might apply. The ones the lawyers seem to consider conventional IIRC it says that modifying, distributing (including publishing) a work requires permission from the copyright holder, and, in the absence of such a permission, such acts are forbidden by law. Do you even have a case here? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From a.badger at gmail.com Mon Jun 9 16:56:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Jun 2008 09:56:55 -0700 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> Message-ID: <484D60D7.70100@gmail.com> Matej Cepl wrote: > On Mon, 02 Jun 2008 21:15:33 -0400, Ignacio Vazquez-Abrams scripst: >> On Mon, 2008-06-02 at 22:58 +0200, Christoph H?ger wrote: >>> could you point out why exactly there is "something to do"? >>> >>> I mean, python3000 is a new language and no replacement so if someone >>> is willing to package it (or a package that depends on py3k) she/he >>> should make sure its a python2.x compatible installation (especially in >>> the naming of the package). That should be all, right? >> Python 2.x *will* be discontinued at some time in the future. It may be >> a few years, but it will happen. > > Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let > one or two Rawhide cycles to make all warnings disappear? > I had a look at python-2.6 vs (python-2.5 and python-3.0) this weekend. It looks like this might be a viable path. Here's what I found:: * 2.6 appears to be mostly compatible with 2.5.x. Porting from 2.5.x to 2.6.x seems like it will be pretty routine stuff. * 2.6 seems to be mostly compatible with 3.0 if you use from __future__ import all-the-stuff-that-changed. * It appears that we can mix these with file-level granularity. If this works out we should be able to port individual modules to 3.0 syntax while other modules stay on 2.x. Outstanding issues I saw: * There are some corner cases around unicode handling. 2.6.x with from __future__ does translation so string literals ("Hello World") become type ``unicode`` instead of type ``str``. In 3.0, the implementation of ``str`` is what ``unicode`` is, ``unicode`` no longer exists, and ``byte`` is what ``str`` was. Most things that returned ``str`` will now return ``unicode``. This will have issues for: * Code that checks for unicode type will run on 2.6 but break on 3.x. This includes things like to_unicode()/to_utf8() functions that translate between encodings of unicode and the ``unicode`` type. * Code that loads data from a file, the network, or other source external to python *might* break since there's a variety of different ways this code can decide to return the data and the behaviour will likely change:: 2.x 3.x Evaluation str byte Should happen if no decoding of the bytes is done in the library. Means that things like "print (output)" will no longer work right as this is now a sequence of bytes rather than a string. unicode str Should happen if the library converts bytes to unicode type already. str str Should only happen if the library is updated to convert from raw bytes to unicode. If it doesn't, it's a bug in the library. unicode byte Should only happen if the library drops support for converting from bytes to unicode. Note that there's been updates to file io that may help this: The default encoding is now utf-8 instead of ascii and files that are read using: my_file = open(filename, 'r') will yield unicode lines translated from utf-8 while my_file =open(filename, 'rb') will yield arrays of type ``byte``. * There are incompatible changes to the standard library for 3.x. These changes will affect programs which make use of those modules. (This can happen between 2.x releases as well, just to a different extent). * Similar to the above point, there have been some changes to __builtins__ for 3.x. This means that file() works in 2.6.x but not in 3.x, for instance. So here's a new proposal to shoot down (modified from Jeremy's ideas): 1) Fedora 10 ships with the latest python-2.5.x. 2) The Fedora 11 development tree switches to python-2.6.x soon after F10 is released. 3) We start packaging 3.x versions of modules in preference to 2.x versions where it makes sense (ie: upstream is shipping 3.x based releases; the 3.x code doesn't depend on any of the 3.x library reorganization.) 4) We port our own code to run on 2.6.x with from __future__ import -everything-that-3.x-changes. 5) At the start of F12 development and every release thereafter we evaluate how many modules we still ship that are 2.x only, how much longer py-2.6.x is going to be supported, and how much further python-3.x has diverged from python-2.6.x. At some point the cost-benefit will be such that we move to python-3.x, port upstreams to py-3.x or abandon them, and make sure our code runs on "the real" python-3.x. Risks: * We don't know how compatible python-2.6 and python-3.x will be until they are released. We don't know how compatible they will remain through the life of python-2.6 and as future releases in the python-3.x series are made. * We may have to port some code twice, once for "2.6-in-3.x-mode" and once for the real 3.x (but the ports should each be smaller sizes) * Code we port will need to run on python 2.6 or higher. There will be no way to run code on both python <= 2.5.x and python >= 3.x. In particular, this means that RHEL/CENTOS-5.(0,1,2) will not run the code we port. Infrastructure Group members, take note of this :-(. * We'll be using python-2.6 as a bridge between py-3.x and py-2.x code (Code ported to 3.x importing code written for 2.x and vice versa). We don't know how well tested and maintained that use-case will be. (But we can hope it's well maintained as it does make transitioning between python-2.x and python-3.x easier, which is one of 2.6.x's goals.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Mon Jun 9 17:03:50 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 12:03:50 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: Message-ID: <484D6276.4000308@gmail.com> Alexandre Oliva wrote: > > The tolerance for non-Free Software in Linux's sources (and anywhere > else), be it non-Free firmware blobs, be it drivers developed under > NDA (whose code is obscured and harder or impossible to understand and > adapt to one's needs as a consequence of the NDA), all revolve around > acceptance, endorsement and even promotion of unethical practices that > I don't want to condone or participate in. Not wanting to participate in distributing code without source is one thing; calling it unethical is something else and implies that everyone else is wrong for doing it. > Working towards retaining the ability for people to distribute and use > blobs along with Linux, rather than merely removing the blobs like we > do in Linux-libre, amounts to condoning this practice. It does not > advance our cause. In fact, as others pointed out, such changes make > it easier for unethical vendors to add even more of their blobs to > Linux (or co-maintained packages), which is actually detrimental to > our cause: And again, vendors who distribute code without source are not necessarily unethical even if you don't want to participate in helping the people who would find that code useful or necessary. > Have fun. And please don't bother disputing the values that led to my > conclusion, they're firmly set and the flame war would probably just > annoy everyone who doesn't enjoy this kind of discussion. Now, if you > find any flaws in the reasoning that took me from the premises to the > conclusions, I'd be happy to read about them and discuss them. Personally I consider competition and equality (i.e. having your choice of components) to be much more important than source availability for any component. Thus restrictions on combining and redistributing components are much more evil, unethical, and detrimental to long term developments than any current NDA or binary blob could ever be. -- Les Mikesell lesmikesell at gmail.com From a.badger at gmail.com Mon Jun 9 17:09:08 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Jun 2008 10:09:08 -0700 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> Message-ID: <484D63B4.8050705@gmail.com> Kevin Kofler wrote: > Toshio Kuratomi gmail.com> writes: >> Err... the last time this came up it was successfully argued that having >> "Help" fail to work was a bug. The initial idea was to have something >> within the GNOME stack require yelp but I believe that failed because of >> circular dependencies. >> >> So if this will cause problems because of system-config-* dragging in >> xulrunner we need to come up with some other way of solving the >> help-won't-display bug. > > IMHO it is not a bug, help is an optional feature, and we have tight size > constraints on the live images. > > We also faced a similar issue with KDE 3 apps dragging in all the KDE 4 stack > because khelpcenter is now from KDE 4, there too (even though this probably > doesn't affect any of the live images) we decided to not put a dependency in > and to simply have help in KDE 3 apps only work if the KDE 4 kdebase-runtime is > installed (which will always be the case in a KDE installation anyway). > Giving a newbie a linux live cd to try without having help files is far from ideal. Ways to solve the problem are appreciated. Reasons why you consider it an optional feature rather than an integral part of the user experience will be listened to and either argued with or create converts. Merely claiming size constraints is not likely to create change -- the x86_64 spins of both the live Desktop and live KDE spins are both larger than a CD already. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Mon Jun 9 17:50:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 12:50:19 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> Message-ID: <484D6D5B.5050306@gmail.com> Alexandre Oliva wrote: > >> learn about the actual legal caselaw in the case things like books, > > Since you appear to have done your homework, could you please help me > find any case in which a book was published containing an article > whose authors wrote something like 'I will only permit the publication > of this article if all the articles in the book, and the whole of the > book, are under a copyleft license', the book was published with of > non-copyleft material, and the author of the article sued for > copyright infringement? Even if such a copyright existed, it would not resemble the GPL which explicitly permits works with other terms to be aggregated (and probably would trigger some anti-competitive laws if it tried to restrict that). You'll note that printed combinations of different works do exist and the terms under which each is included do not affect the others. > The GPL, for example, is a mere grant of permissions. It does not > require or prohibit anything, it just grants bounded permissions. > Whatever is forbidden even in the presence of the GPL is forbidden > because the law forbids such actions without a license that permits > them, not because the GPL prohibits them. And thus it has no relationship to other things that might be carried in the same container, regardless of the form of that container. Firmware that happens to live in a vmlinuz container for a while is still no more a part of the kernel than it would be if you had a bag of ROMs that you had to insert yourself to get the same code loaded in your hardware. The difference is just the convenience of the update mechanism. Perhaps someone could write a non-GPL'd alternative loader that would install the firmware and hardware initializers, then load the kernel just to prove this point if they wanted to waste time like writing the fgmp library once did to enable distribution of some less restricted code. >> Nothing of the sort. I'm suggesting conventional interpretations of copyright >> law might apply. The ones the lawyers seem to consider conventional > > IIRC it says that modifying, distributing (including publishing) a > work requires permission from the copyright holder, and, in the > absence of such a permission, such acts are forbidden by law. Do you > even have a case here? A case of what? Content is content, and firmware is just as much separate and independent content whether it is installed on the fly or already in ROM. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Mon Jun 9 17:54:07 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 09 Jun 2008 14:54:07 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1212959526.2534.62.camel@shinybook.infradead.org> (David Woodhouse's message of "Sun\, 08 Jun 2008 22\:12\:06 +0100") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> Message-ID: On Jun 8, 2008, David Woodhouse wrote: > That's nothing special -- it's just the same as we should always be > vigilant for someone slipping non-GPL'd _code_ into the kernel. > Should we just give up, just because people slip up occasionally? Certainly not. But unfortunately it's not just the same. Slipping non-GPL code into the kernel would be a license violation. Legal issues tend to carry a lot more weight than "weaker" policy mandates (*) But what I'm more concerned about has nothing to do with copyright infringement. It has to do with respecting the 4 essential freedoms. Not just firmware. Drivers developed under conditions that deny users the ability to study the source code, understand it, and adapt it to their own needs do not respect freedom #1, even if they are perfectly compliant with the GPL. And I very much doubt think anyone would succeed in removing from, or preventing the addition of drivers to, Linux just because documentation is unavailable and the source code is obscure. If most head Linux developers go to such great lengths to find and wield excuses (*) to justify and defend the addition of code that is so obviously obfuscated and disrespectful of users' 4 essential freedoms (blobs), why would NDA-obscured drivers get treated any more seriously? This is not a case of slipping up. Those are easy to fix, if policies were taken seriously. This is (tacit or explicit) policy based on priorities, "corporate culture", and values held within the team that develops the software. Same thing here in Fedora. How can the policy to make an exception and accept some non-Free software "because it's essential to some users" make sense when other pieces of software that are just are non-Free and just as allegedly essential are banished on the grounds of being non-Free? "But it runs on a separate processor" doesn't even begin to relate with the alleged reasons of their being essential. (*) I wouldn't qualify the distribution of blobs in the Linux kernel as a legal risk these days, and my guess is that this is the sort of opinion that Linus got when he asked his lawyers about it. Consider this: (i) who could possibly claim infringement, and (ii) what would the consequences be? (i) copyright holders of Linux and of the blobs (ii) automatic termination of the license for everyone who has ever distributed the infringing version So, you see, why would a Linux copyright holder push the button if the mass destruction would take themselves down just like everyone else? At this point, given the tacit and vocal acceptance of this kind of code in the kernel, it would even be hard to defend a claim of secondary liability for induction to infringement by the parties who contributed the code to Linux, or by the parties who accepted it. Now, why would any of the copyright holders of the blobs push the button if the result would be the removal of the code that quite likely they contributed themselves in order to support the hardware they sell? That would be little more than FUD and sabotaging. So, no, I don't see any material legal risks in distributing non-Free Linux as it stands today, but this doesn't mean it's permitted by the license or by copyright law. As I stated before, it's a moral, ethical and social issue, even if it's also a negligible legal issue. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Mon Jun 9 17:59:23 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 09 Jun 2008 14:59:23 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D5C2B.4010700@gmail.com> (Les Mikesell's message of "Mon\, 09 Jun 2008 11\:36\:59 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> Message-ID: On Jun 9, 2008, Les Mikesell wrote: > Firmware that happens to be aggregated for convenient delivery and > installation is no more a part of the GPL'd work than firmware that is > already in your machine That's missing the point. It's not so much about the firmware, it's about the GPLed work that depends on it. If you can't "just take the firmware out", and there's no way to obtain the GPL'ed allegedly-separate work, how could the claim of 'mere aggregation' hold any water? Aggregation of what separate works? Where are they? > No, the GPL applies to components that actually are parts of a work as > whole or derivatives. Firmware is something separate, just carried > along for the ride. No, your honor, this is not a book that I printed for sale. It's just a bunch of pages from unrelated works that I stapled/bound together in large quantities and offered to book retailers in exchange for pieces of paper of a different color. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From sundaram at fedoraproject.org Mon Jun 9 18:01:06 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 09 Jun 2008 23:31:06 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D5C2B.4010700@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> Message-ID: <484D6FE2.9000908@fedoraproject.org> Les Mikesell wrote: > David Woodhouse wrote: >> To claim that there is no _legal_ basis for such a restriction is also >> incorrect. Nothing but the GPL gives you the right to distribute the >> Linux kernel. If the GPL has conditions with which you fail to comply, >> then you may not distribute the Linux kernel. > > I'm not sure why you'd consider being unable to distribute the Linux > kernel to be a desirable thing, Since he said no such thing, it is pretty rude to claim that. This is undesirable tactics in a argument that is being used repeatedly. Rahul From lesmikesell at gmail.com Mon Jun 9 18:16:16 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 13:16:16 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D6FE2.9000908@fedoraproject.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D6FE2.9000908@fedoraproject.org> Message-ID: <484D7370.6040408@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> David Woodhouse wrote: > >>> To claim that there is no _legal_ basis for such a restriction is also >>> incorrect. Nothing but the GPL gives you the right to distribute the >>> Linux kernel. If the GPL has conditions with which you fail to comply, >>> then you may not distribute the Linux kernel. >> >> I'm not sure why you'd consider being unable to distribute the Linux >> kernel to be a desirable thing, > > Since he said no such thing, it is pretty rude to claim that. This is > undesirable tactics in a argument that is being used repeatedly. Sorry, if I misunderstood. When someone describes an alternative to promote their argument, I assume they are promoting the alternative as well. But what did that mean if it's not what he wants? -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Mon Jun 9 18:19:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Jun 2008 14:19:38 -0400 Subject: Requirements gathering for new package source control Message-ID: <1213035578.30252.10.camel@localhost.localdomain> At the upcoming FUDCon I plan to hold a session or two regarding requirements and discussions about the future of our package source control. This is NOT a time to argue about one SCM being "better" than another. I don't really want to hear any SCM names at all, rather I'm interested purely in only what we require and what we'd like out of our package source control. I'm sending this mail to get people thinking about it, and to give the people who won't be at FUDCon a chance at dropping their thoughts in. To get the ball rolling, here are a few of my requirements: Be able to track patches separately from the upstream source so that source rpms can easily be created. Be able to have a continuous development "branch" Be able to create release "branches" for doing updates for existing Fedora releases. Release "branches" should inherit history of the repo up until the release happened. Be able to re-create source rpm used to generate any shipped build at any time later, including same version of any helper scripts or metadata used. Be able to checkout only a given package and not the entire package tree Be able to support fine grained enough rights down to different release "branches" of a given package be able to be queried and pulled from anonymously (by the buildsystem, by the web, etc. Be able to trigger scripts such as pre/post commit be able to reliably disseminate commits as they happen to a selected group of people (per package & branch) Be useful for offline development Cheap "branches" Consistency across all modules for scripted actions like rebuilds easy between-branch merging for those who like to ship the same source rpm everywhere ideally, not rely on magic 'branch' files for the build & tag-fu to work I'll be gathering feedback over the next few days and putting them into a not as of yet created wiki page. Thank you all for your thoughtful consideration. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Mon Jun 9 18:32:12 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 09 Jun 2008 20:32:12 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <484D772C.6020503@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating schrieb: > I'll be gathering feedback over the next few days and putting them into > a not as of yet created wiki page. One requirement from my side is the ability to check out one or more modules without the requirement to download the whole repository. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhNdyIACgkQT2AHK6txfgx/mgCfcC3JhSmEOAu73fmNiPR42acs r6UAoIXv7GW7sA9PI8tmAPGJJ5swTJ3h =IEst -----END PGP SIGNATURE----- From lesmikesell at gmail.com Mon Jun 9 18:34:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 13:34:55 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> Message-ID: <484D77CF.5030507@gmail.com> Alexandre Oliva wrote: > On Jun 9, 2008, Les Mikesell wrote: > >> Firmware that happens to be aggregated for convenient delivery and >> installation is no more a part of the GPL'd work than firmware that is >> already in your machine > > That's missing the point. No, it _is_ the point. > It's not so much about the firmware, it's > about the GPLed work that depends on it. The GPL'd part doesn't depend any more or less on it whether it is loaded on the fly or already there in ROM - or you've updated the contents some other way. > If you can't "just take the > firmware out", and there's no way to obtain the GPL'ed > allegedly-separate work, how could the claim of 'mere aggregation' > hold any water? Aggregation of what separate works? Where are they? You do have access to all of the parts and the freedom to split them up any way you want. What's stopping you? >> No, the GPL applies to components that actually are parts of a work as >> whole or derivatives. Firmware is something separate, just carried >> along for the ride. > > No, your honor, this is not a book that I printed for sale. It's just > a bunch of pages from unrelated works that I stapled/bound together in > large quantities and offered to book retailers in exchange for pieces > of paper of a different color. Exactly. If such aggregations weren't permitted and perfectly normal when you meet the terms of each component separately, we probably wouldn't have had any anthologies to read for homework in school. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Jun 9 18:36:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Jun 2008 00:06:14 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D7370.6040408@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D6FE2.9000908@fedoraproject.org> <484D7370.6040408@gmail.com> Message-ID: <484D781E.3090108@fedoraproject.org> Les Mikesell wrote: > Sorry, if I misunderstood. When someone describes an alternative to > promote their argument, I assume they are promoting the alternative as > well. But what did that mean if it's not what he wants? It just means exactly what it says. If you don't agree with a license terms, you don't get permission to distribute the software even if the licensing terms seem odd to you as noted by a judge in the recent Skype case for violating GPL. http://laforge.gnumonks.org/weblog/2008/05/08/ This simple fact requires no assumption on your part. Rahul From jkeating at redhat.com Mon Jun 9 18:46:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Jun 2008 14:46:21 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <484D772C.6020503@herr-schmitt.de> References: <1213035578.30252.10.camel@localhost.localdomain> <484D772C.6020503@herr-schmitt.de> Message-ID: <1213037181.30252.15.camel@localhost.localdomain> On Mon, 2008-06-09 at 20:32 +0200, Jochen Schmitt wrote: > One requirement from my side is the ability to check out one or more > modules without the requirement to download the whole repository. I do believe that's covered in my requirement: Be able to checkout only a given package and not the entire package tree -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From choeger at cs.tu-berlin.de Mon Jun 9 19:08:56 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 09 Jun 2008 21:08:56 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <1213038536.8383.8.camel@choeger6> Hi, while maintaining only one small package for some releases I would like to see some decentral version management. My current work looks like that: - checkout current source code - apply changes to .spec - move things to ~/rpmbuild - test build - repeat until things work - move things back to current SCM It would be a great thing, if I could control all that from my own versioned repository copy with some 'make ' commands and finally merge my changes back especially when testing builds for multiple releases. The new workflow would look like: - replace source code with current (ideally by using a handcrafted expansion to make e.g. make source revision 3456) - commit that change locally - commit changes to local .spec file locally - make test - merge final changes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lesmikesell at gmail.com Mon Jun 9 19:03:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 14:03:08 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D781E.3090108@fedoraproject.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D6FE2.9000908@fedoraproject.org> <484D7370.6040408@gmail.com> <484D781E.3090108@fedoraproject.org> Message-ID: <484D7E6C.20001@gmail.com> Rahul Sundaram wrote: > >> Sorry, if I misunderstood. When someone describes an alternative to >> promote their argument, I assume they are promoting the alternative as >> well. But what did that mean if it's not what he wants? > > It just means exactly what it says. If you don't agree with a license > terms, you don't get permission to distribute the software even if the > licensing terms seem odd to you as noted by a judge in the recent Skype > case for violating GPL. > > http://laforge.gnumonks.org/weblog/2008/05/08/ > This simple fact requires no assumption on your part. There are a near-infinite number of simple facts that someone could post here. But why, unless they mean to promote or advocate them? -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Mon Jun 9 19:16:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Jun 2008 15:16:03 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213038536.8383.8.camel@choeger6> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> Message-ID: <1213038963.30252.29.camel@localhost.localdomain> On Mon, 2008-06-09 at 21:08 +0200, Christoph H?ger wrote: > Hi, > > while maintaining only one small package for some releases I would > like > to see some decentral version management. > > My current work looks like that: > > - checkout current source code > - apply changes to .spec > - move things to ~/rpmbuild > - test build > - repeat until things work > - move things back to current SCM > > It would be a great thing, if I could control all that from my own > versioned repository copy with some 'make ' commands and > finally merge my changes back especially when testing builds for > multiple releases. Any reason why you're not using make test-srpm and rpmbuild or just make local? (see make help for a trove of options) -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon Jun 9 19:19:20 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Jun 2008 00:49:20 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D7E6C.20001@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D6FE2.9000908@fedoraproject.org> <484D7370.6040408@gmail.com> <484D781E.3090108@fedoraproject.org> <484D7E6C.20001@gmail.com> Message-ID: <484D8238.4070608@fedoraproject.org> Les Mikesell wrote: > > There are a near-infinite number of simple facts that someone could post > here. But why, unless they mean to promote or advocate them? It was posted as a reply in context. Go back and read it if you weren't paying attention. If you can't satisfy the license on the whole, you don't have permission to distribute the software. The point is that you can't simply ignore parts that you don't like. This doesn't say anything at all about the desirability of the outcome as you claimed. Rahul From aoliva at redhat.com Mon Jun 9 19:37:58 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 09 Jun 2008 16:37:58 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D77CF.5030507@gmail.com> (Les Mikesell's message of "Mon\, 09 Jun 2008 13\:34\:55 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D77CF.5030507@gmail.com> Message-ID: On Jun 9, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> On Jun 9, 2008, Les Mikesell wrote: >> >>> Firmware that happens to be aggregated for convenient delivery and >>> installation is no more a part of the GPL'd work than firmware that is >>> already in your machine >> >> That's missing the point. > No, it _is_ the point. No, you're focusing only on the firmware. I'm focusing on the whole work distributed under the name Linux and allegedly (and falsely) under GPLv2, in spite of containing these firmwares so intertwined that you can't just rip off the "pages" of the book corresponding to the firmwares and expect the rest of make sense (to a compiler). Although a number of the firmwares are indeed printed in "separate pages" (files), some are actually interspersed with GPLed code. Even if you were to believe the theory that separate files bound together say at link are covered by the "mere aggregation in the same media" exception, I don't see how it could possibly fly when it's hard even to pinpoint the separate works within a single file, and that modifying that file so as to remove the offending portions might even be argued as a violation of the license of the offending portions. This all *screams* SINGLE WORK, not separate works. To be separate works, you'd have to start out by being able to point at and obtain both/all the works separately. > The GPL'd part doesn't depend any more or less on it whether it is > loaded on the fly or already there in ROM Please tell me you don't honestly believe you wouldn't have to modify the GPLed part to be able to load the tg3 firmwares on the fly or use them straight from ROM. > You do have access to all of the parts and the freedom to split them > up any way you want. What's stopping you? Nothing. In fact, I'm doing just that. However, this doesn't mean I didn't have to modify any of the allegedly separate works in order to accomplish that. I did. So how are they separate works in the first place? If you have to rephrase a chapter of a book for it to make sense if you print the book after removing another chapter, could you honestly defend the claim that the chapters were separate works in the first place? > Exactly. If such aggregations weren't permitted and perfectly normal > when you meet the terms of each component separately, we probably > wouldn't have had any anthologies to read for homework in school. Read again what you wrote. "when you meet the terms of each component separately". Think about it. That some authors don't object to anthologies derived from their works doesn't make all anthologies permissible by copyright law. You still have to get permission from the copyright holders of each individual work and comply with their terms. Think about it this way: If you want to publish a sequel of a novel along with its predecessor, and the license you have doesn't grant you permission to modify the work, then no matter how odd it looks to have the end of the predecessor repeated (with changes) in the first chapter of the sequel, that's how you gotta publish them. Now, consider this: you got a copy this fictitious kernel with source code and firmware embedded in it, but you don't have permission to modify the kernel at all, even though you have source code and permission to study it, recompile it and distribute it. So you look at the sources and you notice that you don't want this firmware in your kernel image, because you don't have the device that requires it. So you remove the firwmare and notice that the kernel won't compile any more. What now? Do you get permission to modify the kernel (creating a derived work thereof) just because it won't compile after you rip off a "separate work"? Is it really still a separate work if you have to do that? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From salimma at fedoraproject.org Mon Jun 9 19:58:00 2008 From: salimma at fedoraproject.org (Michel Alexandre Salim) Date: Mon, 09 Jun 2008 15:58:00 -0400 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: <484D63B4.8050705@gmail.com> References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> Message-ID: <484D8B48.4040403@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: > Kevin Kofler wrote: >> Toshio Kuratomi gmail.com> writes: >>> Err... the last time this came up it was successfully argued that >>> having "Help" fail to work was a bug. The initial idea was to have >>> something within the GNOME stack require yelp but I believe that >>> failed because of circular dependencies. >>> >>> So if this will cause problems because of system-config-* dragging in >>> xulrunner we need to come up with some other way of solving the >>> help-won't-display bug. >> >> IMHO it is not a bug, help is an optional feature, and we have tight >> size constraints on the live images. >> >> We also faced a similar issue with KDE 3 apps dragging in all the KDE >> 4 stack because khelpcenter is now from KDE 4, there too (even though >> this probably doesn't affect any of the live images) we decided to not >> put a dependency in and to simply have help in KDE 3 apps only work if >> the KDE 4 kdebase-runtime is installed (which will always be the case >> in a KDE installation anyway). >> > Giving a newbie a linux live cd to try without having help files is far > from ideal. Ways to solve the problem are appreciated. Reasons why you > consider it an optional feature rather than an integral part of the user > experience will be listened to and either argued with or create > converts. Merely claiming size constraints is not likely to create > change -- the x86_64 spins of both the live Desktop and live KDE spins > are both larger than a CD already. > So make yelp Provides: gnome-help-viewer and have packages that have help files require it instead? That way, live CDs can override this by having a stub package. Ditto with kdebase-runtime providing kde-help-viewer (hm, sounds like the next thing for FD.o to standardize: help viewing) - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhNi0UACgkQWt0J3fd+7ZClJACcDveLk7iu8fkLqGMvf/MEPzOZ YFcAn1pQG2Cl4hS/XCOxuxEsxsP8SS4x =Pw6a -----END PGP SIGNATURE----- From alan at redhat.com Mon Jun 9 20:43:14 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jun 2008 16:43:14 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> Message-ID: <20080609204314.GA4009@devserv.devel.redhat.com> > Same source file, even. Mere aggregation? Where can I get the > separate works, then? The firmware is available in the windows driver, and various other drivers. So you can get it that way. I believe the tg3 file may be available on its own from your own tree. > > and also on the boundaries of contract created by copyright. > > ?!?!? Copyright does not create contracts. Copyright creates Bingo.. and copyright does not give you power over other works or over a large number of activities and ways of using them. Contract law does allow you to do things like that copyright is much more limited. > IIRC it says that modifying, distributing (including publishing) a > work requires permission from the copyright holder, and, in the > absence of such a permission, such acts are forbidden by law. Do you > even have a case here? I do not need your permission to put your book on the same bookcase as someone elses book. Nor do you have any standing to impose restrictions relating to other works via copyright. Alan From alan at redhat.com Mon Jun 9 20:55:28 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jun 2008 16:55:28 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> Message-ID: <20080609205528.GB4009@devserv.devel.redhat.com> On Mon, Jun 09, 2008 at 02:54:07PM -0300, Alexandre Oliva wrote: > license or by copyright law. As I stated before, it's a moral, > ethical and social issue, even if it's also a negligible legal issue. It is an interface between two systems. Consider a typical PC system You can load the CPU firmware updates by - Having the BIOS load it - Having the kernel load it - Having user space apps load it That block could be - residing at an address in ROM - residing at an address in RAM used by the BIOS - residing at an address attached to the kernel image - residing at an address attached to the initrd image Thats the sole difference - the address it appears at. Exactly why does the address in RAM change the "morality" of the distribution. Or would you like try equivocating around "good PC bad Linux" v "Good Linux Bad PC" depending who distributes which bit. Do you buy an "evil" widget with ROM binary firmware or a "good" widget with no proprietary code included that needs an "evil" OS product ? We are *not* talking about two tightly bound pieces of code here but general interfaces. The moment you've got a driver and firmware very closely tied together and sharing structure to the point they were clearly written and designed as one thing its a bit different yes. You also complain about the attitude of the kernel developers - well generally speaking we happened to write the code in question.... Alan From j.w.r.degoede at hhs.nl Mon Jun 9 21:00:10 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 09 Jun 2008 23:00:10 +0200 Subject: Kernel headers changes in F10? In-Reply-To: <20080609142612.GA6336@redhat.com> References: <1212401125.30350.17.camel@cookie.hadess.net> <4843C47F.3000001@hhs.nl> <1212402825.16924.84.camel@pmac.infradead.org> <20080602170931.GA27063@redhat.com> <48442A37.8030501@hhs.nl> <20080602172853.GB27063@redhat.com> <484431A3.6010706@hhs.nl> <20080603134725.GA12485@redhat.com> <20080609142612.GA6336@redhat.com> Message-ID: <484D99DA.9090601@hhs.nl> John W. Linville wrote: > On Tue, Jun 03, 2008 at 09:47:25AM -0400, John W. Linville wrote: >> On Mon, Jun 02, 2008 at 07:45:07PM +0200, Hans de Goede wrote: >>> John W. Linville wrote: >>>> On Mon, Jun 02, 2008 at 07:13:27PM +0200, Hans de Goede wrote: >>>>> John W. Linville wrote: >>>>>> Almost certainly because of this commit: >>>>>> >>>>>> commit 2218228392080f0ca2fc2974604e79f57b12c436 >>>>>> Author: Kirill A. Shutemov >>>>>> Date: Tue Apr 22 16:38:55 2008 +0300 >>>>>> >>>>>> Make linux/wireless.h be able to compile >>>>>> >>>>>> Signed-off-by: Kirill A. Shutemov >>>>>> Signed-off-by: John W. Linville >>>>>> >>>>>> I may have let this slip by due to the "able to compile" bit -- >>>>>> should I not have merged it? I don't have a record or recollection >>>>>> of what motivated the patch originally. >>>> As I said, I have no record or memory of why this patch was needed. >>>> It looks like it was a mistake for me to let it though in the first >>>> place. My guess is that he wanted to include linux/wireless.h from >>>> userland without including other kernel headers...? >>> Looks like a good candidate for reverting. I see little arguments to keep >>> this patch in, it will probably break compilation of other users of >>> linux/wireless.h too, as those probably also already include to >>> get the necessary stuff from there. >> I have reverted that patch in rawhide, and I'm working with Kirill >> for a more permanent solution. > > FWIW, Dave M. NAKed the partial-revert attempt upstream. Can the > userland packages cope? Well I managed to fix gkrellm-wifi to workaround the fact that one can no longer include and at the same time, but I suspect there will be others which will get an FTBFS bug failed in the near future now. Regards, Hans From choeger at cs.tu-berlin.de Mon Jun 9 21:09:01 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 09 Jun 2008 23:09:01 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213038963.30252.29.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <1213038963.30252.29.camel@localhost.localdomain> Message-ID: <1213045741.8383.16.camel@choeger6> Am Montag, den 09.06.2008, 15:16 -0400 schrieb Jesse Keating: > On Mon, 2008-06-09 at 21:08 +0200, Christoph H?ger wrote: > > Hi, > > > > while maintaining only one small package for some releases I would > > like > > to see some decentral version management. > > > > My current work looks like that: > > > > - checkout current source code > > - apply changes to .spec > > - move things to ~/rpmbuild > > - test build > > - repeat until things work > > - move things back to current SCM > > > > It would be a great thing, if I could control all that from my own > > versioned repository copy with some 'make ' commands and > > finally merge my changes back especially when testing builds for > > multiple releases. > > Any reason why you're not using make test-srpm and rpmbuild or just make > local? (see make help for a trove of options) Err, well, .... oohmpf, I just did not know about ... So forget about the script wishes and just think of giving everyone his own local repository to make maintainers life a little bit more comfortable. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From loupgaroublond at gmail.com Mon Jun 9 21:11:02 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 9 Jun 2008 23:11:02 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <484D60D7.70100@gmail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> Message-ID: <7f692fec0806091411r1a605e52weaea88328f1af3a2@mail.gmail.com> 2008/6/9 Toshio Kuratomi : > I had a look at python-2.6 vs (python-2.5 and python-3.0) this weekend. It > looks like this might be a viable path. Here's what I found:: > * Code we port will need to run on python 2.6 or higher. There will be no > way to run code on both python <= 2.5.x and python >= 3.x. In particular, > this means that RHEL/CENTOS-5.(0,1,2) will not run the code we port. > Infrastructure Group members, take note of this :-(. Good. We *should* be eating our own dogfood and using Fedora exclusively in the Infrastructure environment. :P (That said, before you flame me, I do understand the technicalities behind the decisions not to.) -Yaakov From dwmw2 at infradead.org Mon Jun 9 21:11:33 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 22:11:33 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609205528.GB4009@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: <1213045893.2534.85.camel@shinybook.infradead.org> On Mon, 2008-06-09 at 16:55 -0400, Alan Cox wrote: > That block could be > - residing at an address in ROM > - residing at an address in RAM used by the BIOS > - residing at an address attached to the kernel image > - residing at an address attached to the initrd image > > Thats the sole difference - the address it appears at. You're equivocating. The _important_ difference, in this context, is how it's distributed. The GPL clearly states that there can exist sections of which which _are_ independent and separate works in themselves -- but when you distribute those _same_ sections as part of a whole which is a work based on the GPL'd Program... The _distribution_ of stuff together is what makes the difference, even when some of that 'stuff' would be considered to be a completely independent and separate work, when distributed separately. You obviously disagree, but you haven't really explained why. Maybe Les' mail is relevant here -- he seems to think that we should argue based on what we _want_ to be true, rather than what the evidence actually indicates? Do you believe that copyright law _prevents_ the GPL from making requirements about those separate works, in such a way that still lets you distribute the GPL'd work without complying with the licence? Or do you believe that the GPL does not actually impose the requirements it seems to impose in ?2? Perhaps you believe that _all_ forms of aggregation can be labelled "mere aggregation on a volume of a storage or distribution medium" and thus that the whole of those three paragraphs in the licence are just a big no-op? Can we submit a non-GPL'd driver as a .o file, call it 'mere aggregation' and argue that it's not a GPL violation? Or is it another example of Les' "we argue what we want to believe, regardless of the facts"? -- dwmw2 From opensource at till.name Mon Jun 9 21:12:28 2008 From: opensource at till.name (Till Maas) Date: Mon, 09 Jun 2008 23:12:28 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <200806092312.29798.opensource@till.name> On Mon June 9 2008, Jesse Keating wrote: > At the upcoming FUDCon I plan to hold a session or two regarding > requirements and discussions about the future of our package source > control. This is NOT a time to argue about one SCM being "better" than > another. I don't really want to hear any SCM names at all, rather I'm > interested purely in only what we require and what we'd like out of our > package source control. I'm sending this mail to get people thinking > about it, and to give the people who won't be at FUDCon a chance at > dropping their thoughts in. I would like to have a way so easily track patches against the cvs state of a package with the possibility to do private commits and an easy way to merge them to the official branch or show them others in a way that they can easily merge them. This would make co-maintaining packages a lot easier imho. Also it should not take that long to to get a diff like it does with cvs. It would be also helpful, if it was possible to checkout only the active branches of a package instead and when this would be the default beheaviour when one checks out a package. Maybe this could be achieved with an "active" and an "archive" branch of /rpms/ for each package in some scms. The active branch would currently only include F-{7,8,9} EL-{4,5} and devel. Another thing that comes to my mind, would be an easy way to merge changes from devel to the F-? branches. E.g. the scm could track when one merged from devel to F-9 the last time and make it possible to merge these changes to the F-9 branch easily, even when the F-9 branch contains changes that are not in devel. 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 lesmikesell at gmail.com Mon Jun 9 21:22:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 16:22:14 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D77CF.5030507@gmail.com> Message-ID: <484D9F06.1020407@gmail.com> Alexandre Oliva wrote: > >> No, it _is_ the point. > > No, you're focusing only on the firmware. I'm focusing on the whole > work distributed under the name Linux and allegedly (and falsely) > under GPLv2, in spite of containing these firmwares so intertwined > that you can't just rip off the "pages" of the book corresponding to > the firmwares and expect the rest of make sense (to a compiler). > Although a number of the firmwares are indeed printed in "separate > pages" (files), some are actually interspersed with GPLed code. What I don't understand is why you think there is some requirement in terms of page boundaries or storage mechanism involved in copyright separation. I've never seen any such thing. > Even > if you were to believe the theory that separate files bound together > say at link are covered by the "mere aggregation in the same media" > exception, I don't see how it could possibly fly when it's hard even > to pinpoint the separate works within a single file, and that > modifying that file so as to remove the offending portions might even > be argued as a violation of the license of the offending portions. > This all *screams* SINGLE WORK, not separate works. No, it screams common storage, particularly when you know that it runs on separate hardware elements and can't possibly be a single work when it executes. > To be separate > works, you'd have to start out by being able to point at and obtain > both/all the works separately. Where is that requirement stated? I've never seen anything explicitly stating technical details of how separation must appear or be maintained. >> The GPL'd part doesn't depend any more or less on it whether it is >> loaded on the fly or already there in ROM > > Please tell me you don't honestly believe you wouldn't have to modify > the GPLed part to be able to load the tg3 firmwares on the fly or use > them straight from ROM. I believe there there wouldn't be any difference if the identical content were already in ROM - or some non-GPL'd pre-execute loader installed it instead of the kernel. >> You do have access to all of the parts and the freedom to split them >> up any way you want. What's stopping you? > > Nothing. In fact, I'm doing just that. > > However, this doesn't mean I didn't have to modify any of the > allegedly separate works in order to accomplish that. I did. So how > are they separate works in the first place? It is unrelated content that generally executes in an unrelated context. It could have been in ROM already. It could have been loaded by something else. Loading those contents some other way doesn't make them more or less separate, just less convenient. This might be made more clear if the loader is generalized and the contents separated so that it is obvious that changes in firmware contents do not need modifications in the GPL'd mechanism - and in fact are not related to the loader at all. But that seems obvious anyway, like the code that plays music is separate from the music content, or an ebook text is separate from the code that displays it. That would not be changed even if you combined them in the same medium or file for convenient storage. > If you have to rephrase a chapter of a book for it to make sense if > you print the book after removing another chapter, could you honestly > defend the claim that the chapters were separate works in the first > place? Yes, and I think copyright law supports that even if it is a bit fuzzy. >> Exactly. If such aggregations weren't permitted and perfectly normal >> when you meet the terms of each component separately, we probably >> wouldn't have had any anthologies to read for homework in school. > > Read again what you wrote. "when you meet the terms of each component > separately". Think about it. I did think about it. It is an aggregation, explicitly permitted by the GPL, so only the terms of the loaded component could be a problem with the combination. And I don't see any more reason to question the compliance of terms on included firmware than on included sources. > Now, consider this: you got a copy this fictitious kernel with source > code and firmware embedded in it, but you don't have permission to > modify the kernel at all, even though you have source code and > permission to study it, recompile it and distribute it. So you look > at the sources and you notice that you don't want this firmware in > your kernel image, because you don't have the device that requires it. I don't think that's a sufficient reason for me to want to remove something, but OK. > So you remove the firwmare and notice that the kernel won't compile > any more. What now? Ignore it, consider it a feature in case you get one of the devices in question, or ask someone with permission to modify to make the change for you. > Do you get permission to modify the kernel > (creating a derived work thereof) just because it won't compile after > you rip off a "separate work"? If it mattered that much, I'd try to figure out why the removal affected compilation and supply a compiler-satisfying substitute. > Is it really still a separate work if > you have to do that? Yes, unless you can establish that it is impossible to provide a compiler-satisfying alternative. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Mon Jun 9 21:21:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Jun 2008 17:21:36 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213045741.8383.16.camel@choeger6> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <1213038963.30252.29.camel@localhost.localdomain> <1213045741.8383.16.camel@choeger6> Message-ID: <1213046496.30252.33.camel@localhost.localdomain> On Mon, 2008-06-09 at 23:09 +0200, Christoph H?ger wrote: > Err, well, .... oohmpf, I just did not know about ... > > So forget about the script wishes and just think of giving everyone his > own local repository to make maintainers life a little bit more > comfortable. Indeed. I do believe that would fall under my requirement for being usable offline. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jun 9 21:30:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Jun 2008 17:30:19 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <200806092312.29798.opensource@till.name> References: <1213035578.30252.10.camel@localhost.localdomain> <200806092312.29798.opensource@till.name> Message-ID: <1213047019.30252.38.camel@localhost.localdomain> These are good, albeit a bit lengthy. Lets see what we can do here. On Mon, 2008-06-09 at 23:12 +0200, Till Maas wrote: > > I would like to have a way so easily track patches against the cvs state of a > package with the possibility to do private commits and an easy way to merge > them to the official branch or show them others in a way that they can easily > merge them. This would make co-maintaining packages a lot easier imho. I think I know what you're talking about here, but I want to clarify. You get a copy of the "upstream" frob module. You then do some local changes and even local commits against frob. You can query upstream "frob" to see if anything changed upstream and integrate those into your copy. Eventually you take your local changes and push them 'upstream', right? > > Also it should not take that long to to get a diff like it does with cvs. This is a nice easy concise one, and should fall under the 'offline use' case, but I'll spell it out explicitly. > > It would be also helpful, if it was possible to checkout only the active > branches of a package instead and when this would be the default beheaviour > when one checks out a package. Maybe this could be achieved with an "active" > and an "archive" branch of /rpms/ for each package in some scms. The > active branch would currently only include F-{7,8,9} EL-{4,5} and devel. Good suggestion! I'll add it into the lists, maybe a bit more terse. > > Another thing that comes to my mind, would be an easy way to merge changes > from devel to the F-? branches. E.g. the scm could track when one merged from > devel to F-9 the last time and make it possible to merge these changes to the > F-9 branch easily, even when the F-9 branch contains changes that are not in > devel. Ok, I think I follow that. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon Jun 9 21:33:59 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jun 2008 17:33:59 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213045893.2534.85.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> Message-ID: <20080609213359.GA11775@devserv.devel.redhat.com> On Mon, Jun 09, 2008 at 10:11:33PM +0100, David Woodhouse wrote: > distribute those _same_ sections as part of a whole which is a work > based on the GPL'd Program... I do not believe they are "part of a whole which is a work based on..". In this case I believe they are independant works that are merely aggregated. The alternate position would be that a general interface between two independent works somehow made them one. That would just as equally say that firefox and the web are one work. > Do you believe that copyright law _prevents_ the GPL from making > requirements about those separate works, in such a way that still lets > you distribute the GPL'd work without complying with the licence? That would seem to be a "how often do you beat your wife" question. The underlying falsehood being that the GPL licence is not being complied with I don't need your permission to copy the firmware for the tg3 driver I need the permission of Broadcom. Alan From maximilianbianco at gmail.com Mon Jun 9 21:51:31 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 09 Jun 2008 17:51:31 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213045893.2534.85.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> Message-ID: <484DA5E3.40402@gmail.com> David Woodhouse wrote: > On Mon, 2008-06-09 at 16:55 -0400, Alan Cox wrote: >> That block could be >> - residing at an address in ROM >> - residing at an address in RAM used by the BIOS >> - residing at an address attached to the kernel image >> - residing at an address attached to the initrd image >> >> Thats the sole difference - the address it appears at. > > You're equivocating. > > The _important_ difference, in this context, is how it's distributed. > > The GPL clearly states that there can exist sections of which which > _are_ independent and separate works in themselves -- but when you > distribute those _same_ sections as part of a whole which is a work > based on the GPL'd Program... > > The _distribution_ of stuff together is what makes the difference, even > when some of that 'stuff' would be considered to be a completely > independent and separate work, when distributed separately. > > You obviously disagree, but you haven't really explained why. > > Maybe Les' mail is relevant here -- he seems to think that we should > argue based on what we _want_ to be true, rather than what the evidence > actually indicates? > > Do you believe that copyright law _prevents_ the GPL from making > requirements about those separate works, in such a way that still lets > you distribute the GPL'd work without complying with the licence? > > Or do you believe that the GPL does not actually impose the requirements > it seems to impose in ?2? Perhaps you believe that _all_ forms of > aggregation can be labelled "mere aggregation on a volume of a storage > or distribution medium" and thus that the whole of those three > paragraphs in the licence are just a big no-op? Can we submit a > non-GPL'd driver as a .o file, call it 'mere aggregation' and argue that > it's not a GPL violation? > > Or is it another example of Les' "we argue what we want to believe, > regardless of the facts"? > This is the sort of comment, whether intentional or no that leads to flame wars. I enjoy reading a civil discussion but let's not bait people. Things can be phrased better, certainly I know that from experience as I have the same tendency to walk the razor's edge with regards to my language choice from time to time. Let's keep it civil shall we? I'd like to learn something but it's going to be difficult if we make it personal. Argue your point on its merits not on the short comings of the other person's argument. Thank You Max -- If opinions were really like assholes the we'd each have just one From kevin.kofler at chello.at Mon Jun 9 21:55:32 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 21:55:32 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> Message-ID: Toshio Kuratomi gmail.com> writes: > the x86_64 spins of both the live Desktop and live KDE spins > are both larger than a CD already. No, in Fedora 9 they aren't, due to the removal of all multilib packages by default, the x86_64 live images are now below 700 MB, but barely. Adding yelp and its dependencies would put the KDE image well above 700 MB, both for i686 and for x86_64. Kevin Kofler From kevin.kofler at chello.at Mon Jun 9 22:01:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 22:01:14 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484D8B48.4040403@fedoraproject.org> Message-ID: Michel Alexandre Salim fedoraproject.org> writes: > So make yelp Provides: gnome-help-viewer and have packages that have > help files require it instead? That way, live CDs can override this by > having a stub package. Ditto with kdebase-runtime providing kde-help-viewer And what would that broken hack gain us over the GNOME live image simply pulling in yelp explicitly if they aren't already doing that? I don't think making packages think a dependency is there when it actually isn't is the right way to solve problems like this, help won't be any more available with a dummy yelp than with none at all. > (hm, sounds like the next thing for FD.o to standardize: help viewing) That would of course help, but not in the short term. Kevin Kofler From opensource at till.name Mon Jun 9 22:02:34 2008 From: opensource at till.name (Till Maas) Date: Tue, 10 Jun 2008 00:02:34 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213047019.30252.38.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <200806092312.29798.opensource@till.name> <1213047019.30252.38.camel@localhost.localdomain> Message-ID: <200806100002.40674.opensource@till.name> On Mon June 9 2008, Jesse Keating wrote: > These are good, albeit a bit lengthy. Lets see what we can do here. > > On Mon, 2008-06-09 at 23:12 +0200, Till Maas wrote: > > I would like to have a way so easily track patches against the cvs state > > of a package with the possibility to do private commits and an easy way > > to merge them to the official branch or show them others in a way that > > they can easily merge them. This would make co-maintaining packages a lot > > easier imho. > > I think I know what you're talking about here, but I want to clarify. > You get a copy of the "upstream" frob module. You then do some local > changes and even local commits against frob. You can query upstream > "frob" to see if anything changed upstream and integrate those into your > copy. Eventually you take your local changes and push them 'upstream', > right? If upstream here is the Fedora scm, then this is what I mean. 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 a.badger at gmail.com Mon Jun 9 22:18:35 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Jun 2008 15:18:35 -0700 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> Message-ID: <484DAC3B.1080508@gmail.com> Kevin Kofler wrote: > Toshio Kuratomi gmail.com> writes: >> the x86_64 spins of both the live Desktop and live KDE spins >> are both larger than a CD already. > > No, in Fedora 9 they aren't, due to the removal of all multilib packages by > default, the x86_64 live images are now below 700 MB, but barely. Adding yelp > and its dependencies would put the KDE image well above 700 MB, both for i686 > and for x86_64. > You can't count on that:: -rw-r--r-- 1 ftp ftp 729272320 May 08 02:31 Fedora-9-x86_64-Live-KDE.iso -rw-r--r-- 1 ftp ftp 727169024 May 08 02:18 Fedora-9-x86_64-Live.iso """ A Mode-1 CD-ROM, which has the full three layers of error correction data, contains a net 2048 bytes of the available 2352 per sector. In a Mode-2 CD-ROM, which is mostly used for video files, there are 2336 user-available bytes per sector. The net byte rate of a Mode-1 CD-ROM, based on comparison to CDDA audio standards, is 44.1k/s?4B?2048/2352 = 153.6 kB/s. The playing time is 74 minutes, or 4440 seconds, so that the net capacity of a Mode-1 CD-ROM is 682 MB.""" -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Mon Jun 9 22:34:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 09 Jun 2008 17:34:40 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213045893.2534.85.camel@shinybook.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> Message-ID: <484DB000.6020304@gmail.com> David Woodhouse wrote: > > You're equivocating. > > The _important_ difference, in this context, is how it's distributed. No, it's all about the content. > The GPL clearly states that there can exist sections of which which > _are_ independent and separate works in themselves -- but when you > distribute those _same_ sections as part of a whole which is a work > based on the GPL'd Program... And you'll note that there are no technical details about putting things in the same box or on the same media or in the same file that define an aggregation as a 'whole'. > The _distribution_ of stuff together is what makes the difference, even > when some of that 'stuff' would be considered to be a completely > independent and separate work, when distributed separately. No, the distribution packaging or method is really unrelated to the content. For example, the FSF considers it a GPL infringement to ship non-GPL'd content (even in source form) that an end user must link to a GPL'd library to function. Personally I disagree with that and would be shocked to see a court uphold it, but you never know... > You obviously disagree, but you haven't really explained why. > > Maybe Les' mail is relevant here -- he seems to think that we should > argue based on what we _want_ to be true, rather than what the evidence > actually indicates? I didn't say you 'should' do that. I just don't see the point of arguing for something you don't want. > Do you believe that copyright law _prevents_ the GPL from making > requirements about those separate works, in such a way that still lets > you distribute the GPL'd work without complying with the licence? The license is the only thing that lets you distribute at all. I don't think anyone argues with that. > Or do you believe that the GPL does not actually impose the requirements > it seems to impose in ?2? Aggregation is permitted. > Perhaps you believe that _all_ forms of > aggregation can be labelled "mere aggregation on a volume of a storage > or distribution medium" and thus that the whole of those three > paragraphs in the licence are just a big no-op? Do you see something in there that defines how aggregation can and can't be done? At one level, on unix-like systems a disk, a filesystem, and and archive are really all files. So you are just quibbling over irrelevant file formatting details until you look at the content. > Can we submit a > non-GPL'd driver as a .o file, call it 'mere aggregation' and argue that > it's not a GPL violation? Linus was once widely quoted as saying that that it was not a violation even if he won't stand behind that statement today. I probably would never have used it for any work had binary drivers been prohibited from the start. Note the exception to the stock GPL in regard to the use of interfaces in the Linux license. > Or is it another example of Les' "we argue what we want to believe, > regardless of the facts"? The facts are that aggregation is permitted and the techniques of aggregation aren't enumerated to some limited set. If it were otherwise the current aggregation wouldn't exist. -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Mon Jun 9 22:44:10 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 22:44:10 +0000 (UTC) Subject: Requirements gathering for new package source control References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> Message-ID: Christoph H?ger cs.tu-berlin.de> writes: > It would be a great thing, if I could control all that from my own > versioned repository copy with some 'make ' commands and > finally merge my changes back especially when testing builds for > multiple releases. Why don't you just commit the changes even if you don't know yet whether they build? Especially for a small package where you're the sole maintainer, it won't really matter if CVS HEAD isn't always buildable. For better or for worse, you'll also notice that many maintainers with many packages won't even bother building locally first, we usually just commit, tag and build, and after we get the failure mail from Koji, fix, commit, force-tag and resubmit, and repeat that until the build succeeds. Decentralized commits don't help with that at all (they only add an extra "push" step after the commit, which is just one more chance to screw up). Kevin Kofler From kevin.kofler at chello.at Mon Jun 9 22:57:31 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 9 Jun 2008 22:57:31 +0000 (UTC) Subject: Requirements gathering for new package source control References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > Be useful for offline development Is that really a desirable thing at all? I know decentralized systems are "in" at the moment, but I think they're really unhelpful and counterproductive. Offline/private development: * keeps others from seeing what you're doing - it's a step towards a closed development model, away from our goals of openness, * risks reinventing the wheel, because you don't know what the comaintainers have committed locally, * increases the risk of merge conflicts, because a whole bunch of changes gets dumped on the repo at once. What I think we should encourage instead is to commit early, commit often. Even if the work is only partly done, it is often useful to commit what you have. And with "commit" there, I really mean committing/pushing to the central repo, not locally. The problem as I see it is that N local commits and one big push are always compared to one big central commit (and there of course the N local commits win because they keep the history), but that's not the proper way to use a centralized source control system, N central commits are. Decentralized source control is only a way to make source control abuse slightly less of an issue, while at the same time encouraging such abuse. In addition, the decentralized model introduces an additional source of errors: not only can you forget to commit, but you can also forget to push what you committed. Kevin Kofler From dominik at greysector.net Mon Jun 9 23:01:16 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 10 Jun 2008 01:01:16 +0200 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> Message-ID: <20080609230115.GA4252@mokona.greysector.net> On Tuesday, 10 June 2008 at 00:44, Kevin Kofler wrote: > Christoph H?ger cs.tu-berlin.de> writes: > > It would be a great thing, if I could control all that from my own > > versioned repository copy with some 'make ' commands and > > finally merge my changes back especially when testing builds for > > multiple releases. > > Why don't you just commit the changes even if you don't know yet whether they > build? Especially for a small package where you're the sole maintainer, it > won't really matter if CVS HEAD isn't always buildable. > > For better or for worse, you'll also notice that many maintainers with many > packages won't even bother building locally first, we usually just commit, tag > and build, and after we get the failure mail from Koji, fix, commit, force-tag > and resubmit, and repeat that until the build succeeds. You don't have to tag to build. You can do scratch builds of HEAD in koji. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From opensource at till.name Mon Jun 9 23:11:01 2008 From: opensource at till.name (Till Maas) Date: Tue, 10 Jun 2008 01:11:01 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <20080609230115.GA4252@mokona.greysector.net> References: <1213035578.30252.10.camel@localhost.localdomain> <20080609230115.GA4252@mokona.greysector.net> Message-ID: <200806100111.07304.opensource@till.name> On Tue June 10 2008, Dominik 'Rathann' Mierzejewski wrote: > You don't have to tag to build. You can do scratch builds of HEAD in koji. You do not even have to commit, you can scratch builds from a src.rpm. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dominik at greysector.net Tue Jun 10 00:07:24 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 10 Jun 2008 02:07:24 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <200806100111.07304.opensource@till.name> References: <1213035578.30252.10.camel@localhost.localdomain> <20080609230115.GA4252@mokona.greysector.net> <200806100111.07304.opensource@till.name> Message-ID: <20080610000724.GB4252@mokona.greysector.net> On Tuesday, 10 June 2008 at 01:11, Till Maas wrote: > On Tue June 10 2008, Dominik 'Rathann' Mierzejewski wrote: > > > You don't have to tag to build. You can do scratch builds of HEAD in koji. > > You do not even have to commit, you can scratch builds from a src.rpm. Yes, but if the source is large, doing builds from CVS saves you a lot of time (depending on how fast your connection is). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From kzak at redhat.com Tue Jun 10 00:36:27 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 10 Jun 2008 02:36:27 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <20080610003627.GK2912@nb.net.home> On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: > Thank you all for your thoughtful consideration. - be able to easily rebase/refresh a patch - be able to easily verify a repository consistency - be useful with generic protocols (e.g. http, rsync) - be script-able (for local customization, for integration with rpmbuild, ...) wishes (but not requirements): - be able to make (and verify) a signed commit/tag - be able to keep track of details about patches (author, committer, some special marks (e.g. "signed-of-by", "reviewed-by", ...) - be able to generate statistics about patches (diffstat) - be able to generate change logs - be able to generate patches (to avoid unwanted "creativity", it'd be nice to use same format for all Fedora patches) BTW, do we already know if we want to maintain source code (= git, hg, ...) or patches files (= StGit, Quilt)? I think that maintain patch files by a classic SCM is very insane. Karel -- Karel Zak From airlied at redhat.com Tue Jun 10 01:13:41 2008 From: airlied at redhat.com (Dave Airlie) Date: Tue, 10 Jun 2008 11:13:41 +1000 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <1213060421.3438.2.camel@clockmaker.usersys.redhat.com> On Mon, 2008-06-09 at 22:57 +0000, Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > Be useful for offline development > > Is that really a desirable thing at all? I know decentralized systems are "in" > at the moment, but I think they're really unhelpful and counterproductive. > Offline/private development: > * keeps others from seeing what you're doing - it's a step towards a closed > development model, away from our goals of openness, > * risks reinventing the wheel, because you don't know what the comaintainers > have committed locally, > * increases the risk of merge conflicts, because a whole bunch of changes gets > dumped on the repo at once. How many people just have CVS checkouts they never check-in? its the same thing, if there are conflicts they have to deal with them before checking in in any case. so really this is FUD, in fact from my experience with decentralised VCS, people are more willing to push random branches to personal repos etc. If you have a personal development repo, you can drop all your experimental branches there for others to see if they ever feel like it. Also very useful as a form of remote backup for tasks you come and go from. Dave. From mspevack at redhat.com Mon Jun 9 22:37:55 2008 From: mspevack at redhat.com (Max Spevack) Date: Tue, 10 Jun 2008 00:37:55 +0200 (CEST) Subject: Fedora Websites in need of development help Message-ID: Hi Fedora Developers, Do you know even a little bit about any of the following: * python * genshi * apache And do you want a chance to learn more and/or put your skills to work? The Fedora Websites team is actively looking for some development help on our build scripts -- this is the code that takes templates and turns it into HTML. [1] It's critical for people who want to create local mockups of new designs, and also for pushing our web code into test environments and ultimately into production. If you are interested, please join the fedora-websites-list [2], introduce yourself (if you're not already known), and look for Ricky Zhou. Thanks! --Max [1] http://git.fedorahosted.org/git/fedora-web.git?p=fedora-web.git;a=blob;f=fedoraproject.org/README [2] http://www.redhat.com/mailman/listinfo/fedora-websites-list _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From paul at xelerance.com Tue Jun 10 03:39:46 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 9 Jun 2008 23:39:46 -0400 (EDT) Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: > In addition, the decentralized model introduces an additional source of errors: > not only can you forget to commit, but you can also forget to push what you > committed. On the contrary. With git I can commit all I want in the train without internet connectivity, and when my laptop gets back online it can *automatically* push to the central repository (eg via some NetworkManager controllerd 'ppp-up like script) And at the central repository, git hooks can trigger building, testing, packaging, etc. It can tag in the repository when the build succeeds, and a simple git fetch on the clients can tell me about the build status without needing to go to some website and interacting with ajax. Paul From dwmw2 at infradead.org Tue Jun 10 09:29:53 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jun 2008 10:29:53 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609213359.GA11775@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> Message-ID: <1213090193.32207.722.camel@pmac.infradead.org> On Mon, 2008-06-09 at 17:33 -0400, Alan Cox wrote: > I do not believe they are "part of a whole which is a work based on..". In > this case I believe they are independant works that are merely aggregated. To be clear, I also believe them to be independent works -- I don't think there's any debate about that. But they are independent works which are being combined into a larger, coherent whole and distributed that way. I do not believe that they are "merely aggregated on a volume of a storage or distribution medium" like a magazine cover CD. And thus, I believe that the GPL extends "to each and every part, regardless of who wrote it". _That_ is the 'alternate position'; not this: > The alternate position would be that a general interface between two > independent works somehow made them one. Not at all. That would be silly, and is clearly _not_ my position. The general interface between the firmware and the kernel exists even when you distribute the firmware as a separate work. And the GPL clearly doesn't apply to it when you distribute it as a separate work. It is the _distribution_ of a collective whole based on both firmware and kernel together, which makes the difference under the GPL. > That would just as equally say that firefox and the web are one work. That's a complete non-sequitur -- nobody would ever attempt to _distribute_ an aggregation of "firefox" and "the web" together as a single collective whole. You really do seem to have missed the point that it's about _distribution_, of both derived and _collective_ works. I believe that if we follow your logic, we should also be able to distribute GPL'd code linked against proprietary libraries. Yes, we've combined them together into one executable -- but evidently we can call it "merely aggregation" and get away with anything. There's a general interface between the independent parts, which you seem to believe excuses the combination, yes? We should be able to distribute binary-only drivers actually linked into the kernel too. If we accept that they are independent works in the first place?, then 'merely aggregating' them into the vmlinux should be fine, right? Now admittedly, there _is_ a grey area here -- it's not particularly clear-cut where "collective works based on the Program" ends, and where "mere aggregation on a volume of a storage or distribution medium" starts. But even though there's a grey area, I don't think it's at all realistic to stretch that boundary as far as you seem to be claiming we should. You seem to be arguing as if you believe that incorporation of any 'independent' work automatically means that we should consider the combined whole to be 'mere aggregation on a volume of a storage or distribution medium', rather than a collective work with associated requirements under the GPL. Yet the GPL _explicitly_ states that it refers to such collective works -- with explicit reference to sections of that whole which, when distributed separately, would be considered independent and separate works in themselves. Your viewpoint would render the latter half of ?2 a verbose no-op, and is clearly at odds with the intent, as well as the letter, of the GPL. But as ever, there is no definitive answer to that until/unless it's ruled in court. -- dwmw2 ? which admittedly is disputed by some, but not the point here. From alan at redhat.com Tue Jun 10 09:36:58 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 05:36:58 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213090193.32207.722.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> Message-ID: <20080610093658.GA13339@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 10:29:53AM +0100, David Woodhouse wrote: > It is the _distribution_ of a collective whole based on both firmware > and kernel together, which makes the difference under the GPL. Are you claiming they are a database. I don't understand your "collective work" here. What sort of a work do you claim it is, and why does the collective work acquire some kind of extra rights ? > I believe that if we follow your logic, we should also be able to > distribute GPL'd code linked against proprietary libraries. Yes, we've > combined them together into one executable -- but evidently we can call > it "merely aggregation" and get away with anything. There's a general > interface between the independent parts, which you seem to believe > excuses the combination, yes? In some cases the answer is probably yes, not because the GPL likes the idea but because the rights in copyright probably don't extend to that. > We should be able to distribute binary-only drivers actually linked into > the kernel too. If we accept that they are independent works in the > first place??, then 'merely aggregating' them into the vmlinux should be > fine, right? That rather depends upon whether they are derivative which is an area that seems ot have little clarity and no computing caselaw. From rawhide at fedoraproject.org Tue Jun 10 09:43:08 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 10 Jun 2008 09:43:08 +0000 (UTC) Subject: rawhide report: 20080610 changes Message-ID: <20080610094309.00C71209D05@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080609/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080610/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package kaya A Statically typed, imperative programming-language New package mathomatic Small, portable symbolic math program Updated Packages: Falcon-0.8.10-3.fc10 -------------------- * Mon Jun 9 18:00:00 2008 Michel Alexandre Salim - 0.8.10-3 - Revert r401 patch; does not fix cmake-2.6 problem on Rawhide Reverting to manually using 'make install' in individual subdirectories * Mon Jun 9 18:00:00 2008 Michel Alexandre Salim - 0.8.10-2 - Merge in cmake fixes from core/trunk r401 - Patch core/CMakeLists.txt to default to /usr, as it appears that the requested prefix is not properly used - Fix incorrect #! interpreter in falconeer.fal PackageKit-0.2.3-2.20080609.fc10 -------------------------------- * Mon Jun 9 18:00:00 2008 Richard Hughes - 0.2.3-2.20080609 - Add intltool to the BR. * Mon Jun 9 18:00:00 2008 Richard Hughes - 0.2.3-1.20080609 - Pull in a new snapshot from the unstable branch. bmpx-0.40.14-5.fc9 ------------------ * Sat Jun 7 18:00:00 2008 Alexander Kahl - 0.40.14-5 - explicitly added intltool build requirement * Sat Jun 7 18:00:00 2008 Alexander Kahl - 0.40.14-4 - explicitly added libtool build requirement * Fri Jun 6 18:00:00 2008 Alexander Kahl - 0.40.14-3 - disabled sid support for now, problems on ppc * Sun May 18 18:00:00 2008 Alexander Kahl - 0.40.14-2 - added explicit dbus-devel and dbus-glib-devel dependencies - added explicit libSM-devel dependency * Sun May 18 18:00:00 2008 Alexander Kahl - 0.40.14-1 - update to 0.40.14 - removed patches for now-fixed issues - removed empty ChangeLog cairo-dock-1.6.0-0.1.svn1087_trunk.fc10 --------------------------------------- * Mon Jun 9 18:00:00 2008 Mamoru Tasaka - svn 1087 ccsm-0.7.6-2.fc10 ----------------- * Mon Jun 9 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-2 - added BR intltool * Sun Jun 8 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.7.6-1 - 0.7.6 update cluster-2.99.04-1.fc10 ---------------------- * Mon Jun 9 18:00:00 2008 Fabio M. Di Nitto - 2.99.04-1 - New upstream release - Update license tags after major upstream cleanup (note: rgmanager includes a shell script that is shipped under OSL 2.1 license). - Update inclusion of documents to reflect updated COPYRIGHT file from upstream. - Add documentation to different packages. clustermon-0.13.0-4.fc9 ----------------------- * Fri Jun 6 18:00:00 2008 Ryan McCabe 0.13.0-4 - Recognize F9 by name (Sulphur). collectd-4.4.1-1.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Alan Pevec 4.4.1-1 - New upstream version 4.4.1. - plugin changes: reenable iptables, disable ascent * Tue May 27 18:00:00 2008 Alan Pevec 4.4.0-2 - disable iptables/libiptc * Mon May 26 18:00:00 2008 Alan Pevec 4.4.0-1 - New upstream version 4.4.0. crontabs-1.10-23.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Marcela Maslanova 1.10-23 - 450084 LANG=C is set up for running scripts em8300-0.17.0-1.fc10 -------------------- * Mon Jun 9 18:00:00 2008 Ville Skytt?? - 0.17.0-1 - 0.17.0. emacs-22.2-5.fc9 ---------------- * Fri May 23 18:00:00 2008 Chip Coldwell 1:22.2-5 - drop the old icon in favor of the new set from FSF, and rebuild the gtk icon cache in the post and postun scriptlets. - add /usr/share/X11/app-defaults/Emacs and xorg-x11-fonts-75dpi dependency to get sane screen display font - update to php-mode 1.4 - drop the wrapper script; we use alternatives for better or worse now - patch rpm-spec-mode to use a real compilation mode - bring back setarch -R ... the dumper tries to detect address space randomization and compensate on its own, but the heuristics aren't 100% - drop the files.el patch; this is now in the upstream tarball - don't use smp_mflags on second make invocation evince-2.22.2-1.fc9 ------------------- * Wed May 28 18:00:00 2008 Matthias Clasen - 2.22.2-1 - Uodate toi 2.22.2 expect-5.43.0-14.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Vitezslav Crhonek - 5:43.0-14 - Use latest config.sub file for package build Resolves: #449560 fbida-2.07-1.fc10 ----------------- * Mon Jun 9 18:00:00 2008 Adrian Reber - 2.07-1 - updated to 2.07 - fixes "The fbi command aborts with a stack trace" (#448126) fedora-ds-admin-1.1.5-1.fc10 ---------------------------- * Fri Jun 6 18:00:00 2008 Rich Megginson - 1.1.5-1 - Resolves: Bug 448366 - genrb no longer supports -p option ffcall-1.10-1.fc9 ----------------- frysk-0.4-0.fc10 ---------------- * Mon Jun 9 18:00:00 2008 Sami Wagiaalla - 0.4-0 - import frysk-0.4.tar.bz2 - removed Patch7: frysk-0.0.1.2008.02.29.rh1-jboolean-array.patch - removed Patch8: frysk-0.0.1.2008.02.29.rh1-asm-includes.patch - removed Patch10: frysk-0.0.1.2008.03.19.rh1-fparser8.patch - removed Patch11: frysk-0.2.1-ppc-build.patch - Added fdebugdump files to files list - Added libfrysk-sys-jni.so to file list. - remove fparser from executable list. - remove test_main_looper from file list. - remove libfrysk-cdtparser from file list. ganglia-3.0.7-2.fc10 -------------------- * Mon Jun 9 18:00:00 2008 Jarod Wilson 3.0.7-2 - Bump and rebuild against latest rrdtool gcc-4.3.1-1 ----------- * Mon Jun 9 18:00:00 2008 Jakub Jelinek 4.3.1-1 - update from gcc-4_3-branch - 4.3.1 release - PRs ada/24880, ada/26635, bootstrap/35169, bootstrap/36452, c++/35578, c++/35986, c++/36023, c++/36237, c++/36308, fortran/35184, fortran/35743, fortran/35745, fortran/35756, fortran/35759, fortran/35780, fortran/35864, fortran/35997, fortran/36176, fortran/36233, libfortran/35990, libfortran/35993, libfortran/35995, libgcj/36252, libstdc++/35922, middle-end/34973, middle-end/36013, middle-end/36077, middle-end/36093, middle-end/36106, middle-end/36137, middle-end/36154, middle-end/36172, middle-end/36194, middle-end/36227, middle-end/36244, middle-end/36300, middle-end/PR28690, rtl-optimization/36111, rtl-optimization/36419, target/27386, target/30243, target/34932, target/35661, target/35921, target/36079, target/36090, target/36095, target/36182, target/36224, target/36321, target/36362, tree-optimization/34244, tree-optimization/34330, tree-optimization/34976, tree-optimization/35204, tree-optimization/36098, tree-optimization/36119, tree-optimization/36129, tree-optimization/36181, tree-optimization/36187, tree-optimization/36245, tree-optimization/36262, tree-optimization/36291, tree-optimization/36293, tree-optimization/36339 - OpenMP 3.0 support * Tue May 20 18:00:00 2008 Tom "spot" Callaway 4.3.0-11 - fix missing file with sparcv9 * Sun May 18 18:00:00 2008 Tom "spot" Callaway 4.3.0-9 - sparcv9 support and detection * Sun May 18 18:00:00 2008 Tom "spot" Callaway 4.3.0-10 - make sparcv9 the multilib_32_arch for sparc64 gnome-packagekit-0.2.3-2.20080609.fc10 -------------------------------------- * Mon Jun 9 18:00:00 2008 Richard Hughes - 0.2.3-2.20080609 - Add intltool to the BR. * Mon Jun 9 18:00:00 2008 Richard Hughes - 0.2.3-1.20080609 - Pull in a new snapshot from the unstable branch. gnome-user-docs-2.22.1-1.fc9 ---------------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 2.22.1-1 - Update to 2.22.1 gtkspell-2.0.13-1.fc10 ---------------------- * Mon Jun 9 18:00:00 2008 Matthew Barnes - 2.0.13-1.fc9 - Update to 2.0.13 - Add BuildRequires: intltool - Remove "libs" patch (fixed upstream). - Remove patch for RH bug #216412 (fixed upstream). - Remove patch for RH bug #245888 (fixed upstream). joda-time-1.5.2-6.tzdata2008c.fc10 ---------------------------------- * Mon Jun 9 18:00:00 2008 Conrad Meyer - 1.5.2-6.tzdata2008c - New version with new tzdata (2008c). libitl-0.6.4-5.fc10 ------------------- * Mon Jun 9 18:00:00 2008 Mohd Izhar Firdaus Ismail 0.6.4-5 - fix for FTBFS bug #449622 libtool-1.5.26-2.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Dennis Gilmore 1.5.26-2 - build against gcc 4.3.1 man-1.6f-8.fc10 --------------- * Mon Jun 9 18:00:00 2008 Ivana Varekova - 1.6f-8 - Resolves: #449272 Latest man behaves very strange for non-existing man pages - Resolves: #449275 Unowned directories where man package provides content for netpbm-10.35.45-1.fc10 ---------------------- * Mon Jun 9 18:00:00 2008 Jindrich Novy 10.35.45-1 - update to 10.35.45 - fixes anytopnm, pamtohtmltbl, xvminitoppm, pbmtogo, tgatoppm ocaml-3.10.2-4.fc10 ------------------- * Mon Jun 9 18:00:00 2008 Richard W.M. Jones - 3.10.2-4 - Add ocaml-3.11-dev12-no-executable-stack.patch (bz #450551). ocaml-gettext-0.3.2-2.fc10 -------------------------- * Mon Jun 9 18:00:00 2008 Richard W.M. Jones - 0.3.2-2 - Need to disable tests on ppc64 as well since the tests only work with gettext-camomile. * Mon Jun 9 18:00:00 2008 Richard W.M. Jones - 0.3.2-1 - New upstream release 0.3.2 (fixeds rhbz 446916). perl-YAML-Syck-1.05-1.fc10 -------------------------- * Mon Jun 9 18:00:00 2008 Steven Pritchard 1.05-1 - Update to 1.05. php-pear-Cache-Lite-1.7.4-1.fc10 -------------------------------- * Mon Jun 9 18:00:00 2008 Remi Collet 1.7.4-1 - update to 1.7.4 pixman-0.11.4-1.fc10 -------------------- * Mon Jun 9 18:00:00 2008 Soren Sandmann 0.11.4-1 - Update to 0.11.4 * Mon Jun 9 18:00:00 2008 Soren Sandmann 0.11.2-1 - Update to 0.11.2 plymouth-0.2.0-1.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Ray Strode - 0.2.0-1 - Update to version 0.2.0 - Integrate more tightly with nash (pending nash changes) - ship libs for out of tree splash plugins - gradient support - random bug fixes python-genshi-0.5-1.fc10 ------------------------ * Mon Jun 9 18:00:00 2008 Jeffrey C. Ollie - 0.5-1 - Update to released version of Genshi. ruby-gnome2-0.17.0-0.1.rc1.fc10 ------------------------------- * Sun Jun 8 18:00:00 2008 Mamoru Tasaka - 0.17.0-0.1.rc1 - 0.17.0 rc1 - Remove upstreamed patches - 2 patches remain - ruby-gnome2-0.17.0-rc1-script.patch - ruby-gnome2-all-0.16.0-xulrunner.patch - Restrict ruby abi dependency to exact 1.8 version - Fix the license (to strict LGPLv2) rubygem-activeldap-1.0.0-1.fc10 ------------------------------- * Mon Jun 9 18:00:00 2008 Darryl Pierce - 1.0.0-1 - Release 1.0.0 of the gem. rubygem-hoe-1.5.3-2.fc10 ------------------------ * Mon Jun 9 18:00:00 2008 Darryl Pierce - 1.5.3-2 - Fixed the dependency for the newer version of rubygem-rubyforge. * Tue Jun 3 18:00:00 2008 Darryl Pierce - 1.5.3-1 - New release of Hoe. rubygem-rubyforge-1.0.0-1.fc10 ------------------------------ * Mon Jun 9 18:00:00 2008 Darryl Pierce - 1.0.0-1 - New version of RubyForge released. scim-tomoe-0.6.0-3.fc10 ----------------------- * Mon Apr 14 18:00:00 2008 Jens Petersen - 0.6.0-3 - fix build under gcc43 (#440886) - use the main sourceforge project URL seahorse-2.22.2-1.fc9 --------------------- * Wed May 28 18:00:00 2008 Matthias Clasen 2.22.2-1 - Update to 2.22.2 slrn-0.9.9-0.1.pre108.fc10 -------------------------- * Mon Jun 9 18:00:00 2008 Miroslav Lichvar 0.9.9-0.1.pre108 - update to 0.9.9-pre108 - enable inews support - remove -D_GNU_SOURCE from CFLAGS sound-juicer-2.23.0-1.fc10 -------------------------- * Mon Jun 9 18:00:00 2008 - Bastien Nocera - 2.23.0-1 - Update to 2.23.0 sugar-0.81.3-1.fc10 ------------------- * Mon Jun 9 18:00:00 2008 Simon Schampijer - 0.81.3-1 - Search in the activity list (Tomeu) - Add installation date in the activity list (Tomeu) - Improve performance of the activity list (Tomeu) - Sort activities in the list and ring by installation date (Tomeu) - Speaker device (Martin Dengler) - Graphical frontend for the control panel (Simon) - Rotate the dpad keys when the screen rotate button is pressed (Erik Garrison) sugar-base-0.81.1-1.fc10 ------------------------ * Mon Jun 9 18:00:00 2008 Simon Schampijer - 0.81.1-1 - Fix logging (Tomeu) sugar-toolkit-0.81.4-1.fc10 --------------------------- * Mon Jun 9 18:00:00 2008 Simon Schampijer - 0.81.4-1 - Add an installation time property to the activity bundle (Tomeu) - Reveal palettes on right-click (Eben) - Refactor bundlebuilder and add dist_source command (Marco) - Enable journal to do open-with for activity bundles (Chema) - Add timezone, hot_corners, warm_edges to the profile (Simon) system-config-printer-1.0.1-1.fc10 ---------------------------------- * Mon Jun 9 18:00:00 2008 Tim Waugh 1.0.1-1 - Update pysmbc to 1.0.3. - 1.0.1 (bug #450119). taskjuggler-2.4.1-3.fc10 ------------------------ * Mon Jun 9 18:00:00 2008 Kevin Kofler - 2.4.1-3 - disable kdepim support on F10+, kdepim 3 no longer available * Tue May 20 18:00:00 2008 Ondrej Vasik - 2.4.1-2 - kdepim broken dependencies rebuild tuxcmd-0.6.36-3.fc10 -------------------- * Mon Jun 9 18:00:00 2008 Tomas Bzatek 0.6.36-3 - Add ZIP module util-linux-ng-2.14-1.fc10 ------------------------- * Mon Jun 9 18:00:00 2008 Karel Zak 2.14-1 - upgrade to stable util-linux-ng release vino-2.22.2-1.fc9 ----------------- * Wed May 28 18:00:00 2008 Matthias Clasen - 2.22.2-1 - Update to 2.22.2 wine-1.0-0.3.rc3.fc9 -------------------- * Sun Jun 1 18:00:00 2008 Andreas Bierfert - 1.0-0.3.rc3 - version upgrade * Fri May 23 18:00:00 2008 Andreas Bierfert - 1.0-0.2.rc2 - version upgrade - add compile workaround for fedora 9/rawhide (#440139) * Sat May 10 18:00:00 2008 Andreas Bierfert - 1.0-0.1.rc1 - version upgrade to rc1 * Mon May 5 18:00:00 2008 Andreas Bierfert - 0.9.61-1 - version upgrade * Fri Apr 18 18:00:00 2008 Andreas Bierfert - 0.9.60-1 - version upgrade * Sat Apr 5 18:00:00 2008 Andreas Bierfert - 0.9.59-1 - version upgrade wordwarvi-0.13-1.fc10 --------------------- * Mon Jun 9 18:00:00 2008 Hans de Goede 0.13-1 - New upstream release 0.13 xenner-0.37-1.fc10 ------------------ * Mon Jun 9 18:00:00 2008 Gerd Hoffmann - 0.37-1.fc10 - update to version 0.37 - make fedora 9 and opensuse 10.3 guests fly. - update %doc filelist. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 53 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From choeger at cs.tu-berlin.de Tue Jun 10 10:00:12 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 10 Jun 2008 12:00:12 +0200 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> Message-ID: <1213092012.5125.2.camel@choeger6> Am Montag, den 09.06.2008, 22:44 +0000 schrieb Kevin Kofler: > Christoph H?ger cs.tu-berlin.de> writes: > > It would be a great thing, if I could control all that from my own > > versioned repository copy with some 'make ' commands and > > finally merge my changes back especially when testing builds for > > multiple releases. > > Why don't you just commit the changes even if you don't know yet whether they > build? Especially for a small package where you're the sole maintainer, it > won't really matter if CVS HEAD isn't always buildable. Well I am not alone maintaining that package and I thought that spamming comaintainers with "hmm, let's see if _that_ works" commit mails would not be that nice ;) But the real reason is that I always try to make sensefull commits only to a central repo so every revision is a complete buildable version. This avoids others checking out and getting mad about half made work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From michel.sylvan at gmail.com Tue Jun 10 11:12:09 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 10 Jun 2008 07:12:09 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <484E6189.7070405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > At the upcoming FUDCon I plan to hold a session or two regarding > requirements and discussions about the future of our package source > control. This is NOT a time to argue about one SCM being "better" than > another. I don't really want to hear any SCM names at all, rather I'm > interested purely in only what we require and what we'd like out of our > package source control. I'm sending this mail to get people thinking > about it, and to give the people who won't be at FUDCon a chance at > dropping their thoughts in. > ... > I'll be gathering feedback over the next few days and putting them into > a not as of yet created wiki page. > Being able to keep classify patches: - - backports from upstream SCM - - fixes for upstream, already forwarded (with integration to upstream bug-filing system if possible, or at least the bug report URL) - - fixes for upstream, unsent (still being tested or cleaned-up) - - Fedora-specific fixes, not to be forwarded Regards, - -- Michel Salim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhOYYQACgkQWt0J3fd+7ZBXVACeJNe4kLUXh4NTZ/S/Q2H4QHzQ qPgAn1A1zt4AZHjz11LsAmJAekm06jX9 =caCJ -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Tue Jun 10 11:57:56 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Jun 2008 13:57:56 +0200 (CEST) Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies Message-ID: <389552.959071213099076255.JavaMail.www@wwinf8402> I'd like to propose another wiki URL structure change. In the past years, with the previous wiki, there was a drive to build deeply nested page hierarchies. For example Foo SIG was hosted in SIGs/Foo, and its contents put yet another level deeper ie SIGs/Foo/Subject I've noticed while trying to clean up my auto-converted SIG pages that mediawiki **really** wants to use a flat page hierarchy, with categories used to group sets of pages (not surprising given its wikipedia roots; an encyclopedy hierarchy is flat). So I'd like the authorization for interested groups to stop trying to use the tools the way they were not intended, kill the nested deep hierarchy mess and move pages to the wiki root. For example: - SIGs + Category:SIGs + SIGs -> Category:SIGs (redirection) + Special_Interest_Groups -> Category:SIGs (redirection) - SIGs/Foo + Category:Foo SIG (in Category:SIGs) + SIGs/Foo -> Category:Foo SIG (redirection) + Foo_special_interest_group -> Category:Foo SIG (redirection) - SIGs/Foo/Subject1 + Subject1 (in Category:Foo SIG) + SIGs/Foo/Subject1 -> Subject1 (redirection) - SIGs/Foo/Subject2 + Subject2 (in Category:Foo SIG) + SIGs/Foo/Subject2 -> Subject2 (redirection) - SIGs/Bar + Category:Bar SIG (in Category:SIGs) + SIGs/Bar -> Category:Bar SIG (redirection) + Bar_special_interest_group -> Category:Bar SIG (redirection) - SIGs/Bar/Subject3 + Subject3 (in Category:Bar SIG) + SIGs/Bar/Subject3 -> Subject3 (redirection) I've already done some work in this direction for the Fonts SIG: http://fedoraproject.org/wiki/SIGs/Fonts http://fedoraproject.org/wiki/Category:Fonts http://fedoraproject.org/wiki/Category:Font_wishlist As you can see, replacing file hierarchies by categories work pretty well, except all the indexes are user-hostile for items not moved to the wiki root (which I have not done yet). So I'd like to do the last step and flatten completely my SIG page hierarchy. Regards, -- Nicolas Mailhot Cr?ez votre adresse ?lectronique pr?nom.nom at laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at niemueller.de Tue Jun 10 12:07:34 2008 From: tim at niemueller.de (Tim Niemueller) Date: Tue, 10 Jun 2008 14:07:34 +0200 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <389552.959071213099076255.JavaMail.www@wwinf8402> References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: <484E6E86.60608@niemueller.de> Nicolas Mailhot schrieb: > I'd like to propose another wiki URL structure change. > > In the past years, with the previous wiki, there was a drive to build > deeply nested page hierarchies. For example Foo SIG was hosted in > SIGs/Foo, and its contents put yet another level deeper ie SIGs/Foo/Subject I like the paths, as they are the structuring element everybody is used to from his home directory. I'd rather keep it. I specifically don't like the Category:... links, especially not how it was done in the Fonts SIG example. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From jwboyer at gmail.com Tue Jun 10 12:19:20 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 08:19:20 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <484E6189.7070405@gmail.com> References: <1213035578.30252.10.camel@localhost.localdomain> <484E6189.7070405@gmail.com> Message-ID: <20080610081920.1a4bcee3@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 07:12:09 -0400 Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Jesse Keating wrote: > > At the upcoming FUDCon I plan to hold a session or two regarding > > requirements and discussions about the future of our package source > > control. This is NOT a time to argue about one SCM being "better" than > > another. I don't really want to hear any SCM names at all, rather I'm > > interested purely in only what we require and what we'd like out of our > > package source control. I'm sending this mail to get people thinking > > about it, and to give the people who won't be at FUDCon a chance at > > dropping their thoughts in. > > > ... > > I'll be gathering feedback over the next few days and putting them into > > a not as of yet created wiki page. > > > Being able to keep classify patches: > - - backports from upstream SCM > - - fixes for upstream, already forwarded (with integration to upstream > bug-filing system if possible, or at least the bug report URL) > - - fixes for upstream, unsent (still being tested or cleaned-up) > - - Fedora-specific fixes, not to be forwarded You can do all of those already. Just include comments at the top of the patch itself. josh From jwboyer at gmail.com Tue Jun 10 12:23:19 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 08:23:19 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <20080610003627.GK2912@nb.net.home> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> Message-ID: <20080610082319.57708a22@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 02:36:27 +0200 Karel Zak wrote: > On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: > > Thank you all for your thoughtful consideration. > > - be able to easily rebase/refresh a patch That's pretty outside the scope of any SCM we deploy. Use tools like quilt. > - be able to keep track of details about patches (author, committer, > some special marks (e.g. "signed-of-by", "reviewed-by", ...) You can do this in the patches themselves. > - be able to generate statistics about patches (diffstat) Erm... just use diffstat? What does that have to do with the SCM? > - be able to generate change logs > > - be able to generate patches (to avoid unwanted "creativity", it'd > be nice to use same format for all Fedora patches) Generate patches from what? We don't store exploded tarballs. We store tarballs and patches. josh From lemenkov at gmail.com Tue Jun 10 12:24:22 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 10 Jun 2008 16:24:22 +0400 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <484E6E86.60608@niemueller.de> References: <389552.959071213099076255.JavaMail.www@wwinf8402> <484E6E86.60608@niemueller.de> Message-ID: 2008/6/10 Tim Niemueller : > Nicolas Mailhot schrieb: >> I'd like to propose another wiki URL structure change. >> >> In the past years, with the previous wiki, there was a drive to build >> deeply nested page hierarchies. For example Foo SIG was hosted in >> SIGs/Foo, and its contents put yet another level deeper ie SIGs/Foo/Subject > > I like the paths, as they are the structuring element everybody is used > to from his home directory. Using only paths are old and quite obsolete way to structure blobs of information - categories (read - labels) are better. We need flat structure with necessary amount of tags/categories. Take a look at Wikipedia or remember when you last time tried to add "Genre" to your audio-file when you're constrained to add only one :). Note that pages in wiki aren't files - they just pages and they can exists in many different categories. Using paths will render us to multiple issues with duplicating pages (huge number of redirections), many dupes while searching etc. Home directory is very bad example since many files there are not duplicated instead of wiki. -- With best regards! From lemenkov at gmail.com Tue Jun 10 12:27:17 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 10 Jun 2008 16:27:17 +0400 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <389552.959071213099076255.JavaMail.www@wwinf8402> References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: 2008/6/10 Nicolas Mailhot : > I'd like to propose another wiki URL structure change. > > In the past years, with the previous wiki, there was a drive to build deeply > nested page hierarchies. For example Foo SIG was hosted in SIGs/Foo, and its > contents put yet another level deeper ie SIGs/Foo/Subject Yes. We need to flatten this mess. > As you can see, replacing file hierarchies by categories work pretty well, > except all the indexes are user-hostile for items not moved to the wiki root > (which I have not done yet). So I'd like to do the last step and flatten > completely my SIG page hierarchy. Vote for this! -- With best regards! From email.ahmedkamal at googlemail.com Tue Jun 10 13:04:57 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 10 Jun 2008 16:04:57 +0300 Subject: RFE: autofsck Message-ID: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> I would like to propose echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck Working with a local ISP in some rural area where there's a lot of power cuts! The ISP guys were asking like, "Why is it that Linux boxes need manual intervention to get back up after a power cut!" .. "Can't you script what you're doing to get it back up" ?! Does not having this as the default makes sense in some tangible number of cases ?! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzak at redhat.com Tue Jun 10 13:06:41 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 10 Jun 2008 15:06:41 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <20080610082319.57708a22@vader.jdub.homelinux.org> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> Message-ID: <20080610130641.GB5842@nb.net.home> On Tue, Jun 10, 2008 at 08:23:19AM -0400, Josh Boyer wrote: > On Tue, 10 Jun 2008 02:36:27 +0200 > Karel Zak wrote: > > > On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: > > > Thank you all for your thoughtful consideration. > > > > - be able to easily rebase/refresh a patch > > That's pretty outside the scope of any SCM we deploy. Use tools like > quilt. [...] > Generate patches from what? We don't store exploded tarballs. We > store tarballs and patches. Right... so, why we need any SCM (=source code managment)? Shouldn't be better for our work to use quilt+rsync? Karel -- Karel Zak From dwmw2 at infradead.org Tue Jun 10 13:24:30 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jun 2008 14:24:30 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080610093658.GA13339@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> Message-ID: <1213104270.32207.770.camel@pmac.infradead.org> On Tue, 2008-06-10 at 05:36 -0400, Alan Cox wrote: > On Tue, Jun 10, 2008 at 10:29:53AM +0100, David Woodhouse wrote: > > It is the _distribution_ of a collective whole based on both firmware > > and kernel together, which makes the difference under the GPL. > > Are you claiming they are a database. I don't understand your "collective work" > here. What sort of a work do you claim it is, and why does the collective work > acquire some kind of extra rights ? Under copyright law, a collective work is a work in which a number of contributions, each constituting separate and independent works in themselves, are assembled into a collective whole. To create a collective work, permission must be obtained from the owners of the copyrights of the constituent parts. Obviously, there is nothing in copyright law which allows someone to make claims over an independent work _you_ have written all by yourself. The GPL operates under copyright law, and as such it only talks about permissions which you are granted, or denied, in relation to the GPL'd work itself. That includes the permission, or refusal of permission, to include that GPL'd work within a collective work. It so happens that the GPL grants you permission to include the GPL'd "Program" in a collective work _only_ when the other constituent parts of that collective work are also available under the terms of the GPL. No magic "extra rights" over the other, independent sections are implied, and none are needed. It's just that unless those independent sections _do_ happen to be available under the terms of the GPL, you are refused permission to include the original GPL'd "Program" in your collective work. That is _entirely_ within the remit of a copyright licence. It operates purely by restricting your permissions on the original GPL'd work. Consider an analogy: I write short stories. Copyright law states that you do not have permission to publish my short stories in an anthology unless I grant it to you. I grant blanket permission for _anyone_ to reprint my stories in their collections, but _only_ if the other stories in each collection are all stories which have been made available under the same terms. You publish an anthology with a bunch of my stories and one of your own, for which you have _not_ granted such permission to others. That is an offence under copyright law. Not because I have assumed "some kind of extra rights" over your own independent work, but because you didn't have permission to use _my_ work in those circumstances. -- dwmw2 From sandeen at redhat.com Tue Jun 10 13:36:31 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 08:36:31 -0500 Subject: RFE: autofsck In-Reply-To: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> Message-ID: <484E835F.5020301@redhat.com> Ahmed Kamal wrote: > I would like to propose > > echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck > echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck > > Working with a local ISP in some rural area where there's a lot of power > cuts! The ISP guys were asking like, "Why is it that Linux boxes need > manual intervention to get back up after a power cut!" .. "Can't you > script what you're doing to get it back up" ?! > Does not having this as the default makes sense in some tangible number > of cases ?! > Adding -y could potentially be dangerous. e2fsck asks when the answer isn't obvious. In some situations, perhaps, but I probably would not make this default. I'm more concerned that you're seeing so many problems; with a journaling filesystem you really shouldn't have any filesystem metadata integrity problems on power loss; that is, if you have barriers on (which ext3 doesn't by default) and if your storage can pass barriers (which lvm doesn't), or if you have drive write cache disabled (which hurts performance pretty badly). I'd rather address the root of the problem and sort out why, if you are paying the journaling overhead penalty at runtime, it's not saving you on power loss. -Eric From cra at WPI.EDU Tue Jun 10 13:46:33 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 10 Jun 2008 09:46:33 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484E835F.5020301@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> Message-ID: <20080610134633.GZ10754@angus.ind.WPI.EDU> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: > journaling filesystem you really shouldn't have any filesystem metadata > integrity problems on power loss; that is, if you have barriers on > (which ext3 doesn't by default) and if your storage can pass barriers > (which lvm doesn't), or if you have drive write cache disabled (which > hurts performance pretty badly). I wasn't aware that LVM destroyed the kind of guarantees about filesystem metadata being written out to disk that jounaling filesystems rely on? If so, should we perhaps rethink the decision to use LVM by default on Fedora installs? From jkeating at redhat.com Tue Jun 10 13:48:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jun 2008 09:48:18 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <20080610082319.57708a22@vader.jdub.homelinux.org> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> Message-ID: <1213105698.30252.41.camel@localhost.localdomain> On Tue, 2008-06-10 at 08:23 -0400, Josh Boyer wrote: > Generate patches from what? We don't store exploded tarballs. We > store tarballs and patches. Really that's up for debate. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Tue Jun 10 13:59:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 09:59:30 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <20080610130641.GB5842@nb.net.home> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> <20080610130641.GB5842@nb.net.home> Message-ID: <20080610095930.6ed0e53e@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 15:06:41 +0200 Karel Zak wrote: > On Tue, Jun 10, 2008 at 08:23:19AM -0400, Josh Boyer wrote: > > On Tue, 10 Jun 2008 02:36:27 +0200 > > Karel Zak wrote: > > > > > On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: > > > > Thank you all for your thoughtful consideration. > > > > > > - be able to easily rebase/refresh a patch > > > > That's pretty outside the scope of any SCM we deploy. Use tools like > > quilt. > > [...] > > > Generate patches from what? We don't store exploded tarballs. We > > store tarballs and patches. > > Right... so, why we need any SCM (=source code managment)? Shouldn't > be better for our work to use quilt+rsync? No... have you ever tried to deal with multiple people working on the same package without some kind of merge/conflict detection capability built into the tool used to "commit"? Also, you want to preserve the history. As an aside, your patches should be short-lived in the SCM as they should be on their way upstream to be merged into the next release. josh From sandeen at redhat.com Tue Jun 10 14:05:34 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 09:05:34 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610134633.GZ10754@angus.ind.WPI.EDU> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> Message-ID: <484E8A2E.4060605@redhat.com> Chuck Anderson wrote: > On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >> journaling filesystem you really shouldn't have any filesystem metadata >> integrity problems on power loss; that is, if you have barriers on >> (which ext3 doesn't by default) and if your storage can pass barriers >> (which lvm doesn't), or if you have drive write cache disabled (which >> hurts performance pretty badly). > > I wasn't aware that LVM destroyed the kind of guarantees about > filesystem metadata being written out to disk that jounaling > filesystems rely on? If so, should we perhaps rethink the decision to > use LVM by default on Fedora installs? I wouldn't say destroys, but at least reduces. See http://lwn.net/Articles/283161/ and associated lkml thread... By default, lvm on fedora is almost always on a single device, and Andi Kleen has sent a patch to allow barriers to pass on that setup: http://lkml.org/lkml/2008/2/15/125 but AFAICT it's not been merged yet. Barriers do have performance impact, which is probably historically why they're off by default on ext3. I'm not totally convinced that it's a good tradeoff. xfs has them on by default; I'm not sure about reiserfs. My patch to enable them by default on ext4 just went upstream. -Eric From a.badger at gmail.com Tue Jun 10 14:18:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Jun 2008 07:18:29 -0700 Subject: Requirements gathering for new package source control In-Reply-To: <20080610095930.6ed0e53e@vader.jdub.homelinux.org> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> <20080610130641.GB5842@nb.net.home> <20080610095930.6ed0e53e@vader.jdub.homelinux.org> Message-ID: <484E8D35.3070201@gmail.com> Josh Boyer wrote: > On Tue, 10 Jun 2008 15:06:41 +0200 > Karel Zak wrote: > >> On Tue, Jun 10, 2008 at 08:23:19AM -0400, Josh Boyer wrote: >>> On Tue, 10 Jun 2008 02:36:27 +0200 >>> Karel Zak wrote: >>> >>>> On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: >>>>> Thank you all for your thoughtful consideration. >>>> - be able to easily rebase/refresh a patch >>> That's pretty outside the scope of any SCM we deploy. Use tools like >>> quilt. >> [...] >> >>> Generate patches from what? We don't store exploded tarballs. We >>> store tarballs and patches. >> Right... so, why we need any SCM (=source code managment)? Shouldn't >> be better for our work to use quilt+rsync? > > No... have you ever tried to deal with multiple people working on the > same package without some kind of merge/conflict detection capability > built into the tool used to "commit"? > It could be argued that storing patches in an SCM has conflict detection but not merge capability. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jwboyer at gmail.com Tue Jun 10 14:21:04 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 10:21:04 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213105698.30252.41.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> <1213105698.30252.41.camel@localhost.localdomain> Message-ID: <20080610102104.3c85ae03@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 09:48:18 -0400 Jesse Keating wrote: > On Tue, 2008-06-10 at 08:23 -0400, Josh Boyer wrote: > > Generate patches from what? We don't store exploded tarballs. We > > store tarballs and patches. > > Really that's up for debate. Sure. And we've had that debate before. I still believe that if you want an exploded source tree, use the upstream version and develop against _that_. Any patches in the Fedora package SCM should only be there until it gets resolved upstream. Some exceptions will likely apply, but those should be rare and shouldn't require an exploded version of the source to handle. josh From email.ahmedkamal at googlemail.com Tue Jun 10 14:30:10 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 10 Jun 2008 17:30:10 +0300 Subject: RFE: autofsck In-Reply-To: <484E835F.5020301@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> Message-ID: <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> I totally agree we should fix the core cause. If there's anything to prevent file system errors from ever happening, go for it. However, when the inevitable Filesystem errors, Fix(y/n): appears, when was the last time you pressed "n"! Unless you're Theodore tso there's not so much you could do, eh! So why not make that the default On Tue, Jun 10, 2008 at 4:36 PM, Eric Sandeen wrote: > Ahmed Kamal wrote: > > I would like to propose > > > > echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck > > echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck > > > > Working with a local ISP in some rural area where there's a lot of power > > cuts! The ISP guys were asking like, "Why is it that Linux boxes need > > manual intervention to get back up after a power cut!" .. "Can't you > > script what you're doing to get it back up" ?! > > Does not having this as the default makes sense in some tangible number > > of cases ?! > > > > Adding -y could potentially be dangerous. e2fsck asks when the answer > isn't obvious. In some situations, perhaps, but I probably would not > make this default. > > I'm more concerned that you're seeing so many problems; with a > journaling filesystem you really shouldn't have any filesystem metadata > integrity problems on power loss; that is, if you have barriers on > (which ext3 doesn't by default) and if your storage can pass barriers > (which lvm doesn't), or if you have drive write cache disabled (which > hurts performance pretty badly). > > I'd rather address the root of the problem and sort out why, if you are > paying the journaling overhead penalty at runtime, it's not saving you > on power loss. > > -Eric > > -- > 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 sandeen at redhat.com Tue Jun 10 14:35:36 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 09:35:36 -0500 Subject: RFE: autofsck In-Reply-To: <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> Message-ID: <484E9138.6010001@redhat.com> Ahmed Kamal wrote: > I totally agree we should fix the core cause. If there's anything to > prevent file system errors from ever happening, go for it. However, when > the inevitable > Filesystem errors, Fix(y/n): > appears, when was the last time you pressed "n"! Unless you're Theodore > tso there's not so much you could do, eh! So why not make that the default For the same reason that Ted T'so doesn't think the software itself should blindly assume -y as the default. ;) You are basically asking the Fedora scripts to override the e2fsck defaults chosen by Ted as the safest approach. If nothing else, forcing the user to press "y" at least alerts them that something has gone wrong. An unattended box rebooting post-disaster, running e2fsck -y may move huge swaths of data to lost+found automatically and leave the user scratching their heads about where on earth all their email went (or whatever). If you like the tradeoff by all means set it on your boxes, it may be the right answer in your situation, but I don't like it for a default. -Eric From jwboyer at gmail.com Tue Jun 10 14:35:59 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 10:35:59 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <484E8D35.3070201@gmail.com> References: <1213035578.30252.10.camel@localhost.localdomain> <20080610003627.GK2912@nb.net.home> <20080610082319.57708a22@vader.jdub.homelinux.org> <20080610130641.GB5842@nb.net.home> <20080610095930.6ed0e53e@vader.jdub.homelinux.org> <484E8D35.3070201@gmail.com> Message-ID: <20080610103559.6fa49520@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 07:18:29 -0700 Toshio Kuratomi wrote: > Josh Boyer wrote: > > On Tue, 10 Jun 2008 15:06:41 +0200 > > Karel Zak wrote: > > > >> On Tue, Jun 10, 2008 at 08:23:19AM -0400, Josh Boyer wrote: > >>> On Tue, 10 Jun 2008 02:36:27 +0200 > >>> Karel Zak wrote: > >>> > >>>> On Mon, Jun 09, 2008 at 02:19:38PM -0400, Jesse Keating wrote: > >>>>> Thank you all for your thoughtful consideration. > >>>> - be able to easily rebase/refresh a patch > >>> That's pretty outside the scope of any SCM we deploy. Use tools like > >>> quilt. > >> [...] > >> > >>> Generate patches from what? We don't store exploded tarballs. We > >>> store tarballs and patches. > >> Right... so, why we need any SCM (=source code managment)? Shouldn't > >> be better for our work to use quilt+rsync? > > > > No... have you ever tried to deal with multiple people working on the > > same package without some kind of merge/conflict detection capability > > built into the tool used to "commit"? > > > It could be argued that storing patches in an SCM has conflict detection > but not merge capability. Which is more than rsync has... josh From alan at redhat.com Tue Jun 10 14:43:25 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 10:43:25 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213104270.32207.770.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> Message-ID: <20080610144325.GA28121@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 02:24:30PM +0100, David Woodhouse wrote: > Under copyright law, a collective work is a work in which a number of > contributions, each constituting separate and independent works in > themselves, are assembled into a collective whole. Yes I know that. I'm curious why you think the two independent works are somehow a collective work. > work itself. That includes the permission, or refusal of permission, to > include that GPL'd work within a collective work. The GPL says: "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." Last time I checked both disk and RAM are storage media and the two works appear to be independent. I can't find a rational way to interpret it otherwise. We get into the world of 'f the program is GPL then the icons are GPL because they are connected with it. Or games where you'd argue the music files magically become GPL Take the cases you think are a collective/derivative and the cases you think are not and define a test by which this can be ascertained, then perhaps I can see what you are trying to argue.. > Consider an analogy: I write short stories. Copyright law states that > you do not have permission to publish my short stories in an anthology > unless I grant it to you. Subject to the limits in law yes. > I grant blanket permission for _anyone_ to reprint my stories in their > collections, but _only_ if the other stories in each collection are all > stories which have been made available under the same terms. And as a publisher I publish your work and a different work under different covers. The retailer happens to decide to resell them as a bundle. Now I'd like to get to that state anyway so that firmware is nicely seperate from the kernel sources and it is clearer about licenses and what is what. I'm unconvinced it is neccessary, but I am not a lawyer. From alan at redhat.com Tue Jun 10 14:44:48 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 10:44:48 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610134633.GZ10754@angus.ind.WPI.EDU> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> Message-ID: <20080610144448.GB28121@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 09:46:33AM -0400, Chuck Anderson wrote: > filesystem metadata being written out to disk that jounaling > filesystems rely on? If so, should we perhaps rethink the decision to > use LVM by default on Fedora installs? I would agree with that regardless (although LVM barrier handling if it is broken does want fixing - I was under the impression it was ok). My boxes are much faster without LVM so I always turn it off. From buildsys at fedoraproject.org Tue Jun 10 14:39:56 2008 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Jun 2008 10:39:56 -0400 Subject: Package EVR problems in Fedora 2008-06-10 Message-ID: <200806101439.m5AEduua026283@localhost.localdomain> Broken upgrade path report for repositories F7, F7-updates, F7-updates- testing, F8, F8-updates, F8-updates-testing cpl: F7-updates > F8 (0:4.1.0-2.fc7 > 0:4.1.0-1.fc9) GMT-coastlines: F7-updates > F8 (0:1.10-1 > 0:1.9-3) redet-doc: F7-updates > F8 (0:8.23-2 > 0:8.22-1.fc8) system-config-vsftpd: F7-updates > F8 (0:0.5.1-2.fc7 > 0:0.5.1-1.fc10) From alan at redhat.com Tue Jun 10 14:47:59 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 10:47:59 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484E8A2E.4060605@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> Message-ID: <20080610144759.GC28121@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 09:05:34AM -0500, Eric Sandeen wrote: > Barriers do have performance impact, which is probably historically why > they're off by default on ext3. I'm not totally convinced that it's a The cost is dropping rapidly with SATA devices. With a modern SATA disk and NCQ we really really want them on - you've got 31 commands in flight and 16MB or so of drive cache that will be written back in *arbitary* order. Thats a recipe for disaster. A few years ago with one command at a time wind up disks and at most 2MB it wasn't so bad. It really should be getting set on by either our kernel or the installer in the SATA cases. Alan From sandeen at redhat.com Tue Jun 10 14:49:16 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 09:49:16 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610144448.GB28121@devserv.devel.redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> Message-ID: <484E946C.2080206@redhat.com> Alan Cox wrote: > On Tue, Jun 10, 2008 at 09:46:33AM -0400, Chuck Anderson wrote: >> filesystem metadata being written out to disk that jounaling >> filesystems rely on? If so, should we perhaps rethink the decision to >> use LVM by default on Fedora installs? > > I would agree with that regardless (although LVM barrier handling if it is > broken does want fixing - I was under the impression it was ok). My boxes > are much faster without LVM so I always turn it off. LVM barriers aren't so much broken as simply un-implemented by design. static int dm_request(struct request_queue *q, struct bio *bio) { ... /* * There is no use in forwarding any barrier request since we can't * guarantee it is (or can be) handled by the targets correctly. */ if (unlikely(bio_barrier(bio))) { bio_endio(bio, -EOPNOTSUPP); return 0; } ... and somebody should probably measure the lvm overhead in general, I suppose. :) -Eric From sandeen at redhat.com Tue Jun 10 14:53:34 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 09:53:34 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610144759.GC28121@devserv.devel.redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> Message-ID: <484E956E.5080300@redhat.com> Alan Cox wrote: > On Tue, Jun 10, 2008 at 09:05:34AM -0500, Eric Sandeen wrote: >> Barriers do have performance impact, which is probably historically why >> they're off by default on ext3. I'm not totally convinced that it's a > > The cost is dropping rapidly with SATA devices. With a modern SATA disk and > NCQ we really really want them on - you've got 31 commands in flight and 16MB > or so of drive cache that will be written back in *arbitary* order. Thats > a recipe for disaster. A few years ago with one command at a time wind up > disks and at most 2MB it wasn't so bad. It really should be getting set on by > either our kernel or the installer in the SATA cases. > > Alan > I think the problem is, barriers are really implemented as drive cache flushes. So under certain workloads the performance really does hurt. But if the alternative is a good chance of filesystem corruption on power loss, remind me again why we run a journaling fileystem at all? :) If ext3 doesn't get barriers on by default upstream then I would suggest that yes, we should patch the kernel ourselves to do so, or set the installer to create fstabs which specify it for filesystems that don't have barriers on by default. ... after lvm stops filtering it out, anyway. -Eric From ajax at redhat.com Tue Jun 10 14:53:50 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 10 Jun 2008 10:53:50 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <200806101439.m5AEduua026283@localhost.localdomain> References: <200806101439.m5AEduua026283@localhost.localdomain> Message-ID: <1213109630.28032.25.camel@localhost.localdomain> On Tue, 2008-06-10 at 10:39 -0400, buildsys at fedoraproject.org wrote: > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > testing, F8, F8-updates, F8-updates-testing Apologies for this. I'm trying to get this running again and didn't notice that the script sends mail by default. Proper EVR report to follow eventually. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Tue Jun 10 14:57:57 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 10:57:57 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484E946C.2080206@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> Message-ID: <20080610145757.GA29525@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 09:49:16AM -0500, Eric Sandeen wrote: > if (unlikely(bio_barrier(bio))) { > bio_endio(bio, -EOPNOTSUPP); > return 0; > } > > ... and somebody should probably measure the lvm overhead in general, I > suppose. :) About 30% for disk performance on my test box. Obviously that isn't all some LVM code corner case and there are other problems in there to reach that difference on dbench. That's FC8 and I believe some lvm fixes for performance have occurred since I did the runs (FC8 no updates). Alan From billcrawford1970 at gmail.com Tue Jun 10 15:31:53 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 10 Jun 2008 16:31:53 +0100 Subject: RFE: autofsck In-Reply-To: <484E9138.6010001@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> Message-ID: <544eb990806100831k6cc02b1ci20203ea8e1fff82a@mail.gmail.com> 2008/6/10 Eric Sandeen : > For the same reason that Ted T'so doesn't think the software itself > should blindly assume -y as the default. ;) You are basically asking > the Fedora scripts to override the e2fsck defaults chosen by Ted as the > safest approach. Would making "-p" the default be an acceptable compromise? [I thought we used to do this, but I could be losing my marbles] From dwmw2 at infradead.org Tue Jun 10 15:32:50 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jun 2008 16:32:50 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080610144325.GA28121@devserv.devel.redhat.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> Message-ID: <1213111970.32207.835.camel@pmac.infradead.org> On Tue, 2008-06-10 at 10:43 -0400, Alan Cox wrote: > On Tue, Jun 10, 2008 at 02:24:30PM +0100, David Woodhouse wrote: > > Under copyright law, a collective work is a work in which a number of > > contributions, each constituting separate and independent works in > > themselves, are assembled into a collective whole. > > Yes I know that. I'm curious why you think the two independent works are > somehow a collective work. Because they have been assembled into a collective whole; the bzImage file which is distributed and used as a single entity, and which makes use of both the firmware and the GPL'd kernel code. Also, in the case of the source code, because they are integrated into the kernel source and into its build system, and distributed as complementary parts of a coherent whole. > > work itself. That includes the permission, or refusal of permission, to > > include that GPL'd work within a collective work. > > The GPL says: > > "In addition, mere aggregation of another work not based on the Program > with the Program (or with a work based on the Program) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License." > > Last time I checked both disk and RAM are storage media and the two works > appear to be independent. > > I can't find a rational way to interpret it otherwise. I do not find it rational to assert that the above-quoted exception exempts _all_ collective work from the preceding conditions, purely on the basis that it happens to be stored on a 'storage medium'. Such a wide-sweeping exemption would effectively render the preceding two paragraphs entirely redundant. When it speaks of 'mere aggregation on a volume of a storage or distribution medium', I take that to mean things like free and shareware software CDs on the cover of a magazine. Not a blanket exemption for _any_ work which happens to get stored on something we can call a 'storage medium', which would even cover examples like GPL'd programs using proprietary libraries. You effectively seem to be saying "you can do what you like as long as you store it on disk", which is not a reasonable interpretation of the intent of those sections of the GPL. > We get into the world of 'f the program is GPL then the icons are GPL > because they are connected with it. Or games where you'd argue the > music files magically become GPL Again, it would depend on whether the icons, or music files, are distributed as part of a collective whole which is a work based on the Program. There is no fundamental problem here. And nothing "magically becomes GPL". Either it _is_ available under a GPL-compatible licence and you are permitted to incorporate it into a collective work under the terms of the GPL, or not, and you may not do so. There's no magic involved. > Take the cases you think are a collective/derivative and the cases you think are > not and define a test by which this can be ascertained, then perhaps I can > see what you are trying to argue.. As I said, it is a grey area. There is no easy test. We understand what a collective work is, of course, and we can see that the GPL explicitly spells out its intention to extend to collective works based on the Program, and explicitly speaks of its permissions extending to sections of a collective work which are independent and separate works in themselves, but distributed as part of a collective work. The only part which is really subject to interpretation is the part you quoted above, where it grants an exception for "mere aggregation on a volume of a storage or distribution medium". You seem to believe that this exception applies to _anything_ you can store on a hard drive or in memory -- which I don't consider to be at all reasonable because it would effectively render the preceding paragraphs of the ?2 entirely pointless, and is obviously not consistent with the stated intent. I believe that exception is intended for things such as magazine cover CDs, carrying a bunch of mostly unrelated software. It _might_ even (and I suspect we should hope that it does) cover Linux distributions with many programs collected together for convenient installation. But when it comes to such things as a bzImage file which contains both a driver for some hardware _and_ the firmware which drives it, and which will not operate on that hardware unless both of those fundamentally intertwined parts are present, I do not believe that is covered by the exception. The test, if a single such test were possible, would probably be something along the lines of whether the works in question were really just bundled together on a hard drive or CD as if by coincidence, or whether they're really interdependent. It would actually make more sense for me to ask the same question of _you_, since your interpretation would seem to be rendering that part of the GPL entirely void. Can you tell us under what circumstances you believe the GPL _would_ extend to something which is reasonably considered an 'independent and separate work in itself', and what _your_ 'test' would be? > Now I'd like to get to that state anyway so that firmware is nicely seperate > from the kernel sources and it is clearer about licenses and what is what. I'm > unconvinced it is neccessary, but I am not a lawyer. As I said, there's no real answer to the question of whether it's "mere aggregation on a volume of a storage or distribution medium" until/unless a court has ruled on it -- and we each seem to think that the other's position is irrational. But I think we can agree that _until_ there's a ruling, including the firmware in the kernel is just a gratuitous risk. At least, I'm _working_ on making it gratuitous, by removing the _technical_ obstacles which have historically made it suboptimal to remove the firmware from the kernel -- and when that's done, it'll just be silly for us to continue to include it. With the CONFIG_BUILTIN_FIRMWARE config option, you _can_ still include arbitrary firmware into your kernel, if you want to take that legal risk. But it'll no longer be the default. -- dwmw2 From dwmw2 at infradead.org Tue Jun 10 15:39:02 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jun 2008 16:39:02 +0100 Subject: Merge review In-Reply-To: <61081.198.175.55.5.1213105962.squirrel@mail.jcomserv.net> References: <49139.198.175.55.5.1213100281.squirrel@mail.jcomserv.net> <484E76BC.6090605@redhat.com> <61081.198.175.55.5.1213105962.squirrel@mail.jcomserv.net> Message-ID: <1213112342.32207.842.camel@pmac.infradead.org> On Tue, 2008-06-10 at 08:52 -0500, Jon Ciesla wrote: > > David has moved on from Red Hat - you can ping him at his personal email > > (cc'ed above), thanks! > > Will do, thanks Ric! > > David, what are your plans re ownership of this (and possibly other) package? I have stated that I have no plans to relinquish ownership of any Fedora packages, and I have asked for the recent changes in bugzilla to be fixed. I'm sure Ric doesn't _really_ want to own all my Fedora packages, although he's welcome to RHEL glibc-kernheaders :) I hope that it'll get fixed fairly shortly, although I appreciate dkl has recently spawned and is not going to be particularly responsive. -- dwmw2 From jwboyer at gmail.com Tue Jun 10 15:34:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 11:34:39 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <1213109630.28032.25.camel@localhost.localdomain> References: <200806101439.m5AEduua026283@localhost.localdomain> <1213109630.28032.25.camel@localhost.localdomain> Message-ID: <20080610113439.0cb9ac5c@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 10:53:50 -0400 Adam Jackson wrote: > On Tue, 2008-06-10 at 10:39 -0400, buildsys at fedoraproject.org wrote: > > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > > testing, F8, F8-updates, F8-updates-testing > > Apologies for this. I'm trying to get this running again and didn't > notice that the script sends mail by default. Proper EVR report to > follow eventually. Which script are you using? The one in the rel-eng repo has code that connects to koji to see if there are builds queued that might fix the paths. This is mostly used during freeze times, but it could be extended to see if there are builds in the updates-candidates tags too. josh From bruno at wolff.to Tue Jun 10 15:56:56 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 10 Jun 2008 10:56:56 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484E946C.2080206@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> Message-ID: <20080610155656.GA27645@wolff.to> On Tue, Jun 10, 2008 at 09:49:16 -0500, Eric Sandeen wrote: > > LVM barriers aren't so much broken as simply un-implemented by design. > > static int dm_request(struct request_queue *q, struct bio *bio) > { > ... > /* > * There is no use in forwarding any barrier request since we can't > * guarantee it is (or can be) handled by the targets correctly. > */ That seems weird. I thought one of the reasons for having stacked block devices is that you could pass on barrier requests. I have seen comments about adding barrier support to linear block devices that currently don't support it (e.g. dmcrypt) relatively recently. On a somewhat related note there was a discussion about issues with barriers on lmkl last February that suggested there are issues with sync on linux if you have write cache enabled even if you are using barriers. From sandeen at redhat.com Tue Jun 10 16:02:02 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 11:02:02 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610155656.GA27645@wolff.to> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> <20080610155656.GA27645@wolff.to> Message-ID: <484EA57A.2010007@redhat.com> Bruno Wolff III wrote: > On Tue, Jun 10, 2008 at 09:49:16 -0500, > Eric Sandeen wrote: >> LVM barriers aren't so much broken as simply un-implemented by design. >> >> static int dm_request(struct request_queue *q, struct bio *bio) >> { >> ... >> /* >> * There is no use in forwarding any barrier request since we can't >> * guarantee it is (or can be) handled by the targets correctly. >> */ > > That seems weird. I thought one of the reasons for having stacked block devices > is that you could pass on barrier requests. Not really; in general it is trickier w/ more devices I think. md for example passes barriers on raid1 but not 0 or 5 AFAIK... > I have seen comments about adding barrier support to linear block devices > that currently don't support it (e.g. dmcrypt) relatively recently. > > On a somewhat related note there was a discussion about issues with barriers > on lmkl last February that suggested there are issues with sync on linux > if you have write cache enabled even if you are using barriers. Got a url? Thanks, -Eric From limb at jcomserv.net Tue Jun 10 16:11:55 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 10 Jun 2008 11:11:55 -0500 (CDT) Subject: Merge review In-Reply-To: <1213112342.32207.842.camel@pmac.infradead.org> References: <49139.198.175.55.5.1213100281.squirrel@mail.jcomserv.net> <484E76BC.6090605@redhat.com> <61081.198.175.55.5.1213105962.squirrel@mail.jcomserv.net> <1213112342.32207.842.camel@pmac.infradead.org> Message-ID: <2748.198.175.55.5.1213114315.squirrel@mail.jcomserv.net> > On Tue, 2008-06-10 at 08:52 -0500, Jon Ciesla wrote: >> > David has moved on from Red Hat - you can ping him at his personal >> email >> > (cc'ed above), thanks! >> >> Will do, thanks Ric! >> >> David, what are your plans re ownership of this (and possibly other) >> package? > > I have stated that I have no plans to relinquish ownership of any Fedora > packages, and I have asked for the recent changes in bugzilla to be > fixed. I'm sure Ric doesn't _really_ want to own all my Fedora packages, > although he's welcome to RHEL glibc-kernheaders :) > > I hope that it'll get fixed fairly shortly, although I appreciate dkl > has recently spawned and is not going to be particularly responsive. Ah, good, glad to hear it. Shall I add your infradead address back to this particular BZ? > -- > dwmw2 > -- novus ordo absurdum From sandeen at redhat.com Tue Jun 10 16:21:19 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 11:21:19 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610145757.GA29525@devserv.devel.redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> <20080610145757.GA29525@devserv.devel.redhat.com> Message-ID: <484EA9FF.9030604@redhat.com> Alan Cox wrote: > On Tue, Jun 10, 2008 at 09:49:16AM -0500, Eric Sandeen wrote: >> if (unlikely(bio_barrier(bio))) { >> bio_endio(bio, -EOPNOTSUPP); >> return 0; >> } >> >> ... and somebody should probably measure the lvm overhead in general, I >> suppose. :) > > About 30% for disk performance on my test box. Obviously that isn't all > some LVM code corner case and there are other problems in there to reach > that difference on dbench. That's FC8 and I believe some lvm fixes for > performance have occurred since I did the runs (FC8 no updates). > > Alan > quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2. ext3 on /dev/sdc: Throughput 679.495 MB/sec 4 procs ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc: Throughput 665.599 MB/sec 4 procs -Eric From kwade at redhat.com Tue Jun 10 16:06:06 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 10 Jun 2008 09:06:06 -0700 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: <1213113966.3866.28.camel@calliope.phig.org> On Tue, 2008-06-10 at 16:27 +0400, Peter Lemenkov wrote: > 2008/6/10 Nicolas Mailhot : > > I'd like to propose another wiki URL structure change. > > > > In the past years, with the previous wiki, there was a drive to build deeply > > nested page hierarchies. For example Foo SIG was hosted in SIGs/Foo, and its > > contents put yet another level deeper ie SIGs/Foo/Subject > > Yes. We need to flatten this mess. > > > As you can see, replacing file hierarchies by categories work pretty well, > > except all the indexes are user-hostile for items not moved to the wiki root > > (which I have not done yet). So I'd like to do the last step and flatten > > completely my SIG page hierarchy. > > Vote for this! Before the move and since, we've been discussing this issue amongst the wiki gardening crew. We'd like to see new pages adhere to a new structure, and to have groups begin moving existing pages to a new structure. We're working on the details of the structure at [[Help:Wiki Structure]]: http://fedoraproject.org/wiki/Help:Wiki_Structure * Flat namespaces: Docs/SecurityGuide => Security_Guide * Categories: Docs/Drafts/GetInvolvedGuide => Get_Involved_Guide in Category:Draft_Documentation, then moved to Category:Documentation when complete One thing we've been tossing back and forth is how to deal with the two distinct audiences to the wiki: end-users and contributors. One argument is categorize and create ways to keep from duplicate naming problems. For example, adding (SIG) on the end of SIG pages. Another idea is to use Namespace:Foo, that is, create a new MediaWiki "Namespace" that sorts content into a separated part of the wiki. This removes the content from the index for the site Namespace (FedoraProject:). This might make sense in some cases, e.g. QA: for all the QA test plans. I don't think we want to sequester SIG or subProject content in that way. One reason we used directory-like hierarchy in the past was to make it "easier" to find pages. MediaWiki has a good search mechanism, but AFAICT it needs spaces "_" in page names to find words in titles. Regardless, it's going to do a better job of helping people find content than the MoinMoin search did. Another view point is that we don't want to hide contributor content from end-users, but it would help if we, for example, put a badge on end-user focused pages so it was clear "this is for help with using Fedora." That can be easily done with a template, cf. [[Template:Move]] for an idea of how it works. - Karsten -- Karsten Wade, Sr. 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 Tue Jun 10 16:27:01 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 10 Jun 2008 09:27:01 -0700 Subject: Some highlights about MediaWiki for noobs :) In-Reply-To: <870180fe0806090849m352ad8a6u18948d4a80805b53@mail.gmail.com> References: <870180fe0806090849m352ad8a6u18948d4a80805b53@mail.gmail.com> Message-ID: <1213115221.3866.32.camel@calliope.phig.org> On Mon, 2008-06-09 at 09:49 -0600, Jerry James wrote: > On Sun, Jun 8, 2008 at 12:36 AM, Peter Lemenkov > wrote: > Pages, which are good candidates for merging, can be found > there: > > List of users: > https://fedoraproject.org/wiki/Special:Listusers > > List of lonely pages: > https://fedoraproject.org/wiki/Special:Lonelypages > > I found that many users still didn't link their new login-name > with > their old personal pages. > > My page has very little content, so I just created my new page and > copied the content over. Now I can't figure out how to delete the old > page. Is there a good site where a mediawiki newbie like me can learn > how to get around? http://fedoraproject.org/wiki/Help:Editing There is a link from there at the top of the page to deeper/richer MediaWiki help. What you are looking to do is to move your old UserName page to your new User:Userid page. This plus a bit more is described here: https://fedoraproject.org/wiki/FedoraProject:Wiki_migration_to-do The wiki gardening crew hangs out in #fedora-docs to help with all of that. - Karsten -- Karsten Wade, Sr. 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 dwmw2 at infradead.org Tue Jun 10 16:27:16 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jun 2008 17:27:16 +0100 Subject: Merge review In-Reply-To: <2748.198.175.55.5.1213114315.squirrel@mail.jcomserv.net> References: <49139.198.175.55.5.1213100281.squirrel@mail.jcomserv.net> <484E76BC.6090605@redhat.com> <61081.198.175.55.5.1213105962.squirrel@mail.jcomserv.net> <1213112342.32207.842.camel@pmac.infradead.org> <2748.198.175.55.5.1213114315.squirrel@mail.jcomserv.net> Message-ID: <1213115236.32207.844.camel@pmac.infradead.org> On Tue, 2008-06-10 at 11:11 -0500, Jon Ciesla wrote: > > On Tue, 2008-06-10 at 08:52 -0500, Jon Ciesla wrote: > >> > David has moved on from Red Hat - you can ping him at his personal > >> email > >> > (cc'ed above), thanks! > >> > >> Will do, thanks Ric! > >> > >> David, what are your plans re ownership of this (and possibly other) > >> package? > > > > I have stated that I have no plans to relinquish ownership of any Fedora > > packages, and I have asked for the recent changes in bugzilla to be > > fixed. I'm sure Ric doesn't _really_ want to own all my Fedora packages, > > although he's welcome to RHEL glibc-kernheaders :) > > > > I hope that it'll get fixed fairly shortly, although I appreciate dkl > > has recently spawned and is not going to be particularly responsive. > > Ah, good, glad to hear it. Shall I add your infradead address back to > this particular BZ? Probably best just to wait till they all get fixed. -- dwmw2 From tim at niemueller.de Tue Jun 10 16:28:34 2008 From: tim at niemueller.de (Tim Niemueller) Date: Tue, 10 Jun 2008 18:28:34 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <484EABB2.4050203@niemueller.de> Jesse Keating schrieb: > I'll be gathering feedback over the next few days and putting them into > a not as of yet created wiki page. I'd like to have an easy way to setup a local repository before the review request (for example on fedorapeople.org), so that others can easily follow and multiple maintainers to-be can work on the package *before* the review request is through and the package checked in. In that case importing into the package repo (by the admin) could mean pulling from the preview repo. It would be nice if the common files could be kind of an external reference, such that changes to the common files are immediately visible without committing them to each and every package sub-repo/dir. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From lesmikesell at gmail.com Tue Jun 10 16:31:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 10 Jun 2008 11:31:36 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213111970.32207.835.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> Message-ID: <484EAC68.2020303@gmail.com> David Woodhouse wrote: > >> Yes I know that. I'm curious why you think the two independent works are >> somehow a collective work. > > Because they have been assembled into a collective whole; the bzImage > file which is distributed and used as a single entity, They are aggregated together. > and which makes > use of both the firmware and the GPL'd kernel code. Separately. The firmware is downloaded to respective devices and is no more a part of the kernel than the content of a music file is part of the code that plays it. > Also, in the case of the source code, because they are integrated into > the kernel source and into its build system, and distributed as > complementary parts of a coherent whole. You aggregate something for distribution. It's not a whole unless the components are combined. And while this may be a fuzzy area for things covered by the stock GPL, the version that covers Linux specifically says >> >> I can't find a rational way to interpret it otherwise. > > I do not find it rational to assert that the above-quoted exception > exempts _all_ collective work from the preceding conditions, purely on > the basis that it happens to be stored on a 'storage medium'. Such a > wide-sweeping exemption would effectively render the preceding two > paragraphs entirely redundant. No, what exempts it is the fact that they are separate things both in their origin and destination. > When it speaks of 'mere aggregation on a volume of a storage or > distribution medium', I take that to mean things like free and shareware > software CDs on the cover of a magazine. When that was written and for a long time after, there was no GPL'd OS, so among other things it meant that commercial unix distributors (without which there wouldn't have been any way to run the GPL'd code...) could include GPL'd items in their distribution or along with other add-on packages. > Not a blanket exemption for > _any_ work which happens to get stored on something we can call a > 'storage medium', which would even cover examples like GPL'd programs > using proprietary libraries. Not _any_ work - just separate works. > You effectively seem to be saying "you can do what you like as long as > you store it on disk", which is not a reasonable interpretation of the > intent of those sections of the GPL. No, you can take separate works and put them together as long as they remain separate works - as the stuff loaded into a device's firmware is separate from the kernel. >> We get into the world of 'f the program is GPL then the icons are GPL >> because they are connected with it. Or games where you'd argue the >> music files magically become GPL > > Again, it would depend on whether the icons, or music files, are > distributed as part of a collective whole which is a work based on the > Program. There is no fundamental problem here. Temporarily aggregating two separate items into one storage container doesn't change the fact that they are separate items. > And nothing "magically becomes GPL". Either it _is_ available under a > GPL-compatible licence and you are permitted to incorporate it into a > collective work under the terms of the GPL, or not, and you may not do > so. There's no magic involved. Permission to make a collective work is irrelevant to aggregating separate things. >> Take the cases you think are a collective/derivative and the cases you think are >> not and define a test by which this can be ascertained, then perhaps I can >> see what you are trying to argue.. > > As I said, it is a grey area. There is no easy test. We understand what > a collective work is, of course, and we can see that the GPL explicitly > spells out its intention to extend to collective works based on the > Program, and explicitly speaks of its permissions extending to sections > of a collective work which are independent and separate works in > themselves, but distributed as part of a collective work. > > The only part which is really subject to interpretation is the part you > quoted above, where it grants an exception for "mere aggregation on a > volume of a storage or distribution medium". Which is, of course, the relevant part. > You seem to believe that > this exception applies to _anything_ you can store on a hard drive or in > memory Straw man.. No one said any such thing. > -- which I don't consider to be at all reasonable because it > would effectively render the preceding paragraphs of the ?2 entirely > pointless, and is obviously not consistent with the stated intent. And an irrelevant argument, since this is covered by the copyright concepts of derived works. > I believe that exception is intended for things such as magazine cover > CDs, carrying a bunch of mostly unrelated software. Please... try to imagine the time when that was written and think about tapes full of commercial software instead. > It _might_ even (and > I suspect we should hope that it does) cover Linux distributions with > many programs collected together for convenient installation. But when > it comes to such things as a bzImage file which contains both a driver > for some hardware _and_ the firmware which drives it, and which will not > operate on that hardware unless both of those fundamentally intertwined > parts are present, I do not believe that is covered by the exception. Where does it say that one file format or another is not a reasonable way to aggregate for distribution? > The test, if a single such test were possible, would probably be > something along the lines of whether the works in question were really > just bundled together on a hard drive or CD as if by coincidence, or > whether they're really interdependent. Now you are getting somewhere but the answer to any such test won't depend on _how_ that firmware got installed. That is, if the kernel is prohibited from being distributed because it depends on firmware, then it won't matter whether it carries that content along, or it is already there in ROM or preloaded flash. > It would actually make more sense for me to ask the same question of > _you_, since your interpretation would seem to be rendering that part of > the GPL entirely void. Can you tell us under what circumstances you > believe the GPL _would_ extend to something which is reasonably > considered an 'independent and separate work in itself', and what _your_ > 'test' would be? In the past the FSF has claimed that something should be considered a derived work and covered by the GPL if it needed a GPL'd library to function, even if it was not distributed together. Since the firmware contents are specific to the device and typically function with other OS's, I'd think that makes them independent and separate. >> Now I'd like to get to that state anyway so that firmware is nicely seperate >> from the kernel sources and it is clearer about licenses and what is what. I'm >> unconvinced it is neccessary, but I am not a lawyer. > > As I said, there's no real answer to the question of whether it's "mere > aggregation on a volume of a storage or distribution medium" > until/unless a court has ruled on it -- and we each seem to think that > the other's position is irrational. > > But I think we can agree that _until_ there's a ruling, including the > firmware in the kernel is just a gratuitous risk. The same risk goes with any GPL covered work. There's always the chance that you'll find some part of it had restrictions that make it impossible to distribute the whole. Being able to read the source doesn't make a difference in that respect. > At least, I'm > _working_ on making it gratuitous, by removing the _technical_ obstacles > which have historically made it suboptimal to remove the firmware from > the kernel -- and when that's done, it'll just be silly for us to > continue to include it. With the CONFIG_BUILTIN_FIRMWARE config option, > you _can_ still include arbitrary firmware into your kernel, if you want > to take that legal risk. But it'll no longer be the default. It would make the fact that the firmware images are separate items more obvious if they were bundled separately from the code that installs them, but there's really no difference except in the technique used for aggregation. -- Les Mikesell lesmikesell at gmail.com From paul at xelerance.com Tue Jun 10 16:30:53 2008 From: paul at xelerance.com (Paul Wouters) Date: Tue, 10 Jun 2008 12:30:53 -0400 (EDT) Subject: RFE: autofsck In-Reply-To: <484E9138.6010001@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> Message-ID: > For the same reason that Ted T'so doesn't think the software itself > should blindly assume -y as the default. ;) You are basically asking > the Fedora scripts to override the e2fsck defaults chosen by Ted as the > safest approach. Who, aside from Ted Tso, can do anything else but re-run with "yes"? You are just postponing the problem, and thereby adding to the problem. > If nothing else, forcing the user to press "y" at least alerts them that > something has gone wrong. We already know something is wrong, our box is missing waiting in single user mode. > An unattended box rebooting post-disaster, > running e2fsck -y may move huge swaths of data to lost+found > automatically and leave the user scratching their heads about where on > earth all their email went (or whatever). As compared to rebooting post-disaster, being gone, needing the sysadmin to drive over, find single user mode, run e2fsck, get INCONSISTENT FILESYSTEM detected, and rerun with e2fsck -y, which puts all files in lost+found. How different your scenario from having "-y" or not? Nothing. However, on the OTHER 99.99% of the scnearios, your box is dead in the water and boxes with -y are back online. I'd rather scratch my head on a missing email. Besides, if THAT is what you want to fix, then fix that by warning the user/root/wheel group upon login if there are files in lost+found. > If you like the tradeoff by all means set it on your boxes, it may be > the right answer in your situation, but I don't like it for a default. You're wrong. I had a discussion with Ted himself who sees that the current way is wrong. You can find me ranting every fedora release that it is wrong. I run boxes all over the planet, from RH9 to F9 and RHEL. It's a problem. It's always been a problem. What would help is to add /etc/sysconfig/autofsck with the line # AUTOFSCK_OPT="-y" so at least we don't have to keep reading rc.sysvinit to figure out which version of fedora we need to change which script/variable to make this happen. Though personally, I'd prefer an Anaconda option for it. "Unselect this option if you want to disable automatic repair attempts of the filesystem, and have a chance to use a raw filesystem editor to directly edit raw blocks on disk" Let's face it. There are 10 people in the world who could and maybe want, to do this to an ext3 filesystem, and I'm pretty sure they maintain less then 0.00001% of the Fedora servers ouf there. Paul From buildsys at fedoraproject.org Tue Jun 10 16:24:36 2008 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Jun 2008 12:24:36 -0400 Subject: Package EVR problems in Fedora 2008-06-10 Message-ID: <200806101624.m5AGOaWP027275@localhost.localdomain> Broken upgrade path report for repositories F7, F7-updates, F7-updates- testing, F8, F8-updates, F8-updates-testing, F9, F9-updates, F9-updates- testing, F7, F7-updates, F7-updates-testing, F8, F8-updates, F8-updates- testing, F9, F9-updates, F9-updates-testing, rawhide AcetoneISO2: F7-updates > F9-updates (0:2.0.2-4.fc7 > 0:2.0.2-3.fc9) F8-updates > F9-updates (0:2.0.2-4.fc8 > 0:2.0.2-3.fc9) aplus-fsf: F7-updates-testing > F9 (0:4.22.1-3.fc7 > 0:4.22.1-2.fc9) F8-updates > F9 (0:4.22.1-3.fc8 > 0:4.22.1-2.fc9) asunder: F7-updates-testing > F9 (0:1.5-1.fc7 > 0:1.0.2-1.fc9) F8-updates-testing > F9 (0:1.5-1.fc8 > 0:1.0.2-1.fc9) blam: F8-updates > F9 (0:1.8.3-15.fc8 > 0:1.8.3-13.fc9) bouml-doc: F7-updates > F8-updates (0:4.2-1 > 0:3.4-1) cairo-clock: F7-updates > F8-updates (0:0.3.4-2.fc7 > 0:0.3.4-1.fc8) F7-updates > F9 (0:0.3.4-2.fc7 > 0:0.3.4-1.fc9) cpl: F7-updates > F8-updates (0:4.1.0-2.fc7 > 0:4.1.0-1.fc8) F7-updates > F9 (0:4.1.0-2.fc7 > 0:4.1.0-1.fc9) ctapi-cyberjack: F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8) dbus-python: F7-updates > F8 (0:0.82.3-1.fc7 > 0:0.82.0-2.fc8) driftnet: F7-updates > F9 (0:0.1.6-18.20040426cvs.fc7 > 0:0.1.6-16.20040426cvs.fc9) F8-updates > F9 (0:0.1.6-19.20040426cvs.fc8 > 0:0.1.6-16.20040426cvs.fc9) eclipse-phpeclipse: F7-updates > F8 (0:1.1.8-17.fc7 > 0:1.1.8-16.fc7) ecore: F8-updates > F9-updates (0:0.9.9.042-4.fc8 > 0:0.9.9.042-3.fc9) eric: F7-updates > F8-updates (0:3.9.5-3.fc7 > 0:3.9.5-2.fc8) evolution-rss: F8-updates > F9 (0:0.0.8-9.fc8 > 0:0.0.8-7.fc9) fedora-idm-console: F8-updates > F9 (0:1.1.1-3.fc8 > 0:1.1.1-2.fc9) fio: F8-updates > F9 (0:1.19-1.fc8 > 0:1.18-1.fc9) ganyremote: F8-updates > F9-updates-testing (0:3.0-1.fc8 > 0:2.8-2.fc9) gbrainy: F8-updates-testing > F9-updates-testing (0:0.70-3.fc8 > 0:0.70-1.fc9) geoqo: F7-updates-testing > F9 (0:0.97-1.fc7 > 0:0.96-5.fc9) F8-updates-testing > F9 (0:0.97-1.fc8 > 0:0.96-5.fc9) ghc: F8-updates > F9 (0:6.8.2-8.fc8 > 0:6.8.2-2.fc9) GMT: F7-updates > F9-updates (0:4.3.1-2.fc7 > 0:4.3.1-1.fc9) F8-updates > F9-updates (0:4.3.1-2.fc8 > 0:4.3.1-1.fc9) gnash: F7-updates > F9 (0:0.8.2-3.fc7 > 0:0.8.2-2.fc9) F8-updates > F9 (0:0.8.2-3.fc8 > 0:0.8.2-2.fc9) gnome-do: F8-updates > F9 (0:0.4.2.0-1.fc8 > 0:0.4.0.1-1.fc9) gnuradio: F8-updates > F9 (0:3.1.2-1.fc8 > 0:3.1.1-4.fc9) grub: F8-updates-testing > F9 (0:0.97-33.1.fc8 > 0:0.97-33.fc9) gtkmm24: F8-updates > F9 (0:2.12.7-1.fc8 > 0:2.12.5-1.fc9) gtkmozembedmm: F8-updates > F9 (0:1.4.2.cvs20060817-20.fc8 > 0:1.4.2.cvs20060817-17.fc9) haproxy: F7-updates > F9 (0:1.3.14.4-1.fc7 > 0:1.3.14.3-1.fc9) F8-updates > F9 (0:1.3.14.4-1.fc8 > 0:1.3.14.3-1.fc9) httrack: F7-updates-testing > F9 (0:3.42-10.fc7 > 0:3.42-9.fc9) F8-updates-testing > F9 (0:3.42-10.fc8 > 0:3.42-9.fc9) idm-console-framework: F8-updates > F9 (0:1.1.1-3.fc8 > 0:1.1.1-1.fc8) inadyn: F7-updates > F9 (0:1.96.2-4.fc7 > 0:1.96.2-3.fc9) F8-updates > F9 (0:1.96.2-4.fc8 > 0:1.96.2-3.fc9) initng-ifiles: F7-updates > F9 (0:0.1.5-1.fc7 > 0:0.1.4-5.fc9) F8-updates > F9 (0:0.1.5-1.fc8 > 0:0.1.4-5.fc9) itpp: F7-updates > F9 (0:4.0.4-1.fc7 > 0:4.0.0-2.fc9) F8-updates > F9 (0:4.0.4-1.fc8 > 0:4.0.0-2.fc9) jna: F8-updates > F9 (0:3.0.2-8.fc8 > 0:3.0.2-7.fc9) knetworkmanager: F7-updates-testing > F8-updates (0:0.2.2-3.fc7 > 0:0.2-0.7.fc8) libdvdnav: F8-updates-testing > F9 (0:4.1.2-1.fc8 > 0:4.1.1-6.fc9) libntlm: F8-updates > F9 (0:1.0-1.fc8 > 0:0.4.2-1.fc9) libxcb: F7-updates > F8-updates (0:1.1-1.fc7 > 0:1.0-4.fc8) mod_geoip: F7-updates > F9 (0:1.2.2-1.fc7 > 0:1.2.0-2.fc9) F8-updates > F9 (0:1.2.2-1.fc8 > 0:1.2.0-2.fc9) mod_security: F7-updates > F9 (0:2.1.7-1.fc7 > 0:2.1.6-1.fc9) F8-updates > F9 (0:2.1.7-1.fc8 > 0:2.1.6-1.fc9) namazu: F7-updates > F9 (0:2.0.18-3.fc7 > 0:2.0.18-1.fc9) F8-updates > F9 (0:2.0.18-3.fc8 > 0:2.0.18-1.fc9) nethack: F7-updates > F8-updates (0:3.4.3-17.fc7 > 0:3.4.3-16.fc8) ngspice: F7-updates > F9 (0:17-15.fc7 > 0:17-14.fc9) F8-updates > F9 (0:17-15.fc8 > 0:17-14.fc9) obconf: F8-updates-testing > F9 (0:2.0.3-2.fc8 > 0:2.0.3-1.fc9) ocaml-deriving: F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) ocaml-gsl: F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) ocaml-json-static: F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) ocaml-lacaml: F8-updates > F9 (0:4.3.0-3.fc8 > 0:4.3.0-2.fc9) ocaml-mysql: F8-updates > F9 (0:1.0.4-3.fc8 > 0:1.0.4-2.fc9) ocaml-openin: F8-updates > F9 (0:20070524-3.fc8 > 0:20070524-2.fc9) ocaml-ounit: F8-updates > F9-updates (0:1.0.2-3.fc8 > 0:1.0.2-2.fc9) ocaml-pa-monad: F8-updates > F9-updates (0:1.2.0-4.fc8 > 0:1.2.0-3.fc9) ocaml-pgocaml: F8-updates > F9-updates (0:1.1-2.fc8 > 0:1.1-1.fc9) ocaml-res: F8-updates > F9-updates (0:2.2.5-3.fc8 > 0:2.2.5-1.fc9) ocaml-xmlrpc-light: F8-updates > F9 (0:0.6-3.fc8 > 0:0.6-2.fc9) openbox: F8-updates-testing > F9 (0:3.4.7.2-2.fc8 > 0:3.4.6.1-1.fc9) perl-Device-SerialPort: F8 > F9 (0:1.003001-1.fc8 > 0:1.04-3.fc9) perl-Geo-IP: F7-updates > F9 (0:1.31-1.fc7 > 0:1.30-3.fc9) F8-updates > F9 (0:1.31-1.fc8 > 0:1.30-3.fc9) perl-QWizard: F7-updates-testing > F9 (0:3.14-1.fc7 > 0:3.13-3.fc9) F8-updates-testing > F9 (0:3.14-1.fc8 > 0:3.13-3.fc9) php-magickwand: F8-updates > F9 (0:1.0.6-2.fc8 > 0:1.0.6-1.fc9) pm-utils: F7-updates-testing > F8 (0:0.99.4-17.fc7 > 0:0.99.4-6.fc8) pybluez: F7-updates > F9 (0:0.9.2-1.fc7 > 0:0.9.1-4.fc9) F8 > F9 (0:0.9.2-1.fc7 > 0:0.9.1-4.fc9) pychess: F7-updates > F8-updates (0:0.8-2.fc7 > 0:0.8-1.fc8) pyjigdo: F7-updates > F9 (0:0.3.0-1.fc7 > 0:0.2-3.fc9) F8-updates > F9 (0:0.3.0-1.fc8 > 0:0.2-3.fc9) python-tgcaptcha: F8-updates-testing > F9 (0:0.11-3.fc8 > 0:0.11-2.fc9) redet-doc: F7-updates > F8 (0:8.23-2 > 0:8.22-1.fc8) F7-updates > F9 (0:8.23-2 > 0:8.22-1.fc8) rkward: F7-updates-testing > F8-updates-testing (0:0.4.9a-3.fc7 > 0:0.4.9a-2.fc8) rsync: F7-updates > F8-updates (0:2.6.9-6.fc7 > 0:2.6.9-5.fc8) snownews: F7-updates > F9 (0:1.5.9-1.fc7 > 0:1.5.8-2.fc9) F8-updates > F9 (0:1.5.9-1.fc8 > 0:1.5.8-2.fc9) specto: F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: F7-updates > F9 (0:0.10-1.fc7 > 0:0.9-3.fc9) F8-updates > F9 (0:0.10-1.fc8 > 0:0.9-3.fc9) streamtuner: F8-updates > F9 (0:0.99.99-19.fc8 > 0:0.99.99-17.fc9) subcommander: F7-updates > F9 (0:1.2.3-1.fc7.1 > 0:1.2.2-12.fc9) F8-updates > F9 (0:1.2.3-1.fc8.1 > 0:1.2.2-12.fc9) system-config-vsftpd: F7-updates > F8-updates (0:0.5.1-2.fc7 > 0:0.5.1-1.fc8) F7-updates > F9-updates (0:0.5.1-2.fc7 > 0:0.5.1-1.fc9) TurboGears: F8-updates-testing > F9 (0:1.0.4.4-3.fc8 > 0:1.0.4.4-2.fc9) uncrustify: F7-updates-testing > F9 (0:0.46-1.fc7 > 0:0.45-1.fc9) F8-updates-testing > F9 (0:0.46-1.fc8 > 0:0.45-1.fc9) virt-df: F8-updates > F9-updates (0:2.1.1-8.fc8 > 0:2.1.1-7.fc9) virt-top: F8-updates-testing > F9-updates (0:1.0.1-4.fc8 > 0:1.0.1-3.fc9) wdaemon: F7-updates-testing > F9 (0:0.13-2.fc7 > 0:0.13-1.fc9) F8-updates-testing > F9 (0:0.13-3.fc8 > 0:0.13-1.fc9) xbase: F7-updates > F8 (0:2.0.0-8.fc7 > 0:2.0.0-7.fc8) From kwade at redhat.com Tue Jun 10 16:32:35 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 10 Jun 2008 09:32:35 -0700 Subject: Some highlights about MediaWiki for noobs :) In-Reply-To: References: Message-ID: <1213115555.3866.38.camel@calliope.phig.org> On Sun, 2008-06-08 at 10:30 +0400, Peter Lemenkov wrote: > * Redirection pages. Almost all of us already have old userpages, but > after migrating to MediaWiki we all got new ones, named differently. > For sake of simplicity, you don't need to copypaste text from old page > to new (or vice versa) - just add redirection. For example, user Peter > has old page [[PeterLemenkov]]. He wants to merge the former and the > latter. For doint this he just edits page [[Peter]] and adds the only > message: > > #REDIRECT [[PeterLemenkov]] > > Thats all - every visitor of page [[Peter]] will be redirected to > [[PeterLemenkov]]. See latest edits - I already fixed som pages. Do you mean User:Lemenkov (or whatever your FAS user ID is)? What I think you are looking to do is to do a ''move'', which is a tab at the top of the page when you are logged in. This sets up a redirect automatically. The rest of this is described here: http://fedoraproject.org/wiki/FedoraProject:Wiki_migration_to-do > * Rich set of special pages. Thanks much for pointing out these feature pages to folks. MediaWiki has many Special: pages that are great assistance to a community documentation effort. Riding on MediaWiki/Wikipedia's experience in pre-built wiki tooling is another benefit of this migration. - Karsten -- Karsten Wade, Sr. 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 ajax at redhat.com Tue Jun 10 16:29:32 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 10 Jun 2008 12:29:32 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080610113439.0cb9ac5c@vader.jdub.homelinux.org> References: <200806101439.m5AEduua026283@localhost.localdomain> <1213109630.28032.25.camel@localhost.localdomain> <20080610113439.0cb9ac5c@vader.jdub.homelinux.org> Message-ID: <1213115372.28032.29.camel@localhost.localdomain> On Tue, 2008-06-10 at 11:34 -0400, Josh Boyer wrote: > On Tue, 10 Jun 2008 10:53:50 -0400 > Adam Jackson wrote: > > > On Tue, 2008-06-10 at 10:39 -0400, buildsys at fedoraproject.org wrote: > > > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > > > testing, F8, F8-updates, F8-updates-testing > > > > Apologies for this. I'm trying to get this running again and didn't > > notice that the script sends mail by default. Proper EVR report to > > follow eventually. > > Which script are you using? The one in the rel-eng repo has code that > connects to koji to see if there are builds queued that might fix the > paths. This is mostly used during freeze times, but it could be > extended to see if there are builds in the updates-candidates tags too. http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Tue Jun 10 16:31:08 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 10 Jun 2008 12:31:08 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <200806101624.m5AGOaWP027275@localhost.localdomain> References: <200806101624.m5AGOaWP027275@localhost.localdomain> Message-ID: <1213115468.28032.31.camel@localhost.localdomain> On Tue, 2008-06-10 at 12:24 -0400, buildsys at fedoraproject.org wrote: > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > testing, F8, F8-updates, F8-updates-testing, F9, F9-updates, F9-updates- > testing, F7, F7-updates, F7-updates-testing, F8, F8-updates, F8-updates- > testing, F9, F9-updates, F9-updates-testing, rawhide This one is much closer to right. It's still not attaching package owner names, and I don't think it's actually checking rawhide correctly. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Jun 10 16:42:19 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 10 Jun 2008 11:42:19 -0500 Subject: RFE: autofsck In-Reply-To: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> Message-ID: <1218b5bc0806100942w4e045807p622c6bcad7cb32ca@mail.gmail.com> 2008/6/10 Ahmed Kamal : > Working with a local ISP in some rural area where there's a lot of power > cuts! The ISP guys were asking like, "Why is it that Linux boxes need manual > intervention to get back up after a power cut!" .. "Can't you script what > you're doing to get it back up" ?! > Does not having this as the default makes sense in some tangible number of > cases ?! Seems to me the obvious question is, if you are an ISP and you have a known problem with power dropouts, why are all these boxes not on UPSs and rigged to shut themselves down properly on power fail? ... Not that this is an excuse for journaling not doing its job. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeen at redhat.com Tue Jun 10 16:45:30 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 11:45:30 -0500 Subject: RFE: autofsck In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> Message-ID: <484EAFAA.9070902@redhat.com> Paul Wouters wrote: > You're wrong. I had a discussion with Ted himself who sees that the > current way is wrong. If Ted thinks it's wrong, perhaps he would accept a patch to make -y the default instead of having distros work around the upstream defaults via scripts? > What would help is to add /etc/sysconfig/autofsck with the line > > # AUTOFSCK_OPT="-y" > > so at least we don't have to keep reading rc.sysvinit to figure out which > version of fedora we need to change which script/variable to make this > happen. Yep, I agree that if scripts are looking for magic sysconfig files they should probably exist at least as placeholders... -Eric From notting at redhat.com Tue Jun 10 17:30:35 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Jun 2008 13:30:35 -0400 Subject: Notice: F7 EOL on 2008-06-13 Message-ID: <20080610173035.GD32125@nostromo.devel.redhat.com> This is a reminder that F7 goes EOL on 2008-06-13. If you have any critical updates lingering in testing, you may want to have them moved final before then. Then again, there hopefully aren't too many updates at this point... Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From alan at redhat.com Tue Jun 10 17:31:26 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 13:31:26 -0400 Subject: Merge review In-Reply-To: <1213112342.32207.842.camel@pmac.infradead.org> References: <49139.198.175.55.5.1213100281.squirrel@mail.jcomserv.net> <484E76BC.6090605@redhat.com> <61081.198.175.55.5.1213105962.squirrel@mail.jcomserv.net> <1213112342.32207.842.camel@pmac.infradead.org> Message-ID: <20080610173126.GA3666@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 04:39:02PM +0100, David Woodhouse wrote: > I have stated that I have no plans to relinquish ownership of any Fedora > packages, and I have asked for the recent changes in bugzilla to be > fixed. I'm sure Ric doesn't _really_ want to own all my Fedora packages, > although he's welcome to RHEL glibc-kernheaders :) It also reassigned all the bugs you reported as being reported by Ric so will mess the stats and stuff up. I've filed a report about that problem Alan From alan at redhat.com Tue Jun 10 17:32:36 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 13:32:36 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484EA9FF.9030604@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> <20080610145757.GA29525@devserv.devel.redhat.com> <484EA9FF.9030604@redhat.com> Message-ID: <20080610173236.GB3666@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 11:21:19AM -0500, Eric Sandeen wrote: > quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G > memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2. > > ext3 on /dev/sdc: > Throughput 679.495 MB/sec 4 procs > > ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc: > Throughput 665.599 MB/sec 4 procs Nice numbers, although I was testing pair of ATA disks ;) From sandeen at redhat.com Tue Jun 10 17:34:29 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 12:34:29 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610173236.GB3666@devserv.devel.redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> <20080610145757.GA29525@devserv.devel.redhat.com> <484EA9FF.9030604@redhat.com> <20080610173236.GB3666@devserv.devel.redhat.com> Message-ID: <484EBB25.3000600@redhat.com> Alan Cox wrote: > On Tue, Jun 10, 2008 at 11:21:19AM -0500, Eric Sandeen wrote: >> quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G >> memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2. >> >> ext3 on /dev/sdc: >> Throughput 679.495 MB/sec 4 procs >> >> ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc: >> Throughput 665.599 MB/sec 4 procs > > Nice numbers, although I was testing pair of ATA disks ;) > Should probably re-test that too. :) -Eric (wasn't *trying* to show off...) From alan at redhat.com Tue Jun 10 17:36:02 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 13:36:02 -0400 Subject: RFE: autofsck In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> Message-ID: <20080610173602.GC3666@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote: > Who, aside from Ted Tso, can do anything else but re-run with "yes"? You > are just postponing the problem, and thereby adding to the problem. Most users. > Though personally, I'd prefer an Anaconda option for it. > > "Unselect this option if you want to disable automatic repair > attempts of the filesystem, and have a chance to use a > raw filesystem editor to directly edit raw blocks on disk" That would suck. For most users you might as well ask them if they wanted frobnicate the meta-haddock. > Let's face it. There are 10 people in the world who could and maybe want, > to do this to an ext3 filesystem, and I'm pretty sure they maintain less > then 0.00001% of the Fedora servers ouf there. There are lots of cases you want that thing to stop. For example if there is important data on the box and you decide to get advice first. If you follow the most basic single rule of recovering a damaged file system you want it to stop so you can make a copy. Indeed you may well need a professional recovery expert or have a support contract and need to ask the helpdesk... -y in some cases is also things like: "Destroy any hope of recovering your PhD Thesis" Alan From mschwendt at gmail.com Tue Jun 10 17:54:46 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 10 Jun 2008 19:54:46 +0200 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <1213115468.28032.31.camel@localhost.localdomain> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <1213115468.28032.31.camel@localhost.localdomain> Message-ID: <20080610195446.b6ba4762.mschwendt@gmail.com> On Tue, 10 Jun 2008 12:31:08 -0400, Adam Jackson wrote: > On Tue, 2008-06-10 at 12:24 -0400, buildsys at fedoraproject.org wrote: > > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > > testing, F8, F8-updates, F8-updates-testing, F9, F9-updates, F9-updates- > > testing, F7, F7-updates, F7-updates-testing, F8, F8-updates, F8-updates- > > testing, F9, F9-updates, F9-updates-testing, rawhide > > This one is much closer to right. It's still not attaching package > owner names, and I don't think it's actually checking rawhide correctly. If I remember correctly, repo ids must contain a number, which is searched for. So, "rawhide" => "F10-development", for example. The package owner names can only be loaded if the script is updated to authenticate against FAS2 like it is done with the EPEL repoclosure report. Username and password can be passed to PackageOwners.py [1] (which was not necessary on buildsys.fedoraproject.org and FAS1). upgradecheck.py does not support any options to take username/password yet. [1] http://cvs.fedoraproject.org/viewcvs/extras-repoclosure/?root=fedora From ajax at redhat.com Tue Jun 10 18:06:58 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 10 Jun 2008 14:06:58 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080610195446.b6ba4762.mschwendt@gmail.com> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <1213115468.28032.31.camel@localhost.localdomain> <20080610195446.b6ba4762.mschwendt@gmail.com> Message-ID: <1213121218.28032.36.camel@localhost.localdomain> On Tue, 2008-06-10 at 19:54 +0200, Michael Schwendt wrote: > On Tue, 10 Jun 2008 12:31:08 -0400, Adam Jackson wrote: > > On Tue, 2008-06-10 at 12:24 -0400, buildsys at fedoraproject.org wrote: > > > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > > > testing, F8, F8-updates, F8-updates-testing, F9, F9-updates, F9-updates- > > > testing, F7, F7-updates, F7-updates-testing, F8, F8-updates, F8-updates- > > > testing, F9, F9-updates, F9-updates-testing, rawhide > > > > This one is much closer to right. It's still not attaching package > > owner names, and I don't think it's actually checking rawhide correctly. > > If I remember correctly, repo ids must contain a number, which is > searched for. So, "rawhide" => "F10-development", for example. Yeah, I fixed that locally. "rawhide" gets into the set of repos to look at, as per the blurb above, but it doesn't seem to show up in the output. Which I know is bogus, since I just fixed an EVR inversion in rawhide today. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at xelerance.com Tue Jun 10 18:24:55 2008 From: paul at xelerance.com (Paul Wouters) Date: Tue, 10 Jun 2008 14:24:55 -0400 (EDT) Subject: RFE: autofsck In-Reply-To: <20080610173602.GC3666@devserv.devel.redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> Message-ID: On Tue, 10 Jun 2008, Alan Cox wrote: > Date: Tue, 10 Jun 2008 13:36:02 -0400 > From: Alan Cox > To: Development discussions related to Fedora > Subject: Re: RFE: autofsck > > On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote: >> Who, aside from Ted Tso, can do anything else but re-run with "yes"? You >> are just postponing the problem, and thereby adding to the problem. > > Most users. Right. Most users can't even use a command line, let alone a raw disk editor. >> Though personally, I'd prefer an Anaconda option for it. >> >> "Unselect this option if you want to disable automatic repair >> attempts of the filesystem, and have a chance to use a >> raw filesystem editor to directly edit raw blocks on disk" > > That would suck. For most users you might as well ask them if they wanted > frobnicate the meta-haddock. Indeed. We agree there. Hence "unselect". Let's assume that users who don't know what frobinating a meta-haddock is, will stick to defaults :) > There are lots of cases you want that thing to stop. For example if there is > important data on the box and you decide to get advice first. If you follow > the most basic single rule of recovering a damaged file system you want it > to stop so you can make a copy. Indeed you may well need a professional recovery > expert or have a support contract and need to ask the helpdesk... How many people on this list have: a) paid for root filesystem data recovery b) answered "no" and hand edited the root fs? > -y in some cases is also things like: > "Destroy any hope of recovering your PhD Thesis" Don't story your PhD on your root fs. Also, if you want to protect against PhD thesis for normal users, you should make root's "rm" alias a global setting. Just to remind you, what people have a problem with is not running manual fsck's on certain filesystems. People have a problem with machines being stuck in single user mode waiting for manual intervention leading "fsck -y" anyway on the root filesystem. If my remote machine comes back, starts sshd, and then has /home not mounted because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y manually. Paul From sandeen at redhat.com Tue Jun 10 18:32:44 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 10 Jun 2008 13:32:44 -0500 Subject: RFE: autofsck In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> Message-ID: <484EC8CC.8000002@redhat.com> Paul Wouters wrote: > Just to remind you, what people have a problem with is not running manual > fsck's on certain filesystems. People have a problem with machines being stuck > in single user mode waiting for manual intervention leading "fsck -y" anyway > on the root filesystem. > > If my remote machine comes back, starts sshd, and then has /home not mounted > because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y > manually. As a bit of a tangent, if you see this fairly often, any idea why? Journaling should in general protect you from needing any sort of fsck after a power loss or oops; that's what they're for, right. I'd be curious to know what sorts of corruptions you wind up finding. How the corruption gets coped with once found is one point worth discussing, but where's it coming from in the first place? My guess is it's lack of barrier writes, but it's worth getting to the bottom of it, and hopefully this will make the choice of e2fsck parameters less relevant. :) -Eric From choeger at cs.tu-berlin.de Tue Jun 10 19:16:42 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 10 Jun 2008 21:16:42 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213035578.30252.10.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> Message-ID: <1213125402.3188.5.camel@choeger6> ?Hi, I just had another idea (correct me, when thats already possible - again): How about some kind of automagic spec file generation for the versioning part? Some kind of every commit/branch gets its own Version header generated, that would easily allow every possible assertion on how versioning information shall be handled. regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jkeating at j2solutions.net Tue Jun 10 19:23:36 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 10 Jun 2008 15:23:36 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213125402.3188.5.camel@choeger6> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> Message-ID: <1213125816.30252.61.camel@localhost.localdomain> On Tue, 2008-06-10 at 21:16 +0200, Christoph H?ger wrote: > I just had another idea (correct me, when thats already possible - > again): > How about some kind of automagic spec file generation for the versioning > part? Some kind of every commit/branch gets its own Version header > generated, that would easily allow every possible assertion on how > versioning information shall be handled. This somewhat possible now, I think the kernel package has done something like this in the past. It makes the spec file look like soup though, and not very friendly to those that want to base their work off your spec file outside our source control. Personally I'd rather stay away from source control magic making it's way into the specfiles. -- Jesse Keating RHCE (jkeating.livejournal.com) Fedora Project (fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From choeger at cs.tu-berlin.de Tue Jun 10 19:28:03 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 10 Jun 2008 21:28:03 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213125816.30252.61.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> Message-ID: <1213126083.3188.11.camel@choeger6> Am Dienstag, den 10.06.2008, 15:23 -0400 schrieb Jesse Keating: > On Tue, 2008-06-10 at 21:16 +0200, Christoph H?ger wrote: > > I just had another idea (correct me, when thats already possible - > > again): > > How about some kind of automagic spec file generation for the versioning > > part? Some kind of every commit/branch gets its own Version header > > generated, that would easily allow every possible assertion on how > > versioning information shall be handled. > > This somewhat possible now, I think the kernel package has done > something like this in the past. It makes the spec file look like soup > though, and not very friendly to those that want to base their work off > your spec file outside our source control. Personally I'd rather stay > away from source control magic making it's way into the specfiles. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Then the obvious solution would be to create a meta-spec file and let whoever wants to (which would include SCM) create a specific specfile from that. This could have even more advantages like some kind of inheritance (you could use generic "java packages" or "autoconf packages") or automagic selinux policy creation from meta informations. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From email.ahmedkamal at googlemail.com Tue Jun 10 19:33:12 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 10 Jun 2008 22:33:12 +0300 Subject: RFE: autofsck In-Reply-To: <484EC8CC.8000002@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> <484EC8CC.8000002@redhat.com> Message-ID: <3da3b5b40806101233n2a684efbpcba705b964a70702@mail.gmail.com> Since on similar topics we could argue forever, is it reasonable to have a poll system where devs/users would vote on such questions like should such a feature be the default or not ? On Tue, Jun 10, 2008 at 9:32 PM, Eric Sandeen wrote: > Paul Wouters wrote: > > > Just to remind you, what people have a problem with is not running manual > > fsck's on certain filesystems. People have a problem with machines being > stuck > > in single user mode waiting for manual intervention leading "fsck -y" > anyway > > on the root filesystem. > > > > If my remote machine comes back, starts sshd, and then has /home not > mounted > > because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run > fsck -y > > manually. > > As a bit of a tangent, if you see this fairly often, any idea why? > Journaling should in general protect you from needing any sort of fsck > after a power loss or oops; that's what they're for, right. I'd be > curious to know what sorts of corruptions you wind up finding. > > How the corruption gets coped with once found is one point worth > discussing, but where's it coming from in the first place? My guess is > it's lack of barrier writes, but it's worth getting to the bottom of it, > and hopefully this will make the choice of e2fsck parameters less > relevant. :) > > -Eric > > -- > 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 verbum.org Tue Jun 10 19:38:13 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 10 Jun 2008 15:38:13 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213125816.30252.61.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> Message-ID: 2008/6/10 Jesse Keating : > On Tue, 2008-06-10 at 21:16 +0200, Christoph H?ger wrote: > > I just had another idea (correct me, when thats already possible - > > again): > > How about some kind of automagic spec file generation for the versioning > > part? Some kind of every commit/branch gets its own Version header > > generated, that would easily allow every possible assertion on how > > versioning information shall be handled. > > This somewhat possible now, I think the kernel package has done > something like this in the past. It makes the spec file look like soup > though, and not very friendly to those that want to base their work off > your spec file outside our source control. Personally I'd rather stay > away from source control magic making it's way into the specfiles. > Which limits us to spec file hell forever? I think a two pronged solution is going to be better moving forward: 1) Encourage people to work within the Fedora context as much as possible, and thus gain the advantage as we improve our tools 2) For those that can't (e.g. you're a company with modifications to kernel/whatever you want to keep secret), we make it easy to bootstrap a koji instance and the rest of our tools inside your firewall -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Jun 10 19:38:50 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Jun 2008 15:38:50 -0400 Subject: RFE: autofsck In-Reply-To: <3da3b5b40806101233n2a684efbpcba705b964a70702@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> <484EC8CC.8000002@redhat.com> <3da3b5b40806101233n2a684efbpcba705b964a70702@mail.gmail.com> Message-ID: <20080610193850.GA8385@nostromo.devel.redhat.com> Ahmed Kamal (email.ahmedkamal at googlemail.com) said: > Since on similar topics we could argue forever, is it reasonable to have a > poll system where devs/users would vote on such questions like should such a > feature be the default or not ? I'm fairly sure voting for features is a rather bad idea. Bill From jkeating at redhat.com Tue Jun 10 19:44:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jun 2008 15:44:02 -0400 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> Message-ID: <1213127042.30252.70.camel@localhost.localdomain> On Tue, 2008-06-10 at 15:38 -0400, Colin Walters wrote: > Which limits us to spec file hell forever? I think a two pronged solution > is going to be better moving forward: Absolutely not. In fact it lets us move to something different even faster if we want to, as we don't have to worry about replicating all that %magic% somewhere else. Keeping things simple allows for easier change. > 1) Encourage people to work within the Fedora context as much as possible, > and thus gain the advantage as we improve our tools > 2) For those that can't (e.g. you're a company with modifications to > kernel/whatever you want to keep secret), we make it easy to bootstrap a > koji instance and the rest of our tools inside your firewall I don't think keeping things simple and keeping the %magic% away hurts this ideal. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From walters at verbum.org Tue Jun 10 19:52:05 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 10 Jun 2008 15:52:05 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213127042.30252.70.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> <1213127042.30252.70.camel@localhost.localdomain> Message-ID: 2008/6/10 Jesse Keating : > On Tue, 2008-06-10 at 15:38 -0400, Colin Walters wrote: > > Which limits us to spec file hell forever? I think a two pronged > solution > > is going to be better moving forward: > > Absolutely not. In fact it lets us move to something different even > faster if we want to, as we don't have to worry about replicating all > that %magic% somewhere else. Keeping things simple allows for easier > change. It sounds like what you're saying is that spec file/build, or to be more general - workflow - changes are out of scope for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maximilianbianco at gmail.com Tue Jun 10 20:07:30 2008 From: maximilianbianco at gmail.com (max bianco) Date: Tue, 10 Jun 2008 16:07:30 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <20080610134633.GZ10754@angus.ind.WPI.EDU> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> Message-ID: On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: > On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >> journaling filesystem you really shouldn't have any filesystem metadata >> integrity problems on power loss; that is, if you have barriers on >> (which ext3 doesn't by default) and if your storage can pass barriers >> (which lvm doesn't), or if you have drive write cache disabled (which >> hurts performance pretty badly). > > I wasn't aware that LVM destroyed the kind of guarantees about > filesystem metadata being written out to disk that jounaling > filesystems rely on? If so, should we perhaps rethink the decision to > use LVM by default on Fedora installs? > What was the reason for using LVM in the first place. My most recent install I was really tempted to not go with the defaults but because I really don't know much about filesystems, I figured the best thing in that case was stick to the defaults. Now I am reconsidering again...could someone explain the comparative advantages/disadvantages ? Before i do something stupid . -- If opinions were really like assholes we'd each have just one From cmadams at hiwaay.net Tue Jun 10 20:08:18 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 10 Jun 2008 15:08:18 -0500 Subject: Problem with fedoraproject.org DNS? Message-ID: <20080610200818.GI1252182@hiwaay.net> I'm not sure where to send this really, but it appears there is a problem with the DNS for fedoraproject.org. Depending on which .ORG server I ask, I either get pointed to: fedoraproject.org. 86400 IN NS ns1.theplanet.com. fedoraproject.org. 86400 IN NS ns2.theplanet.com. or: fedoraproject.org. 86400 IN NS ns1.fedoraproject.org. fedoraproject.org. 86400 IN NS dns1.j2solutions.net. The whois records seem to indicate the first is correct. However, the theplanet servers don't appear to have any records for fedoraproject.org. Also, since there doesn't appear to be a glue records for ns1.fedoraproject.org, that server is unreachable. The j2solutions server appears to actually have data. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From aph at redhat.com Tue Jun 10 20:38:05 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Jun 2008 21:38:05 +0100 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> Message-ID: <484EE62D.2090505@redhat.com> max bianco wrote: > On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: >> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >>> journaling filesystem you really shouldn't have any filesystem metadata >>> integrity problems on power loss; that is, if you have barriers on >>> (which ext3 doesn't by default) and if your storage can pass barriers >>> (which lvm doesn't), or if you have drive write cache disabled (which >>> hurts performance pretty badly). >> I wasn't aware that LVM destroyed the kind of guarantees about >> filesystem metadata being written out to disk that jounaling >> filesystems rely on? If so, should we perhaps rethink the decision to >> use LVM by default on Fedora installs? >> > > What was the reason for using LVM in the first place. My most recent > install I was really tempted to not go with the defaults but because I > really don't know much about filesystems, I figured the best thing in > that case was stick to the defaults. Now I am reconsidering > again...could someone explain the comparative advantages/disadvantages > ? Before i do something stupid . LVM has a lot of advantages with regard to flexibility: you can add a disk to a filesystem, for example. It has a lot of nice features. Andrew. From tcallawa at redhat.com Tue Jun 10 20:40:56 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Jun 2008 16:40:56 -0400 Subject: non responsive policy with invalid mail In-Reply-To: <484D05AD.3080808@nigelj.com> References: <20080606184122.GC2760@free.fr> <604aa7910806081438g243f1801x300fba3ecee214d3@mail.gmail.com> <484D05AD.3080808@nigelj.com> Message-ID: <1213130456.3461.16.camel@localhost.localdomain> On Mon, 2008-06-09 at 22:27 +1200, Nigel Jones wrote: > I believe phone numbers are exposed to the FAS admins, maybe FESCo & > Board might need to be considered for cvsextras and cla_done > respectively. I can already see that information as part of my role for Fedora Legal. I'd prefer to keep access to that to as few people as possible, but I'd be happy to do lookups as needed for FESCo/Board. ~spot From jkeating at redhat.com Tue Jun 10 20:44:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jun 2008 16:44:01 -0400 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> <1213127042.30252.70.camel@localhost.localdomain> Message-ID: <1213130641.4193.1.camel@localhost.localdomain> On Tue, 2008-06-10 at 15:52 -0400, Colin Walters wrote: > > > It sounds like what you're saying is that spec file/build, or to be more > general - workflow - changes are out of scope for this? Well that depends on how long we want to kick around with cvs. If we want to wait until we're using !specfiles, it's likely going to be quite a while. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Tue Jun 10 20:44:24 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 10 Jun 2008 16:44:24 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <1213115372.28032.29.camel@localhost.localdomain> References: <200806101439.m5AEduua026283@localhost.localdomain> <1213109630.28032.25.camel@localhost.localdomain> <20080610113439.0cb9ac5c@vader.jdub.homelinux.org> <1213115372.28032.29.camel@localhost.localdomain> Message-ID: <20080610164424.52099c92@vader.jdub.homelinux.org> On Tue, 10 Jun 2008 12:29:32 -0400 Adam Jackson wrote: > On Tue, 2008-06-10 at 11:34 -0400, Josh Boyer wrote: > > On Tue, 10 Jun 2008 10:53:50 -0400 > > Adam Jackson wrote: > > > > > On Tue, 2008-06-10 at 10:39 -0400, buildsys at fedoraproject.org wrote: > > > > Broken upgrade path report for repositories F7, F7-updates, F7-updates- > > > > testing, F8, F8-updates, F8-updates-testing > > > > > > Apologies for this. I'm trying to get this running again and didn't > > > notice that the script sends mail by default. Proper EVR report to > > > follow eventually. > > > > Which script are you using? The one in the rel-eng repo has code that > > connects to koji to see if there are builds queued that might fix the > > paths. This is mostly used during freeze times, but it could be > > extended to see if there are builds in the updates-candidates tags too. > > http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora Erg. I claim this to be my fail. I need to merge these two scripts. josh From paul at xelerance.com Tue Jun 10 20:48:11 2008 From: paul at xelerance.com (Paul Wouters) Date: Tue, 10 Jun 2008 16:48:11 -0400 (EDT) Subject: RFE: autofsck In-Reply-To: <484EC8CC.8000002@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> <484EC8CC.8000002@redhat.com> Message-ID: On Tue, 10 Jun 2008, Eric Sandeen wrote: >> because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y >> manually. > > As a bit of a tangent, if you see this fairly often, any idea why? Not "fairly often", but enough to get upset about the missing "-y" option > Journaling should in general protect you from needing any sort of fsck > after a power loss or oops; that's what they're for, right. I'd be > curious to know what sorts of corruptions you wind up finding. I honestly don't remember what kind of errors. It tends to happen on machines for uptimes of > 1 year, so it could be either known bugs in the kernel or some bad ram/write. A few years ago, I had all servers that rebooted fail to find an MBR, apparently some bug had caused writes to the start of the disk. I ended up running (then lilo) on various machines just to be sure. From what I remember, the inconsistency errors tend to be minor (a few lines of errors). The disks that grind most of the fs into lost+found tend to be experimental/development servers that reside in my office. Paul From maximilianbianco at gmail.com Tue Jun 10 20:49:16 2008 From: maximilianbianco at gmail.com (max bianco) Date: Tue, 10 Jun 2008 16:49:16 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484EE62D.2090505@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484EE62D.2090505@redhat.com> Message-ID: On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley wrote: > max bianco wrote: >> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: >>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >>>> journaling filesystem you really shouldn't have any filesystem metadata >>>> integrity problems on power loss; that is, if you have barriers on >>>> (which ext3 doesn't by default) and if your storage can pass barriers >>>> (which lvm doesn't), or if you have drive write cache disabled (which >>>> hurts performance pretty badly). >>> I wasn't aware that LVM destroyed the kind of guarantees about >>> filesystem metadata being written out to disk that jounaling >>> filesystems rely on? If so, should we perhaps rethink the decision to >>> use LVM by default on Fedora installs? >>> >> >> What was the reason for using LVM in the first place. My most recent >> install I was really tempted to not go with the defaults but because I >> really don't know much about filesystems, I figured the best thing in >> that case was stick to the defaults. Now I am reconsidering >> again...could someone explain the comparative advantages/disadvantages >> ? Before i do something stupid . > > LVM has a lot of advantages with regard to flexibility: you can add a > disk to a filesystem, for example. It has a lot of nice features. > > Andrew. > but there seems to be some question as to data integrity or ability to recover data in the event of disaster or am i reading too much into this? -- If opinions were really like assholes we'd each have just one From maximilianbianco at gmail.com Tue Jun 10 20:53:18 2008 From: maximilianbianco at gmail.com (max bianco) Date: Tue, 10 Jun 2008 16:53:18 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484EE62D.2090505@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484EE62D.2090505@redhat.com> Message-ID: On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley wrote: > max bianco wrote: >> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: >>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >>>> journaling filesystem you really shouldn't have any filesystem metadata >>>> integrity problems on power loss; that is, if you have barriers on >>>> (which ext3 doesn't by default) and if your storage can pass barriers >>>> (which lvm doesn't), or if you have drive write cache disabled (which >>>> hurts performance pretty badly). >>> I wasn't aware that LVM destroyed the kind of guarantees about >>> filesystem metadata being written out to disk that jounaling >>> filesystems rely on? If so, should we perhaps rethink the decision to >>> use LVM by default on Fedora installs? >>> >> >> What was the reason for using LVM in the first place. My most recent >> install I was really tempted to not go with the defaults but because I >> really don't know much about filesystems, I figured the best thing in >> that case was stick to the defaults. Now I am reconsidering >> again...could someone explain the comparative advantages/disadvantages >> ? Before i do something stupid . > > LVM has a lot of advantages with regard to flexibility: you can add a > disk to a filesystem, for example. It has a lot of nice features. > > Andrew. > but there seems to be some question as to data integrity or ability to recover data in the event of disaster or am i reading too much into this? Just a pointer to a good source of current info would be enough , if someone has a bookmark, i don't mind doing my own homework but sometimes I find too much opinion and not enough fact. Just a good starting place , if someone would be so kind. -- If opinions were really like assholes we'd each have just one From walters at verbum.org Tue Jun 10 20:58:05 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 10 Jun 2008 16:58:05 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213130641.4193.1.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> <1213127042.30252.70.camel@localhost.localdomain> <1213130641.4193.1.camel@localhost.localdomain> Message-ID: 2008/6/10 Jesse Keating : > > Well that depends on how long we want to kick around with cvs. If we > want to wait until we're using !specfiles, it's likely going to be quite > a while. > I don't think workflow changes implies !specfiles - just perhaps not specfiles exactly as they are today. For example, one simple change we could make when also switching to a new revision control system is to dump the duplicate changelog in the spec file. Mandriva for example I believe generates them from the SVN log when creating SRPMs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Tue Jun 10 21:25:57 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Jun 2008 17:25:57 -0400 Subject: RFE: autofsck In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <3da3b5b40806100730o19895369tceda8b38af1aaad6@mail.gmail.com> <484E9138.6010001@redhat.com> <20080610173602.GC3666@devserv.devel.redhat.com> Message-ID: <20080610212557.GA13723@devserv.devel.redhat.com> On Tue, Jun 10, 2008 at 02:24:55PM -0400, Paul Wouters wrote: > a) paid for root filesystem data recovery > b) answered "no" and hand edited the root fs? I've provided help to people rescuing their root fs and other fs on mailing lists. The local LUG has likewise > thesis for normal users, you should make root's "rm" alias a global setting. nautilus warns and has a track can > If my remote machine comes back, starts sshd, and then has /home not mounted > because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run > fsck -y > manually. And those who know enough to pick that option know enough to set it. The reverse is not true. From bruno at wolff.to Tue Jun 10 21:27:55 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 10 Jun 2008 16:27:55 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484EA57A.2010007@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <20080610144448.GB28121@devserv.devel.redhat.com> <484E946C.2080206@redhat.com> <20080610155656.GA27645@wolff.to> <484EA57A.2010007@redhat.com> Message-ID: <20080610212755.GA32218@wolff.to> On Tue, Jun 10, 2008 at 11:02:02 -0500, Eric Sandeen wrote: > > md for example passes barriers on raid1 but not 0 or 5 AFAIK... I have heard that, but not verified it myself. I am not sure why this is the case as I wouldn't expect doing raid 1 to be that much easier than other types of raid. > Got a url? This is a LWN article pointing to the start of a lmkl thread with the title: "Proposal for "proper" durable fsync() and fdatasync()" http://lwn.net/Articles/270891/ From yanmin_zhang at linux.intel.com Wed Jun 11 00:58:03 2008 From: yanmin_zhang at linux.intel.com (Zhang, Yanmin) Date: Wed, 11 Jun 2008 08:58:03 +0800 Subject: Kernel directory change Message-ID: <1213145883.3054.8.camel@ymzhang> Yi, I installed FC9 Beta ia64 on my Montvale machine and found the kernel directory is changed. The old directory is /boot/efi/efi/redhat, but the new one is /boot/efi/EFI/redhat. Is there any special reason to do so? A couple of test suites assumes ?/boot/efi/efi/redhat. -yanmin From sergio.pasra at gmail.com Wed Jun 11 01:45:29 2008 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Tue, 10 Jun 2008 21:45:29 -0400 Subject: Bind mounts with fedora 9 In-Reply-To: <4846B953.4050800@city-fan.org> References: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> <20080604154316.GB24661@imperial.ac.uk> <4846B953.4050800@city-fan.org> Message-ID: <89b36810806101845j1741abbdu97657fd3b4914187@mail.gmail.com> Hello 2008/6/4 Paul Howarth : > Or: > # umount /var/lib/mysql > # chcon -t mnt_t /var/lib/mysql > # service netfs start > This can't be, because /var/lib/mysql has to be mysqld_db_t in order to work From mmcgrath at redhat.com Wed Jun 11 03:14:44 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 10 Jun 2008 22:14:44 -0500 (CDT) Subject: Problem with fedoraproject.org DNS? In-Reply-To: <20080610200818.GI1252182@hiwaay.net> References: <20080610200818.GI1252182@hiwaay.net> Message-ID: On Tue, 10 Jun 2008, Chris Adams wrote: > I'm not sure where to send this really, but it appears there is a > problem with the DNS for fedoraproject.org. Depending on which .ORG > server I ask, I either get pointed to: > > fedoraproject.org. 86400 IN NS ns1.theplanet.com. > fedoraproject.org. 86400 IN NS ns2.theplanet.com. > > or: > > fedoraproject.org. 86400 IN NS ns1.fedoraproject.org. > fedoraproject.org. 86400 IN NS dns1.j2solutions.net. > > The whois records seem to indicate the first is correct. However, the > theplanet servers don't appear to have any records for > fedoraproject.org. > > Also, since there doesn't appear to be a glue records for > ns1.fedoraproject.org, that server is unreachable. The j2solutions > server appears to actually have data. > We put a request in to iron mountain for projectofedora.org earlier this week. For some reason, they made the changes to fedoraproject.org. If you 'dig ns1.fedoraproject.org' and get sections with "theplanet.com" in it, this affects you. Because we do not control your dns servers, (or the planets) there is little we can do about fixing it quickly. The problem has been fixed but the cache in your DNS may not be corrected. re-run the command "dig ns1.fedoraproject.org" If you see a section like: ;; AUTHORITY SECTION: fedoraproject.org. 60799 IN NS ns2.theplanet.com. fedoraproject.org. 60799 IN NS ns1.theplanet.com. Look at the number in the second field. thats how many seconds remain until your services refresh and you start hitting the correct dns settings again. In the meantime you can access fedora services via /etc/hosts and looking up ip addresses via http://www.dnswatch.info/ Sorry for the confusion / trouble. I honestly have no idea how we could have prevented this since "projectofedora.org" isn't even a typo away from "fedoraproject.org" :) I'll talk to our primary Iron Mountain contact and see if they have any ideas. -Mike From paul at city-fan.org Wed Jun 11 06:37:33 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 11 Jun 2008 07:37:33 +0100 Subject: Bind mounts with fedora 9 In-Reply-To: <89b36810806101845j1741abbdu97657fd3b4914187@mail.gmail.com> References: <89b36810806040751x414c8127hdbcdd288bddbef39@mail.gmail.com> <20080604154316.GB24661@imperial.ac.uk> <4846B953.4050800@city-fan.org> <89b36810806101845j1741abbdu97657fd3b4914187@mail.gmail.com> Message-ID: <20080611073733.79d5d03e@metropolis.intra.city-fan.org> On Tue, 10 Jun 2008 21:45:29 -0400 "Sergio Pascual" wrote: > Hello > > 2008/6/4 Paul Howarth : > > Or: > > # umount /var/lib/mysql > > # chcon -t mnt_t /var/lib/mysql > > # service netfs start > > > > This can't be, because /var/lib/mysql has to be mysqld_db_t in order > to work Yes it can. The mount point should be mnt_t so that it can have something mounted on it, and then the filesystem that is mounted there has a context type of mysqld_db_t at its top level so everything works as normal. That is why I suggested unmounting the filesystem before fixing the label, and then re-mounting it (as "service netfs start" would do, emulating the boot process). Paul. From aph at redhat.com Wed Jun 11 08:21:03 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Jun 2008 09:21:03 +0100 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484EE62D.2090505@redhat.com> Message-ID: <484F8AEF.9020207@redhat.com> max bianco wrote: > On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley wrote: >> max bianco wrote: >>> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: >>>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >>>>> journaling filesystem you really shouldn't have any filesystem metadata >>>>> integrity problems on power loss; that is, if you have barriers on >>>>> (which ext3 doesn't by default) and if your storage can pass barriers >>>>> (which lvm doesn't), or if you have drive write cache disabled (which >>>>> hurts performance pretty badly). >>>> I wasn't aware that LVM destroyed the kind of guarantees about >>>> filesystem metadata being written out to disk that jounaling >>>> filesystems rely on? If so, should we perhaps rethink the decision to >>>> use LVM by default on Fedora installs? >>>> >>> What was the reason for using LVM in the first place. My most recent >>> install I was really tempted to not go with the defaults but because I >>> really don't know much about filesystems, I figured the best thing in >>> that case was stick to the defaults. Now I am reconsidering >>> again...could someone explain the comparative advantages/disadvantages >>> ? Before i do something stupid . >> LVM has a lot of advantages with regard to flexibility: you can add a >> disk to a filesystem, for example. It has a lot of nice features. > but there seems to be some question as to data integrity or ability to > recover data in the event of disaster or am i reading too much into > this? Yes, you are. The question here is about barriers, which are off by default in ext3 anyway. If you're worried about disaster recovery, you need to be looking at backup and replication. Andrew. From mcepl at redhat.com Wed Jun 11 08:22:11 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 11 Jun 2008 10:22:11 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> Message-ID: On 2008-06-09, 16:56 GMT, Toshio Kuratomi wrote: > 1) Fedora 10 ships with the latest python-2.5.x. > 2) The Fedora 11 development tree switches to python-2.6.x soon after=20 > F10 is released. Well, aren't we early enough in the F10 Rawhide to do it now instead of waiting six months? Mat?j From a.badger at gmail.com Wed Jun 11 10:55:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 11 Jun 2008 06:55:34 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> Message-ID: <484FAF26.3090002@gmail.com> Matej Cepl wrote: > On 2008-06-09, 16:56 GMT, Toshio Kuratomi wrote: >> 1) Fedora 10 ships with the latest python-2.5.x. >> 2) The Fedora 11 development tree switches to python-2.6.x soon after=20 >> F10 is released. > > Well, aren't we early enough in the F10 Rawhide to do it now > instead of waiting six months? > It's Geppetto's call but one drawback of switching now is it could mean shipping a non-release python-2.6 in F10 if the python release date slips. Here's python.org's schedule: Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned Sep 03 2008: Python 2.6 and 3.0 final Here's our tentative schedule: Aug 19 2008: Feature Freeze Sep 30 2008: Final devel freeze Oct 10 2008: Preview release Oct 28 2008: Final release Another drawback is that since we have so many programs that we code which are dependent on python, this would mean we'd have less time to test that yum or anaconda, for instance, worked with all the new python code before the release. ie: More moving parts later in the cycle. The pro sides would be: 1) We could include code that is written to run on 3.x/2.6's 3.x compat layer. (I haven't run across any code that only targets 3.x yet.) 2) We and our users can get started on ports of code and experimenting with 3.x/2.6 features sooner. (Not sure how helpful this is for us as we're not likely to want to port until, at least, the py-2.6 release candidate (otherwise something could still change on us.) For users, it does mean that they'll be able to use F10 as a base for porting their apps.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From valent.turkovic at gmail.com Wed Jun 11 11:19:38 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 11 Jun 2008 13:19:38 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212616469.6159.0.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> Message-ID: <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: >> [...] >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? >> > >> > Definitely in the next F9 update. >> >> Will this update contain my patch which allows people to uninstall >> NetworkManager without losing pidgin and evolution (bug #351101)? >> >> You never gave a good reason why this bug has been left unfixed >> for over half a year, especially when the solution is trivial. > > Can you try out > > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 > > when it gets done? > > Thanks, > Dan > >> Regards, >> R. >> >> -- >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu >> "Faith manages." >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I tested NetworkManager via: yum --enablerepo=updates-testing update NetworkManager as you suggested in bugreport but I still see the same bug present. Cheers, 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 keith at karsites.net Wed Jun 11 11:55:05 2008 From: keith at karsites.net (Keith Roberts) Date: Wed, 11 Jun 2008 12:55:05 +0100 (BST) Subject: Problem with F9 installation disks Message-ID: I have submitted a bug report for the F9 installation programs. https://bugzilla.redhat.com/show_bug.cgi?id=450678 Where can I get the latest iso image to create a bootable installation CD from please? I need to check if the bug is still in rawhide. Kind Regards, Keith Roberts ----------------------------------------------------------------- Websites: http://www.php-debuggers.net http://www.karsites.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] ----------------------------------------------------------------- From nicolas.mailhot at laposte.net Wed Jun 11 12:22:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jun 2008 14:22:52 +0200 (CEST) Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <1213113966.3866.28.camel@calliope.phig.org> References: <389552.959071213099076255.JavaMail.www@wwinf8402> <1213113966.3866.28.camel@calliope.phig.org> Message-ID: <3483.192.54.193.53.1213186972.squirrel@rousalka.dyndns.org> Le Mar 10 juin 2008 18:06, Karsten 'quaid' Wade a ?crit : > Before the move and since, we've been discussing this issue amongst > the > wiki gardening crew. We'd like to see new pages adhere to a new > structure, and to have groups begin moving existing pages to a new > structure. > > We're working on the details of the structure at [[Help:Wiki > Structure]]: One problem is the conversion left the wiki in a sorry state, so wiki authors need to fix their pages now. I at least can not wait for the [[Help:Wiki Structure]]: page to be finished, the fonts SIG wiki was not operationnal anymore, and I've not finished repairing it. So, since I'm doing changes now anyway, could you please review the current fonts SIG state, and suggest eventual modifications before I'm done? Because I firmly intend to spend time away from wiki gardening once I've returned my wiki perimeter to a correct state. -- Nicolas Mailhot From rawhide at fedoraproject.org Wed Jun 11 09:29:59 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 11 Jun 2008 09:29:59 +0000 (UTC) Subject: rawhide report: 20080611 changes Message-ID: <20080611093000.10C2A209D06@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080610/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080611/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package perl-HTML-Template-Pro Perl/XS module to use HTML Templates from CGI scripts New package perl-Object-MultiType Perl Objects as Hash, Array, Scalar, Code and Glob at the same time New package perl-XML-Atom-SimpleFeed No-fuss generation of Atom syndication feeds New package telepathy-sofiasip SIP connection manager for Telepathy New package trac-spamfilter-plugin Spam-Filter plugin for Trac Removed package xmoto-edit Updated Packages: LabPlot-1.6.0.1-1.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Kevin Kofler - 1.5.1.6-7 - fix build against latest liborigin on F10 (backported from 1.6.0) * Tue Jun 10 18:00:00 2008 Chitlesh Goorah - 1.6.0.1-1 - New upstream release 1.6.0.1 - Now compatible with liborigin 20080225 - Bugfix: #449653: FTBFS LabPlot-1.5.1.6-6.fc9 - Bugfix: #434019: LabPlot failed massrebuild attempt for GCC 4.3 - Added qhull-devel as BR automoc-1.0-0.5.20080527svn811390.fc10 -------------------------------------- * Tue Jun 10 18:00:00 2008 Lorenzo Villani - 1.0-0.5.20080527svn811390 - Leave automoc4.files.in in _libdir - Same applies to Automoc4Config.cmake bibus-1.4.3-1.fc10 ------------------ * Tue Jun 10 18:00:00 2008 Alex Lancaster - 1.4.3-1 - Update to latest upstream (1.4.3) - Make package arch-specific to allow package to find appropriate location for x86_64 (#438527) - Fix PNG corruption introduced by fixing line-feeds, patch thanks to Nicolas Thierry-Mieg (#448483) - Add missing images to doc cairo-dock-1.6.0-0.1.svn1089_trunk.fc10 --------------------------------------- * Wed Jun 11 18:00:00 2008 Mamoru Tasaka - svn 1089 compiz-0.7.6-4.fc10 ------------------- * Tue Jun 10 18:00:00 2008 Adel Gadllah - 0.7.6-4 - Disable kde3 to fix local builds (RH #449123) ettercap-0.7.3-23.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Jon Ciesla - 0.7.3-23 - Patch to fix ui in daemon mode BZ 450029. evolution-brutus-1.2.17-1.fc10 ------------------------------ * Tue Jun 10 18:00:00 2008 Alex Lancaster - 1.2.17-1 - Update to 1.2.17 which works against evolution-data-server 2.24 - Fix FTBFS (#449548) - Rebuild for new ImageMagick to fix broken deps. fontmatrix-0.4.2-2.fc10 ----------------------- * Tue Jun 10 18:00:00 2008 Parag - 0.4.2-2 - Resolves: rh#449406:FTBFS fontmatrix-0.4.2-1.fc9 freetds-0.82-1.fc10 ------------------- * Mon Jun 9 18:00:00 2008 Dmitry Butskoy - 0.82-1 - Upgrade to 0.82 freetype-2.3.6-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Behdad Esfahbod 2.3.6-1 - Update to 2.3.6 * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 2.3.5-5 - fix license tag - add sparc64 to list of 64bit arches gnome-panel-2.23.3-2.fc10 ------------------------- * Tue Jun 10 18:00:00 2008 Matthias Clasen - 2.23.3-2 - Avoid unnecessary wakeups in the clock for monitoring Gentoo config file locations gphoto2-2.4.1-1.fc10 -------------------- * Mon Jun 2 18:00:00 2008 Jindrich Novy 2.4.1-1 - update to 2.4.1 (#443515, #436138) - remove libgphoto2, it's now packaged separately grip-3.2.0-19.fc10 ------------------ * Tue Jun 10 18:00:00 2008 Adrian Reber - 1:3.2.0-19 - removed now unnecessary cell-renderer patch - fixed "default config creates ogg files with .mp3 extension" (#427017) gtkpod-0.99.12-3.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Todd Zullinger - 0.99.12-3 - use xdg-open as default player (#449199) (patch from Debarshi Ray) - update %description to include more complete model list hunspell-pt-0.20080610-1.fc10 ----------------------------- * Tue Jun 10 18:00:00 2008 Caolan McNamara - 0.20080610-1 - latest version iptables-1.4.1-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Thomas Woerner 1.4.1-1 - new version 1.4.1 with new build environment - additional ipv6 network mask patch from Jan Engelhardt - spec file cleanup - removed old patches * Fri Jun 6 18:00:00 2008 Tom "spot" Callaway 1.4.0-5 - use normal kernel headers, not linux/compiler.h - change BuildRequires: kernel-devel to kernel-headers - We need to do this to be able to build for both sparcv9 and sparc64 (there is no kernel-devel.sparcv9) kernel-2.6.26-0.57.rc5.git3.fc10 -------------------------------- libdvdnav-4.1.3-0.1.fc10 ------------------------ * Fri Jun 6 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.1 - update to current SVN (pre-4.1.3) - macroize - re-enable parallel make * Sun Apr 13 18:00:00 2008 Dominik Mierzejewski 4.1.2-1 - update to 4.1.2 - drop obsolete patches (merged upstream) libnotify-0.4.4-11.fc10 ----------------------- * Tue Jun 10 18:00:00 2008 Colin Walters - 0.4.4-11 - Add patch neccessary for reliable notification positioning liborigin-20080225-1.fc10 ------------------------- * Tue Jun 10 18:00:00 2008 Chitlesh Goorah - 20080225-1 - New upstream release 20080225 libtirpc-0.1.8-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Steve Dickson 0.1.8-1 - Update to latest upstream version 0.1.8 logwatch-7.3.6-23.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Ivana Varekova 7.3.6-23 - Resolves: #450494 MailTo configuration parameter is ignored loudmouth-1.4.0-1.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Brian Pepple - 1.4.0-1 - Update to 1.4.0. man-pages-2.80-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Ivana Varekova - 2.80-1 - update to 2.80 - Resolves: #450187 deprecate malloc_hook(3) man page net-snmp-5.4.1-19.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Jan Safranek 5.4.1-19 - fix various flaws (CVE-2008-2292 CVE-2008-0960) ocaml-libvirt-0.4.2.4-1.fc10 ---------------------------- * Tue Jun 10 18:00:00 2008 Richard W.M. Jones - 0.4.2.4-1 - New upstream version. openbox-3.4.7.2-3.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Miroslav Lichvar - 3.4.7.2-3 - Clean up properties after gdm in session scripts (#444135) - Add license to xdg-menu script openoffice.org-3.0.0-0.0.18.1.fc10 ---------------------------------- * Mon Jun 9 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.18-1 - next version - drop integrated openoffice.org-2.4.0.ooo85854.sw.graphicsaveas.patch - drop integrated openoffice.org-3.0.0.ooo88815.oox.parallel.patch * Fri Jun 6 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.17-2 - Resolves: rhbz#450212 openoffice.org-3.0.0.ooo82545.np_sdk.x86_64.patch perl-5.10.0-26.fc10 ------------------- * Tue Jun 10 18:00:00 2008 Stepan Kasal 4:5.10.0-26 - make config parameter list consistent for 32bit and 64bit platforms, add config option -Dinc_version_list=none (#448735) - use perl_archname consistently - cleanup of usage of *_lib macros in %install perl-Class-Inspector-1.23-1.fc10 -------------------------------- * Tue Jun 10 18:00:00 2008 Ralf Cors??pius - 1.23-1 - Upstream update. perl-File-Find-Rule-Perl-1.04-1.fc10 ------------------------------------ * Tue Jun 10 18:00:00 2008 Ralf Cors??pius - 1.04-1 - Upstream update. perl-File-Remove-1.41-1.fc10 ---------------------------- * Tue Jun 10 18:00:00 2008 Ralf Corsepius - 1.41-1 - Upstream update. perl-Font-AFM-1.20-1.fc10 ------------------------- * Tue Jun 10 18:00:00 2008 Ralf Cors??pius - 1.20-1 - Upstream update. perl-Params-Validate-0.91-1.fc10 -------------------------------- * Tue Jun 10 18:00:00 2008 Ralf Cors??pius - 0.91-1 - Upstream update. - Conditionally activate IS_MAINTAINER tests. php-pear-Net-SMTP-1.3.1-1.fc10 ------------------------------ * Tue Jun 10 18:00:00 2008 Remi Collet 1.3.1-1 - update to 1.3.1 - add Comment on howto to run test suite pykickstart-1.38-1.fc10 ----------------------- * Tue Jun 10 18:00:00 2008 Chris Lumens - 1.38-1 - Fix loading the Handler object by looking for a more specific name (#450740). (clumens) qt-4.4.0-7.fc10 --------------- * Tue Jun 10 18:00:00 2008 Than Ngo 4.4.0-7 - fix #450310, multilib issue selinux-policy-3.4.1-5.fc10 --------------------------- sylpheed-2.5.0-0.10.rc2.fc10 ---------------------------- * Tue Jun 10 18:00:00 2008 Michael Schwendt - 2.5.0-0.10.rc2 - work around build problem with gtk2 >= 2.13.1 which drastically changed the number of header-includes for the deprecated header files * Sun Jun 8 18:00:00 2008 Michael Schwendt - 2.5.0-0.8.rc2 - avoid duplicate desktop menu entry - conditional BR oniguruma-devel and --enable-oniguruma * Fri Jun 6 18:00:00 2008 Michael Schwendt - 2.5.0-0.7.rc2 - Update to 2.5.0rc2. * Thu Jun 5 18:00:00 2008 Michael Schwendt - 2.5.0-0.6.rc - Add CTE procmime.c patch from svn. - Fix codeconv.c to support "utf8" locales and not just "UTF-8" (fixes #450063). system-config-kickstart-2.7.17-1.fc10 ------------------------------------- * Tue Jun 10 18:00:00 2008 Chris Lumens 2.7.17-1 - Support --display= (#450431). - No longer use rhpl for translations. - Sort keyboard list by descriptive name, not by console map. - Remove most of the xconfig and monitor command support. - Use s-c-date's timezone list since that's what anaconda does (#445195). system-config-printer-1.0.2-1.fc10 ---------------------------------- * Tue Jun 10 18:00:00 2008 Tim Waugh 1.0.2-1 - 1.0.2. wine-1.0-0.4.rc4.fc10 --------------------- * Fri Jun 6 18:00:00 2008 Andreas Bierfert - 1.0-0.4.rc4 - version upgrade wxMaxima-0.7.5-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Rex Dieter 0.7.5-1 - wxMaxima-0.7.5 - exclude ppc (#448734) xfce4-verve-plugin-0.3.5-5.fc10 ------------------------------- * Wed Jun 11 18:00:00 2008 Christoph Wickert - 0.3.5-5 - BuildRequire dbus-glib-devel for all releases (#449438) xorg-x11-proto-devel-7.3-13.fc10 -------------------------------- * Tue Jun 10 18:00:00 2008 Adam Jackson 7.3-13 - xproto 7.0.13 - xextproto 7.0.3 ypbind-1.20.4-6.fc10 -------------------- * Tue Jun 10 18:00:00 2008 Vitezslav Crhonek - 3:1.20.4-6 - Don't disable allow_ypbind SELinux boolean on service shutdown Resolves: #448240 Summary: Added Packages: 5 Removed Packages: 1 Modified Packages: 46 Broken deps for i386 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.i386 requires libtds.so.5 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.x86_64 requires libtds.so.5()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.ppc requires libtds.so.5 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.ppc64 requires libtds.so.5()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From jwilson at redhat.com Wed Jun 11 13:12:34 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jun 2008 09:12:34 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213125816.30252.61.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213125402.3188.5.camel@choeger6> <1213125816.30252.61.camel@localhost.localdomain> Message-ID: <200806110912.34768.jwilson@redhat.com> On Tuesday 10 June 2008 03:23:36 pm Jesse Keating wrote: > On Tue, 2008-06-10 at 21:16 +0200, Christoph H?ger wrote: > > I just had another idea (correct me, when thats already possible - > > again): > > How about some kind of automagic spec file generation for the versioning > > part? Some kind of every commit/branch gets its own Version header > > generated, that would easily allow every possible assertion on how > > versioning information shall be handled. > > This somewhat possible now, I think the kernel package has done > something like this in the past. Still does. > It makes the spec file look like soup though Agreed. > and not very friendly to those that want to base their work off > your spec file outside our source control. Despite the soup, we've tried to actually make it easy for people to do their own custom build, and they generally don't need to touch anything but one %define. Here's a chunk of what we've got: # Polite request for people who spin their own kernel rpms: # please modify the "buildid" define in a way that identifies # that the kernel isn't the stock distribution kernel, for example, # by setting the define to ".local" or ".bz123456" # #% define buildid .local # fedora_build defines which build revision of this kernel version we're # building. Rather than incrementing forever, as with the prior versioning # setup, we set fedora_cvs_origin to the current cvs revision s/1.// of the # kernel spec when the kernel is rebased, so fedora_build automatically # works out to the offset from the rebase, so it doesn't get too ginormous. # %define fedora_cvs_origin 623 %define fedora_build %(R="$Revision: 1.682 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) ...and so on. The above two lines are certainly fugly, but in the end, do nothing more than some simple math to create an auto-incrementing number -- 682 - 623 = 59, which leads to NVR kernel-2.6.26-0.59.rc5.git4.fc10. > Personally I'd rather stay > away from source control magic making it's way into the specfiles. Indeed, if SCM != CVS, that's gonna need an overhaul... -- Jarod Wilson jwilson at redhat.com From yi.zhan at intel.com Wed Jun 11 14:08:17 2008 From: yi.zhan at intel.com (Zhan, Yi) Date: Wed, 11 Jun 2008 22:08:17 +0800 Subject: [Fedora-ia64-list] Kernel directory change In-Reply-To: <1213189422.3673.2.camel@centrino> References: <1213145883.3054.8.camel@ymzhang> <1213189422.3673.2.camel@centrino> Message-ID: > -----Original Message----- > From: Doug Chapman [mailto:dchapman at redhat.com] > Sent: Wednesday, June 11, 2008 9:04 PM > To: ia64 Fedora Core Development > Cc: Zhan at redhat.com; Zhan, Yi; Development discussions related to Fedora > Subject: Re: [Fedora-ia64-list] Kernel directory change > > On Wed, 2008-06-11 at 08:58 +0800, Zhang, Yanmin wrote: > > Yi, > > > > I installed FC9 Beta ia64 on my Montvale machine and found the kernel > > directory is changed. The old directory is /boot/efi/efi/redhat, but the > > new one is /boot/efi/EFI/redhat. Is there any special reason to do so? > > > > A couple of test suites assumes ?/boot/efi/efi/redhat. > > > > -yanmin > > > > This changed a while back. What it appears happened was that the vfat > filesystem for some reason now understands upper/lower case. In > actuality it was always /boot/efi/EFI but the linux implementation of > vfat shifted the directory name to lower case. > Yes the file system changing might be the point. There is a "%define image_install_path boot/efi/EFI/redhat" for ia64 in kernel.spec since fc4. So the kernel dir was always /boot/efi/EFI/redhat. Yi From maximilianbianco at gmail.com Wed Jun 11 14:21:49 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 11 Jun 2008 10:21:49 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484F8AEF.9020207@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484EE62D.2090505@redhat.com> <484F8AEF.9020207@redhat.com> Message-ID: <484FDF7D.7030803@gmail.com> Andrew Haley wrote: > max bianco wrote: >> On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley wrote: >>> max bianco wrote: >>>> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson wrote: >>>>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote: >>>>>> journaling filesystem you really shouldn't have any filesystem metadata >>>>>> integrity problems on power loss; that is, if you have barriers on >>>>>> (which ext3 doesn't by default) and if your storage can pass barriers >>>>>> (which lvm doesn't), or if you have drive write cache disabled (which >>>>>> hurts performance pretty badly). >>>>> I wasn't aware that LVM destroyed the kind of guarantees about >>>>> filesystem metadata being written out to disk that jounaling >>>>> filesystems rely on? If so, should we perhaps rethink the decision to >>>>> use LVM by default on Fedora installs? >>>>> >>>> What was the reason for using LVM in the first place. My most recent >>>> install I was really tempted to not go with the defaults but because I >>>> really don't know much about filesystems, I figured the best thing in >>>> that case was stick to the defaults. Now I am reconsidering >>>> again...could someone explain the comparative advantages/disadvantages >>>> ? Before i do something stupid . >>> LVM has a lot of advantages with regard to flexibility: you can add a >>> disk to a filesystem, for example. It has a lot of nice features. > >> but there seems to be some question as to data integrity or ability to >> recover data in the event of disaster or am i reading too much into >> this? > > Yes, you are. The question here is about barriers, which are off by > default in ext3 anyway. If you're worried about disaster recovery, you > need to be looking at backup and replication. > > Andrew. > I am the victim of the poorly worded question, due entirely to my own ignorance on the subject but I did a little poking around so I'll have another go at it. Is disaster recovery more difficult with an LVM than the older standard partioning scheme? -- Revenge is for the ignorant From buc at odusz.so-cdu.ru Wed Jun 11 14:28:27 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 11 Jun 2008 18:28:27 +0400 Subject: /bin/mail replacement (next generation of mailx) Message-ID: <484FE10B.1050404@odu.neva.ru> I would like to propose upgrade the "mailx" package (cmdline /bin/mail interface) to the newer source from the Heirloom project: http://heirloom.sourceforge.net/mailx.html . The new source is derived from the old one and is fully compatible with it. Such a replacement (from old bsd mailx-8.1.x to the Heirloom's mailx-12.x) is already done in OpenSuse and Slackware. Initially, the project was named as "nail". Since the version of 12.x it was renamed to the ordinary name of "mailx", (because the original mailx-8.x no more developed). Under the name of "nail" it is already in Fedora. I continue to maintain it as "nail", while the original mailx-8.x is used. Mailx-12.x adds a lot of useful functionality to the "cmdline mail command", which seems to be expected long years ago. Without it, some tasks can be performed only by TUI or even GUI applications, which makes impossible to automate things by scripts. My initial motivation to add nail/mailx to Fedora was inspired by the time of switching to Dovecot IMAP server and recommendation to switch from mailbox to Maildir format. The current /bin/mail do not work with Maildir, hence it cannot be used for reading mail from cmdline at all (until you still use mailbox format). Besides the Maildir support (which looks like a strong requirement for the upgrading), there are such features as MIME support, encodings, attachments, POP3/IMAP, direct SMTP, SSL etc., see http://heirloom.sourceforge.net/mailx.html Note, that SSL support can be provided either by OpenSSL or by NSS. The use of NSS matches the recent requirements of Fedora's "Security Consolidation". Any comments? Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From skvidal at fedoraproject.org Wed Jun 11 14:34:47 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 11 Jun 2008 10:34:47 -0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FE10B.1050404@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> Message-ID: <1213194887.16019.8.camel@cutter> On Wed, 2008-06-11 at 18:28 +0400, Dmitry Butskoy wrote: > I would like to propose upgrade the "mailx" package (cmdline /bin/mail > interface) to the newer source from the Heirloom project: > http://heirloom.sourceforge.net/mailx.html . The new source is derived > from the old one and is fully compatible with it. > > Such a replacement (from old bsd mailx-8.1.x to the Heirloom's > mailx-12.x) is already done in OpenSuse and Slackware. > > Initially, the project was named as "nail". Since the version of 12.x it > was renamed to the ordinary name of "mailx", (because the original > mailx-8.x no more developed). Under the name of "nail" it is already in > Fedora. I continue to maintain it as "nail", while the original > mailx-8.x is used. > > Mailx-12.x adds a lot of useful functionality to the "cmdline mail > command", which seems to be expected long years ago. Without it, some > tasks can be performed only by TUI or even GUI applications, which makes > impossible to automate things by scripts. > > My initial motivation to add nail/mailx to Fedora was inspired by the > time of switching to Dovecot IMAP server and recommendation to switch > from mailbox to Maildir format. The current /bin/mail do not work with > Maildir, hence it cannot be used for reading mail from cmdline at all > (until you still use mailbox format). Besides the Maildir support (which > looks like a strong requirement for the upgrading), there are such > features as MIME support, encodings, attachments, POP3/IMAP, direct > SMTP, SSL etc., see http://heirloom.sourceforge.net/mailx.html > > Note, that SSL support can be provided either by OpenSSL or by NSS. The > use of NSS matches the recent requirements of Fedora's "Security > Consolidation". > Does the cli format break compat with mailx as we know it now? Ie: will we need to fix an arse-load of cron jobs and what not to behave? -sv From nigel.metheringham at dev.intechnology.co.uk Wed Jun 11 14:38:51 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 11 Jun 2008 15:38:51 +0100 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FE10B.1050404@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> Message-ID: On 11 Jun 2008, at 15:28, Dmitry Butskoy wrote: > Mailx-12.x adds a lot of useful functionality to the "cmdline mail > command", which seems to be expected long years ago. Without it, > some tasks can be performed only by TUI or even GUI applications, > which makes impossible to automate things by scripts. This looks good, but on a minimal system how many other packages would be pulled in as dependancies over the existing mailx? Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From kevin.kofler at chello.at Wed Jun 11 14:42:04 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 14:42:04 +0000 (UTC) Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: Nicolas Mailhot laposte.net> writes: > So I'd like the authorization for interested groups to stop trying to use the > tools the way they were not intended, kill the nested deep hierarchy mess and > move pages to the wiki root. Sorry, but I really really don't like this idea. :-( I like how everything relevant to the KDE SIG is under SIGs/KDE, we know who's responsible for those pages and we're sure not to trip on anybody else's page names that way. I think the (directory) tree structure clearly indicates who's reponsible for what, e.g. Packaging/* is FPC's domain, SIGs/KDE/* is KDE SIG's domain etc. One big flat namespace works well for projects like Wikipedia where everything is free for all, but in Fedora, we have subprojects, which should have their own namespace. (Yes, everyone with a wiki account is free to edit pages in most directories, but there's still one group which is responsible.) Mediawiki namespaces such as KDE:Foo might work, but I don't think they were really intended to be used in this way, AFAICT they're intended to represent special pages such as Image:* or Talk:* instead. Kevin Kofler From buc at odusz.so-cdu.ru Wed Jun 11 15:02:12 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 11 Jun 2008 19:02:12 +0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <1213194887.16019.8.camel@cutter> References: <484FE10B.1050404@odu.neva.ru> <1213194887.16019.8.camel@cutter> Message-ID: <484FE8F4.2090607@odu.neva.ru> seth vidal wrote: > > Does the cli format break compat with mailx as we know it now? Ie: will > we need to fix an arse-load of cron jobs and what not to behave? > There is an upstream's recommendation to use in scripts (including cron jobs) as "MAILRC=/dev/null mailx", whereas now it is jist "mail". I don't know whether it is for corner cases or it is an actual issue. Perhaps we should look how Suse and Slackware package this (btw, Suse had switched for a long time). Anyway, we can implement /bin/mail and /usr/bin/Mail as wrappers (or patch the mailx to differ its behaviour depending on how it was called)... ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From buc at odusz.so-cdu.ru Wed Jun 11 15:06:19 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 11 Jun 2008 19:06:19 +0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: References: <484FE10B.1050404@odu.neva.ru> Message-ID: <484FE9EB.5090301@odu.neva.ru> Nigel Metheringham wrote: > > On 11 Jun 2008, at 15:28, Dmitry Butskoy wrote: > >> Mailx-12.x adds a lot of useful functionality to the "cmdline mail >> command", which seems to be expected long years ago. Without it, some >> tasks can be performed only by TUI or even GUI applications, which >> makes impossible to automate things by scripts. > > > This looks good, but on a minimal system how many other packages would > be pulled in as dependancies over the existing mailx? For now, "openssl" (or "nss") and "krb5-libs". Is it OK for a minimal system? ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From kevin.kofler at chello.at Wed Jun 11 15:07:07 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 15:07:07 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> Message-ID: Toshio Kuratomi gmail.com> writes: > The playing time is 74 minutes, or 4440 seconds, so that the > net capacity of a Mode-1 CD-ROM is 682 MB.""" Uh, 74 minute CDs are completely obsolete, around here (Austria) they don't even sell these anymore! 80 minute / 700 MB CDs are the standard size these days, and those are what Fedora's live images are (and have always been) designed to fit. Kevin Kofler From nicolas.mailhot at laposte.net Wed Jun 11 15:09:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jun 2008 17:09:07 +0200 (CEST) Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: <41756.192.54.193.53.1213196947.squirrel@rousalka.dyndns.org> Le Mer 11 juin 2008 16:42, Kevin Kofler a ?crit : > Nicolas Mailhot laposte.net> writes: >> So I'd like the authorization for interested groups to stop trying >> to use the >> tools the way they were not intended, kill the nested deep hierarchy >> mess and >> move pages to the wiki root. > > Sorry, but I really really don't like this idea. :-( > > I like how everything relevant to the KDE SIG is under SIGs/KDE, Fine for you :) I didn't ask for the permission to move your pages, I asked the permission for interested groups to move theirs. If the old way works better for you, stick to the old way, just let me use the new one. My interest in the new way is purely pragmatic, spending several days fixing up old-way pages (with a rawhide browser) was an eye opener. I want as much stuff as possible automated to avoid going through this mess again in the future. Automating in mediawiki means categories, thus I'll use categories. -- Nicolas Mailhot From rjones at redhat.com Wed Jun 11 15:04:59 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Jun 2008 16:04:59 +0100 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <200806101624.m5AGOaWP027275@localhost.localdomain> References: <200806101624.m5AGOaWP027275@localhost.localdomain> Message-ID: <20080611150459.GA9646@amd.home.annexia.org> On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org wrote: > ocaml-deriving: > F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) > > ocaml-gsl: > F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) > > ocaml-json-static: > F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) [etc etc] Is this wrong? I'm afraid to say that a lot of packages I have do this. The reason is that I develop and build packages on Rawhide, then backport them to F-8. However when backporting to F-8 I have to bump the release number up, typically because I have to add an ExcludeArch: ppc64[*] for F-8, but may be because of other packing twiddling too. I wasn't aware that there had to be a strict increase in package numbering between branches. (In fact, I wasn't aware that Fedora even allowed updating between Fedora releases). Rich. [*] Although I suppose we could backport David Woodhouses OCaml-on-ppc64 patch to F-8, but that wouldn't fix the packages which are already like this. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Wed Jun 11 15:07:52 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Jun 2008 16:07:52 +0100 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080611150459.GA9646@amd.home.annexia.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: <20080611150752.GB9646@amd.home.annexia.org> On Wed, Jun 11, 2008 at 04:04:59PM +0100, Richard W.M. Jones wrote: > The reason is that I develop and build packages on Rawhide, then > backport them to F-8. In case that wasn't clear, I meant only when adding completely new packages after review requests, rather than my general methodology. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From paul at city-fan.org Wed Jun 11 15:13:25 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 11 Jun 2008 16:13:25 +0100 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080611150459.GA9646@amd.home.annexia.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: <484FEB95.4040100@city-fan.org> Richard W.M. Jones wrote: > On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org wrote: >> ocaml-deriving: >> F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) >> >> ocaml-gsl: >> F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) >> >> ocaml-json-static: >> F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) > [etc etc] > > Is this wrong? > > I'm afraid to say that a lot of packages I have do this. The reason > is that I develop and build packages on Rawhide, then backport them to > F-8. However when backporting to F-8 I have to bump the release > number up, typically because I have to add an ExcludeArch: ppc64[*] > for F-8, but may be because of other packing twiddling too. > > I wasn't aware that there had to be a strict increase in package > numbering between branches. (In fact, I wasn't aware that Fedora even > allowed updating between Fedora releases). When you do this backporting, add a release bump after the %{?dist} instead of before it, e.g.: ocaml-json-static-0.9.6-3.fc9 ocaml-json-static-0.9.6-3.fc8.1 This maintains the upgrade paths as intended. Paul. From kevin.kofler at chello.at Wed Jun 11 15:10:10 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 15:10:10 +0000 (UTC) Subject: Requirements gathering for new package source control References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > You don't have to tag to build. You can do scratch builds of HEAD in koji. But then you still have to issue a real build after the last scratch build succeeded, so you have wasted one build, wasting both your time and Koji's cycles. Much more efficient to always use non-scratch builds (unless you're building something which really shouldn't end up in Rawhide any time soon). Kevin Kofler From kevin.kofler at chello.at Wed Jun 11 15:17:35 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 15:17:35 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-06-10 References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: Richard W.M. Jones redhat.com> writes: > Is this wrong? EVR problems are bad. "Should never happen" type bad. Fedora n+1 updates MUST have a higher EVR than Fedora n updates. Rawhide MUST have a higher EVR than Fedora n updates for all n except in some rare cases in freeze periods. > I'm afraid to say that a lot of packages I have do this. The reason > is that I develop and build packages on Rawhide, then backport them to > F-8. However when backporting to F-8 I have to bump the release > number up, typically because I have to add an ExcludeArch: ppc64[*] > for F-8, but may be because of other packing twiddling too. Then you have to bump the version after the disttag, not in front of it. If you do a F8-specific change to a package numbered "2%{?dist}", you have to number it as "2%{?dist}.1", not "3%{?dist}". > I wasn't aware that there had to be a strict increase in package > numbering between branches. (In fact, I wasn't aware that Fedora even > allowed updating between Fedora releases). Yes, there has to be one and yes, Fedora allows updating from one release to the next! What you have to do now to fix this is to issue "bump version" updates for F9 (even if there are no other changes) to fix the EVR ordering. Kevin Kofler From buc at odusz.so-cdu.ru Wed Jun 11 15:20:14 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 11 Jun 2008 19:20:14 +0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FE8F4.2090607@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <1213194887.16019.8.camel@cutter> <484FE8F4.2090607@odu.neva.ru> Message-ID: <484FED2E.4090302@odu.neva.ru> Dmitry Butskoy wrote: > seth vidal wrote: >> >> Does the cli format break compat with mailx as we know it now? Ie: will >> we need to fix an arse-load of cron jobs and what not to behave? >> > > There is an upstream's recommendation to use in scripts (including > cron jobs) as "MAILRC=/dev/null mailx", whereas now it is jist "mail". > I don't know whether it is for corner cases or it is an actual issue. > Perhaps we should look how Suse and Slackware package this (btw, Suse > had switched for a long time). BTW, the current "mail" already reads ~/.mailrc and, depending on "-n", /etc/mail.rc . Mailx-12.x will do the same (it explains why Suse does not use any wrappers etc.). IOW, nothing worse. ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From caillon at redhat.com Wed Jun 11 15:23:37 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Jun 2008 11:23:37 -0400 Subject: Notice: F7 EOL on 2008-06-13 In-Reply-To: <20080610173035.GD32125@nostromo.devel.redhat.com> References: <20080610173035.GD32125@nostromo.devel.redhat.com> Message-ID: <484FEDF9.1000609@redhat.com> Bill Nottingham wrote: > This is a reminder that F7 goes EOL on 2008-06-13. If you have any > critical updates lingering in testing, you may want to have them > moved final before then. Then again, there hopefully aren't too many > updates at this point... How long will the F7 package set remain available on the master/mirrors? For those that wish to e.g. yum install preupgrade in order to get to something newer. From mschwendt at gmail.com Wed Jun 11 15:23:31 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Jun 2008 17:23:31 +0200 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080611150459.GA9646@amd.home.annexia.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: <20080611172331.063f1945.mschwendt@gmail.com> On Wed, 11 Jun 2008 16:04:59 +0100, Richard W.M. Jones wrote: > On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org wrote: > > ocaml-deriving: > > F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) > > > > ocaml-gsl: > > F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) > > > > ocaml-json-static: > > F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) > [etc etc] > > Is this wrong? > > I'm afraid to say that a lot of packages I have do this. The reason > is that I develop and build packages on Rawhide, then backport them to > F-8. However when backporting to F-8 I have to bump the release > number up, typically because I have to add an ExcludeArch: ppc64[*] > for F-8, but may be because of other packing twiddling too. That's no reason. %if 0%{?fedora} > 8 # something %endif Effectively, you can create a spec file in "devel" which you can copy unmodified to older branches. If, however, you really need to modify'n'bump an older branch only, increase the "Release" value in the least-significant position at the very right, 4%{?dist} => 4%{?dist}.1 => %{?dist}.2 => and so on but if it's just minor modifications, you better use the %fedora macro as above. > I wasn't aware that there had to be a strict increase in package > numbering between branches. (In fact, I wasn't aware that Fedora even > allowed updating between Fedora releases). What do you think why does Anaconda support distribution upgrades? It has been the official upgrade method for many years (as with old Red Hat Linux), and our users do also Yum/Apt-based dist-upgrades. From kevin.kofler at chello.at Wed Jun 11 15:21:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 15:21:30 +0000 (UTC) Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies References: <389552.959071213099076255.JavaMail.www@wwinf8402> <41756.192.54.193.53.1213196947.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > Fine for you :) I didn't ask for the permission to move your pages, I > asked the permission for interested groups to move theirs. If the old > way works better for you, stick to the old way, just let me use the > new one. That's fine with me. :-) > My interest in the new way is purely pragmatic, spending several days > fixing up old-way pages (with a rawhide browser) was an eye opener. I > want as much stuff as possible automated to avoid going through this > mess again in the future. Automating in mediawiki means categories, > thus I'll use categories. Just FYI, pywikipedia can mass-edit pages which match regexes such as SIGs/KDE/Meetings/[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] (that's how I fixed the transcript links which all got broken by the migration). Kevin Kofler From ajax at redhat.com Wed Jun 11 15:24:19 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 11 Jun 2008 11:24:19 -0400 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <20080611150459.GA9646@amd.home.annexia.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: <1213197859.28032.79.camel@localhost.localdomain> On Wed, 2008-06-11 at 16:04 +0100, Richard W.M. Jones wrote: > On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org wrote: > > ocaml-deriving: > > F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) > > > > ocaml-gsl: > > F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) > > > > ocaml-json-static: > > F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) > [etc etc] > > Is this wrong? > > I'm afraid to say that a lot of packages I have do this. The reason > is that I develop and build packages on Rawhide, then backport them to > F-8. However when backporting to F-8 I have to bump the release > number up, typically because I have to add an ExcludeArch: ppc64[*] > for F-8, but may be because of other packing twiddling too. > > I wasn't aware that there had to be a strict increase in package > numbering between branches. (In fact, I wasn't aware that Fedora even > allowed updating between Fedora releases). It's very strongly encouraged. We do provide upgrade paths between releases (and are even working to make them more robust). So yes, please do keep EVRs for older releases lower (in the rpmvercmp sense) than those for newer releases. When in doubt: % sudo yum -y install rpmdevtools % rpmdev-vercmp 0:0.9.6-4.fc8 0:0.9.6-3.fc9 0:0.9.6-4.fc8 is newer - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Jun 11 15:39:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jun 2008 17:39:26 +0200 (CEST) Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <484FEB95.4040100@city-fan.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> <484FEB95.4040100@city-fan.org> Message-ID: <54750.192.54.193.53.1213198766.squirrel@rousalka.dyndns.org> Le Mer 11 juin 2008 17:13, Paul Howarth a ?crit : > Richard W.M. Jones wrote: >> On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org >> wrote: >>> ocaml-deriving: >>> F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) >>> >>> ocaml-gsl: >>> F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) >>> >>> ocaml-json-static: >>> F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) >> [etc etc] >> >> Is this wrong? >> >> I'm afraid to say that a lot of packages I have do this. The reason >> is that I develop and build packages on Rawhide, then backport them >> to >> F-8. However when backporting to F-8 I have to bump the release >> number up, typically because I have to add an ExcludeArch: ppc64[*] >> for F-8, but may be because of other packing twiddling too. >> >> I wasn't aware that there had to be a strict increase in package >> numbering between branches. (In fact, I wasn't aware that Fedora >> even >> allowed updating between Fedora releases). > > When you do this backporting, add a release bump after the %{?dist} > instead of before it, e.g.: > > ocaml-json-static-0.9.6-3.fc9 > ocaml-json-static-0.9.6-3.fc8.1 I really don't see why ocaml-json-static-0.9.6-3.fc8 can not be created instead. Our tools allow the following workflow push foo-x-1.fc8 push foo-x-1.fc9 push foo-x-2.fc9 push foo-x-2.fc8 There is zero reason why foo-x-2.fc8 can not be built after foo-x-2.fc9 -- Nicolas Mailhot From notting at redhat.com Wed Jun 11 15:57:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 11 Jun 2008 11:57:36 -0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FED2E.4090302@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <1213194887.16019.8.camel@cutter> <484FE8F4.2090607@odu.neva.ru> <484FED2E.4090302@odu.neva.ru> Message-ID: <20080611155736.GC26416@nostromo.devel.redhat.com> Dmitry Butskoy (buc at odusz.so-cdu.ru) said: > BTW, the current "mail" already reads ~/.mailrc and, depending on "-n", > /etc/mail.rc . Mailx-12.x will do the same (it explains why Suse does not > use any wrappers etc.). IOW, nothing worse. If it's command-line compatible for older users, I don't see a problem. Bill From skvidal at fedoraproject.org Wed Jun 11 15:57:39 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 11 Jun 2008 11:57:39 -0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FED2E.4090302@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <1213194887.16019.8.camel@cutter> <484FE8F4.2090607@odu.neva.ru> <484FED2E.4090302@odu.neva.ru> Message-ID: <1213199859.16019.28.camel@cutter> On Wed, 2008-06-11 at 19:20 +0400, Dmitry Butskoy wrote: > Dmitry Butskoy wrote: > > seth vidal wrote: > >> > >> Does the cli format break compat with mailx as we know it now? Ie: will > >> we need to fix an arse-load of cron jobs and what not to behave? > >> > > > > There is an upstream's recommendation to use in scripts (including > > cron jobs) as "MAILRC=/dev/null mailx", whereas now it is jist "mail". > > I don't know whether it is for corner cases or it is an actual issue. > > Perhaps we should look how Suse and Slackware package this (btw, Suse > > had switched for a long time). > > BTW, the current "mail" already reads ~/.mailrc and, depending on "-n", > /etc/mail.rc . Mailx-12.x will do the same (it explains why Suse does > not use any wrappers etc.). IOW, nothing worse. > If it acts the same then I don't see a good reason not to upgrade it. Though I will say - maybe do this as an F10 thing and let f8,F9 keep the older one? -sv From gemi at bluewin.ch Wed Jun 11 16:01:52 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 11 Jun 2008 18:01:52 +0200 Subject: Need help with clisp on ppc Message-ID: <1213200112.1514.2.camel@localhost.localdomain> I was trying to build the latest clisp release 2.45 for F9+. i386 and x86_64 seem fine, but again on ppc the fails. Could someone with ppc experience look into this (ppc64 is still disabled, anyways). The current spec is found in the F-9 cvs branch. Regards, gemi From buc at odusz.so-cdu.ru Wed Jun 11 16:05:52 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 11 Jun 2008 20:05:52 +0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <1213199859.16019.28.camel@cutter> References: <484FE10B.1050404@odu.neva.ru> <1213194887.16019.8.camel@cutter> <484FE8F4.2090607@odu.neva.ru> <484FED2E.4090302@odu.neva.ru> <1213199859.16019.28.camel@cutter> Message-ID: <484FF7E0.3000508@odu.neva.ru> seth vidal wrote: > On Wed, 2008-06-11 at 19:20 +0400, Dmitry Butskoy wrote: > >> BTW, the current "mail" already reads ~/.mailrc and, depending on "-n", >> /etc/mail.rc . Mailx-12.x will do the same (it explains why Suse does >> not use any wrappers etc.). IOW, nothing worse. >> >> > > If it acts the same then I don't see a good reason not to upgrade it. > Though I will say - maybe do this as an F10 thing and let f8,F9 keep the > older one? > Sure. As Rawhide (F10) thing only. For those who want it in F8/F9, there is already "nail" :) ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From kevin at scrye.com Wed Jun 11 16:21:55 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 11 Jun 2008 10:21:55 -0600 Subject: Need help with clisp on ppc In-Reply-To: <1213200112.1514.2.camel@localhost.localdomain> References: <1213200112.1514.2.camel@localhost.localdomain> Message-ID: <20080611102155.1c162d94@ohm.scrye.com> On Wed, 11 Jun 2008 18:01:52 +0200 gemi at bluewin.ch (G?rard Milmeister) wrote: > I was trying to build the latest clisp release 2.45 for F9+. i386 and > x86_64 seem fine, but again on ppc the fails. Could someone with ppc > experience look into this (ppc64 is still disabled, anyways). The > current spec is found in the F-9 cvs branch. I have a ppc32 rawhide machine here for just such testing/fixing. If you send me a ssh key I would be happy to make you an account so you could investigate. Or if there is anyone else in the cvsextras group who wants to look, I would be happy to get them access as well. I am planning on getting things setup so I can just have all the cvsextras group people automagically have access to these test machines. More news as I get it. > Regards, > gemi kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From seg at haxxed.com Wed Jun 11 16:43:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 11 Jun 2008 11:43:53 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <484E956E.5080300@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> Message-ID: <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> On Tue, Jun 10, 2008 at 9:53 AM, Eric Sandeen wrote: > I think the problem is, barriers are really implemented as drive cache > flushes. So under certain workloads the performance really does hurt. > But if the alternative is a good chance of filesystem corruption on > power loss, remind me again why we run a journaling fileystem at all? :) > > If ext3 doesn't get barriers on by default upstream then I would suggest > that yes, we should patch the kernel ourselves to do so, or set the > installer to create fstabs which specify it for filesystems that don't > have barriers on by default. ... after lvm stops filtering it out, anyway. I would like to put in my +1 for this. Performance is pointless on if you can not trust that your data is safe. I have on many occasions run fscks on my supposedly clean ext3 filesystems, only to find some mild corruption. How can this happen? Isn't journaling supposed to prevent this? One day I ran a fsck before doing some filesystem resizing, only to find one of my irreplacible personal photos had become corrupted. I had no way to know when or why this file got corrupted, it had been written to disk some time ago and never touched since. I trusted journaling, and it failed me. (Yes, I have a backup. I think...) After this, I now turn on autofsck on all my machines, so that corruption at least can't go undetected for years. Which means after a power fail it takes my primary desktop with a pretty full 250gb drive 20-30 minutes to come back up, which is incredibly irritating, but I have to know my data is safe. I've even picked up a habit of obsessively checksumming all my really important files. I wish the filesystem would help do this for me. (ZFS...) Knowing is half the battle. See, what can happen here, is a file can get corrupted, and I may not notice until years later. By then I may have cycled through several full backups, and long since lost the backup I did have of the file... This must be fixed. Only through a long painful process of losing faith have I learned to not trust my filesystems. I suspect there are many others out there who have been bitten by filesystem corruption and just don't know it yet. Only now do I learn the likely reason for this corruption. How would I have reported this? I just assumed it was hardware glitches. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Wed Jun 11 16:50:53 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 11 Jun 2008 12:50:53 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530184739.GA2473@imperial.ac.uk> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> Message-ID: <1213203053.5747.20.camel@localhost.localdomain> On Wed, 2008-06-11 at 13:19 +0200, Valent Turkovic wrote: > On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: > > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > >> [...] > >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > >> > > >> > Definitely in the next F9 update. > >> > >> Will this update contain my patch which allows people to uninstall > >> NetworkManager without losing pidgin and evolution (bug #351101)? > >> > >> You never gave a good reason why this bug has been left unfixed > >> for over half a year, especially when the solution is trivial. > > > > Can you try out > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 > > > > when it gets done? > > > > Thanks, > > Dan > > > >> Regards, > >> R. > >> > >> -- > >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski > >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > >> "Faith manages." > >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > >> > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > I tested NetworkManager via: > yum --enablerepo=updates-testing update NetworkManager > > as you suggested in bugreport but I still see the same bug present. What's the output of: ls -al /etc/rc3.d/*Net* Dan From sandeen at redhat.com Wed Jun 11 16:56:13 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 11 Jun 2008 11:56:13 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> Message-ID: <485003AD.8010701@redhat.com> Callum Lerwick wrote: > I would like to put in my +1 for this. Performance is pointless on if > you can not trust that your data is safe. I have on many occasions run > fscks on my supposedly clean ext3 filesystems, only to find some mild > corruption. How can this happen? Isn't journaling supposed to prevent > this? One day I ran a fsck before doing some filesystem resizing, only > to find one of my irreplacible personal photos had become corrupted. I > had no way to know when or why this file got corrupted, it had been > written to disk some time ago and never touched since. I trusted > journaling, and it failed me. Filesystem corruption can happen for many reasons, and journaling cannot save you from them all. Think about bad cables, memory, kernel bugs, bad hardware, rogue writes to the block device, etc. Journaling doesn't help you in the face of any of these problems. If you are talking about data corruption, it could have been an application bug for example (did a photo editor corrupt it when you wrote the edited version?) There is a long line of things which can go wrong, unfortunately. Trusting journalling to keep all your data safe now and forevermore is misguided. > (Yes, I have a backup. I think...) After > this, I now turn on autofsck on all my machines, so that corruption at > least can't go undetected for years. Which means after a power fail it > takes my primary desktop with a pretty full 250gb drive 20-30 minutes to > come back up, which is incredibly irritating, but I have to know my data > is safe. I've even picked up a habit of obsessively checksumming all my > really important files. I wish the filesystem would help do this for me. > (ZFS...) > > Knowing is half the battle. See, what can happen here, is a file can get > corrupted, and I may not notice until years later. By then I may have > cycled through several full backups, and long since lost the backup I > did have of the file... > > This must be fixed. Only through a long painful process of losing faith > have I learned to not trust my filesystems. I suspect there are many > others out there who have been bitten by filesystem corruption and just > don't know it yet. > > Only now do I learn the likely reason for this corruption. How would I > have reported this? I just assumed it was hardware glitches. True, corruption from out-of-order writes due to lack of barriers is hard to identify as such. But unfortunately there are a few other things that could have gone wrong too. There are things in the works to help on the integrity front, though (see http://oss.oracle.com/projects/data-integrity/ for example). -Eric From mschwendt at gmail.com Wed Jun 11 16:58:48 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Jun 2008 18:58:48 +0200 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <54750.192.54.193.53.1213198766.squirrel@rousalka.dyndns.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> <484FEB95.4040100@city-fan.org> <54750.192.54.193.53.1213198766.squirrel@rousalka.dyndns.org> Message-ID: <440f31f60806110958y1b35f4a1ge18d8c6f39631189@mail.gmail.com> 2008/6/11 Nicolas Mailhot: > >> When you do this backporting, add a release bump after the %{?dist} >> instead of before it, e.g.: >> >> ocaml-json-static-0.9.6-3.fc9 >> ocaml-json-static-0.9.6-3.fc8.1 > > I really don't see why ocaml-json-static-0.9.6-3.fc8 can not be > created instead. Our tools allow the following workflow > > push foo-x-1.fc8 > push foo-x-1.fc9 > push foo-x-2.fc9 > push foo-x-2.fc8 > > There is zero reason why foo-x-2.fc8 can not be built after foo-x-2.fc9 > I believe the problem here is the packager develops and builds for F9 [or Rawhide], then mass-distributes a final package to F8 and older branches, finds out that it doesn't build and fixes it till it builds. While fixing it, release is bumped once or multiple times, but not right of %{dist}. Since the fixes are specific to the older dists, they are not pushed to F9/Rawhide. The spec files and release values get out-of-sync. From jkeating at redhat.com Wed Jun 11 17:27:53 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jun 2008 13:27:53 -0400 Subject: Notice: F7 EOL on 2008-06-13 In-Reply-To: <484FEDF9.1000609@redhat.com> References: <20080610173035.GD32125@nostromo.devel.redhat.com> <484FEDF9.1000609@redhat.com> Message-ID: <1213205273.4193.45.camel@localhost.localdomain> On Wed, 2008-06-11 at 11:23 -0400, Christopher Aillon wrote: > > How long will the F7 package set remain available on the master/mirrors? > For those that wish to e.g. yum install preupgrade in order to get to > something newer. The 7 bits will remain obtainable via mirrormanager mirrorlists for the forseeable future, like years and years down the road. Whether or not those bits stay on the expensive primary mirror is up for debate, but likely won't be shuffled off for another year. If and when the bits do migrate, published urls for these (the baseurl and the mirrorlist url) will continue to direct users to the content, regardless of where it is. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From email.ahmedkamal at googlemail.com Wed Jun 11 17:48:29 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 11 Jun 2008 20:48:29 +0300 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <485003AD.8010701@redhat.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> <485003AD.8010701@redhat.com> Message-ID: <3da3b5b40806111048y5566f868s31beed292ef824d@mail.gmail.com> Reference this: http://blogs.sun.com/bonwick/entry/casablanca Does anyone know if we're getting ZFS anytime soon?! On Wed, Jun 11, 2008 at 7:56 PM, Eric Sandeen wrote: > Callum Lerwick wrote: > > > I would like to put in my +1 for this. Performance is pointless on if > > you can not trust that your data is safe. I have on many occasions run > > fscks on my supposedly clean ext3 filesystems, only to find some mild > > corruption. How can this happen? Isn't journaling supposed to prevent > > this? One day I ran a fsck before doing some filesystem resizing, only > > to find one of my irreplacible personal photos had become corrupted. I > > had no way to know when or why this file got corrupted, it had been > > written to disk some time ago and never touched since. I trusted > > journaling, and it failed me. > > Filesystem corruption can happen for many reasons, and journaling cannot > save you from them all. Think about bad cables, memory, kernel bugs, > bad hardware, rogue writes to the block device, etc. Journaling doesn't > help you in the face of any of these problems. If you are talking about > data corruption, it could have been an application bug for example (did > a photo editor corrupt it when you wrote the edited version?) There is > a long line of things which can go wrong, unfortunately. Trusting > journalling to keep all your data safe now and forevermore is misguided. > > > (Yes, I have a backup. I think...) After > > this, I now turn on autofsck on all my machines, so that corruption at > > least can't go undetected for years. Which means after a power fail it > > takes my primary desktop with a pretty full 250gb drive 20-30 minutes to > > come back up, which is incredibly irritating, but I have to know my data > > is safe. I've even picked up a habit of obsessively checksumming all my > > really important files. I wish the filesystem would help do this for me. > > (ZFS...) > > > > Knowing is half the battle. See, what can happen here, is a file can get > > corrupted, and I may not notice until years later. By then I may have > > cycled through several full backups, and long since lost the backup I > > did have of the file... > > > > This must be fixed. Only through a long painful process of losing faith > > have I learned to not trust my filesystems. I suspect there are many > > others out there who have been bitten by filesystem corruption and just > > don't know it yet. > > > > Only now do I learn the likely reason for this corruption. How would I > > have reported this? I just assumed it was hardware glitches. > > True, corruption from out-of-order writes due to lack of barriers is > hard to identify as such. But unfortunately there are a few other > things that could have gone wrong too. There are things in the works to > help on the integrity front, though (see > http://oss.oracle.com/projects/data-integrity/ for example). > > -Eric > > -- > 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 rjones at redhat.com Wed Jun 11 18:07:00 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Jun 2008 19:07:00 +0100 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> Message-ID: <20080611180700.GA3528@amd.home.annexia.org> On Wed, Jun 11, 2008 at 03:17:35PM +0000, Kevin Kofler wrote: > What you have to do now to fix this is to issue "bump version" updates for > F9 (even if there are no other changes) to fix the EVR ordering. OK, thanks everyone. What I will do is bump everything in the affected packages in the later releases (it's late now so probably tomorrow ...) so that this issue is fixed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From iarnell at epo.org Wed Jun 11 18:53:26 2008 From: iarnell at epo.org (Iain Arnell) Date: Wed, 11 Jun 2008 20:53:26 +0200 Subject: (no subject) Message-ID: A long time ago (2007-04-06 06:29:59 GMT), Nicolas Mailhot stated (http://www.redhat.com/archives/rhl-devel-list/2007-April/msg00254.html): > you can't package JBoss properly if you don't package a JVM, Fedora > will only package FLOSS code and the consensus seems to be it's more > efficient to wait for the actual Java 7 SUN GPL release than make gcj > feature-complete enough for JBoss. If no JBoss packages appear in Fedora > after this JVM release, please yell. I realise that openjdk doesn't strictly meet the stated conditions, but surely close enough that I can yell... WHERE ARE THE JBOSS PACKAGES IN FEDORA? Or, are there any secret redhat plans/projects to move the existing packages from JBEAP into Fedora (and hopefully into EPEL too)? It seems that a large chunk of the work has been done already. From skvidal at fedoraproject.org Wed Jun 11 19:04:57 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 11 Jun 2008 15:04:57 -0400 Subject: (no subject) In-Reply-To: References: Message-ID: <1213211097.16019.50.camel@cutter> On Wed, 2008-06-11 at 20:53 +0200, Iain Arnell wrote: > > A long time ago (2007-04-06 06:29:59 GMT), Nicolas Mailhot stated > (http://www.redhat.com/archives/rhl-devel-list/2007-April/msg00254.html): > > > you can't package JBoss properly if you don't package a JVM, Fedora > > will only package FLOSS code and the consensus seems to be it's more > > efficient to wait for the actual Java 7 SUN GPL release than make gcj > > feature-complete enough for JBoss. If no JBoss packages appear in Fedora > > after this JVM release, please yell. > > I realise that openjdk doesn't strictly meet the stated conditions, > but surely close enough that I can yell... > > WHERE ARE THE JBOSS PACKAGES IN FEDORA? > > Or, are there any secret redhat plans/projects to move the existing > packages from JBEAP into Fedora (and hopefully into EPEL too)? It > seems that a large chunk of the work has been done already. There are not secret red hat plans/projects wrt fedora at all. All the plans are in public. If you want jboss packages in fedora I think the best bet is to submit them. -sv From denis at poolshark.org Wed Jun 11 19:25:57 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 11 Jun 2008 21:25:57 +0200 Subject: Koji ppc build stuck ? Message-ID: <485026C5.4090408@poolshark.org> Could somebody kick that build ? :-) http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 From dominik at greysector.net Wed Jun 11 19:26:42 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 11 Jun 2008 21:26:42 +0200 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> Message-ID: <20080611192641.GA20214@mokona.greysector.net> On Wednesday, 11 June 2008 at 17:10, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > You don't have to tag to build. You can do scratch builds of HEAD in koji. > > But then you still have to issue a real build after the last scratch build > succeeded, so you have wasted one build, wasting both your time and Koji's > cycles. Much more efficient to always use non-scratch builds (unless you're > building something which really shouldn't end up in Rawhide any time soon). It's not wasted if you're expecting it to fail, but you don't know how it will fail. And I don't have a ppc box under my desk, mind you. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mikeb at redhat.com Wed Jun 11 20:00:07 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 11 Jun 2008 16:00:07 -0400 Subject: Koji ppc build stuck ? In-Reply-To: <485026C5.4090408@poolshark.org> References: <485026C5.4090408@poolshark.org> Message-ID: <1213214407.31380.32.camel@localhost.localdomain> On Wed, 2008-06-11 at 21:25 +0200, Denis Leroy wrote: > Could somebody kick that build ? :-) > > http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 Done. From bpepple at fedoraproject.org Wed Jun 11 20:11:01 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 11 Jun 2008 16:11:01 -0400 Subject: Plan for tomorrows (20080611) FESCO meeting Message-ID: <1213215061.2881.2.camel@kennedy> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- sponsor nominations -- Remi Collet /topic FESCo-Meeting -- sponsor nominations -- Ignacio Vazquez-Abrams /topic FESCo-Meeting -- sponsor nominations -- Nicolas Mailhot /topic FESCo-Meeting -- sponsor nominations -- Axel Thimm /topic FESCo-Meeting -- sponsor nominations -- G?rard Milmeister /topic FESCO-Meeting -- FESCo meeting at FUDCon? -- all /topic FESCO-Meeting -- FESCo Responsibilities/Role? -- all /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. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. 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: 197 bytes Desc: This is a digitally signed message part URL: From gemi at bluewin.ch Wed Jun 11 20:57:33 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 11 Jun 2008 22:57:33 +0200 Subject: Need help with clisp on ppc In-Reply-To: <20080611102155.1c162d94@ohm.scrye.com> References: <1213200112.1514.2.camel@localhost.localdomain> <20080611102155.1c162d94@ohm.scrye.com> Message-ID: <1213217853.1514.4.camel@localhost.localdomain> On Wed, 2008-06-11 at 10:21 -0600, Kevin Fenzi wrote: > If you send me a ssh key I would be happy to make you an account so > you could investigate. Or if there is anyone else in the cvsextras > group who wants to look, I would be happy to get them access as well. I would rather have somebody with ppc experience look at it. From ajax at redhat.com Wed Jun 11 21:17:59 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 11 Jun 2008 17:17:59 -0400 Subject: Planned libOSMesa changes Message-ID: <1213219079.28032.118.camel@localhost.localdomain> We currently have libOSMesa's soname pinned at libOSMesa.so.6 rather than upstream's libOSMesa.so.7, because there was no effective ABI change between the two. This is kind of lame. We are also building three copies of libOSMesa, one for each of 8, 16, and 32 bits per pixel. This is wasteful since, I believe as of Mesa 6.5.something, it's possible to build a libOSMesa that can do all three depths. So I'd like to fix both of these things in F10. I'd like to ship exactly one copy of the library, built for all three depths, with an soname of libOSMesa.so.7. Repoquery tells me the following packages will be affected: kbiof - owned by oddsocks (Ian Chapman) paraview - owned by orion (Orion Poplawski) vtk - owned by athimm (Axel Thimm) So if this is you, consider yourself informed, and please raise objections soon if at all. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Wed Jun 11 21:22:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 11 Jun 2008 21:22:57 +0000 (UTC) Subject: Requirements gathering for new package source control References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > It's not wasted if you're expecting it to fail, but you don't know how it > will fail. And I don't have a ppc box under my desk, mind you. You're rarely 100% sure that the build will fail. If there's even the slightest chance that the build may succeed, it's a waste to issue it as a scratch build. Kevin Kofler From loupgaroublond at gmail.com Wed Jun 11 21:26:38 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 11 Jun 2008 23:26:38 +0200 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> Message-ID: <7f692fec0806111426p13b00dcfq5c903e1205152f74@mail.gmail.com> 2008/6/11 Callum Lerwick : > On Tue, Jun 10, 2008 at 9:53 AM, Eric Sandeen wrote: >> >> I think the problem is, barriers are really implemented as drive cache >> flushes. So under certain workloads the performance really does hurt. >> But if the alternative is a good chance of filesystem corruption on >> power loss, remind me again why we run a journaling fileystem at all? :) >> >> If ext3 doesn't get barriers on by default upstream then I would suggest >> that yes, we should patch the kernel ourselves to do so, or set the >> installer to create fstabs which specify it for filesystems that don't >> have barriers on by default. ... after lvm stops filtering it out, >> anyway. > > I would like to put in my +1 for this. Performance is pointless on if you > can not trust that your data is safe. I have on many occasions run fscks on > my supposedly clean ext3 filesystems, only to find some mild corruption. How > can this happen? Isn't journaling supposed to prevent this? One day I ran a > fsck before doing some filesystem resizing, only to find one of my > irreplacible personal photos had become corrupted. I had no way to know when > or why this file got corrupted, it had been written to disk some time ago > and never touched since. I trusted journaling, and it failed me. (Yes, I > have a backup. I think...) After this, I now turn on autofsck on all my > machines, so that corruption at least can't go undetected for years. Which > means after a power fail it takes my primary desktop with a pretty full > 250gb drive 20-30 minutes to come back up, which is incredibly irritating, > but I have to know my data is safe. I've even picked up a habit of > obsessively checksumming all my really important files. I wish the > filesystem would help do this for me. (ZFS...) > > Knowing is half the battle. See, what can happen here, is a file can get > corrupted, and I may not notice until years later. By then I may have cycled > through several full backups, and long since lost the backup I did have of > the file... > > This must be fixed. Only through a long painful process of losing faith have > I learned to not trust my filesystems. I suspect there are many others out > there who have been bitten by filesystem corruption and just don't know it > yet. > > Only now do I learn the likely reason for this corruption. How would I have > reported this? I just assumed it was hardware glitches. Journaling won't save you from this problem, necessarily. What you gain from journaling is when your process aborts half way through because of any failure at all. The integrity you get is not that every piece of data is intact and correct, but that no bit is in a transitory state. This means any transaction, or change of state from A to B, that affects more than one bit on the hard drive, is a concrete, isolated and discrete change. This is the only guarantee you get from a journaled file system. This means, your system crashes while doing a banking transaction, you don't lose money without a record being made to whom you paid it to. It means that while rotating a photo, your power goes out, you don't have half a rotate photo saved on your hard drive. It means that there are no lost blocks on your hard drive of files that didn't save while doing something very critical. File copy operations are either completed or not. You don't gain long term storage. You do gain transaction security. -Yaakov From wolfy at nobugconsulting.ro Wed Jun 11 21:16:43 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 12 Jun 2008 00:16:43 +0300 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FE9EB.5090301@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> Message-ID: <485040BB.5070305@nobugconsulting.ro> On 06/11/2008 06:06 PM, Dmitry Butskoy wrote: > Nigel Metheringham wrote: >> >> On 11 Jun 2008, at 15:28, Dmitry Butskoy wrote: >> >>> Mailx-12.x adds a lot of useful functionality to the "cmdline mail >>> command", which seems to be expected long years ago. Without it, >>> some tasks can be performed only by TUI or even GUI applications, >>> which makes impossible to automate things by scripts. I am 100% in favor. I already use nail instead of mail everywhere I need to use command line tools. What I love most is it's ability to attach files. >> >> >> This looks good, but on a minimal system how many other packages >> would be pulled in as dependancies over the existing mailx? > > For now, "openssl" (or "nss") and "krb5-libs". Is it OK for a minimal > system? openssl and krb5-libs are already required by openssh so I'd say it's not a problem From sandeen at redhat.com Wed Jun 11 21:43:09 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 11 Jun 2008 16:43:09 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <7f692fec0806111426p13b00dcfq5c903e1205152f74@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> <7f692fec0806111426p13b00dcfq5c903e1205152f74@mail.gmail.com> Message-ID: <485046ED.7060805@redhat.com> Yaakov Nemoy wrote: > This means, your system crashes while doing a banking transaction, you > don't lose money without a record being made to whom you paid it to. > It means that while rotating a photo, your power goes out, you don't > have half a rotate photo saved on your hard drive. Well, not in general, at least not from normal filesystem journaling. The stuff you're talking about here is by and large the responsibility of the app doing the writing. Filesystem journaling is often only for metadata, to ensure metadata consistency, or something like data=journaled... but if your photo app writes out half of the edited jpeg over the top of the existing file in one syscall and then you crash before it makes a 2nd intended write, in general journaling is not going to help you there, either. see for example this talk: eat my data: how everybody gets file IO wrong http://lca2007.linux.org.au/talk/278.html We'll discuss: - when data hits disk - what causes data to hit disk - how you can ensure that data is on disk - how applications get this wrong - how a file system is not a database (and vice versa) -Eric From dominik at greysector.net Wed Jun 11 22:06:11 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 12 Jun 2008 00:06:11 +0200 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> Message-ID: <20080611220611.GB20214@mokona.greysector.net> On Wednesday, 11 June 2008 at 23:22, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > It's not wasted if you're expecting it to fail, but you don't know how it > > will fail. And I don't have a ppc box under my desk, mind you. > > You're rarely 100% sure that the build will fail. If there's even the slightest > chance that the build may succeed, it's a waste to issue it as a scratch build. Right, so let's disable all scratch builds because someone may be wasting a tiny bit of Fedora's build cluster's resources. Better yet, let's track these evildoers, kill them, their families and their cats, and burn their houses. That'll show them. I'll just get my flamethrower. Oh wait, I'm already wearing one. R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From yanmin_zhang at linux.intel.com Thu Jun 12 01:04:06 2008 From: yanmin_zhang at linux.intel.com (Zhang, Yanmin) Date: Thu, 12 Jun 2008 09:04:06 +0800 Subject: [Fedora-ia64-list] Kernel directory change In-Reply-To: <1213189422.3673.2.camel@centrino> References: <1213145883.3054.8.camel@ymzhang> <1213189422.3673.2.camel@centrino> Message-ID: <1213232646.3054.16.camel@ymzhang> On Wed, 2008-06-11 at 09:03 -0400, Doug Chapman wrote: > On Wed, 2008-06-11 at 08:58 +0800, Zhang, Yanmin wrote: > > Yi, > > > > I installed FC9 Beta ia64 on my Montvale machine and found the kernel > > directory is changed. The old directory is /boot/efi/efi/redhat, but the > > new one is /boot/efi/EFI/redhat. Is there any special reason to do so? > > > > A couple of test suites assumes ?/boot/efi/efi/redhat. > > > > -yanmin > > > > This changed a while back. What it appears happened was that the vfat > filesystem for some reason now understands upper/lower case. In > actuality it was always /boot/efi/EFI but the linux implementation of > vfat shifted the directory name to lower case. > > Note that under the EFI shell it was always an upper case EFI as that is > what is actually on the filesystem. I would suggest modifying your test > to handle either case. That's not a good idea. Although it's caused by vfat improvements, I would suggest to keep the old interface. Long long ago, there was a long discussion about interface change on LKML. It's a bad idea to change interfaces or API when they become de facto. From seg at haxxed.com Thu Jun 12 03:52:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 11 Jun 2008 22:52:28 -0500 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <7f692fec0806111426p13b00dcfq5c903e1205152f74@mail.gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <484E8A2E.4060605@redhat.com> <20080610144759.GC28121@devserv.devel.redhat.com> <484E956E.5080300@redhat.com> <1218b5bc0806110943n6fb11db5v5a18c8ec86cc758e@mail.gmail.com> <7f692fec0806111426p13b00dcfq5c903e1205152f74@mail.gmail.com> Message-ID: <1218b5bc0806112052m280cbe61jf33f09fc68161061@mail.gmail.com> On Wed, Jun 11, 2008 at 4:26 PM, Yaakov Nemoy wrote: > Journaling won't save you from this problem, necessarily. What you > gain from journaling is when your process aborts half way through > because of any failure at all. The integrity you get is not that > every piece of data is intact and correct, but that no bit is in a > transitory state. This means any transaction, or change of state from > A to B, that affects more than one bit on the hard drive, is a > concrete, isolated and discrete change. This is the only guarantee > you get from a journaled file system. I again point out this is a file that was written once and never again modified. Nothing should have been writing to it. The metadata got trashed somehow, as I remember it gave some "inode has wrong size" error, I told e2fsck to fix it and the file ended up 0 bytes. I don't see how this could be blamed on anything but the kernel or hardware, and this particular machine is fairly new, with decent quality hardware, so I'm pretty certain the hardware isn't flaky. Though now that I think of it I've had problems with the r300 drivers locking up the system. Should a hardware lockup cause this kind of problem? If you ask me, no, not to a file that's not even open. Especially as I obsessively type "sync" before doing anything at all risky, but it seems I can't necessarily even trust sync to do its job. Go figure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Thu Jun 12 06:51:31 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Jun 2008 08:51:31 +0200 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> Message-ID: <1213253491.3951.48.camel@beck.corsepiu.local> On Wed, 2008-06-11 at 21:22 +0000, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > It's not wasted if you're expecting it to fail, but you don't know how it > > will fail. And I don't have a ppc box under my desk, mind you. > > You're rarely 100% sure that the build will fail. If there's even the slightest > chance that the build may succeed, it's a waste to issue it as a scratch build. Iff you have access to all architectures Fedora tries to support and iff Fedora repos were consistent (Which they often aren't) Ralf From valent.turkovic at gmail.com Thu Jun 12 07:36:39 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jun 2008 09:36:39 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1213203053.5747.20.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> <1213203053.5747.20.camel@localhost.localdomain> Message-ID: <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> On Wed, Jun 11, 2008 at 6:50 PM, Dan Williams wrote: > On Wed, 2008-06-11 at 13:19 +0200, Valent Turkovic wrote: >> On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: >> > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: >> >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: >> >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: >> >> [...] >> >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? >> >> > >> >> > Definitely in the next F9 update. >> >> >> >> Will this update contain my patch which allows people to uninstall >> >> NetworkManager without losing pidgin and evolution (bug #351101)? >> >> >> >> You never gave a good reason why this bug has been left unfixed >> >> for over half a year, especially when the solution is trivial. >> > >> > Can you try out >> > >> > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 >> > >> > when it gets done? >> > >> > Thanks, >> > Dan >> > >> >> Regards, >> >> R. >> >> >> >> -- >> >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski >> >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu >> >> "Faith manages." >> >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" >> >> >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> I tested NetworkManager via: >> yum --enablerepo=updates-testing update NetworkManager >> >> as you suggested in bugreport but I still see the same bug present. > > What's the output of: > > ls -al /etc/rc3.d/*Net* > > Dan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > ]# ls -al /etc/rc3.d/*Net* lrwxrwxrwx 1 root root 24 2008-04-24 09:44 /etc/rc3.d/S99NetworkManager -> ../init.d/NetworkManager -- 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 nigel.metheringham at dev.intechnology.co.uk Thu Jun 12 07:58:17 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 12 Jun 2008 08:58:17 +0100 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <484FE9EB.5090301@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> Message-ID: <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> On 11 Jun 2008, at 16:06, Dmitry Butskoy wrote: > Nigel Metheringham wrote: >> This looks good, but on a minimal system how many other packages >> would be pulled in as dependancies over the existing mailx? > For now, "openssl" (or "nss") and "krb5-libs". Is it OK for a minimal > system? Both of those ought to be on a system anyhow (openssh would need them). I was concerned that things like imap support could pull in a pile of other deps, but that sets my mind at rest wrt bloating the minimal install. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From kwade at redhat.com Thu Jun 12 08:12:47 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 12 Jun 2008 01:12:47 -0700 Subject: (no subject) In-Reply-To: <1213211097.16019.50.camel@cutter> References: <1213211097.16019.50.camel@cutter> Message-ID: <1213258367.3866.219.camel@calliope.phig.org> On Wed, 2008-06-11 at 15:04 -0400, seth vidal wrote: > All the plans are in public. If you want jboss packages in fedora I > think the best bet is to submit them. +1 The developers working on upstream at JBoss.org are not necessarily experienced packagers. Think of them like any upstream, although one with an obvious vested interest in being in Fedora. So, a way to proceed would be to approach the particular JBoss.org project(s) you want to see packaged and ask if they need any help, etc. (Please let me know if you run in to any problems with that.) - Karsten -- Karsten Wade, Sr. 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 nicolas.mailhot at laposte.net Thu Jun 12 08:15:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jun 2008 10:15:07 +0200 (CEST) Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <54750.192.54.193.53.1213198766.squirrel@rousalka.dyndns.org> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> <484FEB95.4040100@city-fan.org> <54750.192.54.193.53.1213198766.squirrel@rousalka.dyndns.org> Message-ID: <49332.192.54.193.53.1213258507.squirrel@rousalka.dyndns.org> Le Mer 11 juin 2008 17:39, Nicolas Mailhot a ?crit : > I really don't see why ocaml-json-static-0.9.6-3.fc8 can not be > created instead. Our tools allow the following workflow > > push foo-x-1.fc8 > push foo-x-1.fc9 > push foo-x-2.fc9 > push foo-x-2.fc8 > > There is zero reason why foo-x-2.fc8 can not be built after > foo-x-2.fc9 Also when you know you're going to iterate on past releases something like this works too push foo-x-1.1.0.fc8 push foo-x-1.1.0.fc9 push foo-x-2.1.0.fc9 push foo-x-2.0.1.fc8 push foo-x-2.0.2.fc8 push foo-x-2.0.3.fc8 push foo-x-2.0.4.fc8 push foo-x-2.1.0.fc8 (with the x.0.y.fcstable in testing only) -- Nicolas Mailhot From valent.turkovic at gmail.com Thu Jun 12 08:30:37 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jun 2008 10:30:37 +0200 Subject: Features that would be great for Fedora 10 Message-ID: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> Here are just few features that I believe would be great for Fedora 10 to have: 1. RFE: Add desktop folder with examples of what "fedora thing" can do :) https://bugzilla.redhat.com/show_bug.cgi?id=315171 Lisa gets Fedora 10 Live CD from her Joe (her geeky boyfriend) and puts it in her laptop. After she gets presented with a different looking desktop that she is usually presented she doesn't know what this "fedora thing" actually does and can do. Joe gives her a CD version of Ubuntu, after loosing temper with trying to explain what fedora can actually do. Lisa puts Ubuntu CD in and after few minutes she clicks through a few examples on her new desktop and sees that this "Ubuntu thing" does more that that "Fedora thing" like plays music & videos, shows nice spreadsheets and other documents. It would be great for Fedora to add directory on desktop with some nice examples what Fedora and OSS can do. There are great videos on redhat magazine page and I'm sure there are other great resources - new users need to be exposed to them in this way. Also there is a initiative for contriburots to make screencasts and this feature would be a great match with it if they merged together. 2. RFE: Desktop shortcut for joining Fedora IRC (aka "Get Live Help"): https://bugzilla.redhat.com/show_bug.cgi?id=430217 and https://bugzilla.redhat.com/show_bug.cgi?id=179703 Fedora is about freedom+communication, right? Why not make this statement more that just a nice slogan. If you installed sabayon linux you could experienced for yourself what this really means. I as a new user to gentoo (sabayon is based on gentoo) was really blown away with this feature. It is really, really simple to implement and gives a real meaning to a communication friendly linux distro. In sabayon link to their IRC chat has a simple name "Get Live Help" and it work fabulous! I didn't have any Portage experience so I poped in IRC chat room and was on my way after I got quick help. Whis kind of help was precious to me and would love to see it in fedora as one of it's main features and not just as a slogan. screenshot: http://www.flickr.com/photo_zoom.gne?id=382063978&size=l 3. Add abillity to define ntfs mount points in anaconda https://bugzilla.redhat.com/show_bug.cgi?id=430084 We can define ext3, reiserfs, xfs and vfat partition mount points in anaconda during the install but just ntfs. Cheers, 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 kwade at redhat.com Thu Jun 12 08:36:38 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 12 Jun 2008 01:36:38 -0700 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: References: <389552.959071213099076255.JavaMail.www@wwinf8402> Message-ID: <1213259798.3866.221.camel@calliope.phig.org> On Wed, 2008-06-11 at 14:42 +0000, Kevin Kofler wrote: > Nicolas Mailhot laposte.net> writes: > > So I'd like the authorization for interested groups to stop trying to use the > > tools the way they were not intended, kill the nested deep hierarchy mess and > > move pages to the wiki root. > > Sorry, but I really really don't like this idea. :-( > > I like how everything relevant to the KDE SIG is under SIGs/KDE, we know who's > responsible for those pages and we're sure not to trip on anybody else's page > names that way. I think the (directory) tree structure clearly indicates who's > reponsible for what, e.g. Packaging/* is FPC's domain, SIGs/KDE/* is KDE SIG's > domain etc. > > One big flat namespace works well for projects like Wikipedia where everything > is free for all, but in Fedora, we have subprojects, which should have their > own namespace. (Yes, everyone with a wiki account is free to edit pages in most > directories, but there's still one group which is responsible.) Mediawiki > namespaces such as KDE:Foo might work, but I don't think they were really > intended to be used in this way, AFAICT they're intended to represent special > pages such as Image:* or Talk:* instead. They also do not appear in the default search index. That is a main reason to be careful what we put there. I doubt we want to hide any of the content you are talking about. I'm not personally against the nested directory-like structure; it is similar to how my brain stores information, so I can recall wiki URLs and such fairly well. However, we used that structure in Moin for pragmatic reasons that should be reviewed in light of how MediaWiki works. We should review if that scheme is still as useful as before, and if it can be replaced with a better scheme. For example, if you put every KDE SIG page in the [[Category:KDE SIG]], you may have gained the exact same value as nesting page names (making it easy to find and maintain an area of the wiki). Plus you may have a new set of cool things you can do because of the categorization. There are other ways to designate that a group is sponsoring a certain page. One we discussed is a "badge" that says, "You are encouraged to edit this page to make it better; if you have any questions, please contact the page sponsors, the Fonts SIG." We want to encourage people to edit pages. Does having pages in nested namespace make people feel as if, "Packaging/Foo must be owned by Packaging, I better not touch this page"? Finally, there is the situation with the search index. One of the PITAs of Moin Moin search is that a keyword for the title is always expanded as if from a wildcard search. You get back a ton of pages, with the relevant one buried in the middle. If you guessed the wrong word, good luck in the page turning up. By having spaces in names, MediaWiki allows *us*, the thinking humans, the chunk the longstringofwords into something sensible. Maybe we're lucky and MediaWiki considers a '/' to be a chunk separator. But in my usage, I've found the MediaWiki search to be better, especially where it can find the actual word amongst the 13,000+ titles in the index. - Karsten -- Karsten Wade, Sr. 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 paul at city-fan.org Thu Jun 12 08:41:42 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 12 Jun 2008 09:41:42 +0100 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <1213259798.3866.221.camel@calliope.phig.org> References: <389552.959071213099076255.JavaMail.www@wwinf8402> <1213259798.3866.221.camel@calliope.phig.org> Message-ID: <4850E146.2020609@city-fan.org> Karsten 'quaid' Wade wrote: > We want to encourage people to edit pages. Does having pages in nested > namespace make people feel as if, "Packaging/Foo must be owned by > Packaging, I better not touch this page"? Unfortunate example. At least on the old wiki, Packaging/* had ACLs preventing anybody outside the packaging committee from making changes there, and if that's not the case in the new wiki, that's probably not by design. Paul. From loupgaroublond at gmail.com Thu Jun 12 08:46:35 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 12 Jun 2008 10:46:35 +0200 Subject: Features that would be great for Fedora 10 In-Reply-To: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> Message-ID: <7f692fec0806120146r3fe63f88gf568d9049b7b558b@mail.gmail.com> On Thu, Jun 12, 2008 at 10:30 AM, Valent Turkovic wrote: > Here are just few features that I believe would be great for Fedora 10 to have: > > 1. RFE: Add desktop folder with examples of what "fedora thing" can do :) > https://bugzilla.redhat.com/show_bug.cgi?id=315171 > > Lisa gets Fedora 10 Live CD from her Joe (her geeky boyfriend) and > puts it in her laptop. After she gets presented with a different > looking desktop that > she is usually presented she doesn't know what this "fedora thing" > actually does and can do. Joe gives her a CD version of Ubuntu, after > loosing temper with trying to explain what fedora can actually do. > Lisa puts Ubuntu CD in and after few minutes she clicks through a few > examples on her new desktop and sees that this "Ubuntu thing" does > more that that "Fedora thing" like plays music & videos, shows nice > spreadsheets and other documents. > > It would be great for Fedora to add directory on desktop with some > nice examples what Fedora and OSS can do. There are great videos on > redhat magazine page and I'm sure there are other great resources - > new users need to be exposed to them in this way. Also there is a > initiative for contriburots to make screencasts and this feature would > be a great match with it if they merged together. How about a welcome screen that pops up everytime you boot up, with an obnoxious shortcut to it in the top of our 'go' menu. No matter how many times you 'disable this the next time it boots', it still nags you to install aMSN. I think a folder might not be the best interface, but even so, putting in a default bookmarks like we do already is not really effective either. Maybe this is something the myFedora guys might want to look at at some point. -Yaakov From dwmw2 at infradead.org Thu Jun 12 09:00:01 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jun 2008 10:00:01 +0100 Subject: Need help with clisp on ppc In-Reply-To: <1213217853.1514.4.camel@localhost.localdomain> References: <1213200112.1514.2.camel@localhost.localdomain> <20080611102155.1c162d94@ohm.scrye.com> <1213217853.1514.4.camel@localhost.localdomain> Message-ID: <1213261202.26255.122.camel@pmac.infradead.org> On Wed, 2008-06-11 at 22:57 +0200, G?rard Milmeister wrote: > On Wed, 2008-06-11 at 10:21 -0600, Kevin Fenzi wrote: > > If you send me a ssh key I would be happy to make you an account so > > you could investigate. Or if there is anyone else in the cvsextras > > group who wants to look, I would be happy to get them access as well. > I would rather have somebody with ppc experience look at it. I'll take a look at it, if nobody else has, just as soon as I'm done with bug 450790 -- which is confusing the hell out of me, since we seem to be crashing in a certain function without actually hitting the breakpoint at the beginning of that function. Although if I build with -finstrument-functions I _see_ the call to __cyg_profile_func_enter() when we enter the damn function. Now I'm starting to suspect gdb is toying with me... -- dwmw2 From tim.lauridsen at googlemail.com Thu Jun 12 09:16:12 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Thu, 12 Jun 2008 11:16:12 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <484FAF26.3090002@gmail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> <484FAF26.3090002@gmail.com> Message-ID: <4850E95C.8040707@googlemail.com> Toshio Kuratomi wrote: > Matej Cepl wrote: >> On 2008-06-09, 16:56 GMT, Toshio Kuratomi wrote: >>> 1) Fedora 10 ships with the latest python-2.5.x. >>> 2) The Fedora 11 development tree switches to python-2.6.x soon after=20 >>> F10 is released. >> >> Well, aren't we early enough in the F10 Rawhide to do it now instead >> of waiting six months? >> > It's Geppetto's call but one drawback of switching now is it could mean > shipping a non-release python-2.6 in F10 if the python release date > slips. Here's python.org's schedule: > > Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned > Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned > Sep 03 2008: Python 2.6 and 3.0 final > > Here's our tentative schedule: > Aug 19 2008: Feature Freeze > Sep 30 2008: Final devel freeze > Oct 10 2008: Preview release > Oct 28 2008: Final release > > Another drawback is that since we have so many programs that we code > which are dependent on python, this would mean we'd have less time to > test that yum or anaconda, for instance, worked with all the new python > code before the release. ie: More moving parts later in the cycle. > > The pro sides would be: > 1) We could include code that is written to run on 3.x/2.6's 3.x compat > layer. (I haven't run across any code that only targets 3.x yet.) > > 2) We and our users can get started on ports of code and experimenting > with 3.x/2.6 features sooner. (Not sure how helpful this is for us as > we're not likely to want to port until, at least, the py-2.6 release > candidate (otherwise something could still change on us.) For users, it > does mean that they'll be able to use F10 as a base for porting their > apps.) > > -Toshio > As a python programmer, i would love to play with new python features, and hopefully it will make life easier for the current unicode nightmare in python when working with i18n, but as a yum contributor, i also see the potential upgrade nightmare a switch to a non backwards compatibility version of python and for anaconda there will also be a lot of problems and all the other python stuff, it will need a lot of work to make the code work with python 3.0, without any benefit than running the latest & greatest, over time there will befits (i hpoe ). The only safe way i can see is to have to 2 python stacks 2.5 & 3.0 for a while, i know it sucks, but in this case, it will make the transition much smoother without breaking every python program out there. SO my proposal will be: F10: python 2.5 (primary) python 3.0 (secondary) F11: python 3.0 (primary) python 2.5 (secondary) F12: python 3.0 (primary) Python 2.6 will only introduce an extra step in transformation 2.5 -> 2.6 -> 3.0, so it only fit if we what a very slow transformation into 3.0 and want to run 2.6 for a 2-4 fedora releases, before switching to 3.0. Let me now know if it sound totally insane :) Tim Tim From mcepl at redhat.com Thu Jun 12 09:36:06 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 12 Jun 2008 11:36:06 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> <484FAF26.3090002@gmail.com> <4850E95C.8040707@googlemail.com> Message-ID: <6977i5xsds.ln2@ppp1053.in.ipex.cz> On 2008-06-12, 09:16 GMT, Tim Lauridsen wrote: > also see the potential upgrade nightmare a switch to a non > backwards compatibility version of python and for anaconda Am I totally wrong when I think that 2.6 should be 100% backward compatible with 2.5 (unless explicitly requested in the python script itself and even then it should just emit DepreceatedWarnings)? Mat?j From rawhide at fedoraproject.org Thu Jun 12 09:51:36 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 12 Jun 2008 09:51:36 +0000 (UTC) Subject: rawhide report: 20080612 changes Message-ID: <20080612095137.02253209D0F@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080611/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080612/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package lxtask Lightweight and desktop independent task manager New package perl-XML-Smart Implementation of XML parser and writer for Perl New package python-yenc yEnc Module for Python New package xfbib Lightweight BibTeX editor for the Xfce desktop environment Updated Packages: NetworkManager-0.7.0-0.10.svn3747.fc10 -------------------------------------- * Wed Jun 11 18:00:00 2008 Dan Williams - 1:0.7.0-0.10.svn3747 - Update to latest SVN - Enable connection sharing - Respect VPN-provided routes PackageKit-0.2.3-3.20080611.fc10 -------------------------------- * Wed Jun 11 18:00:00 2008 Richard Hughes - 0.2.3-3.20080611 - Pull in a new snapshot from the unstable branch. - Fixes RH#450594 where there are insane length error messages - Get the group for the package when we do ::Detail() akonadi-0.81.0-0.2.20080526svn812787.fc10 ----------------------------------------- * Tue Jun 3 18:00:00 2008 Kevin Kofler 0.81.0-0.2.20080526svn812787 - BR automoc, drop automoc hack amarok-1.4.9.1-4.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Dennis Gilmore - 1.4.9.1-4 - we are building sparc32 as sparcv9 not sparc now fix ifnarch busybox-1.10.3-1.fc10 --------------------- * Tue Jun 10 18:00:00 2008 Ivana Varekova - 1:1.10.3-1 - update to 1.10.3 cairo-dock-1.6.0-0.2.svn1089_trunk.fc10 --------------------------------------- compiz-0.7.6-5.fc10 ------------------- * Wed Jun 11 18:00:00 2008 Adel Gadllah - 0.7.6-5 - Revert to old gconf schmema install script compiz-fusion-0.7.6-3.fc10 -------------------------- * Wed Jun 11 18:00:00 2008 Adel Gadllah 0.7.6-3 - Revert to old gconf schmema install script compiz-fusion-extras-0.7.6-3.fc10 --------------------------------- * Wed Jun 11 18:00:00 2008 Adel Gadllah 0.7.6-3 - Revert to old gconf schmema install script cpdup-1.11-2.fc10 ----------------- * Wed Jun 11 18:00:00 2008 Michel Alexandre Salim - 1.11-2 - Fix build problems with GLIBC on 64-bit archs ds9-5.2-4.fc10 -------------- * Wed Jun 11 18:00:00 2008 Sergio Pascual - 5.2-4 - Removing dependency in etags * Wed Jun 11 18:00:00 2008 Sergio Pascual - 5.2-3 - Using tkcon fatsort-0.9.8.2-1.fc10 ---------------------- * Wed Jun 11 18:00:00 2008 Till Maas - 0.9.8.2-1 - New upstream release * Wed Jun 11 18:00:00 2008 Till Maas - 0.9.8.1-1 - New upstream release * Mon Jun 9 18:00:00 2008 Till Maas - 0.9.8-1 - New upstream release - move install to Makefile/patch - ChangeLog is now CHANGES - Disable stripping in Makefile gnokii-0.6.26-1.fc10 -------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 0.6.26-1 - Update to 0.6.26 gnome-packagekit-0.2.3-3.20080611.fc10 -------------------------------------- * Wed Jun 11 18:00:00 2008 Richard Hughes - 0.2.3-3.20080611 - Pull in a new snapshot from the unstable branch. - New interface for gpk-application - one that doesn't suck - UI fixes for gpk-repo and gpk-update-viewer gnome-phone-manager-0.60-1.fc10 ------------------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 0.60-1 - Update to 0.60 - Remove vendor from desktop file gnome-python2-desktop-2.22.0-6.fc10 ----------------------------------- * Wed Jun 11 18:00:00 2008 Matthew Barnes - 2.22.0-6.fc10 - Don't drag in devel packages when installing gnome-python2-evolution (RH bug #450932). gvfs-0.99.1-1.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Matthias Clasen - 0.99.1-1 - Update to 0.99.1 hamster-applet-0.6.1-1.fc10 --------------------------- * Wed Jun 11 18:00:00 2008 Mads Villadsen - 0.6.1-1 - Update to latest upstream release - Not stealing middle-click to move applet - Correct label orientation on vertical panels - Fixed fact pushing on overlap * Mon Jun 9 18:00:00 2008 Mads Villadsen - 0.6-1 - Update to latest upstream release - Simple reporting via Overview dialog ipython-0.8.4-1.fc10 -------------------- * Wed Jun 11 18:00:00 2008 James Bowes 0.8.4-1 - Update to 0.8.4 keepassx-0.3.1-1.fc10 --------------------- kernel-2.6.26-0.61.rc5.git5.fc10 -------------------------------- * Wed Jun 11 18:00:00 2008 Eric Paris - allow things like restorecon to read invalid labels from the disk * Wed Jun 11 18:00:00 2008 Dave Jones - 2.6.26-rc5-git5 * Tue Jun 10 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-06-09 (http://marc.info/?l=linux-kernel&m=121304710726632&w=2) * Tue Jun 10 18:00:00 2008 Dave Jones - 2.6.26-rc5-git4 kexec-tools-1.102pre-12.fc10 ---------------------------- * Wed Jun 11 18:00:00 2008 Neil Horman - 1.102pre-12 - Added lvm to bin list (bz 443878) less-423-1.fc10 --------------- * Wed Jun 11 18:00:00 2008 Zdenek Prikryl - 423-1 - Update to 423 libHX-1.18-1.fc10 ----------------- * Wed Jun 11 18:00:00 2008 Till Maas - 1.18-1 - Update to latest version libcgroup-0.1c-1.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Dhaval Giani 0.1c-1 - Update to latest upstream libsepol-2.0.30-1.fc10 ---------------------- * Wed Jun 11 18:00:00 2008 Dan Walsh 2.0.30-1 - Upgrade to latest from NSA * Fix endianness bug in the handling of network node addresses from Stephen Smalley. Only affects big endian platforms. Bug reported by John Weeks of Sun upon policy mismatch between x86 and sparc. m2crypto-0.18.2-7 ----------------- * Wed Jun 11 18:00:00 2008 Miloslav Trma?? - 0.18.2-7 - Update m2urllib2 to match the Python 2.5 code instead man-pages-2.80-2.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Ivana Varekova - 2.80-2 - reformulate the malloc_hook patch nntpgrab-0.3.1-2.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Erik van Pienbroek - 0.3.1-2 - Added BR: intltool * Wed Jun 11 18:00:00 2008 Erik van Pienbroek - 0.3.1-1 - Update to version 0.3.1 openoffice.org-3.0.0-0.0.19.1.fc10 ---------------------------------- * Wed Jun 11 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.19-1 - next version - add openoffice.org-3.0.0.ooo90612.sd.insertpasswordedfile.patch pam_mount-0.40-1.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Till Maas - 0.40-1 - Update to new version - set make variable V for full compiler commandline * Mon May 5 18:00:00 2008 Till Maas - 0.35-1 - Update to new version - Use $RPM_BUILD_ROOT instead of %{buildroot} - Update description - create and own %{_localstatedir}/run/pam_mount * Sun Feb 24 17:00:00 2008 Till Maas - 0.33-1 - update to new version perl-Unicode-Map-0.112-15.fc10 ------------------------------ * Thu Jun 5 18:00:00 2008 Aurelien Bompard 0.112-15 - fix build perl-Unicode-MapUTF8-1.11-8.fc10 -------------------------------- * Wed May 21 18:00:00 2008 Paul Howarth 1.11-8 - rebuild for Fedora 9 (#447921) - add buildreqs Test::More, Test::Pod, Test::Pod::Coverage, and Test::Distribution for better test coverage * Thu Dec 6 17:00:00 2007 Paul Howarth 1.11-7 - simplify package build in line with perl spec template - no need to define %{perl_vendorlib} - refactor buildreqs to support build on EL4/5 - mark pod as %doc - use %{version} macro in source URL policycoreutils-2.0.49-4.fc10 ----------------------------- * Wed Jun 11 18:00:00 2008 Dan Walsh 2.0.49-4 - Add semanage permissive * postgresql-8.3.3-1.fc10 ----------------------- * Wed Jun 11 18:00:00 2008 Tom Lane 8.3.3-1 - Update to PostgreSQL 8.3.3. - Remove postgresql-prefer-ncurses.patch, no longer needed in recent Fedora releases because libtermcap is gone. psi-0.11-5.fc10 --------------- * Wed May 21 18:00:00 2008 Tom "spot" Callaway 0.11-5 - fix license tag python-vobject-0.6.6-1.fc10 --------------------------- * Wed Jun 11 18:00:00 2008 James Bowes - 0.6.6-1 - Update to 0.6.6 qca-gnupg-2.0.0-0.2.beta1.fc10 ------------------------------ qca-ossl-2.0.0-0.4.beta3.fc10 ----------------------------- qemu-0.9.1-9.fc10 ----------------- * Wed Jun 11 18:00:00 2008 Daniel P. Berrange - 0.9.1-9.fc10 - Remove bogus wildcard from files list (rhbz #450701) qgtkstyle-0.0-0.1.20080609svn648.fc10 ------------------------------------- * Mon Jun 9 18:00:00 2008 Shawn Starr 0.0-0.1.20080609svn647 - New upstream snapshot, refactoring of gtkstyle - Fix editable combobox, fix menu, dialog checkbox size and shapes - Improved sliders - Fix pixmap cache regressions * Mon Jun 2 18:00:00 2008 Shawn Starr 0.0-0.1.20080601svn636 - New upstream snapshot, Fix endian issues - Check boxes and menu optimizations, fix tabbing issues - Improved tab bar - Fix toolbars and frames with flat-style - Improved toolbar handles * Thu May 29 18:00:00 2008 Shawn Starr 0.0-0.1.20080529svn626 - New upstream snapshot, Improved menu separators - Fix menu separator height, fix paint glitches with comboboxes. qt-4.4.0-6.fc10 --------------- quagga-0.99.10-1.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Martin Nagy - 0.99.10-1 - upgrade to new upstream 0.99.10 samba-3.2.0-1.rc2.16.fc10 ------------------------- * Tue Jun 10 18:00:00 2008 Guenther Deschner - 3.2.0-1.rc2.16 - Update to 3.2.0rc2 - resolves: #449522 - resolves: #448107 * Fri May 30 18:00:00 2008 Guenther Deschner - 3.2.0-1.rc1.15 - Fix security=server - resolves: #449038, #449039 * Wed May 28 18:00:00 2008 Guenther Deschner - 3.2.0-1.rc1.14 - Add fix for CVE-2008-1105 - resolves: #446724 * Fri May 23 18:00:00 2008 Guenther Deschner - 3.2.0-1.rc1.13 - Update to 3.2.0rc1 * Wed May 21 18:00:00 2008 Simo Sorce - 3.2.0-1.pre3.12 - make it possible to print against Vista and XP SP3 as servers - resolves: #439154 * Thu May 15 18:00:00 2008 Guenther Deschner - 3.2.0-1.pre3.11 - Add "net ads join createcomputer=ou1/ou2/ou3" fix (BZO #5465) shared-mime-info-0.40-1.fc10 ---------------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 0.40-1 - Update to 0.40 system-config-firewall-1.2.9-1.fc10 ----------------------------------- * Wed Jun 11 18:00:00 2008 Thomas Woerner 1.2.9-1 - fixed format string to silence inttool - new remider to check if the ip*tables services are enabled - use proper dialog functions in the tui - updated translations: cs, de, es, gu, pl thunar-shares-0.12-1.fc10 ------------------------- * Thu Jun 12 18:00:00 2008 Christoph Wickert - 0.12-1 - Update to 0.12 tkcon-2.5-1.20080610cvs.fc10 ---------------------------- * Tue Jun 10 18:00:00 2008 Wart - 2.5-1.20080610cvs - Update to CVS head for ds9 (BZ #445879) totem-2.23.4-1.fc10 ------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 2.23.4-1 - Update to 2.23.4 - Remove gnome-vfs BRs - Remove xulrunner patches and requires, we don't need them anymore totem-pl-parser-2.23.2-1.fc10 ----------------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 2.23.2-1 - Update to 2.23.2 uudeview-0.5.20-17.fc10 ----------------------- * Wed Jun 11 18:00:00 2008 Adrian Reber - 0.5.20-17 - updated to newest debian patch - removed the other patches which are part of the debian patchset - fixes "uudeview fails to decode any files" (#447664) vym-1.10.0-4.fc10 ----------------- * Tue Jun 10 18:00:00 2008 Jon Ciesla - 1.10.0-4 - Added mime type xml, BZ434929. wpa_supplicant-0.6.3-6.fc10 --------------------------- * Tue Jun 10 18:00:00 2008 Dan Williams - 1:0.6.3-6 - Fix 802.11a frequency bug - Always schedule specific SSID scans to help find hidden APs - Properly switch between modes on mac80211 drivers - Give adhoc connections more time to assocate xfce4-places-plugin-1.1.0-1.fc10 -------------------------------- * Thu Jun 12 18:00:00 2008 Christoph Wickert - 1.1.0-1 - Update to 1.1.0 - Fix changelog Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 54 Broken deps for i386 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.i386 requires libtds.so.5 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 sepostgresql-8.3.1-2.197.fc10.i386 requires postgresql-server = 0:8.3.1 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.x86_64 requires libtds.so.5()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 sepostgresql-8.3.1-2.197.fc10.x86_64 requires postgresql-server = 0:8.3.1 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.ppc requires libtds.so.5 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 sepostgresql-8.3.1-2.197.fc10.ppc requires postgresql-server = 0:8.3.1 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- asterisk-tds-1.6.0-0.14.beta9.fc10.ppc64 requires libtds.so.5()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot sepostgresql-8.3.1-2.197.fc10.ppc64 requires postgresql-server = 0:8.3.1 smart-0.52-54.fc9.ppc64 requires smart-config From a.badger at gmail.com Thu Jun 12 10:42:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Jun 2008 06:42:06 -0400 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> Message-ID: <4850FD7E.903@gmail.com> Kevin Kofler wrote: > Toshio Kuratomi gmail.com> writes: >> The playing time is 74 minutes, or 4440 seconds, so that the >> net capacity of a Mode-1 CD-ROM is 682 MB.""" > > Uh, 74 minute CDs are completely obsolete, around here (Austria) they don't > even sell these anymore! 80 minute / 700 MB CDs are the standard size these > days, and those are what Fedora's live images are (and have always been) > designed to fit. > But not all drives can read 700MB from a CD. Those drives might be obsolete in the sense that you can't buy them on a new computer anymore but there's plenty of old hardware available where it could be a problem. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tim.lauridsen at googlemail.com Thu Jun 12 10:59:59 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Thu, 12 Jun 2008 12:59:59 +0200 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <6977i5xsds.ln2@ppp1053.in.ipex.cz> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> <484FAF26.3090002@gmail.com> <4850E95C.8040707@googlemail.com> <6977i5xsds.ln2@ppp1053.in.ipex.cz> Message-ID: <485101AF.7060200@googlemail.com> Matej Cepl wrote: > On 2008-06-12, 09:16 GMT, Tim Lauridsen wrote: >> also see the potential upgrade nightmare a switch to a non >> backwards compatibility version of python and for anaconda > > Am I totally wrong when I think that 2.6 should be 100% backward > compatible with 2.5 (unless explicitly requested in the python > script itself and even then it should just emit > DepreceatedWarnings)? > > Mat?j > Python will contain some forward 3.0 compability, i have not read any thing about 100% backwards compatibility. http://www.python.org/dev/peps/pep-3000/ but even if it is, then you will have to do a a python 2.5 to python 2.6 with (__future__) features to use some of the new stuff. and later you have to do a 2.6 with (__future__) features to python 3.0, because as they state in then pep-3000 There is no requirement that Python 2.6 code will run unmodified on Python 3.0 Tim From hughsient at gmail.com Thu Jun 12 11:09:10 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 12:09:10 +0100 Subject: PackageKit UI Message-ID: <1213268950.3505.1.camel@hughsie-work> Quite a few people are complaining about the user interface of the Add/Remove program in Fedora 9. This is correct, as I agree the UI interaction was pretty awful in the 0.1.x codebase. This was always going to be a stop-gap solution while we worked on the 0.2.x branch that supported all the sexy things that people wanted like proxy server support, multiple install (and remove) and proper key signing support. This is the current UI of gpk-application in git master (and rawhide from today): http://www.packagekit.org/temp/gpk-application.png It fixes most of the problems with PackageKit 0.1.x (other than the slowness [1]) and I'm hoping to get a build in F9 updates-testing sometime soon. The update viewer and the other tools have also seen some love too. Comments/suggestions welcome, Richard Hughes [1] ?we're still working on a new (much faster) yum backend From sundaram at fedoraproject.org Thu Jun 12 11:15:49 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Jun 2008 16:45:49 +0530 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <48510565.2090407@fedoraproject.org> Richard Hughes wrote: > Quite a few people are complaining about the user interface of the > Add/Remove program in Fedora 9. This is correct, as I agree the UI > interaction was pretty awful in the 0.1.x codebase. > > This was always going to be a stop-gap solution while we worked on the > 0.2.x branch that supported all the sexy things that people wanted like > proxy server support, multiple install (and remove) and proper key > signing support. > > This is the current UI of gpk-application in git master (and rawhide > from today): http://www.packagekit.org/temp/gpk-application.png > > It fixes most of the problems with PackageKit 0.1.x (other than the > slowness [1]) and I'm hoping to get a build in F9 updates-testing > sometime soon. The update viewer and the other tools have also seen some > love too. > > Comments/suggestions welcome, * Why are you not using the application icons in the left side instead of the right corner completely disconnected from the app itself? * What about group installation and removals? Rahul From berrange at redhat.com Thu Jun 12 11:17:38 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 12 Jun 2008 12:17:38 +0100 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <20080612111738.GC1921@redhat.com> On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > This is the current UI of gpk-application in git master (and rawhide > from today): http://www.packagekit.org/temp/gpk-application.png > > It fixes most of the problems with PackageKit 0.1.x (other than the > slowness [1]) and I'm hoping to get a build in F9 updates-testing > sometime soon. The update viewer and the other tools have also seen some > love too. > > Comments/suggestions welcome, In the bottom right corner where you display the license tag, make each named license into a hyperlink to the actual online text. Since we have a pretty well defined list of allowed licenses in Fedora, we ought to be able to identify the online URL for each. The main hard thing would likely be the BSD licenses for which there are sooo many subtle differences in the exact wording people use, even though they're all basically the same. > [1] ???we're still working on a new (much faster) yum backend Would that be the 'yum2' backend ? Or are you working on a 'yum3' backend... Daniel. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From a.badger at gmail.com Thu Jun 12 11:24:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Jun 2008 07:24:07 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <485101AF.7060200@googlemail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> <484FAF26.3090002@gmail.com> <4850E95C.8040707@googlemail.com> <6977i5xsds.ln2@ppp1053.in.ipex.cz> <485101AF.7060200@googlemail.com> Message-ID: <48510757.1060203@gmail.com> Tim Lauridsen wrote: > Matej Cepl wrote: >> On 2008-06-12, 09:16 GMT, Tim Lauridsen wrote: >>> also see the potential upgrade nightmare a switch to a non backwards >>> compatibility version of python and for anaconda >> >> Am I totally wrong when I think that 2.6 should be 100% backward >> compatible with 2.5 (unless explicitly requested in the python script >> itself and even then it should just emit DepreceatedWarnings)? >> >> Mat?j >> > > Python will contain some forward 3.0 compability, i have not read any > thing about 100% backwards compatibility. > > http://www.python.org/dev/peps/pep-3000/ > > but even if it is, then you will have to do a > > a python 2.5 to python 2.6 with (__future__) features to use some of the > new stuff. > and later you have to do a 2.6 with (__future__) features to python 3.0, > because as they state in then pep-3000 > > > There is no requirement that Python 2.6 code will run unmodified on > Python 3.0 > Quoting myself: * 2.6 appears to be mostly compatible with 2.5.x. Porting from 2.5.x to 2.6.x seems like it will be pretty routine stuff. * 2.6 seems to be mostly compatible with 3.0 if you use from __future__ import all-the-stuff-that-changed. * It appears that we can mix these with file-level granularity. If this works out we should be able to port individual modules to 3.0 syntax while other modules stay on 2.x. So there will be issues that require porting between 2.5 <=> 2.6 and 2.6 <=> 3.0. But it seems like most constructs of either python2 or python3 will work on python 2.6. Here's a project that explores the incompatibilities between 2.6 and 3.0 (although the author hasn't looked at both forward and backwards compatibility so he's a little over optimistic. http://code.google.com/p/python-incompatibility/ For a summary of what he's found read: http://python-incompatibility.googlecode.com/svn/trunk/README.txt -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tim.lauridsen at googlemail.com Thu Jun 12 11:21:38 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Thu, 12 Jun 2008 13:21:38 +0200 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <485106C2.3090907@googlemail.com> Richard Hughes wrote: > Quite a few people are complaining about the user interface of the > Add/Remove program in Fedora 9. This is correct, as I agree the UI > interaction was pretty awful in the 0.1.x codebase. > > This was always going to be a stop-gap solution while we worked on the > 0.2.x branch that supported all the sexy things that people wanted like > proxy server support, multiple install (and remove) and proper key > signing support. > > This is the current UI of gpk-application in git master (and rawhide > from today): http://www.packagekit.org/temp/gpk-application.png > > It fixes most of the problems with PackageKit 0.1.x (other than the > slowness [1]) and I'm hoping to get a build in F9 updates-testing > sometime soon. The update viewer and the other tools have also seen some > love too. > > Comments/suggestions welcome, > Look better, but maybe to wide for lower resolution like 800x600. A little 'Left Margin' in the description textview, will make the text more readable. The 'icon" in the right corner looks a little misplaced. use it in package view instead. When using different searches and selecting multiple packages, the should be an easy way to see what packages there is currently selected (in queue), maybe adding a 'Selected Packages" under 'All packages' should do it. Tim Tim From dcbw at redhat.com Thu Jun 12 11:33:02 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 12 Jun 2008 07:33:02 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212321464.25062.2.camel@localhost.localdomain> <4846475E.5040804@gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> <1213203053.5747.20.camel@localhost.localdomain> <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> Message-ID: <1213270382.1469.15.camel@localhost.localdomain> On Thu, 2008-06-12 at 09:36 +0200, Valent Turkovic wrote: > On Wed, Jun 11, 2008 at 6:50 PM, Dan Williams wrote: > > On Wed, 2008-06-11 at 13:19 +0200, Valent Turkovic wrote: > >> On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: > >> > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > >> >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > >> >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > >> >> [...] > >> >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > >> >> > > >> >> > Definitely in the next F9 update. > >> >> > >> >> Will this update contain my patch which allows people to uninstall > >> >> NetworkManager without losing pidgin and evolution (bug #351101)? > >> >> > >> >> You never gave a good reason why this bug has been left unfixed > >> >> for over half a year, especially when the solution is trivial. > >> > > >> > Can you try out > >> > > >> > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 > >> > > >> > when it gets done? > >> > > >> > Thanks, > >> > Dan > >> > > >> >> Regards, > >> >> R. > >> >> > >> >> -- > >> >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski > >> >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > >> >> "Faith manages." > >> >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > >> >> > >> > > >> > -- > >> > fedora-devel-list mailing list > >> > fedora-devel-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> > > >> > >> > >> I tested NetworkManager via: > >> yum --enablerepo=updates-testing update NetworkManager > >> > >> as you suggested in bugreport but I still see the same bug present. > > > > What's the output of: > > > > ls -al /etc/rc3.d/*Net* > > > > Dan > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > ]# ls -al /etc/rc3.d/*Net* > lrwxrwxrwx 1 root root 24 2008-04-24 09:44 > /etc/rc3.d/S99NetworkManager -> ../init.d/NetworkManager Ok, so the even though NM and dbus have resetpriorities in their specfile, it may be that HAL doesn't. You'll want to do the following as a workaround: chkconfig messagebus resetpriorities chkconfig haldaemon resetpriorities chkconfig NetworkManager resetpriorities and then messagebus should be at 22, NM at 27, and hal wherever. Dan From valent.turkovic at gmail.com Thu Jun 12 12:01:28 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jun 2008 14:01:28 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: <1213270382.1469.15.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> <1213203053.5747.20.camel@localhost.localdomain> <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> <1213270382.1469.15.camel@localhost.localdomain> Message-ID: <64b14b300806120501i26504353ic2a0b73d0faace4e@mail.gmail.com> On Thu, Jun 12, 2008 at 1:33 PM, Dan Williams wrote: > On Thu, 2008-06-12 at 09:36 +0200, Valent Turkovic wrote: >> On Wed, Jun 11, 2008 at 6:50 PM, Dan Williams wrote: >> > On Wed, 2008-06-11 at 13:19 +0200, Valent Turkovic wrote: >> >> On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: >> >> > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: >> >> >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: >> >> >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: >> >> >> [...] >> >> >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? >> >> >> > >> >> >> > Definitely in the next F9 update. >> >> >> >> >> >> Will this update contain my patch which allows people to uninstall >> >> >> NetworkManager without losing pidgin and evolution (bug #351101)? >> >> >> >> >> >> You never gave a good reason why this bug has been left unfixed >> >> >> for over half a year, especially when the solution is trivial. >> >> > >> >> > Can you try out >> >> > >> >> > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 >> >> > >> >> > when it gets done? >> >> > >> >> > Thanks, >> >> > Dan >> >> > >> >> >> Regards, >> >> >> R. >> >> >> >> >> >> -- >> >> >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski >> >> >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu >> >> >> "Faith manages." >> >> >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" >> >> >> >> >> > >> >> > -- >> >> > fedora-devel-list mailing list >> >> > fedora-devel-list at redhat.com >> >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > >> >> >> >> >> >> I tested NetworkManager via: >> >> yum --enablerepo=updates-testing update NetworkManager >> >> >> >> as you suggested in bugreport but I still see the same bug present. >> > >> > What's the output of: >> > >> > ls -al /etc/rc3.d/*Net* >> > >> > Dan >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> ]# ls -al /etc/rc3.d/*Net* >> lrwxrwxrwx 1 root root 24 2008-04-24 09:44 >> /etc/rc3.d/S99NetworkManager -> ../init.d/NetworkManager > > Ok, so the even though NM and dbus have resetpriorities in their > specfile, it may be that HAL doesn't. You'll want to do the following > as a workaround: > > chkconfig messagebus resetpriorities > chkconfig haldaemon resetpriorities > chkconfig NetworkManager resetpriorities > > and then messagebus should be at 22, NM at 27, and hal wherever. > > Dan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I did that and now NM is 27 and netfs is 25 # ls -al /etc/rc3.d/*Net* lrwxrwxrwx 1 root root 24 2008-06-12 13:58 /etc/rc3.d/S27NetworkManager -> ../init.d/NetworkManager I'm at work and will report back when I come home because at home. Cheers, 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 hughsient at gmail.com Thu Jun 12 12:13:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 13:13:36 +0100 Subject: PackageKit UI In-Reply-To: <20080612111738.GC1921@redhat.com> References: <1213268950.3505.1.camel@hughsie-work> <20080612111738.GC1921@redhat.com> Message-ID: <1213272816.6436.14.camel@hughsie-work> On Thu, 2008-06-12 at 12:17 +0100, Daniel P. Berrange wrote: > On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > > This is the current UI of gpk-application in git master (and rawhide > > from today): http://www.packagekit.org/temp/gpk-application.png > > > > It fixes most of the problems with PackageKit 0.1.x (other than the > > slowness [1]) and I'm hoping to get a build in F9 updates-testing > > sometime soon. The update viewer and the other tools have also seen some > > love too. > > > > Comments/suggestions welcome, > > In the bottom right corner where you display the license tag, make each > named license into a hyperlink to the actual online text. Since we have > a pretty well defined list of allowed licenses in Fedora, we ought to be > able to identify the online URL for each. The main hard thing would likely > be the BSD licenses for which there are sooo many subtle differences in > the exact wording people use, even though they're all basically the same. Yes, and PackageKit supports licence texts that can be quite complicated, or where packages have two alternate licences. A link isn't so easy. > > [1] ???we're still working on a new (much faster) yum backend > > Would that be the 'yum2' backend ? Or are you working on a 'yum3' backend... yum2 - it's not quite ready for primetime but you can experiment by editing the PackageKit.conf configuration file. If it breaks, you get to keep both pieces :-) Richard. From wolfy at nobugconsulting.ro Thu Jun 12 12:34:19 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 12 Jun 2008 15:34:19 +0300 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: <4850FD7E.903@gmail.com> References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> <4850FD7E.903@gmail.com> Message-ID: <485117CB.1070504@nobugconsulting.ro> Toshio Kuratomi wrote: > Kevin Kofler wrote: >> Toshio Kuratomi gmail.com> writes: >>> The playing time is 74 minutes, or 4440 seconds, so that the net >>> capacity of a Mode-1 CD-ROM is 682 MB.""" >> >> Uh, 74 minute CDs are completely obsolete, around here (Austria) they >> don't even sell these anymore! 80 minute / 700 MB CDs are the >> standard size these days, and those are what Fedora's live images are >> (and have always been) designed to fit. >> > But not all drives can read 700MB from a CD. Those drives might be > obsolete in the sense that you can't buy them on a new computer > anymore but there's plenty of old hardware available where it could be > a problem. I haven't seen yet a disk drive unit manufactured in the last 6 years which is still functional but is unable to read 700 MB disks. Actually I do not remember of ANY unit manufactured this century and unable to read 700 MB disks. From hughsient at gmail.com Thu Jun 12 12:33:03 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 13:33:03 +0100 Subject: PackageKit UI In-Reply-To: <48510565.2090407@fedoraproject.org> References: <1213268950.3505.1.camel@hughsie-work> <48510565.2090407@fedoraproject.org> Message-ID: <1213273983.3968.1.camel@hughsie-work> On Thu, 2008-06-12 at 16:45 +0530, Rahul Sundaram wrote: > * Why are you not using the application icons in the left side > instead > of the right corner completely disconnected from the app itself? The icons in the list change as you select them, for instance a trash icon is overlaid when it's to be deleted. There's also a non-trivial cost of looking up each themed icon which can slow the GUI down a lot. > * What about group installation and removals? Still in the planning state, I've yet to find a good UI for any of this. Yell if you can think of a good one. Richard. From sundaram at fedoraproject.org Thu Jun 12 12:41:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Jun 2008 18:11:54 +0530 Subject: PackageKit UI In-Reply-To: <1213273983.3968.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <48510565.2090407@fedoraproject.org> <1213273983.3968.1.camel@hughsie-work> Message-ID: <48511992.9040806@fedoraproject.org> Richard Hughes wrote: > On Thu, 2008-06-12 at 16:45 +0530, Rahul Sundaram wrote: >> * Why are you not using the application icons in the left side >> instead >> of the right corner completely disconnected from the app itself? > > The icons in the list change as you select them, for instance a trash > icon is overlaid when it's to be deleted. There's also a non-trivial > cost of looking up each themed icon which can slow the GUI down a lot. Can that be done async? > >> * What about group installation and removals? > > Still in the planning state, I've yet to find a good UI for any of this. > Yell if you can think of a good one. Pirut did it in the context menu and providing a button when you click on a group. You might want to check that out. Rahul From hughsient at gmail.com Thu Jun 12 13:01:58 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 14:01:58 +0100 Subject: PackageKit UI In-Reply-To: <48511992.9040806@fedoraproject.org> References: <1213268950.3505.1.camel@hughsie-work> <48510565.2090407@fedoraproject.org> <1213273983.3968.1.camel@hughsie-work> <48511992.9040806@fedoraproject.org> Message-ID: <1213275718.3968.3.camel@hughsie-work> On Thu, 2008-06-12 at 18:11 +0530, Rahul Sundaram wrote: > Richard Hughes wrote: > > On Thu, 2008-06-12 at 16:45 +0530, Rahul Sundaram wrote: > >> * Why are you not using the application icons in the left side > >> instead > >> of the right corner completely disconnected from the app itself? > > > > The icons in the list change as you select them, for instance a trash > > icon is overlaid when it's to be deleted. There's also a non-trivial > > cost of looking up each themed icon which can slow the GUI down a lot. > > Can that be done async? Ohh, I guess so, yes. > >> * What about group installation and removals? > > > > Still in the planning state, I've yet to find a good UI for any of this. > > Yell if you can think of a good one. > > Pirut did it in the context menu and providing a button when you click > on a group. You might want to check that out. Yes, I've checked it out and it didn't seem very obvious to me - it also ties PackageKit into the native comps mapping which it already maps to more abstract groups. Richard. From galibert at pobox.com Thu Jun 12 13:09:42 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 12 Jun 2008 15:09:42 +0200 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <20080612130942.GA59280@dspnet.fr.eu.org> On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > Comments/suggestions welcome, What are your use cases? Do you have any? How do you handle the use case "I need something to type a letter, what can I install for that, what are my choices?". How do you handle the use case "I want my desktop to look cooler, what can I add?". How do you handle the use case "I need some free space, what can I remove?". What information does the opened/closed box icon give, apart from "we have good graphists"? Why do you present multiple versions of the same thing (compiz-gnome in your screenshot), especially as is they were different? Why is the ordering done on the less visible, bottom text? And a detail, Hompage -> Homepage. OG. From valent.turkovic at gmail.com Thu Jun 12 13:11:09 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jun 2008 15:11:09 +0200 Subject: selinux and unmount errors Message-ID: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> I have tested unmounting usb flash stick on 3 laptops with Fedora 9 and on all of them I get selinux alerts during unmount. Also first time I try to unmount I get selinux to prevent it from unmounting! Only second time I try to unmount that unmount succeeds. https://bugzilla.redhat.com/show_bug.cgi?id=450055 Cheers, 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 hughsient at gmail.com Thu Jun 12 13:22:17 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 14:22:17 +0100 Subject: PackageKit UI In-Reply-To: <20080612130942.GA59280@dspnet.fr.eu.org> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> Message-ID: <1213276937.3968.7.camel@hughsie-work> On Thu, 2008-06-12 at 15:09 +0200, Olivier Galibert wrote: > On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > > Comments/suggestions welcome, > > What are your use cases? Do you have any? Lots, see www.packagekit.org. > How do you handle the use case "I need something to type a letter, > what can I install for that, what are my choices?". > How do you handle the use case "I want my desktop to look cooler, what > can I add?". > How do you handle the use case "I need some free space, what can I > remove?". We are prototyping something web-based for this sort of thing. We'll be announcing stuff soon (if it works), I promise. > What information does the opened/closed box icon give, apart from "we > have good graphists"? Open = installed, closed = not installed. The icons also change if you select them to be added or removed. > Why do you present multiple versions of the same thing (compiz-gnome > in your screenshot), especially as is they were different? Ahh, it shows there is an update available. Maybe we need to expose this clearer. > Why is the ordering done on the less visible, bottom text? > > And a detail, Hompage -> Homepage. Ohh, yes, thanks. Richard. From galibert at pobox.com Thu Jun 12 13:41:19 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 12 Jun 2008 15:41:19 +0200 Subject: PackageKit UI In-Reply-To: <1213276937.3968.7.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> Message-ID: <20080612134119.GA64415@dspnet.fr.eu.org> On Thu, Jun 12, 2008 at 02:22:17PM +0100, Richard Hughes wrote: > On Thu, 2008-06-12 at 15:09 +0200, Olivier Galibert wrote: > > On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > > > Comments/suggestions welcome, > > > > What are your use cases? Do you have any? > > Lots, see www.packagekit.org. I may be a tad dense, but I can't find them there. > > How do you handle the use case "I need something to type a letter, > > what can I install for that, what are my choices?". > > How do you handle the use case "I want my desktop to look cooler, what > > can I add?". > > How do you handle the use case "I need some free space, what can I > > remove?". > > We are prototyping something web-based for this sort of thing. We'll be > announcing stuff soon (if it works), I promise. Good. Then, what is your interface for, other than placating those who think they can't survive if they can't point and drool and consider that typing "yum install stuff" is way too complex? > > What information does the opened/closed box icon give, apart from "we > > have good graphists"? > > Open = installed, closed = not installed. The icons also change if you > select them to be added or removed. That's, errr, non-obvious. At all. I don't see how an icon can convey that kind of thing in an obvious way, to be honest. A word+color code combination would probably be better. And you probably need to have filters like "show installed", "show updates", etc directly clickable in the window instead of tucked in a menu. Color the appropriate words in the filter name with the same color than the indicator in the array and you're probably golden. > > Why do you present multiple versions of the same thing (compiz-gnome > > in your screenshot), especially as is they were different? > > Ahh, it shows there is an update available. Maybe we need to expose this > clearer. Ohhhh yes you do. OG. From dwalsh at redhat.com Thu Jun 12 13:42:48 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 12 Jun 2008 09:42:48 -0400 Subject: selinux and unmount errors In-Reply-To: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> References: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> Message-ID: <485127D8.30402@redhat.com> Valent Turkovic wrote: > I have tested unmounting usb flash stick on 3 laptops with Fedora 9 > and on all of them I get selinux alerts during unmount. Also first > time I try to unmount I get selinux to prevent it from unmounting! > Only second time I try to unmount that unmount succeeds. > > https://bugzilla.redhat.com/show_bug.cgi?id=450055 > > Cheers, > Valent. > > This is a leaked file descriptor problem with Hal. It has been reported, a patch has been provided but so far the hal maintainer has not updated his package. From jkeating at redhat.com Thu Jun 12 13:48:04 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jun 2008 09:48:04 -0400 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: <485117CB.1070504@nobugconsulting.ro> References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> <4850FD7E.903@gmail.com> <485117CB.1070504@nobugconsulting.ro> Message-ID: <1213278484.12508.0.camel@localhost.localdomain> On Thu, 2008-06-12 at 15:34 +0300, Manuel Wolfshant wrote: > Toshio Kuratomi wrote: > > Kevin Kofler wrote: > >> Toshio Kuratomi gmail.com> writes: > >>> The playing time is 74 minutes, or 4440 seconds, so that the net > >>> capacity of a Mode-1 CD-ROM is 682 MB.""" > >> > >> Uh, 74 minute CDs are completely obsolete, around here (Austria) they > >> don't even sell these anymore! 80 minute / 700 MB CDs are the > >> standard size these days, and those are what Fedora's live images are > >> (and have always been) designed to fit. > >> > > But not all drives can read 700MB from a CD. Those drives might be > > obsolete in the sense that you can't buy them on a new computer > > anymore but there's plenty of old hardware available where it could be > > a problem. > I haven't seen yet a disk drive unit manufactured in the last 6 years > which is still functional but is unable to read 700 MB disks. Actually I > do not remember of ANY unit manufactured this century and unable to read > 700 MB disks. > Also I don't recall getting any bug reports regarding the CD isos being too large, especially for the Live images. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kzak at redhat.com Thu Jun 12 13:49:29 2008 From: kzak at redhat.com (Karel Zak) Date: Thu, 12 Jun 2008 15:49:29 +0200 Subject: selinux and unmount errors In-Reply-To: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> References: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> Message-ID: <20080612134929.GA31588@nb.net.home> On Thu, Jun 12, 2008 at 03:11:09PM +0200, Valent Turkovic wrote: > I have tested unmounting usb flash stick on 3 laptops with Fedora 9 > and on all of them I get selinux alerts during unmount. Also first > time I try to unmount I get selinux to prevent it from unmounting! > Only second time I try to unmount that unmount succeeds. > > https://bugzilla.redhat.com/show_bug.cgi?id=450055 That's duplicate of: https://bugzilla.redhat.com/show_bug.cgi?id=447195 Karel -- Karel Zak From jkeating at redhat.com Thu Jun 12 13:50:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jun 2008 09:50:00 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <1213253491.3951.48.camel@beck.corsepiu.local> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> <1213253491.3951.48.camel@beck.corsepiu.local> Message-ID: <1213278600.12508.3.camel@localhost.localdomain> On Thu, 2008-06-12 at 08:51 +0200, Ralf Corsepius wrote: > Iff you have access to all architectures Fedora tries to support and iff > Fedora repos were consistent (Which they often aren't) It's nearly impossible for all the Fedora repos to be "consistent" with the buildsystem, particularly because people want what they just built available in the buildroot to build other things against. We can't do a continual stream of changes to the rawhide directory throughout the day, that's just begging for mirrors to slaughter me. Rawhide is only a snapshot, the development stream within Koji is ever moving. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Thu Jun 12 14:06:25 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jun 2008 15:06:25 +0100 Subject: PackageKit UI In-Reply-To: <20080612134119.GA64415@dspnet.fr.eu.org> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> Message-ID: <1213279585.4225.4.camel@hughsie-work> On Thu, 2008-06-12 at 15:41 +0200, Olivier Galibert wrote: > On Thu, Jun 12, 2008 at 02:22:17PM +0100, Richard Hughes wrote: > > On Thu, 2008-06-12 at 15:09 +0200, Olivier Galibert wrote: > > > On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > > > > Comments/suggestions welcome, > > > > > > What are your use cases? Do you have any? > > > > Lots, see www.packagekit.org. > > I may be a tad dense, but I can't find them there. In the developer docs IIRC. > > > How do you handle the use case "I need something to type a letter, > > > what can I install for that, what are my choices?". > > > How do you handle the use case "I want my desktop to look cooler, what > > > can I add?". > > > How do you handle the use case "I need some free space, what can I > > > remove?". > > > > We are prototyping something web-based for this sort of thing. We'll be > > announcing stuff soon (if it works), I promise. > > Good. Then, what is your interface for, other than placating those > who think they can't survive if they can't point and drool and > consider that typing "yum install stuff" is way too complex? It's somewhere in the middle of "What's a computer" to "iwconfig wlan0" - competent users who just want to get something done. > > > What information does the opened/closed box icon give, apart from "we > > > have good graphists"? > > > > Open = installed, closed = not installed. The icons also change if you > > select them to be added or removed. > > That's, errr, non-obvious. At all. I don't see how an icon can > convey that kind of thing in an obvious way, to be honest. A > word+color code combination would probably be better. And you > probably need to have filters like "show installed", "show updates", > etc directly clickable in the window instead of tucked in a menu. > Color the appropriate words in the filter name with the same color > than the indicator in the array and you're probably golden. Colour is a bad indicator as many people don't "do" colour. > > > Why do you present multiple versions of the same thing (compiz-gnome > > > in your screenshot), especially as is they were different? > > > > Ahh, it shows there is an update available. Maybe we need to expose this > > clearer. > > Ohhhh yes you do. There was talk on the mailing list on how we parametrize these better so we can show better icons in the UI. It petered out a few weeks ago, feel free to jump on the mailing list and help out. Thanks! Richard. From krh at redhat.com Thu Jun 12 14:17:51 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Thu, 12 Jun 2008 10:17:51 -0400 Subject: rhgb vs ? In-Reply-To: <1212770541.4772.9.camel@localhost.localdomain> References: <1212769820.5234.5.camel@scrappy.miketc.com> <1212770228.32560.7.camel@aglarond.local> <1212770541.4772.9.camel@localhost.localdomain> Message-ID: <1213280271.15164.30.camel@gaara.bos.redhat.com> On Fri, 2008-06-06 at 12:42 -0400, Matthias Clasen wrote: > On Fri, 2008-06-06 at 12:37 -0400, Jeremy Katz wrote: > > On Fri, 2008-06-06 at 11:30 -0500, Mike Chambers wrote: > > > I know rhgb is being removed and a quicker gdm login process is taking > > > over, or at least something is? I updated my system to rawhide and saw > > > something replace rhgb? What package is that and can it be involved in > > > the kernel options in grub like rhgb used to? > > > > The new package is plymouth[1] but all of the integration pieces haven't > > quite landed yet. But starting to land bits in rawhide helps to make > > that easier, so the staging has begun. rhgb or not in the kernel > > command line will likely continue to have an effect, although there's > > some hand-waving on my part right now with that :-) > > > > Plymouth is actually in rawhide already. > We just missing the mkinitrd bits to make use of it. > That will hopefully fall in place soon. > We are aiming for a demoable new bootsequence by Fudcon. We're also missing the kernel modesetting bits. Until that lands, the plymouth text mode boot screen should work, but it's mostly a stub for now. Kristian From adam at gradientzero.com Thu Jun 12 14:41:31 2008 From: adam at gradientzero.com (Adam Hough) Date: Thu, 12 Jun 2008 09:41:31 -0500 Subject: qemu-kvm segfaulting when running kernel-PAE.i686 Message-ID: Does anyone know of a reason that would cause qemu-kvm to segfault when the system is running the an PAE kernel? Qemu-kvm works fine if I am using the kernel.i686 package. When it does crash under the PAE kernel it leaves this message in dmesg: kvm: 3646: cpu0 unhandled rdmsr: 0xc0000080 kvm: inject_page_fault: double fault 0x804d6ffc kvm: 3646: cpu0 task_switch_interception: task switch is unsupported Selinux is currently set to permissive so I know it is not selinux's fault. I am currently running the 2.6.25.4-30.fc9.i686.PAE kernel. root at tinybox winxp_qemu # qemu-kvm winxp_qemu.img unhandled vm exit: 0x3f60101 vcpu_id 0 rax 000000002446ff20 rbx 000000008054269c rcx 0000000000000000 rdx 0000000000008052 rsi 00000000805426c8 rdi 0000000000000000 rsp 00000000804d7000 rbp 000000008052d44d r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 0000000080540470 rflags 00000086 cs 0008 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0) ds 0023 (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) es 0023 (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0030 (ffdff000/00001fff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) gs 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0028 (80042000/000020ab p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8003f000/3ff idt 8003f400/7ff cr0 8001003d cr2 804d6ffc cr3 abc000 cr4 20 cr8 0 efer 0 Aborted My cpu is a AMD Athlon(tm) X2 Dual Core Processor BE-2400 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch ts fid vid ttp tm stc 100mhzsteps -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Thu Jun 12 14:56:23 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 12 Jun 2008 10:56:23 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300806120501i26504353ic2a0b73d0faace4e@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212588251.13676.0.camel@localhost.localdomain> <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> <1213203053.5747.20.camel@localhost.localdomain> <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> <1213270382.1469.15.camel@localhost.localdomain> <64b14b300806120501i26504353ic2a0b73d0faace4e@mail.gmail.com> Message-ID: <1213282583.6589.5.camel@localhost.localdomain> On Thu, 2008-06-12 at 14:01 +0200, Valent Turkovic wrote: > On Thu, Jun 12, 2008 at 1:33 PM, Dan Williams wrote: > > On Thu, 2008-06-12 at 09:36 +0200, Valent Turkovic wrote: > >> On Wed, Jun 11, 2008 at 6:50 PM, Dan Williams wrote: > >> > On Wed, 2008-06-11 at 13:19 +0200, Valent Turkovic wrote: > >> >> On Wed, Jun 4, 2008 at 11:54 PM, Dan Williams wrote: > >> >> > On Wed, 2008-06-04 at 19:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > >> >> >> On Wednesday, 04 June 2008 at 19:28, Dan Williams wrote: > >> >> >> > On Wed, 2008-06-04 at 17:20 +0200, Valent Turkovic wrote: > >> >> >> [...] > >> >> >> > > Will this happen as an Fedora 9 update or just in rawhide (fedora 10) ? > >> >> >> > > >> >> >> > Definitely in the next F9 update. > >> >> >> > >> >> >> Will this update contain my patch which allows people to uninstall > >> >> >> NetworkManager without losing pidgin and evolution (bug #351101)? > >> >> >> > >> >> >> You never gave a good reason why this bug has been left unfixed > >> >> >> for over half a year, especially when the solution is trivial. > >> >> > > >> >> > Can you try out > >> >> > > >> >> > http://koji.fedoraproject.org/koji/taskinfo?taskID=646433 > >> >> > > >> >> > when it gets done? > >> >> > > >> >> > Thanks, > >> >> > Dan > >> >> > > >> >> >> Regards, > >> >> >> R. > >> >> >> > >> >> >> -- > >> >> >> Fedora http://fedoraproject.org/wiki/DominikMierzejewski > >> >> >> Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > >> >> >> "Faith manages." > >> >> >> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > >> >> >> > >> >> > > >> >> > -- > >> >> > fedora-devel-list mailing list > >> >> > fedora-devel-list at redhat.com > >> >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> >> > > >> >> > >> >> > >> >> I tested NetworkManager via: > >> >> yum --enablerepo=updates-testing update NetworkManager > >> >> > >> >> as you suggested in bugreport but I still see the same bug present. > >> > > >> > What's the output of: > >> > > >> > ls -al /etc/rc3.d/*Net* > >> > > >> > Dan > >> > > >> > -- > >> > fedora-devel-list mailing list > >> > fedora-devel-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> > > >> > >> > >> ]# ls -al /etc/rc3.d/*Net* > >> lrwxrwxrwx 1 root root 24 2008-04-24 09:44 > >> /etc/rc3.d/S99NetworkManager -> ../init.d/NetworkManager > > > > Ok, so the even though NM and dbus have resetpriorities in their > > specfile, it may be that HAL doesn't. You'll want to do the following > > as a workaround: > > > > chkconfig messagebus resetpriorities > > chkconfig haldaemon resetpriorities > > chkconfig NetworkManager resetpriorities > > > > and then messagebus should be at 22, NM at 27, and hal wherever. > > > > Dan > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > I did that and now NM is 27 and netfs is 25 > > # ls -al /etc/rc3.d/*Net* > lrwxrwxrwx 1 root root 24 2008-06-12 13:58 > /etc/rc3.d/S27NetworkManager -> ../init.d/NetworkManager > > I'm at work and will report back when I come home because at home. Bill, weren't we supposed to have netfs start after NM? messagebus is at 22, so maybe we should bump HAL to 23 and NM to 24 or something? I honestly forget where all the stupid priorities need to be. All hail our new upstart overloads in F10. Dan From naheemzaffar at gmail.com Thu Jun 12 15:02:46 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 12 Jun 2008 16:02:46 +0100 Subject: PackageKit UI In-Reply-To: <1213279585.4225.4.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> Message-ID: <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> Been using packagekit for Fedora 9, and I generally like what I see (good work!) things that I think can be improved/current problems: 1. Do NOT list multiple versions of the same package. I see that in current Fedora release too. At times the version numbers are not that easy to compare package-x.y.1.y vs package-x.y.y.1 makes a person think. Other times if both are uninstalled, selecting the wrong one will probably lead to an updated available applet anywway... Solution: only list one - the latest one. If an update is available to the installed version, use the corresponding update icon (bugfix/enhancement/security) instead of an open or closed box. 2. The list on the left is a little "controlled". I am guessing the shown groups are hard settings instead of all possible groups? what groups are subsets of other groups? Solution: have a tree menu. (yes, I realise this was removed earlier from development as a "bad idea".) All packages shows the top level of groups below it. Clicking on any one group will drop a submenu of its subgroups. 3. There is no groupinstall, nor an obvious way to implement it. Solution: It does not have to be obvious This is additional functionality and can be behind a context menu. I doubt everyone even knows about group install. The Pirut way works for those who know where to look. It is better than nothing, it works. With a tree menu (point 2) of all groups, it also has more power. 4a. (from packagekit in Fedora 9) hovering over the applet is sort of useless. 4b. The "progress" (similar to http://www.packagekit.org/img/gpk-progress.png) and "update/install completed" screens is also a useless waste of space. They also leave unnecessary windows open. the completed screens just lie in the background, ignored, giving no indication that a transaction has been completed. Solution: combine the two/three into a better notification: hovering/clicking gives a proper notification with a full queue of what is waiting to happen, maybe with update bars too. the transaction complete bits should also be notifications, not a window that hides behind the one you are actually doing work in, waiting for the transaction to complete. 5. The updates available icons are not too obvious. Since they are in the system tray, it needs to be obvious that they are not just another program running there. I think something like the old up2date icons (bright red circle with an exclamation mark) would gain more attention. From rc040203 at freenet.de Thu Jun 12 14:13:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Jun 2008 16:13:23 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213278600.12508.3.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> <1213253491.3951.48.camel@beck.corsepiu.local> <1213278600.12508.3.camel@localhost.localdomain> Message-ID: <1213280003.3951.68.camel@beck.corsepiu.local> On Thu, 2008-06-12 at 09:50 -0400, Jesse Keating wrote: > On Thu, 2008-06-12 at 08:51 +0200, Ralf Corsepius wrote: > > Iff you have access to all architectures Fedora tries to support and iff > > Fedora repos were consistent (Which they often aren't) > > It's nearly impossible for all the Fedora repos to be "consistent" with > the buildsystem, particularly because people want what they just built > available in the buildroot to build other things against. We can't do a > continual stream of changes to the rawhide directory throughout the day, > that's just begging for mirrors to slaughter me. Rawhide is only a > snapshot, the development stream within Koji is ever moving. Well, though I don't understand this (You could build against rawhide and sync rawhide with newly built packages), I am not complaining ... ... I am just describing what I consider to be facts, which I consider to sufficient reasons for users to apply "scratch-builds" :) At the very moment packagers are facing architectural dependent bugs, or observe build-breakdown in koji, which can't be reproduced in local "rawhide builts", ... scratch-builds become a valuable tool. Ralf From ivazqueznet at gmail.com Thu Jun 12 15:52:08 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 12 Jun 2008 11:52:08 -0400 Subject: Packaging question: /usr/share/gnome/help ownership In-Reply-To: <1213278484.12508.0.camel@localhost.localdomain> References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> <4850FD7E.903@gmail.com> <485117CB.1070504@nobugconsulting.ro> <1213278484.12508.0.camel@localhost.localdomain> Message-ID: <1213285928.18802.18.camel@ignacio.lan> On Thu, 2008-06-12 at 09:48 -0400, Jesse Keating wrote: > On Thu, 2008-06-12 at 15:34 +0300, Manuel Wolfshant wrote: > > I haven't seen yet a disk drive unit manufactured in the last 6 years > > which is still functional but is unable to read 700 MB disks. Actually I > > do not remember of ANY unit manufactured this century and unable to read > > 700 MB disks. > > > > Also I don't recall getting any bug reports regarding the CD isos being > too large, especially for the Live images. ISTR one person in #fedora complaining, but I took it with a grain of salt when his next line was "They make 700MB CDRs?". -- 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 notting at redhat.com Thu Jun 12 15:56:25 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Jun 2008 11:56:25 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1213282583.6589.5.camel@localhost.localdomain> References: <64b14b300806040820u2c39d231ybce3350a5c390a4c@mail.gmail.com> <1212600483.20764.4.camel@localhost.localdomain> <20080604173742.GA5399@mokona.greysector.net> <1212616469.6159.0.camel@localhost.localdomain> <64b14b300806110419q44541fb3x6132f4e98099b17f@mail.gmail.com> <1213203053.5747.20.camel@localhost.localdomain> <64b14b300806120036u4ff591cfxbd098d38e01bb7ca@mail.gmail.com> <1213270382.1469.15.camel@localhost.localdomain> <64b14b300806120501i26504353ic2a0b73d0faace4e@mail.gmail.com> <1213282583.6589.5.camel@localhost.localdomain> Message-ID: <20080612155625.GH14944@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > > I did that and now NM is 27 and netfs is 25 > > > > # ls -al /etc/rc3.d/*Net* > > lrwxrwxrwx 1 root root 24 2008-06-12 13:58 > > /etc/rc3.d/S27NetworkManager -> ../init.d/NetworkManager > > > > I'm at work and will report back when I come home because at home. > > Bill, weren't we supposed to have netfs start after NM? messagebus is > at 22, so maybe we should bump HAL to 23 and NM to 24 or something? I > honestly forget where all the stupid priorities need to be. All hail > our new upstart overloads in F10. netfs is triggered by NM-dispatcher, so things should just work regardless of startup priorities. Bill From denis at poolshark.org Thu Jun 12 15:57:04 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 12 Jun 2008 17:57:04 +0200 Subject: Koji ppc build stuck ? In-Reply-To: <1213214407.31380.32.camel@localhost.localdomain> References: <485026C5.4090408@poolshark.org> <1213214407.31380.32.camel@localhost.localdomain> Message-ID: <48514750.3060206@poolshark.org> Mike Bonnet wrote: > On Wed, 2008-06-11 at 21:25 +0200, Denis Leroy wrote: >> Could somebody kick that build ? :-) >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 Hmm, it happend again. It seems the ppc and ppc64 builds are getting stuck on doxygen ? http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 From rjones at redhat.com Thu Jun 12 16:00:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Jun 2008 17:00:02 +0100 Subject: qemu-kvm segfaulting when running kernel-PAE.i686 In-Reply-To: References: Message-ID: <20080612160002.GA24695@amd.home.annexia.org> On Thu, Jun 12, 2008 at 09:41:31AM -0500, Adam Hough wrote: > Does anyone know of a reason that would cause qemu-kvm to segfault when the > system is running the an PAE kernel? Qemu-kvm works fine if I am using the > kernel.i686 package. What version? This looks similar to: https://bugzilla.redhat.com/show_bug.cgi?id=310591 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From mikeb at redhat.com Thu Jun 12 16:10:45 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 12 Jun 2008 12:10:45 -0400 Subject: Koji ppc build stuck ? In-Reply-To: <48514750.3060206@poolshark.org> References: <485026C5.4090408@poolshark.org> <1213214407.31380.32.camel@localhost.localdomain> <48514750.3060206@poolshark.org> Message-ID: <1213287045.31380.76.camel@localhost.localdomain> On Thu, 2008-06-12 at 17:57 +0200, Denis Leroy wrote: > Mike Bonnet wrote: > > On Wed, 2008-06-11 at 21:25 +0200, Denis Leroy wrote: > >> Could somebody kick that build ? :-) > >> > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 > > Hmm, it happend again. It seems the ppc and ppc64 builds are getting > stuck on doxygen ? > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 Canceled. Both builds were stuck here: 21968 1 21968 rpmbuild -bb --target ppc64 --nodeps builddir/build/SPECS/libburn.spec 21984 21968 21968 \_ /bin/sh -e /var/tmp/rpm-tmp.41664 29983 21984 21968 \_ doxygen doc/doxygen.conf 29984 29983 21968 \_ dot libburn_8h__incl.dot -Tpng -o libburn_8h__incl.png From michel.sylvan at gmail.com Thu Jun 12 16:20:57 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 12 Jun 2008 12:20:57 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> Message-ID: <48514CE9.80208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 max bianco wrote: > What was the reason for using LVM in the first place. My most recent > install I was really tempted to not go with the defaults but because I > really don't know much about filesystems, I figured the best thing in > that case was stick to the defaults. Now I am reconsidering > again...could someone explain the comparative advantages/disadvantages > ? Before i do something stupid . > It's hard to go completely with the defaults, which does not specify a separate partition for home directories too. - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhRTOYACgkQWt0J3fd+7ZBnywCcCbFLRF6zYRKhy3Kawhxoi4He 8I0An2YgsCbsNBoNABTWDeyjRtfrB/kU =WJ83 -----END PGP SIGNATURE----- From adam at gradientzero.com Thu Jun 12 17:00:31 2008 From: adam at gradientzero.com (Adam Hough) Date: Thu, 12 Jun 2008 12:00:31 -0500 Subject: qemu-kvm segfaulting when running kernel-PAE.i686 In-Reply-To: <20080612160002.GA24695@amd.home.annexia.org> References: <20080612160002.GA24695@amd.home.annexia.org> Message-ID: > > What version? > > This looks similar to: > https://bugzilla.redhat.com/show_bug.cgi?id=310591 > https://bugzilla.redhat.com/show_bug.cgi?id=451035 (one that I created for this issue) Running Fedora 9 with latest updates. kernel-PAE-2.6.25.4-30.fc9.i686 qemu-0.9.1-5.fc9.i386 qemu-img-0.9.1-5.fc9.i386 kvm-65-7.fc9.i386 Yes it does look similar but for the fact that the image works fine if I am running kernel-2.6.25.4-30.fc9.i686. I have even tried the -no-kvm-irqchip and -no-kvm-pit switches and it still crashes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From packages at amiga-hardware.com Thu Jun 12 18:02:51 2008 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 12 Jun 2008 19:02:51 +0100 Subject: PackageKit UI In-Reply-To: <1213279585.4225.4.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> Message-ID: <485164CB.3020903@amiga-hardware.com> Richard Hughes wrote: >>>> What information does the opened/closed box icon give, apart from "we >>>> have good graphists"? >>> Open = installed, closed = not installed. The icons also change if you >>> select them to be added or removed. >> That's, errr, non-obvious. At all. I don't see how an icon can >> convey that kind of thing in an obvious way, to be honest. A >> word+color code combination would probably be better. > Colour is a bad indicator as many people don't "do" colour. I think the icon idea is OK but the box icon isn't very obvious. I think something along the lines of a globe with a downwards pointing green arrow overlaid on top could represent "not installed, package needs to be retrieved/downloaded", whilst installed packages could be represented by a silver hard disk icon, perhaps with word 'installed' written on the hard disk label. -- Ian Chapman. From nicolas.mailhot at laposte.net Thu Jun 12 18:12:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jun 2008 20:12:52 +0200 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <1213294373.8892.3.camel@rousalka.okg> Le jeudi 12 juin 2008 ? 12:09 +0100, Richard Hughes a ?crit : > This is the current UI of gpk-application in git master (and rawhide > from today): http://www.packagekit.org/temp/gpk-application.png [?] > Comments/suggestions welcome, From a purely UI POW you should try to propose a three-column mode (vertical UI in evo speak) as widescreens are becoming more common everyday. You could probably treat the Project: Homepage... etc stuff like mail headers (with description as the mail text) and steal all the UI work that went into MUAs over the years. -- 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 Thu Jun 12 18:18:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jun 2008 20:18:01 +0200 Subject: Requirements gathering for new package source control In-Reply-To: <1213278600.12508.3.camel@localhost.localdomain> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <20080611192641.GA20214@mokona.greysector.net> <1213253491.3951.48.camel@beck.corsepiu.local> <1213278600.12508.3.camel@localhost.localdomain> Message-ID: <1213294682.8892.7.camel@rousalka.okg> Le jeudi 12 juin 2008 ? 09:50 -0400, Jesse Keating a ?crit : > On Thu, 2008-06-12 at 08:51 +0200, Ralf Corsepius wrote: > > Iff you have access to all architectures Fedora tries to support and iff > > Fedora repos were consistent (Which they often aren't) > > It's nearly impossible for all the Fedora repos to be "consistent" with > the buildsystem, particularly because people want what they just built > available in the buildroot to build other things against. We can't do a > continual stream of changes to the rawhide directory throughout the day, > that's just begging for mirrors to slaughter me. IMHO someday we should look at completing the mirror tree with a proxy tree. It would work much better for continuous updates as seen on rawhide. With apache including mod_proxy these days, that's not even a matter of making mirrors add squid to their arsenal, just suggest them a good rawhide mod_proxy config. -------------- 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 denis at poolshark.org Thu Jun 12 18:44:05 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 12 Jun 2008 20:44:05 +0200 Subject: Koji ppc build stuck ? In-Reply-To: <1213287045.31380.76.camel@localhost.localdomain> References: <485026C5.4090408@poolshark.org> <1213214407.31380.32.camel@localhost.localdomain> <48514750.3060206@poolshark.org> <1213287045.31380.76.camel@localhost.localdomain> Message-ID: <48516E75.8050200@poolshark.org> Mike Bonnet wrote: > On Thu, 2008-06-12 at 17:57 +0200, Denis Leroy wrote: >> Mike Bonnet wrote: >>> On Wed, 2008-06-11 at 21:25 +0200, Denis Leroy wrote: >>>> Could somebody kick that build ? :-) >>>> >>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 >> Hmm, it happend again. It seems the ppc and ppc64 builds are getting >> stuck on doxygen ? >> >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=52310 > > Canceled. > > Both builds were stuck here: > > 21968 1 21968 rpmbuild -bb --target ppc64 --nodeps builddir/build/SPECS/libburn.spec > 21984 21968 21968 \_ /bin/sh -e /var/tmp/rpm-tmp.41664 > 29983 21984 21968 \_ doxygen doc/doxygen.conf > 29984 29983 21968 \_ dot libburn_8h__incl.dot -Tpng -o libburn_8h__incl.png Thanks Mike, Odd, a ppc-only graphviz bug ? As a workaround, I'll make the graphviz doc images non-ppc. From kwade at redhat.com Thu Jun 12 19:09:30 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 12 Jun 2008 12:09:30 -0700 Subject: Wiki URL Structure (Proposed Change #2): flatten page hierarchies In-Reply-To: <4850E146.2020609@city-fan.org> References: <389552.959071213099076255.JavaMail.www@wwinf8402> <1213259798.3866.221.camel@calliope.phig.org> <4850E146.2020609@city-fan.org> Message-ID: <1213297770.3866.275.camel@calliope.phig.org> On Thu, 2008-06-12 at 09:41 +0100, Paul Howarth wrote: > Karsten 'quaid' Wade wrote: > > We want to encourage people to edit pages. Does having pages in nested > > namespace make people feel as if, "Packaging/Foo must be owned by > > Packaging, I better not touch this page"? > > Unfortunate example. At least on the old wiki, Packaging/* had ACLs > preventing anybody outside the packaging committee from making changes > there, and if that's not the case in the new wiki, that's probably not > by design. Correct, unfortunate example that I picked randomly. The ACLs continue to be in place, as they are on e.g. Legal. Just substitute any other example that fits: SELinux, Art, Ambassadors, DocsProject, etc. - Karsten -- Karsten Wade, Sr. 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 stickster at gmail.com Thu Jun 12 20:48:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 12 Jun 2008 16:48:58 -0400 Subject: Board Elections open on 13 June Message-ID: <1213303738.18352.87.camel@victoria> SHORT FORM: ----------- Elections for the Fedora Project Board open at 0001 UTC on 13 June 2008 -- or about 3.5 hours from the time of this message. The voting system is available at: https://admin.fedoraproject.org/voting The voting system uses the range voting method: http://en.wikipedia.org/wiki/Range_voting ?Any FAS account holder who has completed the CLA may vote in the election. Voting is open until 2359 UTC on 22 June 2008. Election results will be announced shortly thereafter. The final appointed seat on the Board will be filled after the general election as well. Thank you to all the Board members whose seats are up for election, to Nigel Jones for our new voting application, and to the community in advance, for casting their votes for Fedora leadership. LONG FORM (including nominees and other background): ---------------------------------------------------- Recently we converted one Red Hat-appointed seat to a community-elected seat, so there are now five (5) elected seats and four (4) appointed seats. To even out the Board turnover, community members have the opportunity to vote for four (4) elected seats in this election. The elected person with the fourth-highest vote total will serve a half-length term, with that seat being back up for election after the release of Fedora 10. In addition, Karsten Wade's appointment has been extended by six months. This means that after the release of Fedora 10, we will elect two seats and appoint two seats, thus returning to a turnover of roughly half the Board after each release of Fedora. The seats of current Board members Jef Spaleta, Dennis Gilmore, Chris Aillon, and Bob McWhirter are being vacated in this election. ?In addition, the seats of Steve Dickson and Seth Vidal, Board members appointed by Red Hat, are also being vacated. Steve is to be succeeded by Harald Hoyer, and the final appointment will be announced after the general Board elections are over. I would like to thank each of these people for the time and effort they've put into vigorously representing the entire Fedora community on the Board. ?The processes are documented on the Fedora wiki at: https://fedoraproject.org/wiki/Board/Elections In the past few days, the Board and I realized that our guidelines hadn't been updated to match the current FAS implementation, so I've updated them appropriately with the approval of the Board. The election system has changed from approval voting to range voting, but no actual changes have been made in voting requirements. The wording on the wiki has been changed to accurately reflect how the new Fedora Account System works. The nominees for the four elected seats, in no particular order, are: Jon Stanley (jds2001) Tom Callaway (spot) Josh Boyer (jwb) Jonathan Roberts (JonRob) Seth Vidal (skvidal) Dennis Gilmore (irc:dgilmore fas:ausil) Jef Spaleta (irc:spoleeba fas:jspaleta) Jesse Keating (irc:f13 fas:jkeating) Note that you do not have to cast a vote blindly -- you can feel free to ask questions of the candidates. Email them, or feel free to ask your questions on a list they frequent, such as the fedora-advisory-board list: http://redhat.com/archives/fedora-advisory-board The nominees have also placed some summary information about their background and goals on the wiki nominations page: https://fedoraproject.org/wiki/Board/Elections/Nominations These summaries are also available from the "Info" link next to each candidate's name in the voting system. To cast your vote, visit: https://admin.fedoraproject.org/voting If you have any problems with voting, report them immediately in the ticket system, at: https://admin.fedoraproject.org/tickets Use the "elections" category when you file your ticket so that it is directed quickly to the appropriate parties. * * * I'd like everyone voting to remember that this isn't a popularity contest, or a reward system. Think about how you'd like to Board to look when you vote, the same way you think about how you'd like any government body to look when you cast votes for their elections. We have a lot of worthy candidates on this list, and you should pick the ones that you feel will best represent you in advancing the Fedora Project. This is one of numerous ways in which our community makes decisions about the leadership of Fedora. Your vote counts, and I hope you take advantage of it. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From maximilianbianco at gmail.com Thu Jun 12 20:13:45 2008 From: maximilianbianco at gmail.com (max bianco) Date: Thu, 12 Jun 2008 16:13:45 -0400 Subject: LVM negates benefits of jounaling filesystems? [was RFE: autofsck] In-Reply-To: <48514CE9.80208@gmail.com> References: <3da3b5b40806100604x1d000465p37480249d1bd27@mail.gmail.com> <484E835F.5020301@redhat.com> <20080610134633.GZ10754@angus.ind.WPI.EDU> <48514CE9.80208@gmail.com> Message-ID: On Thu, Jun 12, 2008 at 12:20 PM, Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > max bianco wrote: > >> What was the reason for using LVM in the first place. My most recent >> install I was really tempted to not go with the defaults but because I >> really don't know much about filesystems, I figured the best thing in >> that case was stick to the defaults. Now I am reconsidering >> again...could someone explain the comparative advantages/disadvantages >> ? Before i do something stupid . >> > It's hard to go completely with the defaults, which does not specify a > separate partition for home directories too. > I didn't phrase that right. The default is an LVM though, i understand the advantages and i keep a back up so I am not going to repartition the drive but if its harder to recover data from an LVM then I may avoid using that scheme in the future. From kevin.kofler at chello.at Thu Jun 12 21:44:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 12 Jun 2008 21:44:37 +0000 (UTC) Subject: Packaging question: /usr/share/gnome/help ownership References: <484C49EE.6040506@gmail.com> <484CBDBA.9030405@gmail.com> <484D63B4.8050705@gmail.com> <484DAC3B.1080508@gmail.com> <4850FD7E.903@gmail.com> Message-ID: Toshio Kuratomi gmail.com> writes: > But not all drives can read 700MB from a CD. Those drives might be > obsolete in the sense that you can't buy them on a new computer anymore > but there's plenty of old hardware available where it could be a problem. Uh, even my old 1995 4x speed CD-ROM drive (which has since been decommissioned) was able to read 700 MB CDs (completely filled) just fine. That was a drive which is now 13 years old! Kevin Kofler From petersen at redhat.com Fri Jun 13 01:13:29 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 Jun 2008 11:13:29 +1000 Subject: documenting process for packages renamed upstream Message-ID: <4851C9B9.9060601@redhat.com> Is the process for renaming packages in fedora that have been renamed upstream document on the wiki? I haven't been able to find any description of our process in that case. I think it happens often enough that the process should be written down. As I understand it a new package review is not required in the case but cvsadmin requests are needed to create the new package. Jens From henriquecsj at gmail.com Fri Jun 13 03:26:00 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Fri, 13 Jun 2008 00:26:00 -0300 Subject: Changing XDrawChem to Bkchem Message-ID: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> ?Friends, I've using Fedora as my main distro for a while now (FC 3) and here in Brazil, where I study Chemical Engineering, I started to use the excellent XDrawChem software, for drawing chemical structures and diagrams of reactions. I discovered, however, that the development of the program is freezed since November of 2005 [1] and the activities in the discutions lists had ceased a long time ago. The future of this software seems uncertain and, until this point, poor promising, since improvements are not being made and it's outdated in comparison of what expect from a system that cares about constant evolution. After some research and tests, I found the BkChem [2], that it is similar in functions, but it's uninterruptedly being developed and that, in fact, it had shown better results compared to the XdrawChem could obtain at the moment. The structures are more clear, the methods of drawing more refined and the plugins and tools already are compared with the ones that the XDrawChem had. The BkChem is distribuited under GPL and seems to be a good (and promising) substitute to the deceased XdrawChem. ?[1] - http://xdrawchem.sourceforge.net/ [2] - http://bkchem.zirael.org/ Cordially -- Henrique "LonelySpooky" Junior ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivazqueznet at gmail.com Fri Jun 13 04:30:26 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 13 Jun 2008 00:30:26 -0400 Subject: Changing XDrawChem to Bkchem In-Reply-To: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> Message-ID: <1213331426.18802.33.camel@ignacio.lan> On Fri, 2008-06-13 at 00:26 -0300, Henrique Junior wrote: > ?Friends, > > I've using Fedora as my main distro for a while now (FC 3) and here in > Brazil, where I study Chemical Engineering, I started to use the > excellent XDrawChem software, for drawing chemical structures and > diagrams of reactions. I discovered, however, that the development of > the program is freezed since November of 2005 [1] and the activities > in the discutions lists had ceased a long time ago. > The future of this software seems uncertain and, until this point, > poor promising, since improvements are not being made and it's > outdated in comparison of what expect from a system that cares about > constant evolution. > After some research and tests, I found the BkChem [2], that it is > similar in functions, but it's uninterruptedly being developed and > that, in fact, it had shown better results compared to the XdrawChem > could obtain at the moment. The structures are more clear, the methods > of drawing more refined and the plugins and tools already are compared > with the ones that the XDrawChem had. The BkChem is distribuited under > GPL and seems to be a good (and promising) substitute to the deceased > XdrawChem. > > ?[1] - http://xdrawchem.sourceforge.net/ > [2] - http://bkchem.zirael.org/ Thanks for showing an interest! http://fedoraproject.org/wiki/PackageMaintainers/Join -- 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 henriquecsj at gmail.com Fri Jun 13 04:57:15 2008 From: henriquecsj at gmail.com (Henrique "LonelySpooky" Junior) Date: Fri, 13 Jun 2008 01:57:15 -0300 Subject: Changing XDrawChem to Bkchem In-Reply-To: <1213331426.18802.33.camel@ignacio.lan> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> Message-ID: <1213333035.7634.1.camel@localhost.localdomain> Hi, Ignacio I'm not shure to have the necessary skills to do that... =( Em Sex, 2008-06-13 ?s 00:30 -0400, Ignacio Vazquez-Abrams escreveu: > On Fri, 2008-06-13 at 00:26 -0300, Henrique Junior wrote: > > ?Friends, > > > > I've using Fedora as my main distro for a while now (FC 3) and here in > > Brazil, where I study Chemical Engineering, I started to use the > > excellent XDrawChem software, for drawing chemical structures and > > diagrams of reactions. I discovered, however, that the development of > > the program is freezed since November of 2005 [1] and the activities > > in the discutions lists had ceased a long time ago. > > The future of this software seems uncertain and, until this point, > > poor promising, since improvements are not being made and it's > > outdated in comparison of what expect from a system that cares about > > constant evolution. > > After some research and tests, I found the BkChem [2], that it is > > similar in functions, but it's uninterruptedly being developed and > > that, in fact, it had shown better results compared to the XdrawChem > > could obtain at the moment. The structures are more clear, the methods > > of drawing more refined and the plugins and tools already are compared > > with the ones that the XDrawChem had. The BkChem is distribuited under > > GPL and seems to be a good (and promising) substitute to the deceased > > XdrawChem. > > > > ?[1] - http://xdrawchem.sourceforge.net/ > > [2] - http://bkchem.zirael.org/ > > Thanks for showing an interest! > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Henrique "LonelySpooky" Junior Projeto Fedora Brasil From hughsient at gmail.com Fri Jun 13 07:10:42 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jun 2008 08:10:42 +0100 Subject: PackageKit UI In-Reply-To: <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> Message-ID: <1213341042.3291.6.camel@hughsie-work> On Thu, 2008-06-12 at 16:02 +0100, Naheem Zaffar wrote: > Been using packagekit for Fedora 9, and I generally like what I see > (good work!) things that I think can be improved/current problems: > > 1. Do NOT list multiple versions of the same package. I see that in > current Fedora release too. At times the version numbers are not that > easy to compare package-x.y.1.y vs package-x.y.y.1 makes a person > think. Other times if both are uninstalled, selecting the wrong one > will probably lead to an updated available applet anywway... Sure. We've got a LATEST filter in PackageKit for this, but the yum backend doesn't seem to support it. I might hack on that today on the plane. > Solution: only list one - the latest one. If an update is available to > the installed version, use the corresponding update icon > (bugfix/enhancement/security) instead of an open or closed box. Sane. > 2. The list on the left is a little "controlled". I am guessing the > shown groups are hard settings instead of all possible groups? what > groups are subsets of other groups? Yes, comps is mapped into PK's abstract groups. The abstract groups are shared with SUSE, foresight and OpenMOKO, and so just using comps wasn't suitable. > Solution: have a tree menu. (yes, I realise this was removed earlier > from development as a "bad idea".) All packages shows the top level of > groups below it. Clicking on any one group will drop a submenu of its > subgroups. Sure, see above. > 3. There is no groupinstall, nor an obvious way to implement it. > > Solution: It does not have to be obvious This is additional > functionality and can be behind a context menu. Yes, this was my thinking too. > I doubt everyone even > knows about group install. The Pirut way works for those who know > where to look. It is better than nothing, it works. With a tree menu > (point 2) of all groups, it also has more power. Well, I figured that a user would search for KDE and get a ton of packages. Right click on any one of them and you can install or remove the whole "set". > 4a. (from packagekit in Fedora 9) hovering over the applet is sort of useless. > 4b. The "progress" (similar to > http://www.packagekit.org/img/gpk-progress.png) and "update/install > completed" screens is also a useless waste of space. They also leave > unnecessary windows open. the completed screens just lie in the > background, ignored, giving no indication that a transaction has been > completed. Yes, this is mostly fixed with the new code -- there's only one sort of progress box now, and it's only got one progressbar. > Solution: combine the two/three into a better notification: > hovering/clicking gives a proper notification with a full queue of > what is waiting to happen, maybe with update bars too. the transaction > complete bits should also be notifications, not a window that hides > behind the one you are actually doing work in, waiting for the > transaction to complete. I'm not sure about exposing the queue, but it might make sense. > 5. The updates available icons are not too obvious. Since they are in > the system tray, it needs to be obvious that they are not just another > program running there. I think something like the old up2date icons > (bright red circle with an exclamation mark) would gain more > attention. You get the exclaimation mark for high priority or security updates - but I agree the little orange star isn't that helpful Cheers for your comments. Richard. From hughsient at gmail.com Fri Jun 13 07:53:37 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jun 2008 08:53:37 +0100 Subject: PackageKit UI In-Reply-To: <1213294373.8892.3.camel@rousalka.okg> References: <1213268950.3505.1.camel@hughsie-work> <1213294373.8892.3.camel@rousalka.okg> Message-ID: <1213343617.3291.8.camel@hughsie-work> On Thu, 2008-06-12 at 20:12 +0200, Nicolas Mailhot wrote: > From a purely UI POW you should try to propose a three-column mode > (vertical UI in evo speak) as widescreens are becoming more common > everyday. Yes, I tried this as a prototype [1] but everybody hated it. Richard [1] http://www.packagekit.org/temp/gpk-application-multiple.png From hughsient at gmail.com Fri Jun 13 07:56:23 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jun 2008 08:56:23 +0100 Subject: selinux and unmount errors In-Reply-To: <485127D8.30402@redhat.com> References: <64b14b300806120611n71c4a64dp802513b884633b54@mail.gmail.com> <485127D8.30402@redhat.com> Message-ID: <1213343783.3291.9.camel@hughsie-work> On Thu, 2008-06-12 at 09:42 -0400, Daniel J Walsh wrote: > This is a leaked file descriptor problem with Hal. It has been > reported, a patch has been provided but so far the hal maintainer has > not updated his package. I've applied this upstream yesterday and built new packages for F9 and rawhide. See https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5311 for details. Richard. From nicolas.mailhot at laposte.net Fri Jun 13 08:07:54 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Jun 2008 10:07:54 +0200 (CEST) Subject: PackageKit UI In-Reply-To: <1213343617.3291.8.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <1213294373.8892.3.camel@rousalka.okg> <1213343617.3291.8.camel@hughsie-work> Message-ID: <45450.192.54.193.59.1213344474.squirrel@rousalka.dyndns.org> Le Ven 13 juin 2008 09:53, Richard Hughes a ?crit : > > On Thu, 2008-06-12 at 20:12 +0200, Nicolas Mailhot wrote: >> From a purely UI POW you should try to propose a three-column mode >> (vertical UI in evo speak) as widescreens are becoming more common >> everyday. > > Yes, I tried this as a prototype [1] but everybody hated it. > > Richard > > [1] http://www.packagekit.org/temp/gpk-application-multiple.png I think your main problem was the tabs gallore on the right side. It's probably better to have just one column with information presented sequentially in it -- Nicolas Mailhot From harald at redhat.com Fri Jun 13 08:15:59 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 13 Jun 2008 10:15:59 +0200 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: <1213197859.28032.79.camel@localhost.localdomain> References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> <1213197859.28032.79.camel@localhost.localdomain> Message-ID: Adam Jackson wrote: > On Wed, 2008-06-11 at 16:04 +0100, Richard W.M. Jones wrote: >> On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org wrote: >>> ocaml-deriving: >>> F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) >>> >>> ocaml-gsl: >>> F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) >>> >>> ocaml-json-static: >>> F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) >> [etc etc] >> >> Is this wrong? >> >> I'm afraid to say that a lot of packages I have do this. The reason >> is that I develop and build packages on Rawhide, then backport them to >> F-8. However when backporting to F-8 I have to bump the release >> number up, typically because I have to add an ExcludeArch: ppc64[*] >> for F-8, but may be because of other packing twiddling too. >> >> I wasn't aware that there had to be a strict increase in package >> numbering between branches. (In fact, I wasn't aware that Fedora even >> allowed updating between Fedora releases). > > It's very strongly encouraged. We do provide upgrade paths between > releases (and are even working to make them more robust). So yes, > please do keep EVRs for older releases lower (in the rpmvercmp sense) > than those for newer releases. > > When in doubt: > > % sudo yum -y install rpmdevtools > % rpmdev-vercmp 0:0.9.6-4.fc8 0:0.9.6-3.fc9 > 0:0.9.6-4.fc8 is newer > > - ajax > this can be prevented automatically by a cvs-commit check script From dominik at greysector.net Fri Jun 13 08:21:29 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 13 Jun 2008 10:21:29 +0200 Subject: Changing XDrawChem to Bkchem In-Reply-To: <1213333035.7634.1.camel@localhost.localdomain> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> <1213333035.7634.1.camel@localhost.localdomain> Message-ID: <20080613082129.GB1149@mokona.greysector.net> On Friday, 13 June 2008 at 06:57, Henrique LonelySpooky Junior wrote: > Em Sex, 2008-06-13 ?s 00:30 -0400, Ignacio Vazquez-Abrams escreveu: > > On Fri, 2008-06-13 at 00:26 -0300, Henrique Junior wrote: > > > Friends, > > > > > > I've using Fedora as my main distro for a while now (FC 3) and here in > > > Brazil, where I study Chemical Engineering, I started to use the > > > excellent XDrawChem software, for drawing chemical structures and > > > diagrams of reactions. I discovered, however, that the development of > > > the program is freezed since November of 2005 [1] and the activities > > > in the discutions lists had ceased a long time ago. > > > The future of this software seems uncertain and, until this point, > > > poor promising, since improvements are not being made and it's > > > outdated in comparison of what expect from a system that cares about > > > constant evolution. > > > After some research and tests, I found the BkChem [2], that it is > > > similar in functions, but it's uninterruptedly being developed and > > > that, in fact, it had shown better results compared to the XdrawChem > > > could obtain at the moment. The structures are more clear, the methods > > > of drawing more refined and the plugins and tools already are compared > > > with the ones that the XDrawChem had. The BkChem is distribuited under > > > GPL and seems to be a good (and promising) substitute to the deceased > > > XdrawChem. > > > > > > [1] - http://xdrawchem.sourceforge.net/ > > > [2] - http://bkchem.zirael.org/ > > > > Thanks for showing an interest! > > > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > Hi, Ignacio > I'm not shure to have the necessary skills to do that... =( If you're willing to learn, I'm sure there are some seasoned Fedora contributors that will help you (myself included). Why don't you try creating a package of BkChem and submitting it for review? Regards, R. PS. Please do not top-reply. I've fixed the reply order for this mail. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Jun 13 08:23:43 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 13 Jun 2008 10:23:43 +0200 Subject: Package EVR problems in Fedora 2008-06-10 In-Reply-To: References: <200806101624.m5AGOaWP027275@localhost.localdomain> <20080611150459.GA9646@amd.home.annexia.org> <1213197859.28032.79.camel@localhost.localdomain> Message-ID: <20080613082343.GC1149@mokona.greysector.net> On Friday, 13 June 2008 at 10:15, Harald Hoyer wrote: > Adam Jackson wrote: > >On Wed, 2008-06-11 at 16:04 +0100, Richard W.M. Jones wrote: > >>On Tue, Jun 10, 2008 at 12:24:36PM -0400, buildsys at fedoraproject.org > >>wrote: > >>>ocaml-deriving: > >>> F8-updates > F9-updates (0:0.1.1a-4.fc8 > 0:0.1.1a-3.fc9) > >>> > >>>ocaml-gsl: > >>> F8-updates > F9-updates (0:0.6.0-4.fc8 > 0:0.6.0-3.fc9) > >>> > >>>ocaml-json-static: > >>> F8-updates > F9-updates (0:0.9.6-4.fc8 > 0:0.9.6-3.fc9) > >>[etc etc] > >> > >>Is this wrong? > >> > >>I'm afraid to say that a lot of packages I have do this. The reason > >>is that I develop and build packages on Rawhide, then backport them to > >>F-8. However when backporting to F-8 I have to bump the release > >>number up, typically because I have to add an ExcludeArch: ppc64[*] > >>for F-8, but may be because of other packing twiddling too. > >> > >>I wasn't aware that there had to be a strict increase in package > >>numbering between branches. (In fact, I wasn't aware that Fedora even > >>allowed updating between Fedora releases). > > > >It's very strongly encouraged. We do provide upgrade paths between > >releases (and are even working to make them more robust). So yes, > >please do keep EVRs for older releases lower (in the rpmvercmp sense) > >than those for newer releases. > > > >When in doubt: > > > >% sudo yum -y install rpmdevtools > >% rpmdev-vercmp 0:0.9.6-4.fc8 0:0.9.6-3.fc9 > >0:0.9.6-4.fc8 is newer > > > >- ajax > > > > this can be prevented automatically by a cvs-commit check script The harm begins when you do `make tag', so I'd suggest having this check there instead. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From j.w.r.degoede at hhs.nl Fri Jun 13 09:10:44 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Jun 2008 11:10:44 +0200 Subject: Changing XDrawChem to Bkchem In-Reply-To: <20080613082129.GB1149@mokona.greysector.net> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> <1213333035.7634.1.camel@localhost.localdomain> <20080613082129.GB1149@mokona.greysector.net> Message-ID: <48523994.9030408@hhs.nl> Dominik 'Rathann' Mierzejewski wrote: > On Friday, 13 June 2008 at 06:57, Henrique LonelySpooky Junior wrote: >> Em Sex, 2008-06-13 ?s 00:30 -0400, Ignacio Vazquez-Abrams escreveu: >>> On Fri, 2008-06-13 at 00:26 -0300, Henrique Junior wrote: >>>> Friends, >>>> >>>> I've using Fedora as my main distro for a while now (FC 3) and here in >>>> Brazil, where I study Chemical Engineering, I started to use the >>>> excellent XDrawChem software, for drawing chemical structures and >>>> diagrams of reactions. I discovered, however, that the development of >>>> the program is freezed since November of 2005 [1] and the activities >>>> in the discutions lists had ceased a long time ago. >>>> The future of this software seems uncertain and, until this point, >>>> poor promising, since improvements are not being made and it's >>>> outdated in comparison of what expect from a system that cares about >>>> constant evolution. >>>> After some research and tests, I found the BkChem [2], that it is >>>> similar in functions, but it's uninterruptedly being developed and >>>> that, in fact, it had shown better results compared to the XdrawChem >>>> could obtain at the moment. The structures are more clear, the methods >>>> of drawing more refined and the plugins and tools already are compared >>>> with the ones that the XDrawChem had. The BkChem is distribuited under >>>> GPL and seems to be a good (and promising) substitute to the deceased >>>> XdrawChem. >>>> >>>> [1] - http://xdrawchem.sourceforge.net/ >>>> [2] - http://bkchem.zirael.org/ >>> Thanks for showing an interest! >>> >>> http://fedoraproject.org/wiki/PackageMaintainers/Join >> Hi, Ignacio >> I'm not shure to have the necessary skills to do that... =( > > If you're willing to learn, I'm sure there are some seasoned Fedora > contributors that will help you (myself included). Why don't you try > creating a package of BkChem and submitting it for review? > Yip, If you're willing to learn and invest some time into this I'm more then happy to show you the ropes. Regards, Hans From billcrawford1970 at gmail.com Fri Jun 13 09:38:36 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 13 Jun 2008 10:38:36 +0100 Subject: PackageKit UI In-Reply-To: <1213341042.3291.6.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> <1213341042.3291.6.camel@hughsie-work> Message-ID: <544eb990806130238q5effdf01o86fee7fcc82da8d4@mail.gmail.com> 2008/6/13 Richard Hughes : > On Thu, 2008-06-12 at 16:02 +0100, Naheem Zaffar wrote: >> Been using packagekit for Fedora 9, and I generally like what I see >> (good work!) things that I think can be improved/current problems: >> >> 1. Do NOT list multiple versions of the same package. I see that in >> current Fedora release too. At times the version numbers are not that >> easy to compare package-x.y.1.y vs package-x.y.y.1 makes a person >> think. Other times if both are uninstalled, selecting the wrong one >> will probably lead to an updated available applet anywway... > > Sure. We've got a LATEST filter in PackageKit for this, but the yum > backend doesn't seem to support it. I might hack on that today on the > plane. > >> Solution: only list one - the latest one. If an update is available to >> the installed version, use the corresponding update icon >> (bugfix/enhancement/security) instead of an open or closed box. > > Sane. Disagree. If you installed something from updates-testing and want to downgrade to original release or stable update, that should be listed too (with an option to downgrade, preferably presented exactly the way as for a newer one, but perhaps dimmed or something). From rawhide at fedoraproject.org Fri Jun 13 09:58:13 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 13 Jun 2008 09:58:13 +0000 (UTC) Subject: rawhide report: 20080613 changes Message-ID: <20080613095813.C4EDB209D1B@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080612/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080613/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package scim-sayura Sri Lankan input method for SCIM New package xmms-pulse XMMS output plugin for the PulseAudio sound server Updated Packages: Pyrex-0.9.8.4-1.fc10 -------------------- * Thu Jun 12 18:00:00 2008 Matthew Barnes - 0:0.9.8.4-1 - Update to 0.9.8.4 asterisk-1.6.0-0.16.beta9.fc10 ------------------------------ * Thu Jun 12 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.16.beta9 - Disable building cdr_tds since new FreeTDS in rawhide no longer provides needed library. * Wed Jun 11 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.15.beta9 - Bump release and rebuild to fix libtds breakage. blobAndConquer-0.94-1.fc10 -------------------------- * Thu Jun 12 18:00:00 2008 Hans de Goede 0.94-1 - New upstream release 0.94 - Drop all patches (all upstream now) bochs-2.3.7-1.fc10 ------------------ * Mon Jun 9 18:00:00 2008 Hans de Goede 2.3.7-1 - New upstream release 2.3.7 boost-1.34.1-16.fc10 -------------------- * Thu Jun 12 18:00:00 2008 Petr Machata - 1.34.1-16 - Fix "changes meaning of keywords" in boost date_time - Related: #450718 cairo-dock-1.6.0-0.2.svn1094_trunk.fc10 --------------------------------------- * Fri Jun 13 18:00:00 2008 Mamoru Tasaka - svn 1094 collectd-4.4.1-2.fc10 --------------------- * Thu Jun 12 18:00:00 2008 Alan Pevec 4.4.1-2 - Split rrdtool into a subpackage (Chris Lalancette) - cleanup subpackages, split dns plugin, enable ipmi - include /etc/collectd.d (bz#443942) cpanspec-1.75-2.fc10 -------------------- * Thu Jun 12 18:00:00 2008 Steven Pritchard 1.75-2 - Require rpm-build. dblatex-0.2.9-1.fc10 -------------------- * Thu Jun 12 18:00:00 2008 Alex Lancaster - 0.2.9-1 - Update to latest upstream (0.2.9) (#448953) - Remove some redundant Requires and BuildRequires (passivetex pulls in the tetex/tex requires, python dep added automatically) - For F-9+ BR on tex(latex) and texlive-xetex, fix the installation scripts to install extra new files. - Add patch from dblatex mailing list for better handling of a missing xetex. - Conditionally add .egg-info file only if F9+ to allow for unified spec file ettercap-0.7.3-25.fc10 ---------------------- * Thu Jun 12 18:00:00 2008 Jon Ciesla - 0.7.3-25 - Corrected -24 patch. * Thu Jun 12 18:00:00 2008 Jon Ciesla - 0.7.3-24 - Patch to fix daemon mode mitm behaviour BZ 450923. gcc-4.3.1-2 ----------- * Thu Jun 12 18:00:00 2008 Jakub Jelinek 4.3.1-2 - update from gcc-4_3-branch - PRs c++/36408, middle-end/35336, middle-end/36506, testsuite/36443, tree-optimization/36474 - OpenMP 3.0 bugfixes from trunk - fix a thinko in task dispatching on barriers - PRs libgomp/36469, libgomp/36471 - fix nested inline functions in -std=gnu99 mode (#450967, PR c/36507) gdal-1.5.2-1.fc10 ----------------- * Thu Jun 12 18:00:00 2008 Balint Cristian - 1.5.2-1 - a new bugfix upstream - drop gcc43 patch - more license cleaned glib2-2.17.2-1.fc10 ------------------- * Thu Jun 12 18:00:00 2008 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 glibc-2.8.90-6 -------------- * Thu Jun 12 18:00:00 2008 Jakub Jelinek 2.8.90-6 - update from trunk - nscd fixes (#450704) - fix getservbyport (#449358) - fix regexp.h (#446406) - avoid crashing on T_DNAME in DNS responses (#450766) grass-6.3.0-4.fc10 ------------------ * Thu Jun 12 18:00:00 2008 Balint Cristian 6.3.0-4 - address bz#341391 (multilib issue) gstreamer-plugins-base-0.10.19-6.fc10 ------------------------------------- * Wed Jun 11 18:00:00 2008 - Bastien Nocera - 0.10.19-6 - Add patch full of gio fixes gtk2-2.13.2-2.fc10 ------------------ * Wed Jun 11 18:00:00 2008 - Marek Kasik - 2.13.2-2 - Reworked correction of hostname of printer which is the - print job sent to. - Resolves: #248245, #449379 gvfs-0.99.1-2.fc10 ------------------ * Thu Jun 12 18:00:00 2008 Tomas Bzatek - 0.99.1-2 - Fix transfer of whole directories from FTP (#448560) hal-0.5.11-2.fc10 ----------------- * Thu Jun 12 18:00:00 2008 Richard Hughes - 0.5.11-2 - Fix unmounting of USB drives when using SELinux due to a leaking file descriptor (#447195) hesiod-3.1.0-12 --------------- * Thu Jun 12 18:00:00 2008 Nalin Dahyabhai - 3.1.0-12 - call aclocal directly, because autoreconf didn't see the magic comment in the distributed version of aclocal.m4 which made it look like it was safe to generate a new one (#449550) * Mon Jun 2 18:00:00 2008 Nalin Dahyabhai - 3.1.0-11 - force autoreconf to overwrite files (should fix #449550) imlib2-1.4.1-1.fc10 ------------------- * Thu Jun 12 18:00:00 2008 Hans de Goede 1.4.1-1 - New upstream release 1.4.1 - Stop shipping static lib in -devel kernel-2.6.26-0.64.rc5.git7.fc10 -------------------------------- * Thu Jun 12 18:00:00 2008 Dave Jones - 2.6.26-rc5-git7 * Thu Jun 12 18:00:00 2008 Dave Jones - 2.6.26-rc5-git6 libdrm-2.4.0-0.10.fc10 ---------------------- liberation-fonts-1.04-0.1.beta2.fc10 ------------------------------------ * Thu Jun 12 18:00:00 2008 Caius Chance - 1.04-0.1.beta2.fc10 - Updated source version to 1.04.beta2. - Removed License.txt and COPYING as already included in sources. * Thu Apr 10 18:00:00 2008 Caius Chance - 1.03-1.fc9 - Resolves: rhbz#251890 (Exchanged and incomplete glyphs.) - Repack source tarball and re-align source version number. libgphoto2-2.4.1-3.fc10 ----------------------- * Thu Jun 12 18:00:00 2008 Jindrich Novy 2.4.1-3 - libgphoto2-devel requires libusb-devel and libexif-devel for pkgconfig libvirt-0.4.3-1.fc10 -------------------- * Thu Jun 12 18:00:00 2008 Daniel Veillard - 0.4.3-1.fc10 - upstream release 0.4.3 - many bug fixes - many small improvements - serious xenner fixes mapserver-5.0.3-1.fc10 ---------------------- * Thu Jun 12 18:00:00 2008 Balint Cristian 5.0.3-1 - update to 5.0.3 bugfix release - fix some rpmlint warnings mew-6.1-1.fc10 -------------- * Fri Jun 13 18:00:00 2008 Akira TAGOH - 6.1-1 - New upstream release. nautilus-2.23.3-2.fc10 ---------------------- * Thu Jun 12 18:00:00 2008 Tomas Bzatek - 2.23.3-2 - Fix DnD segfaults (#450416, #450449) nautilus-sendto-1.0.0-1.fc10 ---------------------------- * Thu Jun 12 18:00:00 2008 - Bastien Nocera - 1.0.0 - Update to 1.0.0 openldap-2.4.10-1.fc10 ---------------------- * Thu Jun 12 18:00:00 2008 Jan Safranek 2.4.10-1 - new upstream release patch-2.5.4-33.fc10 ------------------- * Thu Jun 12 18:00:00 2008 Tim Waugh 2.5.4-33 - Fix selinux patch and apply it. Build requires libselinux-devel. plymouth-0.3.1-3.fc10 --------------------- * Thu Jun 12 18:00:00 2008 Ray Strode - 0.3.1-3 - scriplet should be preun, not postun * Thu Jun 12 18:00:00 2008 Ray Strode - 0.3.1-2 - Fix postun scriptlet * Thu Jun 12 18:00:00 2008 Ray Strode - 0.3.1-1 - Update to version 0.3.1 - Don't ship generated initrd scripts in tarball * Thu Jun 12 18:00:00 2008 Ray Strode - 0.3.0-1 - Update to version 0.3.0 - Better plugin handling - Better integration with mkinitrd (pending mkinitrd changes) - random bug fixes policycoreutils-2.0.49-6.fc10 ----------------------------- * Thu Jun 12 18:00:00 2008 Dan Walsh 2.0.49-6 - Add deleteall to semanage permissive, cleanup error handling * Thu Jun 12 18:00:00 2008 Dan Walsh 2.0.49-5 - Complete removal of rhpl requirement seaview-2.4-1.fc10 ------------------ * Thu Jun 12 18:00:00 2008 Christian Iseli - 2.4-1 - New upstream version 2.4 - Cleanup changelog formatting selinux-policy-3.4.2-3.fc10 --------------------------- * Thu Jun 12 18:00:00 2008 Dan Walsh 3.4.2-3 - Prevent applications from reading x_device * Thu Jun 12 18:00:00 2008 Dan Walsh 3.4.2-2 - Add /var/lib/selinux context * Wed Jun 11 18:00:00 2008 Dan Walsh 3.4.2-1 - Update to upstream sepostgresql-8.3.3-2.869.fc10 ----------------------------- * Fri Jun 13 18:00:00 2008 - 8.3.3-2.869 - upgrade base PostgreSQL 8.3.1 -> 8.3.3 udev-124-1.fc10 --------------- * Thu Jun 12 18:00:00 2008 Harald Hoyer 124-1 - version 124 - removed udevcontrol, udevtrigger symlinks (use udevadm now) wxPython-2.8.7.1-5.fc10 ----------------------- * Thu Jun 12 18:00:00 2008 Hans de Goede - 2.8.7.1-5 - Fix an attribute error when importing wxPython (compat) module (redhat bugzilla 450073, 450074) xen-3.2.0-12.fc9 ---------------- * Tue Jun 3 18:00:00 2008 Daniel P. Berrange - 3.2.0-12.fc9 - Move /var/run/xend into xen-runtime for pygrub (rhbz #442052) * Wed May 14 18:00:00 2008 Markus Armbruster - 3.2.0-11.fc9 - Disable QEMU image format auto-detection (CVE-2008-2004) - Fix PVFB to validate frame buffer description (CVE-2008-1943) Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 40 Broken deps for i386 ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 rt3-3.6.6-5.fc9.noarch requires perl(DBIx::SearchBuilder) rt3-3.6.6-5.fc9.noarch requires perl(DBIx::SearchBuilder::Record::Cachable) rt3-3.6.6-5.fc9.noarch requires perl(DBIx::SearchBuilder::Unique) rt3-3.6.6-5.fc9.noarch requires perl(DBIx::SearchBuilder::Union) smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From tim.lauridsen at googlemail.com Fri Jun 13 10:30:48 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 13 Jun 2008 12:30:48 +0200 Subject: PackageKit UI In-Reply-To: <1213341042.3291.6.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> <1213341042.3291.6.camel@hughsie-work> Message-ID: <48524C58.3020903@googlemail.com> Richard Hughes wrote: > On Thu, 2008-06-12 at 16:02 +0100, Naheem Zaffar wrote: >> Been using packagekit for Fedora 9, and I generally like what I see >> (good work!) things that I think can be improved/current problems: >> >> 1. Do NOT list multiple versions of the same package. I see that in >> current Fedora release too. At times the version numbers are not that >> easy to compare package-x.y.1.y vs package-x.y.y.1 makes a person >> think. Other times if both are uninstalled, selecting the wrong one >> will probably lead to an updated available applet anywway... > > Sure. We've got a LATEST filter in PackageKit for this, but the yum > backend doesn't seem to support it. I might hack on that today on the > plane. > Now it does. :) Tim From hughsient at gmail.com Fri Jun 13 10:39:57 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jun 2008 11:39:57 +0100 Subject: PackageKit UI In-Reply-To: <48524C58.3020903@googlemail.com> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> <1213341042.3291.6.camel@hughsie-work> <48524C58.3020903@googlemail.com> Message-ID: <1213353597.8914.3.camel@hughsie-work> On Fri, 2008-06-13 at 12:30 +0200, Tim Lauridsen wrote: > Richard Hughes wrote: > > Sure. We've got a LATEST filter in PackageKit for this, but the yum > > backend doesn't seem to support it. I might hack on that today on > the> plane. > > > Now it does. :) Bahh - Now what am I going to do on the plane? :-) Seriously, thanks! Richard. From tim.lauridsen at googlemail.com Fri Jun 13 11:07:00 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 13 Jun 2008 13:07:00 +0200 Subject: PackageKit UI In-Reply-To: <1213353597.8914.3.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> <1213341042.3291.6.camel@hughsie-work> <48524C58.3020903@googlemail.com> <1213353597.8914.3.camel@hughsie-work> Message-ID: <485254D4.5000701@googlemail.com> Richard Hughes wrote: > On Fri, 2008-06-13 at 12:30 +0200, Tim Lauridsen wrote: >> Richard Hughes wrote: >>> Sure. We've got a LATEST filter in PackageKit for this, but the yum >>> backend doesn't seem to support it. I might hack on that today on >> the> plane. >> Now it does. :) > > Bahh - Now what am I going to do on the plane? :-) Seriously, thanks! > > Richard. > What about fixing the yum2 backend :) Tim From choeger at cs.tu-berlin.de Fri Jun 13 11:52:02 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 13 Jun 2008 13:52:02 +0200 Subject: Buildsystem messed up? Message-ID: <1213357922.3195.0.camel@choeger6> Hi, all my builds fail due to: ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'], False, '/var/lib/mock/dist-f9-build-205642-35635/root/', None, 0, True, 0, 103, 103, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'] /etc/profile: line 38: /bin/hostname: No such file or directory warning: Could not canonicalize hostname: x86-7 Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/NetworkManager-openvpn-0.7.0-13.svn3632.fc9.src.rpm LEAVE do --> Did I miss an outage notification? Anything I can do about it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dev at nigelj.com Fri Jun 13 12:02:23 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 14 Jun 2008 00:02:23 +1200 Subject: Buildsystem messed up? In-Reply-To: <1213357922.3195.0.camel@choeger6> References: <1213357922.3195.0.camel@choeger6> Message-ID: <485261CF.20602@nigelj.com> Christoph H?ger wrote: > Hi, > > all my builds fail due to: > > ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 > --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'], False, > '/var/lib/mock/dist-f9-build-205642-35635/root/', None, 0, True, 0, 103, > 103, None, logger= 0x2aaab1ccaf90>) > Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'] > /etc/profile: line 38: /bin/hostname: No such file or directory > warning: Could not canonicalize hostname: x86-7 > Building target platforms: x86_64 > Building for target x86_64 > Wrote: /builddir/build/SRPMS/NetworkManager-openvpn-0.7.0-13.svn3632.fc9.src.rpm > LEAVE do --> > > > Did I miss an outage notification? > Anything I can do about it? > According to http://koji.fedoraproject.org/koji/getfile?taskID=660521&name=root.log you are missing build dependencies. As this is a build for f9-updates-candidates you may need to ask rel-eng to add these packages to your buildroot. - Nigel From choeger at cs.tu-berlin.de Fri Jun 13 12:04:34 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 13 Jun 2008 14:04:34 +0200 Subject: Buildsystem messed up? In-Reply-To: <485261CF.20602@nigelj.com> References: <1213357922.3195.0.camel@choeger6> <485261CF.20602@nigelj.com> Message-ID: <1213358674.3195.3.camel@choeger6> Am Samstag, den 14.06.2008, 00:02 +1200 schrieb Nigel Jones: > Christoph H?ger wrote: > > Hi, > > > > all my builds fail due to: > > > > ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 > > --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'], False, > > '/var/lib/mock/dist-f9-build-205642-35635/root/', None, 0, True, 0, 103, > > 103, None, logger= > 0x2aaab1ccaf90>) > > Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/NetworkManager-openvpn.spec'] > > /etc/profile: line 38: /bin/hostname: No such file or directory > > warning: Could not canonicalize hostname: x86-7 > > Building target platforms: x86_64 > > Building for target x86_64 > > Wrote: /builddir/build/SRPMS/NetworkManager-openvpn-0.7.0-13.svn3632.fc9.src.rpm > > LEAVE do --> > > > > > > Did I miss an outage notification? > > Anything I can do about it? > > > According to > http://koji.fedoraproject.org/koji/getfile?taskID=660521&name=root.log > you are missing build dependencies. > > As this is a build for f9-updates-candidates you may need to ask rel-eng > to add these packages to your buildroot. > > - Nigel > Yes, I figured that out too (with some little irc help), but I only need packages that are in updates already. Ive got them installed. So why are they not in the buildroot? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jun 13 12:25:09 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 13 Jun 2008 21:25:09 +0900 Subject: Buildsystem messed up? In-Reply-To: <1213358674.3195.3.camel@choeger6> References: <1213357922.3195.0.camel@choeger6> <485261CF.20602@nigelj.com> <1213358674.3195.3.camel@choeger6> Message-ID: <48526725.8050302@ioa.s.u-tokyo.ac.jp> Christoph H?ger wrote, at 06/13/2008 09:04 PM +9:00: > Am Samstag, den 14.06.2008, 00:02 +1200 schrieb Nigel Jones: >> Christoph H?ger wrote: >>> Hi, >>> >>> all my builds fail due to: >>> >> According to >> http://koji.fedoraproject.org/koji/getfile?taskID=660521&name=root.log >> you are missing build dependencies. >> >> As this is a build for f9-updates-candidates you may need to ask rel-eng >> to add these packages to your buildroot. >> >> - Nigel >> > > Yes, I figured that out too (with some little irc help), but I only need > packages that are in updates already. Ive got them installed. > So why are they not in the buildroot? Umm.. [tasaka1 at localhost ~]$ koji latest-pkg dist-f9-updates NetworkManager Build Tag Built by ---------------------------------------- -------------------- ---------------- NetworkManager-0.7.0-0.9.3.svn3623.fc9 dist-f9 dcbw [tasaka1 at localhost ~]$ koji latest-pkg dist-f9-build NetworkManager Build Tag Built by ---------------------------------------- -------------------- ---------------- NetworkManager-0.7.0-0.6.8.svn3669.fc8 dist-f9-override dcbw Something seems to be going wrong. (.fc8 package has "dist-f9-override" tag?) Perhaps anyway you should ask to rel-eng team what is happening. Regards, Mamoru From henriquecsj at gmail.com Fri Jun 13 12:31:08 2008 From: henriquecsj at gmail.com (Henrique "LonelySpooky" Junior) Date: Fri, 13 Jun 2008 09:31:08 -0300 Subject: Changing XDrawChem to Bkchem In-Reply-To: <48523994.9030408@hhs.nl> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> <1213333035.7634.1.camel@localhost.localdomain> <20080613082129.GB1149@mokona.greysector.net> <48523994.9030408@hhs.nl> Message-ID: <1213360268.7753.0.camel@localhost.localdomain> I'll try my best. Thank you all. > Yip, > > If you're willing to learn and invest some time into this I'm more then happy > to show you the ropes. > > Regards, > > Hans > -- Henrique "LonelySpooky" Junior Projeto Fedora Brasil From jonathan.underwood at gmail.com Fri Jun 13 13:16:20 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 13 Jun 2008 14:16:20 +0100 Subject: Changing XDrawChem to Bkchem In-Reply-To: <1213360268.7753.0.camel@localhost.localdomain> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> <1213333035.7634.1.camel@localhost.localdomain> <20080613082129.GB1149@mokona.greysector.net> <48523994.9030408@hhs.nl> <1213360268.7753.0.camel@localhost.localdomain> Message-ID: <645d17210806130616k419a1310o4dc0267b7f372232@mail.gmail.com> 2008/6/13 Henrique LonelySpooky Junior : > I'll try my best. > > Thank you all. > A starting point may be to look at the mandriva spec: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/contrib-SPECS/bkchem/bkchem.spec?revision=1.31&view=markup and the PLD spec http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/bkchem.spec?rev=1.36;content-type=text%2Fplain and tailoring them to meet fedora requirements. J. > >> Yip, >> >> If you're willing to learn and invest some time into this I'm more then happy >> to show you the ropes. >> >> Regards, >> >> Hans >> > -- > Henrique "LonelySpooky" Junior > Projeto Fedora Brasil > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jonathan.underwood at gmail.com Fri Jun 13 13:18:01 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 13 Jun 2008 14:18:01 +0100 Subject: Changing XDrawChem to Bkchem In-Reply-To: <1213360268.7753.0.camel@localhost.localdomain> References: <4f629b520806122026tdbfc93ct69f9e85d74ab781d@mail.gmail.com> <1213331426.18802.33.camel@ignacio.lan> <1213333035.7634.1.camel@localhost.localdomain> <20080613082129.GB1149@mokona.greysector.net> <48523994.9030408@hhs.nl> <1213360268.7753.0.camel@localhost.localdomain> Message-ID: <645d17210806130618j5f29a3f9p5738c0546158fb4d@mail.gmail.com> 2008/6/13 Henrique LonelySpooky Junior : > I'll try my best. > > Thank you all. > A starting point may be to look at the mandriva spec: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/contrib-SPECS/bkchem/bkchem.spec?revision=1.31&view=markup and the PLD spec http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/bkchem.spec?rev=1.36;content-type=text%2Fplain and tailoring them to meet fedora requirements. J. > >> Yip, >> >> If you're willing to learn and invest some time into this I'm more then happy >> to show you the ropes. >> >> Regards, >> >> Hans >> > -- > Henrique "LonelySpooky" Junior > Projeto Fedora Brasil > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From brucekeats at gmail.com Fri Jun 13 13:38:29 2008 From: brucekeats at gmail.com (Bruce Keats) Date: Fri, 13 Jun 2008 09:38:29 -0400 Subject: Increasing the size of the available entropy pool for /dev/random in Fedora? Message-ID: <6c0aa9500806130638g331d11dak5c8d3db2f7c5f766@mail.gmail.com> Hi, I am trying to increase the size of the available pool of entropy so that applications that use /dev/random won't block when trying to get 1K random bytes from /dev/random. In the 2.6.23.17 kernel, it appears that the sysctl (proc) interface no longer allows changes to the poolsize (/proc/sys/kernel/random/poolsize). I had a quick look at the random driver (kernel/drivers/char/random.c) and it looked to me that INPUT_POOL_WORDS was the variable. I went ahead and made the change and recompiled the kernel, but I still don't see the available entropy larger than 4K bits (512 bytes). When I check poolsize, it is now reported as 16384, but entropy_avail never seems to get larger than 4096. Even if I leave the system running overnight, the available entropy pool never seems to get larger than 4096. I have been looking at the code and the driver seems fairly convoluted, so I hope someone might save me some digging. Does anyone have any suggestions as to how to increase the available entropy pool size? Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Jun 13 14:06:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jun 2008 10:06:07 -0400 Subject: Buildsystem messed up? In-Reply-To: <48526725.8050302@ioa.s.u-tokyo.ac.jp> References: <1213357922.3195.0.camel@choeger6> <485261CF.20602@nigelj.com> <1213358674.3195.3.camel@choeger6> <48526725.8050302@ioa.s.u-tokyo.ac.jp> Message-ID: <1213365967.7006.0.camel@localhost.localdomain> On Fri, 2008-06-13 at 21:25 +0900, Mamoru Tasaka wrote: > Something seems to be going wrong. (.fc8 package has > "dist-f9-override" tag?) > Perhaps anyway you should ask to rel-eng team what is happening. I have no idea how that happened, but I fixed it. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From choeger at cs.tu-berlin.de Fri Jun 13 14:35:30 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 13 Jun 2008 16:35:30 +0200 Subject: Buildsystem messed up? In-Reply-To: <1213365967.7006.0.camel@localhost.localdomain> References: <1213357922.3195.0.camel@choeger6> <485261CF.20602@nigelj.com> <1213358674.3195.3.camel@choeger6> <48526725.8050302@ioa.s.u-tokyo.ac.jp> <1213365967.7006.0.camel@localhost.localdomain> Message-ID: <1213367730.3195.5.camel@choeger6> Am Freitag, den 13.06.2008, 10:06 -0400 schrieb Jesse Keating: > On Fri, 2008-06-13 at 21:25 +0900, Mamoru Tasaka wrote: > > Something seems to be going wrong. (.fc8 package has > > "dist-f9-override" tag?) > > Perhaps anyway you should ask to rel-eng team what is happening. > > I have no idea how that happened, but I fixed it. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list I did not get it to work, there are still the same packages missing. Do I have to do something to cleanly rebuild or so? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jun 13 15:42:15 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 14 Jun 2008 00:42:15 +0900 Subject: Buildsystem messed up? In-Reply-To: <1213367730.3195.5.camel@choeger6> References: <1213357922.3195.0.camel@choeger6> <485261CF.20602@nigelj.com> <1213358674.3195.3.camel@choeger6> <48526725.8050302@ioa.s.u-tokyo.ac.jp> <1213365967.7006.0.camel@localhost.localdomain> <1213367730.3195.5.camel@choeger6> Message-ID: <48529557.6000704@ioa.s.u-tokyo.ac.jp> Christoph H?ger wrote, at 06/13/2008 11:35 PM +9:00: > Am Freitag, den 13.06.2008, 10:06 -0400 schrieb Jesse Keating: >> On Fri, 2008-06-13 at 21:25 +0900, Mamoru Tasaka wrote: >>> Something seems to be going wrong. (.fc8 package has >>> "dist-f9-override" tag?) >>> Perhaps anyway you should ask to rel-eng team what is happening. >> I have no idea how that happened, but I fixed it. >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I did not get it to work, there are still the same packages missing. > Do I have to do something to cleanly rebuild or so? Seems okay now. http://koji.fedoraproject.org/koji/taskinfo?taskID=660847 Mamoru From mmcgrath at redhat.com Fri Jun 13 16:14:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 13 Jun 2008 11:14:15 -0500 (CDT) Subject: Outage Notification - 2008-06-16 03:00 UTC Message-ID: There will be an outage starting at 2008-06-16 03: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-06-16 03:00 UTC' Affected Services: Websites (wiki only) Smolts.org Cacti Unaffected Services: CVS / Source Control Buildsystem Database DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/623#preview Reason for Outage: The new db1 is installed and ready. This is our primary mysql database and backup for postgres. The OS and storage has already been prepared. Its just a matter of making db1 unavailable, doing a dump, copy, import and IP rename. I expect things to go smoothly as there are no major changes other than hardware. 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 vonbrand at inf.utfsm.cl Fri Jun 13 17:26:43 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 13 Jun 2008 13:26:43 -0400 Subject: Increasing the size of the available entropy pool for /dev/random in Fedora? In-Reply-To: <6c0aa9500806130638g331d11dak5c8d3db2f7c5f766@mail.gmail.com> References: <6c0aa9500806130638g331d11dak5c8d3db2f7c5f766@mail.gmail.com> Message-ID: <200806131726.m5DHQhAf013276@laptop13.inf.utfsm.cl> Bruce Keats wrote: >[Too little entropy available in /dev/random] Use /dev/urandom, or (better yet) seed a "good" RNG (e.g., the one in glibc or Mersenne twister) and criptographically hash its output if really needed. [AFAIR, the random pool is only 512 bytes in size, so it can't contain more "entropy" than that] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From jonstanley at gmail.com Fri Jun 13 18:54:45 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 13 Jun 2008 14:54:45 -0400 Subject: Vendor tags Message-ID: Just FYI in case you see me around your packages - there are some packages that have weird vendor tags in the built RPM in F9. Some that came directly from FC-6 still have a vendor tag of 'Red Hat, Inc.' and some from the early days of koji have a vendor tag that says Koji. I'm making sure that vendor is not in the spec file for all of these, bumping, and rebuilding in rawhide. Having the same vendor tags as RHEL cause problems in various circumstances, so I thought this would be a good (small) cleanup project for F10. I'm also taking the opportunity to fix any license tag issues that I find. If your packages have ACL's (a lot of them that I'm running across), I'm filing bugs against them to have you rebuild and consider removing ACL's. All of these bugs will have the status whiteboard of 'badVendor' Thanks! -Jon From valent.turkovic at gmail.com Fri Jun 13 19:26:23 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 13 Jun 2008 21:26:23 +0200 Subject: Features that would be great for Fedora 10 In-Reply-To: <7f692fec0806120146r3fe63f88gf568d9049b7b558b@mail.gmail.com> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> <7f692fec0806120146r3fe63f88gf568d9049b7b558b@mail.gmail.com> Message-ID: <64b14b300806131226q4902c860v6d6788c7bc93897e@mail.gmail.com> On Thu, Jun 12, 2008 at 10:46 AM, Yaakov Nemoy wrote: > On Thu, Jun 12, 2008 at 10:30 AM, Valent Turkovic > wrote: >> Here are just few features that I believe would be great for Fedora 10 to have: >> >> 1. RFE: Add desktop folder with examples of what "fedora thing" can do :) >> https://bugzilla.redhat.com/show_bug.cgi?id=315171 >> >> Lisa gets Fedora 10 Live CD from her Joe (her geeky boyfriend) and >> puts it in her laptop. After she gets presented with a different >> looking desktop that >> she is usually presented she doesn't know what this "fedora thing" >> actually does and can do. Joe gives her a CD version of Ubuntu, after >> loosing temper with trying to explain what fedora can actually do. >> Lisa puts Ubuntu CD in and after few minutes she clicks through a few >> examples on her new desktop and sees that this "Ubuntu thing" does >> more that that "Fedora thing" like plays music & videos, shows nice >> spreadsheets and other documents. >> >> It would be great for Fedora to add directory on desktop with some >> nice examples what Fedora and OSS can do. There are great videos on >> redhat magazine page and I'm sure there are other great resources - >> new users need to be exposed to them in this way. Also there is a >> initiative for contriburots to make screencasts and this feature would >> be a great match with it if they merged together. > > How about a welcome screen that pops up everytime you boot up, with an > obnoxious shortcut to it in the top of our 'go' menu. No matter how > many times you 'disable this the next time it boots', it still nags > you to install aMSN. > > > > I think a folder might not be the best interface, but even so, putting > in a default bookmarks like we do already is not really effective > either. Maybe this is something the myFedora guys might want to look > at at some point. > > -Yaakov I understand your sarcasm and appreciate it, I know that dolder may not be the best interface but that is just one idea. I must admit that I found folder that Ubuntu had (not sure if it still has it because I don't use it any more) with some OpenOffice calc and Writer example files is great for demoing what can be done with FLOSS software and all from a live CD. So if you and others have other ideas jus keem them flowing... ps. what do you think about other two points? Cheers, 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 Fri Jun 13 20:06:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Jun 2008 01:36:40 +0530 Subject: Collective maintenance Message-ID: <4852D350.20709@fedoraproject.org> Hi, A friend of mine pinged me and asked about the status of this bug https://bugzilla.redhat.com/show_bug.cgi?id=442921 Just using this as an example here since it a simple one. This is apparently just a simple missing dependency but hasn't been fixed in a while. Just using this as a example, assuming that the maintainer is busy, on vacation or something and cvsextras is open, many others could fix this issue bypassing the primary maintainer for the moment but there doesn't seem to be any policy on what kind of fixes can be collectively done. I remember seeing similar discussions before so this isn't a isolated problem. Do we need some guidelines on this so folks like Michael Schwendt (again, just as an example specific to this bug report) can just go ahead and fix the problem noting the details in the commit message instead of having to file a bug report? Rahul From limb at jcomserv.net Fri Jun 13 20:17:00 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 13 Jun 2008 15:17:00 -0500 (CDT) Subject: Collective maintenance In-Reply-To: <4852D350.20709@fedoraproject.org> References: <4852D350.20709@fedoraproject.org> Message-ID: <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> > Hi, > > A friend of mine pinged me and asked about the status of this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=442921 > > Just using this as an example here since it a simple one. This is > apparently just a simple missing dependency but hasn't been fixed in a > while. Just using this as a example, assuming that the maintainer is > busy, on vacation or something and cvsextras is open, many others could > fix this issue bypassing the primary maintainer for the moment but there > doesn't seem to be any policy on what kind of fixes can be collectively > done. I remember seeing similar discussions before so this isn't a > isolated problem. Do we need some guidelines on this so folks like > Michael Schwendt (again, just as an example specific to this bug report) > can just go ahead and fix the problem noting the details in the commit > message instead of having to file a bug report? My left brain side says, maybe we need a policy. My right brain side says, if the acl is open, and you can fix it, fix it. Might actually check out doing that on some easy bugs I've reported. -J > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jspaleta at gmail.com Fri Jun 13 20:23:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jun 2008 12:23:41 -0800 Subject: Features that would be great for Fedora 10 In-Reply-To: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> Message-ID: <604aa7910806131323w673e97ccw62addbed99600207@mail.gmail.com> On Thu, Jun 12, 2008 at 12:30 AM, Valent Turkovic wrote: > 2. RFE: Desktop shortcut for joining Fedora IRC (aka "Get Live Help"): > https://bugzilla.redhat.com/show_bug.cgi?id=430217 and > https://bugzilla.redhat.com/show_bug.cgi?id=179703 > > Fedora is about freedom+communication, right? Why not make this > statement more that just a nice slogan. If you installed sabayon linux > you could experienced for yourself what this really means. I as a new > user to gentoo (sabayon is based on gentoo) was really blown away with > this feature. It is really, really simple to implement and gives a > real meaning to a communication friendly linux distro. This isn't a particularly new idea.. in fact I was active in exactly this sort of channel back when Ximian produced a gnome 2 desktop that lived on top of rhl 7.x as an add-on. What I have to say next is grounded on lessons learned from multiple years of personal experience with helping in irc help channels. I will support adding a live help button or equivalent if and only if there is an effort to identify and organize expert 'helpers' who can agree to a code of conduct and to lead by example in interactions with new users and less experienced helpers. Additionally this group would need to make an effort to organize how they will spread themselves out to cover as much in-channel time as the group is able to cover. Having all available expert helpers volunteer to be in channel from 4 to 6 pm EST, isn't going to create a pervasive culture of right action. If we are going to put the live help in users faces with the expectation to use it, then I expect a group of people in our contributor base to stand up and be accountable for how well such a channel runs and to make sure users are getting the help they need. This group would also need to make an effort to service not just the main English channel but also other language specific channels as best they are able. Greg's translator service idea could help with that. -jef From sundaram at fedoraproject.org Fri Jun 13 20:28:26 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Jun 2008 01:58:26 +0530 Subject: Collective maintenance In-Reply-To: <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> References: <4852D350.20709@fedoraproject.org> <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> Message-ID: <4852D86A.8000706@fedoraproject.org> Jon Ciesla wrote: >> Hi, >> >> A friend of mine pinged me and asked about the status of this bug >> >> https://bugzilla.redhat.com/show_bug.cgi?id=442921 >> >> Just using this as an example here since it a simple one. This is >> apparently just a simple missing dependency but hasn't been fixed in a >> while. Just using this as a example, assuming that the maintainer is >> busy, on vacation or something and cvsextras is open, many others could >> fix this issue bypassing the primary maintainer for the moment but there >> doesn't seem to be any policy on what kind of fixes can be collectively >> done. I remember seeing similar discussions before so this isn't a >> isolated problem. Do we need some guidelines on this so folks like >> Michael Schwendt (again, just as an example specific to this bug report) >> can just go ahead and fix the problem noting the details in the commit >> message instead of having to file a bug report? > > My left brain side says, maybe we need a policy. My right brain side > says, if the acl is open, and you can fix it, fix it. The problem there is one of expectations. Some maintainers are completely ok with this. Personally, I don't have a problem with anyone fixing any bugs on the packages I maintain and would be thankful for that. Other maintainers want more "ownership" and would prefer to be personally notified or do the changes themselves. Technically, we are good to go in most cases since the ACL's are open for majority of the packages. Socially, we are not since there isn't any policy and people don't want to offend existing maintainers by bypassing them (with notable exceptions like the Red Hat desktop team). I would prefer a policy that blurred the line of ownership more to a culture of collective maintenance and sets the right expectations for everyone involved. Then we can follow that up by having bugzilla be aware of easy to fix bugs and people who are interested in doing simple fixes can do that when they find time in between sponsors, SIG's and so on. Rahul From jkeating at j2solutions.net Fri Jun 13 20:27:46 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 13 Jun 2008 16:27:46 -0400 Subject: Collective maintenance In-Reply-To: <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> References: <4852D350.20709@fedoraproject.org> <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> Message-ID: <9339c38c0806131327h6b39c2a2t6715cf68c64142eb@mail.gmail.com> On Fri, Jun 13, 2008 at 4:17 PM, Jon Ciesla wrote: > > > Hi, > > > > A friend of mine pinged me and asked about the status of this bug > > > > https://bugzilla.redhat.com/show_bug.cgi?id=442921 > > > > Just using this as an example here since it a simple one. This is > > apparently just a simple missing dependency but hasn't been fixed in a > > while. Just using this as a example, assuming that the maintainer is > > busy, on vacation or something and cvsextras is open, many others could > > fix this issue bypassing the primary maintainer for the moment but there > > doesn't seem to be any policy on what kind of fixes can be collectively > > done. I remember seeing similar discussions before so this isn't a > > isolated problem. Do we need some guidelines on this so folks like > > Michael Schwendt (again, just as an example specific to this bug report) > > can just go ahead and fix the problem noting the details in the commit > > message instead of having to file a bug report? > > My left brain side says, maybe we need a policy. My right brain side > says, if the acl is open, and you can fix it, fix it. > > Might actually check out doing that on some easy bugs I've reported. > It's a tough call, and really comes down to an issue by issue thing. In this issue there are a couple things going against it. 1) It's a bug regarding a released version, so any changes would require bodhi updates 2) it's essentially enabling a feature, that may or may not work and one would hope that if there was a reason this wasn't turned on, it would be listed in the spec file. For those reasons, I wouldn't be quick to jump in and try to fix it. It'd be worth doing a scratch build just to see if it would compile, and maybe work but I still wouldn't feel comfortable without talking to the maintainer in question first. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From aoliva at redhat.com Fri Jun 13 21:08:39 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 18:08:39 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D6276.4000308@gmail.com> (Les Mikesell's message of "Mon\, 09 Jun 2008 12\:03\:50 -0500") References: <484D6276.4000308@gmail.com> Message-ID: On Jun 9, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >> The tolerance for non-Free Software in Linux's sources (and anywhere >> else), be it non-Free firmware blobs, be it drivers developed under >> NDA (whose code is obscured and harder or impossible to understand and >> adapt to one's needs as a consequence of the NDA), all revolve around >> acceptance, endorsement and even promotion of unethical practices that >> I don't want to condone or participate in. > Not wanting to participate in distributing code without source is one > thing; calling it unethical is something else and implies that > everyone else is wrong for doing it. Merely distributing non-Free Software is not unethical [intent or disregard for harm upon others], it's only immoral [harmful to society at large]. It's imposing the restrictions that render Software non-Free that's unethical. Accepting them, passing them on, encouraging others to do so are all bad, but they're not as much of an aggression as initiating the disrespect for others. In fact, most users who accept such disrespect, and many who pass it on, are more victims, even though they're ultimately helping the aggressors. Failure to resist violence does encourage the aggressor to keep on its act, but being overpowered is not the victim's fault. > And again, vendors who distribute code without source are not > necessarily unethical I don't see how else to describe it. It's willful deprivation of useful information for understanding and improvement of one's copy of a program, and deprivation of additional contributions to society. I don't care how market pressure or other reasons one may use to justify such acts to one's own conscience. Such reasonings as "it makes business sense" or "it's more profitable" or "other businesses do it" could be used to justify slavery as well. Although slavery deprives people of more fundamental freedoms, dependency on technology nowadays is growing the importance of the not-so-fundamental human rights that amount to the 4 essential freedoms of the Free Software definition. > Personally I consider competition and equality (i.e. having your > choice of components) to be much more important than source > availability for any component. Source code is essential for only two of the four freedoms, so don't bother focusing only on that part. Don't let yourself be misled by the term 'Open Source'. Even open source activists know it's not just about the source being open. It's a matter of not being artificially prevented from doing a number of things that every software user should be entitled to do with their own copies of software, just like they're entitled to store whatever they like in cupboards they purchase, figure out their functioning, remove internal walls to make room for larger items, and create other identical or different cupboards for themselves and for others. Same goes for chairs, tables, houses, bikes, etc. The fact that software is mostly intangible should make all this all easier, rather than becoming a tool to create dependency and control people. > Thus restrictions on combining and redistributing components are > much more evil, unethical, and detrimental to long term developments > than any current NDA or binary blob could ever be. I agree with that to a large extent, but it's the law. As long as the law is the way it is, it can be at least put to a better use, to maintain a level playing field. Remember, the GPL doesn't prohibit combining or redistribution, it's the law that does; the GPL permits very broad cases of combination and redistribution that respect others' freedoms. But then, see, I'm not trying to prohibit anyone from creating this combination that contains non-Free Software or distributing it. What I'm concerned about is maintaining a variant that doesn't contain any such non-Free Software, and offering it to whomever might be interested in using it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Fri Jun 13 21:27:30 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 18:27:30 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D6D5B.5050306@gmail.com> (Les Mikesell's message of "Mon\, 09 Jun 2008 12\:50\:19 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <484D6D5B.5050306@gmail.com> Message-ID: On Jun 9, 2008, Les Mikesell wrote: > Even if such a copyright existed, it would not resemble the GPL which > explicitly permits works with other terms to be aggregated Subject to certain conditions, such as that the whole derivative work be offered under the terms of the GPL, the corresponding source code for the entire work be offered, etc. The exception is the narrow case in which you can show that you're merely aggregating the works in a volume of storage or distribution medium. But the moment you claim the aggregate containing a GPLed work is a work in itself, say by claiming copyright over the collection of programs adapted and engineered so as to work as a whole, and attaching a license to it, it's no longer clear that you're still covered by the exception, after all the whole work is evidently a derived work from the GPLed work, and after all the adaptation, it's not clear at all that it is mere aggregation. > You'll note that printed combinations of different works do exist > and the terms under which each is included do not affect the others. Could this be just because the terms of each grant permission for the publication of collective works derived from it, not subject to any conditions? > And thus it has no relationship to other things that might be carried > in the same container, regardless of the form of that container. The important question is whether or not the container amounts to a copyrightable work, evidently derived from the contained parts if so. > Firmware that happens to live in a vmlinuz container Forget the kernel binary. Think of the sources. What is/are the license/s of the work published as linux-2.6.25.tar.bz2? Do you have permission to modify any part of it you want, according to the terms of the GPL? There's no dispute that the firmwares are independent works and that they stand on their own. The important question is whether the GPLed portions of the *kernel* are an independent work that stands on its own. ATM, it doesn't look like it is. The only thing we get is a work that claims to be an aggregate, but if we go looking for the separate pieces, we can find all but the biggest of them. And it's this biggest piece I'm concerned about. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From pertusus at free.fr Fri Jun 13 21:32:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 13 Jun 2008 23:32:43 +0200 Subject: Collective maintenance In-Reply-To: <4852D350.20709@fedoraproject.org> References: <4852D350.20709@fedoraproject.org> Message-ID: <20080613213243.GA2659@free.fr> On Sat, Jun 14, 2008 at 01:36:40AM +0530, Rahul Sundaram wrote: > Hi, > > A friend of mine pinged me and asked about the status of this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=442921 > > Just using this as an example here since it a simple one. This is > apparently just a simple missing dependency but hasn't been fixed in a > while. Just using this as a example, assuming that the maintainer is > busy, on vacation or something and cvsextras is open, many others could > fix this issue bypassing the primary maintainer for the moment but there > doesn't seem to be any policy on what kind of fixes can be collectively > done. There is a policy, here: http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages But it doesn't cover the case you are seing, this is the typical 'easyfix but maintainer is not responding'. > I remember seeing similar discussions before so this isn't a > isolated problem. Indeed. I keep asking people to do some guidelines, I think that it is unfortunate, but it happens too often in fedora. I have easyfix or bugs where I propose to do the work that are opened for months if not more, if I was a casual user, I would find this unacceptable. > can just go ahead and fix the problem noting the details in the commit > message instead of having to file a bug report? I don't think this is right either. In my opinion cases where it is ok to do something like that are rightly covered in the policy mentionned above. I think that a specific policy is needed which would be more similar with the missing in action policy, but for a particular easyfix bug where somebody is ready to do the work, and not for a maintainer. Some people proposed to escalate to FESCO such cases, but I think it is much too common to use FESCo escalation for those cases. -- Pat From aoliva at redhat.com Fri Jun 13 21:35:24 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 18:35:24 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609204314.GA4009@devserv.devel.redhat.com> (Alan Cox's message of "Mon\, 9 Jun 2008 16\:43\:14 -0400") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> Message-ID: On Jun 9, 2008, Alan Cox wrote: > the tg3 file may be available on its own from your own tree. So, before gNewSense cleaned up the kernel in a way that ended up being called linux-libre, it didn't exist as a separate work to be aggregated into other works and result in linux-2.6.25.tar.bz2? And then, since it clearly wasn't the case that these works released under the name linux-libre were combined with a bunch of firmwares to form the non-libre linux releases (there's a causal loop in there somewhere), how does the fact that it's accidentally available from my own tree matter? That's not how copyright works, and you know that. >> > and also on the boundaries of contract created by copyright. >> >> ?!?!? Copyright does not create contracts. Copyright creates > Bingo.. and copyright does not give you power over other works Nobody's talking about power over other unrelated works. We're talking about derivative works formed by combining together multiple works. There's no doubt that copyright does give the holder power over this case. The only possible doubt is whether the combination forms a copyrightable work. > I do not need your permission to put your book on the same bookcase > as someone elses book. The result is clearly not a copyrightable work. > Nor do you have any standing to impose restrictions relating > to other works via copyright. True, but this is a distraction. Nobody's restricting other works. The issue the debate was turned into is whether the GPLed work can be distributed in this way. The more people insist 'taking it out will break', the weaker the 'mere aggregation' defense becomes. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From mschwendt at gmail.com Fri Jun 13 21:32:35 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Jun 2008 23:32:35 +0200 Subject: Collective maintenance In-Reply-To: <9339c38c0806131327h6b39c2a2t6715cf68c64142eb@mail.gmail.com> References: <4852D350.20709@fedoraproject.org> <52525.198.175.55.5.1213388220.squirrel@mail.jcomserv.net> <9339c38c0806131327h6b39c2a2t6715cf68c64142eb@mail.gmail.com> Message-ID: <20080613233235.b96aba94.mschwendt@gmail.com> On Fri, 13 Jun 2008 16:27:46 -0400, Jesse Keating wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=442921 > 1) It's a bug regarding a released version, so any changes would require > bodhi updates Plus: - check other open bugs - check whether there's a new upstream release Else it would be a test update just for this fix, and possibly another one right after that because the maintainer awakes and dislikes the small fix-update that doesn't address other issues. It could even be that additional problems are not covered in bugzilla. I wouldn't want to work on this bug without talking to the package maintainer first. > 2) it's essentially enabling a feature, that may or may not work and one > would hope that if there was a reason this wasn't turned on, it would be > listed in the spec file. > > For those reasons, I wouldn't be quick to jump in and try to fix it. It'd > be worth doing a scratch build just to see if it would compile, and maybe > work but I still wouldn't feel comfortable without talking to the maintainer > in question first. And the maintainer already works with the next upstream release series [in rawhide]. It would not be the first time that those packages are pushed to the other branches. It has been done before with Audacious, even with changes in the plugin ABI+API. From aoliva at redhat.com Fri Jun 13 21:47:29 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 18:47:29 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609205528.GB4009@devserv.devel.redhat.com> (Alan Cox's message of "Mon\, 9 Jun 2008 16\:55\:28 -0400") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: On Jun 9, 2008, Alan Cox wrote: > On Mon, Jun 09, 2008 at 02:54:07PM -0300, Alexandre Oliva wrote: >> license or by copyright law. As I stated before, it's a moral, >> ethical and social issue, even if it's also a negligible legal issue. > You can load the CPU firmware updates by > - Having the BIOS load it > - Having the kernel load it > - Having user space apps load it This completely neglects the question as to how you got the firmware update in the first place. It's like going "Your honor, I shouldn't be punished for the alleged murder because I didn't kill the victim, the bullet did. I just pulled the trigger. Anyone else could have done that and the victim would end up dead just the same, so why should I be punished for something that anyone else could have done?" What kind of a defense is that? It's obvious that who put the bullet in motion has responsibility over the result, even though the victim could have got the bullet in her chest with help from anyone else, or even without help. Likewise, it's obvious that whoever distributed the firmware to you has responsibility over the result, even though you could have got the firmware from many others, or even got them straight from the vendor. Of course, in the case of non-Free Software, the bullet doesn't kill right away; it rather contains addictive poison that the vendor puts in there to get the victims dependent, paralyzed and even thinking it's good for them. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From sundaram at fedoraproject.org Fri Jun 13 21:50:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Jun 2008 03:20:10 +0530 Subject: Collective maintenance In-Reply-To: <20080613213243.GA2659@free.fr> References: <4852D350.20709@fedoraproject.org> <20080613213243.GA2659@free.fr> Message-ID: <4852EB92.9050405@fedoraproject.org> Patrice Dumas wrote: > Indeed. I keep asking people to do some guidelines, I think that it is > unfortunate, but it happens too often in fedora. I have easyfix or bugs > where I propose to do the work that are opened for months if not more, > if I was a casual user, I would find this unacceptable. If you on IRC or if you can mail me offlist, we can work on a policy (or a modification of the existing one) and propose that instead of waiting for this to be done by others. Since you are keenly aware of the problem that I am talking about, your help is appreciated. Thanks. Rahul From lesmikesell at gmail.com Fri Jun 13 22:24:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 13 Jun 2008 17:24:48 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: <4852F3B0.2080202@gmail.com> Alexandre Oliva wrote: > > Likewise, it's obvious that whoever distributed the firmware to you > has responsibility over the result, even though you could have got the > firmware from many others, or even got them straight from the vendor. Errr, what? Is this list, or the computers that carry it, responsible for the odd bit of content above, or are you? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Fri Jun 13 22:33:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 13 Jun 2008 17:33:36 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> Message-ID: <4852F5C0.4060400@gmail.com> Alexandre Oliva wrote: > >> Nor do you have any standing to impose restrictions relating >> to other works via copyright. > > True, but this is a distraction. Nobody's restricting other works. > The issue the debate was turned into is whether the GPLed work can be > distributed in this way. The more people insist 'taking it out will > break', the weaker the 'mere aggregation' defense becomes. The way they are aggregated is the distraction since the unrelated nature of the components would be more obvious if there was a file-level split between firmware payload and deployment code. But whether they are temporarily aggregated into the same file or not doesn't change their underlying status as different things. -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Fri Jun 13 22:34:14 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 14 Jun 2008 00:34:14 +0200 Subject: Features that would be great for Fedora 10 References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> <604aa7910806131323w673e97ccw62addbed99600207@mail.gmail.com> Message-ID: <689bi5xjce.ln2@ppp1053.in.ipex.cz> On 2008-06-13, 20:23 GMT, Jeff Spaleta wrote: > I will support adding a live help button or equivalent if and > only if there is an effort to identify and organize expert > 'helpers' who can agree to a code of conduct and to lead by > example in interactions with new users and less experienced > helpers. What?s wrong with #fedora on Freenode? Mat?j From ivazqueznet at gmail.com Fri Jun 13 22:52:41 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 13 Jun 2008 18:52:41 -0400 Subject: Features that would be great for Fedora 10 In-Reply-To: <689bi5xjce.ln2@ppp1053.in.ipex.cz> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> <604aa7910806131323w673e97ccw62addbed99600207@mail.gmail.com> <689bi5xjce.ln2@ppp1053.in.ipex.cz> Message-ID: <1213397561.18802.52.camel@ignacio.lan> On Sat, 2008-06-14 at 00:34 +0200, Matej Cepl wrote: > On 2008-06-13, 20:23 GMT, Jeff Spaleta wrote: > > I will support adding a live help button or equivalent if and > > only if there is an effort to identify and organize expert > > 'helpers' who can agree to a code of conduct and to lead by > > example in interactions with new users and less experienced > > helpers. > > What?s wrong with #fedora on Freenode? It's had free reign for too long. Getting everyone in there to adhere to some sort of code of conduct is an upward battle at best. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Jun 13 23:00:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jun 2008 15:00:34 -0800 Subject: Features that would be great for Fedora 10 In-Reply-To: <689bi5xjce.ln2@ppp1053.in.ipex.cz> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> <604aa7910806131323w673e97ccw62addbed99600207@mail.gmail.com> <689bi5xjce.ln2@ppp1053.in.ipex.cz> Message-ID: <604aa7910806131600g2eca48dbs9e80a2a898ae79a9@mail.gmail.com> On Fri, Jun 13, 2008 at 2:34 PM, Matej Cepl wrote: > On 2008-06-13, 20:23 GMT, Jeff Spaleta wrote: >> I will support adding a live help button or equivalent if and >> only if there is an effort to identify and organize expert >> 'helpers' who can agree to a code of conduct and to lead by >> example in interactions with new users and less experienced >> helpers. > > What's wrong with #fedora on Freenode? Did I say which channel to use? No. I said I want to see a group of people stand up and be accountable and to adhere to a code of conduct. If those people want to use #fedora...fine. If they want a fresh start with a new channel.. fine. But regardless of what channel is used, I want people to affirm a code of conduct and stand up to be accountable as expert helpers and to organize what helping actually mean so that over time we get better at it. And whatever plan that group comes up with, is sure as hell better be something more elaborate than a bot that says "RTFM" in response to every question. -jef From aoliva at redhat.com Fri Jun 13 23:20:52 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 20:20:52 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213111970.32207.835.camel@pmac.infradead.org> (David Woodhouse's message of "Tue\, 10 Jun 2008 16\:32\:50 +0100") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> Message-ID: > On Tue, 2008-06-10 at 10:43 -0400, Alan Cox wrote: On Jun 10, 2008, David Woodhouse wrote: > Because they have been assembled into a collective whole; the bzImage > file which is distributed and used as a single entity, and which makes > use of both the firmware and the GPL'd kernel code. And some people even go as far as claiming this whole is under the GPL, which is evidently false. > Such a wide-sweeping exemption would effectively render the > preceding two paragraphs entirely redundant. Yup. Which would be inconsistent with the way these things would be interpreted in a court of law. "If interpreting this sentence this way renders this other useless or nonsensical, while there's another interpretation that doesn't, then the former can't be the correct interpretation". > And nothing "magically becomes GPL". Either it _is_ available under a > GPL-compatible licence and you are permitted to incorporate it into a > collective work under the terms of the GPL, or not, and you may not do > so. There's no magic involved. And then, if you do distribute the work you got under the GPL in spite of not having permission to do so in a particular way, you're not only infringing on copyrights, you're also getting your license over the work revoked, so you no longer have permission to modify or distribute it in any other way unless you manage to reinstate the license. >> Take the cases you think are a collective/derivative and the cases >> you think are not and define a test by which this can be >> ascertained, then perhaps I can see what you are trying to argue.. > As I said, it is a grey area. There is no easy test. And there's no reason why it's our burden to provide such a test. It suffices that we provide one interpretation that a court of law could possibly accept. It doesn't even have to be convincing for our biased interlocutors, for it would be enough to convince an unbiased court. > It _might_ even (and I suspect we should hope that it does) cover > Linux distributions with many programs collected together for > convenient installation. When such distros come with a copyright notice over the collective work, a license for the whole, and the various pieces were customized to operate as a unit, it would be a bit difficult to argue it's not a derivative/collective work rather than mere aggregation, methinks out loud. > But when it comes to such things as a bzImage file which contains > both a driver for some hardware _and_ the firmware which drives it, > and which will not operate on that hardware unless both of those > fundamentally intertwined parts are present, I do not believe that > is covered by the exception. I think the case of bzImage may actually be more defensible than that of combined sources, in which a single file contains both GPLed and GPL-incompatible code, and if you just take out the GPL-incompatible code (is that a modification? to which code, under which license?) it won't even compile. Say, the bzImage directly containing these is not all that different from concatenating to the bzImage an initrd containing both modules and firmwares. The only doubt is whether there's still an identifiable separate work in the former case that amounts to the GPLed source code. It's clear that there is such a work in the initrd case, and it's clear that the firmware is a separate work in both cases. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ndbecker2 at gmail.com Fri Jun 13 23:39:57 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 Jun 2008 19:39:57 -0400 Subject: Changing noarch package to arch Message-ID: Cython was a noarch python package, but cython-0.9.8 will be arch-specific. Is there something special that needs to be done to handle this? From aoliva at redhat.com Fri Jun 13 23:43:12 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 20:43:12 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484EAC68.2020303@gmail.com> (Les Mikesell's message of "Tue\, 10 Jun 2008 11\:31\:36 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> Message-ID: On Jun 10, 2008, Les Mikesell wrote: > You aggregate something for distribution. It's not a whole unless the > components are combined. And while this may be a fuzzy area for > things covered by the stock GPL, the version that covers Linux > specifically says Parse error, end of sentence not detected. Please fix and recompile ;-) > No, what exempts it is the fact that they are separate things both in > their origin and destination. And how about during the split-second in which distribution occurs? Aren't the components combined at that time? Because, remember, it's distribution that's regulated by copyrigth law. Not the origin, not the destination. > When that was written and for a long time after, there was no GPL'd > OS, I don't think there is any of these today. Even Fedora, that purported to be under GPLv2, fixed that mistake some time ago, adjusting the license over the collective work so as to say something to the effect that "it's GPLv2 except in as much as this would conflict with the license of the specific package". > No, you can take separate works and put them together as long as they > remain separate works - as the stuff loaded into a device's firmware > is separate from the kernel. You're looking at only one side of the question. The other is, is the kernel separate from the device's firmware? As of today, it very clearly isn't. Or, what evidence can you provide that the kernel is an independent work from the firmwares, against the various pieces of evidence that it is dependent on them? > Temporarily aggregating two separate items into one storage container > doesn't change the fact that they are separate items. Maybe the *temporarily* here is important. What if it's permanent, and you're subject to verbal attacks if you as much as mention the possibility of separating them because this would break one of them? >> I believe that exception is intended for things such as magazine cover >> CDs, carrying a bunch of mostly unrelated software. > Please... try to imagine the time when that was written and think > about tapes full of commercial software instead. Or rather think about the tapes full of GNU software under GPL, LGPL and a bunch of other Free Software packages under various other licenses, some GPL-compatible, some not, built for various operating systems. > In the past the FSF has claimed that something should be considered a > derived work and covered by the GPL if it needed a GPL'd library to > function, even if it was not distributed together. IIRC the reasoning goes like, when it is linked with the library, or gets code from library header files, the copied portions provide strong indication that the program was developed as a work based on the library. And then, the copyrightable copied portions actually make the resulting work actually derived from the library, even if its sources and object files weren't. And then, if you use dynamic linking, this copies far less from the library, but it doesn't change the status in any meaningful way. >> But I think we can agree that _until_ there's a ruling, including the >> firmware in the kernel is just a gratuitous risk. > The same risk goes with any GPL covered work. Nope. The risk that there might be some unknown restricted portion of code hiding in a GPLed program is quite different from that of a known restricted portion. There's even the issue of willful infringement and accepting the calculated risk. > It would make the fact that the firmware images are separate items > more obvious And it would make the kernel a more clearly separate item again. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From dev at nigelj.com Fri Jun 13 23:54:52 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 14 Jun 2008 11:54:52 +1200 Subject: Changing noarch package to arch In-Reply-To: References: Message-ID: <485308CC.8040708@nigelj.com> Neal Becker wrote: > Cython was a noarch python package, but cython-0.9.8 will be arch-specific. > > Is there something special that needs to be done to handle this? > > I don't think there is, just (preferably) make sure that it builds on the big four (i386, x86_64, ppc, ppc64), I don't like the idea of removing functionality for arches all of a sudden. Other than that, just follow the python packaging guidelines and you'll be home free. - Nigel From aoliva at redhat.com Sat Jun 14 00:09:02 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 21:09:02 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484D9F06.1020407@gmail.com> (Les Mikesell's message of "Mon\, 09 Jun 2008 16\:22\:14 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <484D5C2B.4010700@gmail.com> <484D77CF.5030507@gmail.com> <484D9F06.1020407@gmail.com> Message-ID: On Jun 9, 2008, Les Mikesell wrote: > What I don't understand is why you think there is some requirement in > terms of page boundaries or storage mechanism involved in copyright > separation. I've never seen any such thing. Mainly because typesetting, line- and page-breaking for a specific rendering might very well be regarded as modifications for some kinds of works. Heck, even changing the fonts and their relative sizes may amount to a modification. Similarly, if you remove the firmware from the middle of the sources of a C file where they appear, you have to make further adjustments such that it as much as compiles again. > No, it screams common storage, particularly when you know that it runs > on separate hardware elements and can't possibly be a single work when > it executes. The fact that it runs on something is completely irrelevant. That's what makes it software, but it doesn't change in any way how copyright applies to it (except here in Brazil, as it turns out, because there's a separate copyright-like law for software) >> To be separate works, you'd have to start out by being able to >> point at and obtain both/all the works separately. > Where is that requirement stated? Why should it have to be? Since when does separate mean something other than separate? How could inseparable works be separate independent works? > I believe there there wouldn't be any difference if the identical > content were already in ROM There would. You'd have to modify the GPLed code to cope with this. And you'd need copyright permission to do that. > This might be made more clear if the loader is generalized and the > contents separated so that it is obvious that changes in firmware > contents do not need modifications in the GPL'd mechanism Aha, *now* we're getting somewhere. Yes, the problem is not that the firmware is not a separate work. The problem is that the GPLed code at some point became a derived work from these originally-separate works. And, per the GPL, the whole could only be distributed together under the GPL, but one of the originally-separate works can't be distributed like that. Oops. > It is an aggregation, explicitly permitted by the GPL, It is an aggregation, no doubt. But we disagree as to whether it's the kind of mere aggregation that would make it elligible for the additional permission granted by the GPL for this case. > I don't think that's a sufficient reason for me to want to remove > something, but OK. >> So you remove the firwmare and notice that the kernel won't compile >> any more. What now? > Ignore it, consider it a feature in case you get one of the devices in > question, or ask someone with permission to modify to make the change > for you. Oh, so you do need permission in what you claim to be a separate and independent work, to cope with the absence of another unarguably-separate independent work. Can you see the inconsistency in your position yet? >> Do you get permission to modify the kernel >> (creating a derived work thereof) just because it won't compile after >> you rip off a "separate work"? > If it mattered that much, I'd try to figure out why the removal > affected compilation and supply a compiler-satisfying substitute. Wouldn't that be modification of the source file for which you need permission? Say, you have: # Copyright 2006 Evil Empire, Inc, all rights reserved, # except for the portion between quotes in the assignment to "fw" # below. You have permission to remove that portion, but no other # permission is granted as far as modifying this program goes. # This firmware is Copyright 2004 SFS # It is licensed under the terms of the GUN GLP version 3.14, or any # newer version published by the SFS. # Please see fw.asm for the sources and the complete licensing terms. fw="0xde 0xad 0xbe 0xef 0xe7 0xc0" if test -z "$fw"; then echo you loser, you have just made this completely useless fi ... lots of otherwise-useful code ... What do you make of this? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ndbecker2 at gmail.com Sat Jun 14 01:27:06 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 Jun 2008 21:27:06 -0400 Subject: Changing noarch package to arch References: <485308CC.8040708@nigelj.com> Message-ID: Nigel Jones wrote: > Neal Becker wrote: >> Cython was a noarch python package, but cython-0.9.8 will be >> arch-specific. >> >> Is there something special that needs to be done to handle this? >> >> > I don't think there is, just (preferably) make sure that it builds on > the big four (i386, x86_64, ppc, ppc64), I don't like the idea of > removing functionality for arches all of a sudden. > > Other than that, just follow the python packaging guidelines and you'll > be home free. > > - Nigel > Updating did not remove /usr/lib/python2.5/site-packages/Cython. It left a trail of empty subdirectories. I suspect this will cause problems, because python does not handle well having both sitearch and site-nonarch. I'm thinking that yum or rpm has to be updated to handle this correctly. From lesmikesell at gmail.com Sat Jun 14 01:56:11 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 13 Jun 2008 20:56:11 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> Message-ID: <4853253B.1040906@gmail.com> Alexandre Oliva wrote: > On Jun 10, 2008, Les Mikesell wrote: > >> You aggregate something for distribution. It's not a whole unless the >> components are combined. And while this may be a fuzzy area for >> things covered by the stock GPL, the version that covers Linux >> specifically says > > Parse error, end of sentence not detected. Please fix and recompile > ;-) Sorry, after I looked it up I decided that the word 'user' in the exception would have been confusing here and left it out, forgetting about the dangling part. >> No, what exempts it is the fact that they are separate things both in >> their origin and destination. > > And how about during the split-second in which distribution occurs? > Aren't the components combined at that time? Aggregated. >> No, you can take separate works and put them together as long as they >> remain separate works - as the stuff loaded into a device's firmware >> is separate from the kernel. > > You're looking at only one side of the question. And you are only looking at the middle when it is aggregated, not when it originates or is deployed to its separate destination. > The other is, is the > kernel separate from the device's firmware? That's a different question, unrelated to how that firmware got into the device. You might make a plausible case that the GPL restricts code from being run on hardware with non-GPL bios and other firmware. I don't think I'd agree but it would be fun trying to work out the difference between calling something in ROM and a linked library. > As of today, it very > clearly isn't. I don't think that's clear at all, but I think in terms of interfaces and that pretty much by definition, one piece of code ends where the other interface starts - and since using those interfaces is the whole point of having the copy of code I'd have to consider it fair use of your copy. > Or, what evidence can you provide that the kernel is > an independent work from the firmwares, against the various pieces of > evidence that it is dependent on them? It's an interesting question, but it doesn't really relate to copyrights or derived works except in the upside down world of the GPL restrictions where no legal rulings exist. >> Please... try to imagine the time when that was written and think >> about tapes full of commercial software instead. > > Or rather think about the tapes full of GNU software under GPL, LGPL > and a bunch of other Free Software packages under various other > licenses, some GPL-compatible, some not, built for various operating > systems. I can't think about that without remembering the time when GPL software could not have existed without a commercial OS hosting it, and that history makes me believe that the GPL itself cannot prohibit this co-existence even if it is somewhat less necessary now. Saying it does would seem like going back in time and killing your grandparents so you can't exist now... >> In the past the FSF has claimed that something should be considered a >> derived work and covered by the GPL if it needed a GPL'd library to >> function, even if it was not distributed together. > > IIRC the reasoning goes like, when it is linked with the library, or > gets code from library header files, the copied portions provide > strong indication that the program was developed as a work based on > the library. And then, the copyrightable copied portions actually > make the resulting work actually derived from the library, even if its > sources and object files weren't. And then, if you use dynamic > linking, this copies far less from the library, but it doesn't change > the status in any meaningful way. Using header files as needed to make something work was pretty much established as fair use in AT&T's failed suit against BSDI years ago. I don't think there was an actual ruling but they gave up on any hope of winning. The FSF claimed their argument about functionality applied even if no work was copied. >>> But I think we can agree that _until_ there's a ruling, including the >>> firmware in the kernel is just a gratuitous risk. > >> The same risk goes with any GPL covered work. > > Nope. The risk that there might be some unknown restricted portion of > code hiding in a GPLed program is quite different from that of a known > restricted portion. We know the GPL imposes restrictions. That's a given, not a risk. But it doesn't restrict against aggregating other things. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Sat Jun 14 02:54:46 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 23:54:46 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: (Alexandre Oliva's message of "Fri\, 13 Jun 2008 18\:47\:29 -0300") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: On Jun 13, 2008, Alexandre Oliva wrote: > It's like going "Your honor, I shouldn't be punished for the alleged > murder because I didn't kill the victim, the bullet did. I just > pulled the trigger. Anyone else could have done that and the victim > would end up dead just the same, so why should I be punished for > something that anyone else could have done?" Or (for those who override logical thinking with emotional reactions in the presence of hyperboles) "See, officer, I'm not stepping on the grass, my shoes are. I just so happen to have these shoes on right now, but I might as well just take them out and put on another pair, and these will remain just where they are, no difference. See?, that's why you shouldn't fine me." And, no, I obviously didn't accuse you of murder, and I'm pretty sure you know that. Thanks to those who pointed out in private that others might mistaken an hyperbole for a comparison of similar acts. I hope the hipobole :-) above clears that up. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sat Jun 14 02:56:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 23:56:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4852F5C0.4060400@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 17\:33\:36 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <4852F5C0.4060400@gmail.com> Message-ID: On Jun 13, 2008, Les Mikesell wrote: > The way they are aggregated is the distraction Only as long as it clearly remains a mere aggregation. > whether they are temporarily aggregated into the same file or not > doesn't change their underlying status as different things. As long as one of the files didn't require extensive changes to accommodate the presence of the other at the time of "aggregation", or to accommodate the removal, you might have a case. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sat Jun 14 02:58:03 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Jun 2008 23:58:03 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4852F3B0.2080202@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 17\:24\:48 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <4852F3B0.2080202@gmail.com> Message-ID: On Jun 13, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >> Likewise, it's obvious that whoever distributed the firmware to you >> has responsibility over the result, even though you could have got the >> firmware from many others, or even got them straight from the vendor. > Errr, what? Is this list, or the computers that carry it, responsible > for the odd bit of content above, or are you? They didn't choose to distribute that particular content, so no, they're just carriers, like the air through which the bullet flies on the way to its target. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Sat Jun 14 03:21:30 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 13 Jun 2008 22:21:30 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <4852F3B0.2080202@gmail.com> Message-ID: <4853393A.7080104@gmail.com> Alexandre Oliva wrote: > On Jun 13, 2008, Les Mikesell wrote: > >> Alexandre Oliva wrote: >>> Likewise, it's obvious that whoever distributed the firmware to you >>> has responsibility over the result, even though you could have got the >>> firmware from many others, or even got them straight from the vendor. > >> Errr, what? Is this list, or the computers that carry it, responsible >> for the odd bit of content above, or are you? > > They didn't choose to distribute that particular content, so no, > they're just carriers, like the air through which the bullet flies on > the way to its target. How would this be different on a moderated list? Having someone else choose to distribute it still doesn't make them responsible for creating the content or what it contains. Look through the changelogs of some software packages to see how many flaws past versions have contained. Do you hold the distributors responsible for all those problems? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Sat Jun 14 04:18:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 13 Jun 2008 23:18:01 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> Message-ID: <48534679.7040008@gmail.com> Alexandre Oliva wrote: > >> Not wanting to participate in distributing code without source is one >> thing; calling it unethical is something else and implies that >> everyone else is wrong for doing it. > > Merely distributing non-Free Software is not unethical [intent or > disregard for harm upon others], it's only immoral [harmful to society > at large]. It is the restriction against redistributing useful combinations that is the most harmful, not any particular component. > It's imposing the restrictions that render Software > non-Free that's unethical. But it is the GPL restriction that takes away your choices. > Accepting them, passing them on, > encouraging others to do so are all bad, but they're not as much of an > aggression as initiating the disrespect for others. If you respect others you allow them to make their own choices instead of taking them away. > In fact, most > users who accept such disrespect, and many who pass it on, are more > victims, even though they're ultimately helping the aggressors. Aggressors counter each other through competition. > Failure to resist violence does encourage the aggressor to keep on its > act, but being overpowered is not the victim's fault. You aren't a victim when you make your own choices. >> And again, vendors who distribute code without source are not >> necessarily unethical > > I don't see how else to describe it. It's willful deprivation of > useful information for understanding and improvement of one's copy of > a program, and deprivation of additional contributions to society. You are making some philosophical leaps that I can't follow here. First, in the generic terms we are discussing, there is no reason to assume that the source is correct or contains anything useful. Perhaps all the comments are misleading or it doesn't even work. > I > don't care how market pressure or other reasons one may use to justify > such acts to one's own conscience. Such reasonings as "it makes > business sense" or "it's more profitable" or "other businesses do it" > could be used to justify slavery as well. Do you assume a moral imperative for everyone to always share all information that they have? If not, how does distributing a binary trigger this requirement in your mind? From my perspective it seems better to distribute working binaries than nothing - or broken source. But in fact there should be no moral or value judgement on distribution of 'content' since its value can only be determined by the recipient and that determination will relate to his particular needs. > Although slavery deprives > people of more fundamental freedoms, dependency on technology nowadays > is growing the importance of the not-so-fundamental human rights that > amount to the 4 essential freedoms of the Free Software definition. Slavery is taking away choices. So is distributing software that has choice-limiting restrictions. >> Personally I consider competition and equality (i.e. having your >> choice of components) to be much more important than source >> availability for any component. > > Source code is essential for only two of the four freedoms, so don't > bother focusing only on that part. Don't let yourself be misled by > the term 'Open Source'. Even open source activists know it's not just > about the source being open. It's a matter of not being artificially > prevented from doing a number of things that every software user > should be entitled to do with their own copies of software, just like > they're entitled to store whatever they like in cupboards they > purchase, figure out their functioning, remove internal walls to make > room for larger items, and create other identical or different > cupboards for themselves and for others. Same goes for chairs, > tables, houses, bikes, etc. The fact that software is mostly > intangible should make all this all easier, rather than becoming a > tool to create dependency and control people. Yes, but the freedom I want is the freedom to combine components without restrictions. Or actually, for someone else to make those combinations and offer them for less than the price of equivalent popular software. >> Thus restrictions on combining and redistributing components are >> much more evil, unethical, and detrimental to long term developments >> than any current NDA or binary blob could ever be. > > I agree with that to a large extent, but it's the law. As long as the > law is the way it is, it can be at least put to a better use, to > maintain a level playing field. The playing field would level itself if there were less restrictions on being able to recombine components for any purpose. > Remember, the GPL doesn't prohibit combining or redistribution, it's > the law that does; the GPL permits very broad cases of combination and > redistribution that respect others' freedoms. No, the viral nature of the GPL takes away anyone's freedom to choose the copyright for their own work when improving something with existing GPL'd code. > But then, see, I'm not trying to prohibit anyone from creating this > combination that contains non-Free Software or distributing it. What > I'm concerned about is maintaining a variant that doesn't contain any > such non-Free Software, and offering it to whomever might be > interested in using it. And I'm not particularly against that other than not seeing the point. Other than the technical issues of dealing with files early in the boot sequence it would seem to make sense to separate the firmware loaders/initializers from their payloads. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Sat Jun 14 05:31:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jun 2008 21:31:50 -0800 Subject: Changing noarch package to arch In-Reply-To: References: <485308CC.8040708@nigelj.com> Message-ID: <604aa7910806132231w1d9eef74w450ab7a31f0003b2@mail.gmail.com> On Fri, Jun 13, 2008 at 5:27 PM, Neal Becker wrote: > Updating did not remove /usr/lib/python2.5/site-packages/Cython. It left a > trail of empty subdirectories. Uhm rpm -qf /usr/lib/python2.5/site-packages/Cython If this wasn't cleaned up correctly, that suggests a problem with Cython packaging not taking ownership of directories correctly. If the package(s) were constructed correctly they should clean up the directories i think. -jef From alan at redhat.com Sat Jun 14 10:26:43 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Jun 2008 06:26:43 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> Message-ID: <20080614102642.GA4959@devserv.devel.redhat.com> On Fri, Jun 13, 2008 at 06:35:24PM -0300, Alexandre Oliva wrote: > So, before gNewSense cleaned up the kernel in a way that ended up > being called linux-libre, it didn't exist as a separate work to be > aggregated into other works and result in linux-2.6.25.tar.bz2? The tg3 firmware is in various things. The fact its usually shipped aggregated with other works seems to be irrelevant. > > Bingo.. and copyright does not give you power over other works > > Nobody's talking about power over other unrelated works. We're Yes you are. At least thats what everyone else seems to think about firmware > > I do not need your permission to put your book on the same bookcase > > as someone elses book. > > The result is clearly not a copyrightable work. Ditto firmware. Its a mechanical process not a creative one. Alan From alan at redhat.com Sat Jun 14 10:28:51 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Jun 2008 06:28:51 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: <20080614102851.GB4959@devserv.devel.redhat.com> > Of course, in the case of non-Free Software, the bullet doesn't kill > right away; it rather contains addictive poison that the vendor puts > in there to get the victims dependent, paralyzed and even thinking > it's good for them. Sorry this has gone on for too long, you aren't interested in anything anyone has to say, lawyers included. Trying to discuss disputes about licence corner cases by likening your opponents to gun lobby fanatics is offensive to the point you've joined my kill file. Alan From rawhide at fedoraproject.org Sat Jun 14 10:41:08 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 14 Jun 2008 10:41:08 +0000 (UTC) Subject: rawhide report: 20080614 changes Message-ID: <20080614104108.E9B4D209D0F@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080613/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080614/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package perl-TAP-Harness Run Perl standard test scripts with statistics New package vaspview VASP Data Viewer Updated Packages: Cython-0.9.8-2.fc10 ------------------- * Fri Jun 13 18:00:00 2008 Neal Becker - 0.9.8-2 - Install into python_sitearch - Add %check * Fri Jun 13 18:00:00 2008 Neal Becker - 0.9.8-1 - Update to 0.9.8 anaconda-11.4.1.5-1 ------------------- * Fri Jun 13 18:00:00 2008 Chris Lumens - 11.4.1.5-1 - Add a mirrorlist option. (jkeating) - Don't display garbage when prompting for the updates device. (clumens) - Don't write out yum repo config files in kickstart.py. (clumens) - It doesn't make sense to insert a disk into a partition, so don't ask. (clumens) - Unmount /mnt/sysimage/dev manually since it doesn't get an entry. (clumens) - Link ld-linux.so.2 to ld-*.*.*.so (dcantrell) - Quote the repo name in anaconda-ks.cfg in case it includes spaces. (clumens) - Move all the exception classes into a single file. (clumens) - And import iutil a the end as well. (clumens) - Don't display obsoleted packages in the UI. (clumens) asymptote-1.43-1.fc10 --------------------- * Fri Jun 13 18:00:00 2008 Tom "spot" Callaway - 1.43-1 - update to 1.43 automake14-1.4p6-16.fc10 ------------------------ * Fri Jun 13 18:00:00 2008 Karsten Hopp 1.4p6-16 - rebuild to fix vendor tag (#451242) compiz-0.7.6-6.fc10 ------------------- * Fri Jun 13 18:00:00 2008 Adel Gadllah - 0.7.6-6 - Don't use desktops and viewport at the same time device-mapper-multipath-0.4.8-5.fc10 ------------------------------------ * Fri Jun 13 18:00:00 2008 Alasdair Kergon - 0.4.8-5 - Rebuild (rogue vendor tag). (451292) dgae-1.1-4.fc10 --------------- * Fri Jun 13 18:00:00 2008 Jon Ciesla 1.1-4 - Rebuild to fix vendor tag, BZ 451294. drgeo-doc-1.6-9.fc10 -------------------- * Fri Jun 13 18:00:00 2008 Jon Stanley - 1.6-9 - Rebuild for vendor tag cleanup, fix license tag fonts-hebrew-fancy-0.20051122-3.fc10 ------------------------------------ * Fri Jun 13 18:00:00 2008 Jon Stanley - 0.20051122-3 - Rebuild gabedit-2.1.7-1.fc10 -------------------- * Fri Jun 13 18:00:00 2008 Dominik Mierzejewski 2.1.7-1 - updated to latest development version (2.1.7) - dropped obsolete patches gambas2-2.7.0-1.fc10 -------------------- * Fri Jun 13 18:00:00 2008 Tom "spot" Callaway 2.7.0-1 - update to 2.7.0 ganglia-3.1.0-0.3.r1399.fc10 ---------------------------- * Fri Jun 13 18:00:00 2008 Jarod Wilson 3.1.0-0.3.r1399 - One more try at work-around. Needs powerpc64, not ppc64... * Fri Jun 13 18:00:00 2008 Jarod Wilson 3.1.0-0.2.r1399 - Work-around for incorrectly hard-coded libdir on ppc64 * Wed Jun 11 18:00:00 2008 Jarod Wilson 3.1.0-0.1.r1399 - Update to 3.1.x pre-release snapshot, svn rev 1399 glibc-2.8.90-7 -------------- * Fri Jun 13 18:00:00 2008 Jakub Jelinek 2.8.90-7 - update from trunk - avoid *lround* on ppc* clobbering cr3/cr4 registers (#450790) - further nscd fixes (#450704) - use inotify in nscd to watch files gtk2-2.13.3-1.fc10 ------------------ * Fri Jun 13 18:00:00 2008 Matthias Clasen - 2.13.3-1 - Update to 2.13.3 jabbim-0.4-1.fc10 ----------------- * Fri Jun 13 18:00:00 2008 Michal Schmidt - 0.4-1 - Upstream release 0.4 "VELES". kernel-2.6.26-0.67.rc6.git1.fc10 -------------------------------- * Fri Jun 13 18:00:00 2008 Dave Jones - 2.6.26-rc6-git1 libpano13-2.9.12-7.fc10 ----------------------- * Fri Jun 13 18:00:00 2008 Bruno Postle - 2.9.12-7 - Bad URL report, use sourceforge tar.gz rather than slightly different tar.bz2. It seems that there have been two 2.9.12 releases with the old bz2 file being deleted. Diffing trees reveals just a couple of bugfixes in the newer gz version. lvm2-2.02.38-1.fc10 ------------------- * Fri Jun 13 18:00:00 2008 Alasdair Kergon > - 2.02.38-1 - libdevmapper: Make dm_hash_iter safe against deletion. - libdevmapper: Accept a NULL pointer to dm_free silently. - libdevmapper: Calculate string size within dm_pool_grow_object. - libdevmapper: Send reporting field help text to stderr not stdout. - dmsetup: Add tables_loaded, readonly and suspended columns to reports. - dmsetup: Add --nameprefixes for new report output format FIELD=VALUE. - Add --nameprefixes to reporting tools for field name prefix output format. - Fix return values for reporting commands when run with no PVs, LVs, or VGs. - Add omitted unlock_vg() call when sigint_caught() during vg processing. - Fix free_count when reading pool metadata. - Fix segfault when using pvcreate on a device containing pool metadata. - In script-processing mode, stop if any command fails. - Warn if command exits with non-zero status code without a prior log_error. - Correct config file line numbers in messages when parsing comments. - Add missing deactivation after activation failure in lvcreate -Zy. - When removing LV symlinks, skip any where the VG name is not determined. - Fix vgsplit internal counting of snapshot LVs. - Update vgsplit to only restrict split with active LVs involved in split. - Fix vgsplit to only move hidden 'snapshotN' LVs when necessary. - Update vgsplit man page to reflect lvnames on the cmdline. - Update vgsplit to take "-n LogicalVolumeName" on the cmdline. - Fix vgsplit error paths to release vg_to lock. - Avoid spurious duplicate VG messages referring to VGs that are gone. - Drop dev_name_confirmed error message to debug level. - Fix setpriority error message to signed int. - Add assertions to trap deprecated P_ and V_ lock usage. - Avoid using DLM locks with LCK_CACHE type P_ lock requests. - Don't touch /dev in vgrename if activation is disabled. - Exclude VG_GLOBAL from internal concurrent VG lock counter. - Fix vgmerge snapshot_count when source VG contains snapshots. - Fix internal LV counter when a snapshot is removed. - Fix metadata corruption writing lvm1-formatted metadata with snapshots. - Fix lvconvert -m0 allocatable space check. - Don't attempt remote metadata backups of non-clustered VGs. - Improve preferred_names lvm.conf example. - Fix vgdisplay 'Cur LV' field to match lvdisplay output. - Fix lv_count report field to exclude hidden LVs. - Fix some pvmove error status codes. - Indicate whether or not VG is clustered in vgcreate log message. - Mention default --clustered setting in vgcreate man page. - Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. - Update lvmcache VG lock state for all locking types now. - Fix output if overriding command_names on cmdline. - Add check to vg_commit() ensuring VG lock held before writing new VG metadata. - Add validation of LV name to pvmove -n. - Add some basic internal VG lock validation. - Fix vgsplit internal counting of snapshot LVs. - Update vgsplit to only restrict split with active LVs involved in split. - Fix vgsplit to only move hidden 'snapshotN' LVs when necessary. - Update vgsplit man page to reflect lvnames on the cmdline. - Update vgsplit to take "-n LogicalVolumeName" on the cmdline. - Fix vgsplit error paths to release vg_to lock. - Fix vgsplit locking of new VG. - Avoid erroneous vgsplit error message for new VG. - Suppress duplicate message when lvresize fails because of invalid vgname. - Cache VG metadata internally while VG lock is held. - Fix redundant lvresize message if vg doesn't exist. - Make clvmd-cman use a hash rather than an array for node updown info. - Decode numbers in clvmd debugging output. - Fix uninitialised mutex in clvmd if all daemons are not running at startup. - Add config file overrides to clvmd when it reads the active LVs list. - Make clvmd refresh the context correctly when lvm.conf is updated. - Fix another allocation bug with clvmd and large node IDs. - Fix uninitialised variable in clvmd that could cause odd hangs. - Correct command name in lvmdiskscan man page. - clvmd no longer crashes if it sees nodeids over 50. - Fix potential deadlock in clvmd thread handling. - Update usage message for clvmd. - Fix clvmd man page not to print
and clarified debug options. - Escape double quotes and backslashes in external metadata and config data. - Correct a function name typo in _line_append error message. - Fix resetting of MIRROR_IMAGE and VISIBLE_LV after removal of LV. - Fix remove_layer_from_lv to empty the LV before removing it. - Add missing no-longer-used segs_using_this_lv test to check_lv_segments. - Fix lvconvert detection of mirror conversion in progress. - Avoid automatic lvconvert polldaemon invocation when -R specified. - Fix 'pvs -a' to detect VGs of PVs without metadata areas. - Divide up internal orphan volume group by format type. - Fix lvresize to support /dev/mapper prefix in the LV name. - Fix lvresize to pass new size to fsadm when extending device. - Fix unfilled parameter passed to fsadm from lvresize. - Update fsadm to call lvresize if the partition size differs (with option -l). - Fix fsadm to support VG/LV names. mecab-jumandic-5.1.20070304-2.fc10.1 ------------------------------------ * Fri Jun 13 18:00:00 2008 Jon Stanley - 5.1-20070304-2 - Rebuild mkinitrd-6.0.53-1.fc10 ---------------------- * Fri Jun 13 18:00:00 2008 Peter Jones - 6.0.53-1 - Merge changes for plymouth integration. - Merge changes katzj forgot to push from F-9's 6.0.52-{1,2}: - Require isomd5sum so that live images can be verified (#445284) - Handle kvm virtio devices (markmc, #444155) - Output value from fstab into as arg to mkrootdev (pjones, #209473) - Don't depend on system.map (markmc, #430718) nsd-3.0.8-2.fc10 ---------------- * Tue May 6 18:00:00 2008 Paul Wouters - 3.0.8-2 - Fix /dev/null redirection [Venkatesh Krishnamurthi] * Tue May 6 18:00:00 2008 Paul Wouters - 3.0.8-1 - Updated to 3.0.8 perl-Devel-Cover-0.64-1.fc10 ---------------------------- * Fri Jun 13 18:00:00 2008 Tom "spot" Callaway - 0.64-1 - update to 0.64 php-pear-DB-DataObject-FormBuilder-1.0.0-0.6.RC7.fc10 ----------------------------------------------------- * Fri Jun 13 18:00:00 2008 Jon Stanley - 1.0.0-0.6.RC7 - Rebuild - Fix license tag php-pear-Net-Socket-1.0.8-2.fc10 -------------------------------- * Fri Jun 13 18:00:00 2008 Jon Stanley - 1.0.8-2 - Rebuild pixman-0.11.4-2.fc10 -------------------- * Fri Jun 13 18:00:00 2008 Soren Sandmann 0.11.4-2 - Plug bad leak (cherrypicked from master) psgml-1.2.5-8.fc10 ------------------ * Fri Jun 13 18:00:00 2008 Jon Stanley 1.2.5-8 - Rebuild * Wed May 21 18:00:00 2008 Tom "spot" Callaway 1.2.5-7 - fix license tag pykickstart-1.39-1.fc10 ----------------------- * Fri Jun 13 18:00:00 2008 Chris Lumens - 1.39-1 - It's helpful to return the parser object. (clumens) qt-4.4.0-9.fc10 --------------- * Sat Jun 14 18:00:00 2008 Kevin Kofler 4.4.0-9 - restore -qt4 suffixes * Fri Jun 13 18:00:00 2008 Than Ngo 4.4.0-8 - drop qt wrapper, make symlinks to /usr/bin * Tue Jun 10 18:00:00 2008 Than Ngo 4.4.0-7 - fix #450310, multilib issue rhpl-0.216-1 ------------ * Fri Jun 13 18:00:00 2008 Chris Lumens 0.216-1 - Fix Swiss French keyboard layout (#448878). - Now with more Romanian keyboard layouts! (#450381) - Add irish (#431998). - Add inet keycodes to the model (like XKB expects) instead of to the layout (like it doesn't) (ajax). roundcubemail-0.2-0.alpha.fc10 ------------------------------ * Fri Jun 13 18:00:00 2008 Jon Ciesla = 0.2-0.alpha - Update to 0.2-alpha, security fixes for BZ 423271. - mysql update and pear patches applied upstream. - Patched config paths. rsyslog-3.19.7-2.fc10 --------------------- * Fri Jun 13 18:00:00 2008 Peter Vrabec 3.19.7-2 - do not translate Oopses (#450329) * Fri Jun 13 18:00:00 2008 Peter Vrabec 3.19.7-1 - upgrade scim-1.4.7-24.fc10 ------------------ * Fri Jun 13 18:00:00 2008 Jens Petersen - 1.4.7-24.fc10 - scim-sinhala is renamed to scim-sayura source-highlight-2.9-1.fc10 --------------------------- * Fri Jun 13 18:00:00 2008 Adrian Reber - 2.9-1 - updated to 2.9 - removed upstreamed gcc43 patch sugar-datastore-0.8.1-1.fc10 ---------------------------- * Fri Jun 13 18:00:00 2008 Simon Schampijer - 0.8.1-1 - Update to 0.8.1 system-config-kickstart-2.7.18-1.fc10 ------------------------------------- * Fri Jun 13 18:00:00 2008 Chris Lumens 2.7.18-1 - Fix a couple upgrade-related problems. - Enable right-click menu in pirut again. tbb-2.1-1.20080605.fc10 ----------------------- * Fri Jun 13 18:00:00 2008 Petr Machata - 2.1-1.20080605 - New upstream 2.1 - Drop soname patch, parallel make patch, and GCC 4.3 patch unixODBC-2.2.12-8.fc10 ---------------------- * Fri Jun 13 18:00:00 2008 Tom Lane 2.2.12-8 - Install icons in /usr/share/pixmaps, not /usr/share/icons as this package has historically done; the former is considered correct. uw-imap-2007b-1.fc10 -------------------- * Fri Jun 13 18:00:00 2008 Rex Dieter 2.007b-1 - imap-2007b xorg-x11-drv-radeonhd-1.2.1-2.20080613git.fc10 ---------------------------------------------- * Fri Jun 13 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-2.20080613git - New snapshot (upstream commit ad59f09e3e30f5aafbd29a07f1078c2293847ad6): - ad59f09e: MC: HDP_FB_LOCATION on R5xx is direct MMIO not indirect thru MC. xorg-x11-server-1.4.99.902-3.20080612.fc9 ----------------------------------------- * Thu Jun 12 18:00:00 2008 Dave Airlie 1.4.99.902-3.20080612 - xserver-1.5.0-fix-single-aspect.patch - fix 2560x1600 on my monitor. * Thu Jun 12 18:00:00 2008 Dave Airlie 1.4.99.902-2.20080612 - cve-2008-1377: Record and Security Extension Input validation - cve-2008-1379: MIT-SHM extension Input Validation flaw - cve-2008-2360: Render AllocateGlyph extension Integer overflows - cve-2008-2361: Render CreateCursor extension Integer overflows - cve-2008-2362: Render Gradient extension Integer overflows - Rebase to 1.5 head for security patches for above * Mon Jun 9 18:00:00 2008 Adam Jackson 1.4.99.902-1.20080609 - Today's git snapshot. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 40 Broken deps for i386 ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.i386 requires librrd.so.2 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires librrd.so.2()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 lm_sensors-sensord-3.0.1-5.fc9.ppc requires librrd.so.2 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires librrd.so.2()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From a.badger at gmail.com Sat Jun 14 13:31:42 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 14 Jun 2008 09:31:42 -0400 Subject: Changing noarch package to arch In-Reply-To: <604aa7910806132231w1d9eef74w450ab7a31f0003b2@mail.gmail.com> References: <485308CC.8040708@nigelj.com> <604aa7910806132231w1d9eef74w450ab7a31f0003b2@mail.gmail.com> Message-ID: <4853C83E.6080402@gmail.com> Jeff Spaleta wrote: > On Fri, Jun 13, 2008 at 5:27 PM, Neal Becker wrote: >> Updating did not remove /usr/lib/python2.5/site-packages/Cython. It left a >> trail of empty subdirectories. > > Uhm > > rpm -qf /usr/lib/python2.5/site-packages/Cython > > If this wasn't cleaned up correctly, that suggests a problem with > Cython packaging not taking ownership of directories correctly. If > the package(s) were constructed correctly they should clean up the > directories i think. > $ rpm -qf /usr/lib/python2.5/site-packages/Cython Cython-0.9.6.13.1-3.fc9.noarch Here's another question. Are there no files at all in the Cython directory structure? Perhaps something created an untracked file in there and that's why the directories weren't cleaned up. (If not, there's indeed a bug in somewhere.) (Although it didn't exist ~6 months ago when I had a package go from noarch => arch specific.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dwmw2 at infradead.org Sat Jun 14 14:21:09 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Jun 2008 15:21:09 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080614102642.GA4959@devserv.devel.redhat.com> References: <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> Message-ID: <1213453269.26255.368.camel@pmac.infradead.org> On Sat, 2008-06-14 at 06:26 -0400, Alan Cox wrote: > > Nobody's talking about power over other unrelated works. We're > > Yes you are. No, he's not. Obviously, the GPL _cannot_ assume 'power over other unrelated works'. That would not be within the scope of a copyright licence. As a copyright licence, the GPL only restricts your permission to distribute derivative or collective works based on the original GPL'd Program.? Under some circumstances?, the GPL denies you permission to distribute a collective work, where one of the independent and separate works which comprise that collective work is the GPL'd Program, and another of the independent and separate works which comprise that collective work is, well, independent and separate. But in that case, the restriction works purely by denying you permission to distribute the GPL'd Program in that form, not by any magical 'power over other unrelated works'. The GPL phrases it thus: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. To go back to the analogy with short stories... I deny you the right to publish my short story in your anthology because I don't think it goes well with the other stories you chose to include. You seem to think you can go ahead and include my story anyway, on the basis that the other stories I object to are "unrelated works", and that copyright law does not grant me "power over other unrelated works". But I don't need power over those unrelated works. I only need the power to deny you permission to include _my_ work. And that power is _precisely_ what copyright law gives me. -- dwmw2 ? Strictly speaking, of course it is copyright law which _restricts_ your permissions, and the licence only grants some of those permissions back to you. With certain conditions. ? And yes, we disagree on precisely _which_ circumstances, but unless those three paragraphs of the GPL are just a long pointless no-op, there are certainly _some_ circumstances where it does. From aoliva at redhat.com Sat Jun 14 14:22:23 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 11:22:23 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: (Alexandre Oliva's message of "Fri\, 13 Jun 2008 23\:54\:46 -0300") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> Message-ID: On Jun 13, 2008, Alexandre Oliva wrote: > Or (for those who override logical thinking with emotional reactions > in the presence of hyperboles) [...] > And, no, I obviously didn't accuse you of murder, and I'm pretty sure > you know that. Per your response, I guess you didn't know that, and that you did override logical thinking with emotional reactions. Oh well... -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sat Jun 14 14:26:09 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 11:26:09 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080614102642.GA4959@devserv.devel.redhat.com> (Alan Cox's message of "Sat\, 14 Jun 2008 06\:26\:43 -0400") References: <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> Message-ID: On Jun 14, 2008, Alan Cox wrote: > On Fri, Jun 13, 2008 at 06:35:24PM -0300, Alexandre Oliva wrote: >> So, before gNewSense cleaned up the kernel in a way that ended up >> being called linux-libre, it didn't exist as a separate work to be >> aggregated into other works and result in linux-2.6.25.tar.bz2? > The tg3 firmware is in various things. The fact its usually shipped > aggregated with other works seems to be irrelevant. Say, if there was another work that stated "Distribution of this work along with the tg3 firmware is strictly forbidden", would it still be irrelevant? >> > Bingo.. and copyright does not give you power over other works >> >> Nobody's talking about power over other unrelated works. We're > Yes you are. At least thats what everyone else seems to think about firmware Let's try again. This is about the GPLed work. I don't care if it's firmware or anything else. The point is it's GPL-incompatible, therefore you have no permission to distribute the GPLed work along with it as part of a collective/derivative work. No objections to distributing it otherwise. >> > I do not need your permission to put your book on the same bookcase >> > as someone elses book. >> >> The result is clearly not a copyrightable work. > Ditto firmware. Its a mechanical process not a creative one. Oh, really? Then why is it so different when you compare the way it's done in tg3, bnx2x, and nouveau, just to cite a few examples that come to mind. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From alan at redhat.com Sat Jun 14 14:31:06 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Jun 2008 10:31:06 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213453269.26255.368.camel@pmac.infradead.org> References: <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> Message-ID: <20080614143106.GA9770@devserv.devel.redhat.com> On Sat, Jun 14, 2008 at 03:21:09PM +0100, David Woodhouse wrote: > On Sat, 2008-06-14 at 06:26 -0400, Alan Cox wrote: > > > Nobody's talking about power over other unrelated works. We're > > > > Yes you are. > > No, he's not. In your opinion, which seems at odds with most. From aoliva at redhat.com Sat Jun 14 14:43:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 11:43:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4853253B.1040906@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 20\:56\:11 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> Message-ID: On Jun 13, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> On Jun 10, 2008, Les Mikesell wrote: >>> No, you can take separate works and put them together as long as they >>> remain separate works - as the stuff loaded into a device's firmware >>> is separate from the kernel. >> >> You're looking at only one side of the question. > And you are only looking at the middle when it is aggregated, I'm focusing on the moment of distribution because that's what matters for copyright. But if you look before of after, it remains just as aggregated, and to me it's very clearly not mere aggregation. There was creative work in making room for the firmwares inside the source files of various drivers. >> The other is, is the >> kernel separate from the device's firmware? > That's a different question, unrelated to how that firmware got into > the device. I know. I don't understand why you insist on this irrelevant point. Execution is not what this is about. The GPL says running the program is not restricted, and by this it acknowledges that copyright does not restrict that. I'm talking about distribution. >> Or, what evidence can you provide that the kernel is >> an independent work from the firmwares, against the various pieces of >> evidence that it is dependent on them? > It's an interesting question, but it doesn't really relate to > copyrights or derived works except in the upside down world of the GPL > restrictions where no legal rulings exist. 1. The GPL doesn't establish restrictions. 2. This is only *the* important question to tell whether what we have is mere aggregation or a combined work. Because, again, this is not about whether the firmware is a separate work, it's whether the GPLed code in the linux-2.6.whatever tarballs is a separate work. (How do you name an allegedly separate work that doesn't even have a name of its own?) > I can't think about that without remembering the time when GPL > software could not have existed without a commercial OS hosting it, Didn't BSD start before GNU? Sure, it wasn't entirely Free Software back then, but it was hardly a "commercial OS" (nevermind that its tapes were also for sale). > and that history makes me believe that the GPL itself cannot prohibit > this co-existence even if it is somewhat less necessary now. The GPL does not prohibit anything. It's copyright law that does. Copyright law does not regulate co-existence. It regulates copying, distribution, and the creation of derived works. >> gets code from library header files > Using header files as needed to make something work was pretty much > established as fair use in AT&T's failed suit against BSDI years ago. Yup. That's just using an interface. Not the same as getting code from library header files, which is what I wrote. Think inline functions, implicitly-instantiated C++ templates and the like. Situations in which you end up with copies of significant portions of the library code in your object files. > The FSF claimed their argument about functionality applied even if > no work was copied. Yep, IIRC borrowing fictional characters, places, etc of a story does amount to creating a derived work. > We know the GPL imposes restrictions. We don't. You think you do, but you're mistaken. Go read the GPL again. It goes "you have permission to do X this and that way. you have permission to do Y this and that way. Nothing else grants you permission to do X or Y in other ways." Which is to say, it doesn't prohibit, it's copyright law that prohibits other ways of doing X and Y, and also any way of doing Z, when you don't have a license that permits these things. > But it doesn't restrict against aggregating other things. It doesn't restrict mere aggregation, indeed. Mere aggregation does not require modification of any of the works, so it couldn't possibly be restricted by copyright the way copyright works today. That said, copyright law may still restrict the *distribution* of the aggregate. And it's distribution that I'm talking about. And then, we're not talking about mere aggregation. We're talking about a combination in which at least one of the works had to be modified to make room for the other, and that, if you take out the other, it goes kaboom. For modification, copyright law requires permission. So, yes, copyright law does restrict acts of aggregation that are not mere aggregation. (And the distribution of the result, be it mere aggregation or any other form of collective or derivative work.) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From dwmw2 at infradead.org Sat Jun 14 15:07:24 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Jun 2008 16:07:24 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080614143106.GA9770@devserv.devel.redhat.com> References: <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> Message-ID: <1213456044.26255.395.camel@pmac.infradead.org> On Sat, 2008-06-14 at 10:31 -0400, Alan Cox wrote: > On Sat, Jun 14, 2008 at 03:21:09PM +0100, David Woodhouse wrote: > > On Sat, 2008-06-14 at 06:26 -0400, Alan Cox wrote: > > > > Nobody's talking about power over other unrelated works. We're > > > > > > Yes you are. > > > > No, he's not. > > In your opinion, which seems at odds with most. No, I was being _very_ careful to leave matters of opinion out of it, as the second footnote should have made clear. I was quoting the GPL, and very lightly paraphrasing it to help clear up the confusion which you seem intent on seeding. I grant you that there is scope for different opinions on the question of precisely _when_ the GPL restricts your right to incorporate the Program in a collective work, and when you can call it "mere aggregation on a volume of a storage medium". But there is no reasonable scope for different opinions on the question of whether the GPL _may_, under copyright law, restrict your right to incorporate the GPL'd Program in a collective work. Copyright law quite clearly denies you that permission, and unless it is granted back to you by the copyright-holder (i.e. by the GPL), it remains forbidden. And it does _not_ require any kind of magic "power over unrelated works". That phrase seems just to be a deliberate misdirection. -- dwmw2 From aoliva at redhat.com Sat Jun 14 16:17:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 13:17:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4853393A.7080104@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 22\:21\:30 -0500") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <4852F3B0.2080202@gmail.com> <4853393A.7080104@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> They didn't choose to distribute that particular content, so no, >> they're just carriers, like the air through which the bullet flies on >> the way to its target. > How would this be different on a moderated list? That would depend on the role of the moderators. If it's merely to ensure that postings don't deviate from the rules of the list, then I suppose they would still be regarded as carriers. If approval means endorsement to the statements in the message, then they might become co-responsible. > Look through the changelogs of some software packages to see how > many flaws past versions have contained. Do you hold the > distributors responsible for all those problems? Again, it depends (heck, I'm talking more and more like a lawyer, even though I'm not one :-) For example, per Brazilian consumer protection law, if I purchase something as a consumer, I'm entitled to warranty. No ifs or buts. Regardless of whatever my relationship with the copyright holders of the Free Software in the product I purchased is (I got a copyright license from them that states there's no warranty), the vendor who performed the distribution to me is responsible for providing me with warranty. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Sat Jun 14 16:54:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 14 Jun 2008 11:54:39 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> Message-ID: <4853F7CF.3050800@gmail.com> Alexandre Oliva wrote: > >>> The other is, is the >>> kernel separate from the device's firmware? > >> That's a different question, unrelated to how that firmware got into >> the device. > > I know. I don't understand why you insist on this irrelevant point. Because I think it is the only relevent point. It is only if the combined works form a derivative work that restrictions can apply to the combination differently than the components and whether a derivative work is formed does not depend on how the components were distribtuted. See the history of the fgmp library for the FSF stance on separately distributed components - although since it happened before internet search engines were archiving everything it may be a little hard to find the whole story now. > Execution is not what this is about. The GPL says running the program > is not restricted, and by this it acknowledges that copyright does not > restrict that. I'm talking about distribution. It's about a derived work - which the FSF says is the same regardless of the way the parts are distributed. How is using ROM/firmware code different from adding code to link to or dynamically load a commercial libray in a GPLed work, then letting the end user get their own copy of the non-GPL'd library? >>> Or, what evidence can you provide that the kernel is >>> an independent work from the firmwares, against the various pieces of >>> evidence that it is dependent on them? > >> It's an interesting question, but it doesn't really relate to >> copyrights or derived works except in the upside down world of the GPL >> restrictions where no legal rulings exist. > > 1. The GPL doesn't establish restrictions. If the GPL didn't establish restrictions, it would only be a grant to use, copy, and redistribute. The rest of that big file consists of harmful restrictions. > 2. This is only *the* important question to tell whether what we have > is mere aggregation or a combined work. Because, again, this is not > about whether the firmware is a separate work, it's whether the GPLed > code in the linux-2.6.whatever tarballs is a separate work. (How do > you name an allegedly separate work that doesn't even have a name of > its own?) But it is not about how it is distributed. It is whether it becomes a derived work. >> I can't think about that without remembering the time when GPL >> software could not have existed without a commercial OS hosting it, > > Didn't BSD start before GNU? Yes, but not before copyright law, which is what this is about. > Sure, it wasn't entirely Free Software > back then, but it was hardly a "commercial OS" (nevermind that its > tapes were also for sale). Unix has a rather strange history. It was developed in a research branch of AT&T which at the time was a controlled monopoly that was prohibited from selling products outside their specific field. They did sell copies of the source as research projects to universities under the guise of research. And the universities improved it by adding their own code, notably tcp and vi. For some time, installing unix meant starting with the AT&T tapes (at about $20K and only available to universities) and then adding the BSD patches which were distributed freely. Then AT&T was split into separate companies, one of which commercialized unix and rolled in the *BSD improvements to create SysVr4, still overpricing it to the point that no one noticed. Concurrently, the *BSD developers were re-writing the core code to replace all original AT&T code so a working unix could be delivered on the track that became freebsd. BSDI was actually a commercial company selling what they claimed was an AT&T code-free version (at a price actually feasible for use and with source availability), which AT&T disputed. >> and that history makes me believe that the GPL itself cannot prohibit >> this co-existence even if it is somewhat less necessary now. > > The GPL does not prohibit anything. It's copyright law that does. > Copyright law does not regulate co-existence. It regulates copying, > distribution, and the creation of derived works. > >>> gets code from library header files > >> Using header files as needed to make something work was pretty much >> established as fair use in AT&T's failed suit against BSDI years ago. > > Yup. That's just using an interface. Not the same as getting code > from library header files, which is what I wrote. Think inline > functions, implicitly-instantiated C++ templates and the like. > Situations in which you end up with copies of significant portions of > the library code in your object files. But they included the head files which were verbatim copies of the original values. How do you establish that one set of values are OK but others aren't? >> We know the GPL imposes restrictions. > > We don't. You think you do, but you're mistaken. Go read the GPL > again. I'm not mistaken. Everything in there except the conditional grant to use, modify, distribute is a restriction. Go read a less restricted license to see the difference. Perl has an excellent example to counter the harm and divisive nature of the GPL. >> But it doesn't restrict against aggregating other things. > > It doesn't restrict mere aggregation, indeed. Mere aggregation does > not require modification of any of the works, so it couldn't possibly > be restricted by copyright the way copyright works today. That said, > copyright law may still restrict the *distribution* of the aggregate. > And it's distribution that I'm talking about. If the combination is interpreted as a derived work, it doesn't matter if they are distributed together or not. You still wouldn't be able to distribute them separately with the intent to recombine them. If you could, you would be able to add a component to a GPL'd work that links to a commercial library that the end user is expected to obtain separately. > And then, we're not talking about mere aggregation. We're talking > about a combination in which at least one of the works had to be > modified to make room for the other, and that, if you take out the > other, it goes kaboom. Yes, this part is the same even if the firmware is loaded by something else or already exists in ROM. > For modification, copyright law requires > permission. So, yes, copyright law does restrict acts of aggregation > that are not mere aggregation. (And the distribution of the result, > be it mere aggregation or any other form of collective or derivative > work.) But whether it is aggregation or not doesn't depend on the container or packaging for distribution - it is a separate concept. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Sat Jun 14 17:15:25 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 14:15:25 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48534679.7040008@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 23\:18\:01 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > If you respect others you allow them to make their own choices instead > of taking them away. Then take it up to the legislators that came up with copyright law. Once they fix their act (so to speak) then it will be clear that what you perceive as restrictions from the GPL are actually restrictions from copyright law. > Aggressors counter each other through competition. And the strongest prevails and can then form a monopoly that achieves the largest possible number of victims. Good outcome? I'd rather victims got together and demanded the aggressions to stop, rather than having the aggressors compete to see who's the most aggressive. >> Failure to resist violence does encourage the aggressor to keep on its >> act, but being overpowered is not the victim's fault. > You aren't a victim when you make your own choices. Heh. It's not that simple, really. "Your wallet or your life." "Rape or murder?" "Poison or bullet?" > there is no reason to assume that the source is correct or contains > anything useful. Perhaps all the comments are misleading or it > doesn't even work. If it's intentionally misleading, this would just make it yet another case of unethical behavior. If it's just misguided, then it might still be fixable. > Do you assume a moral imperative for everyone to always share all > information that they have? No. It's far more limited than that. It's more along the lines of keeping information secret to excise control over what was given or sold to others, to thereby excise control over others who were foolish enough to trust the offender and accept the gift or make the purchase. > how does distributing a binary trigger this requirement in your > mind? It doesn't, as long as information and permissions necessary to enjoy the four freedoms is provided. > From my perspective it seems better to distribute working binaries > than nothing It's better to give cigarettes to kids at school than to leave them without anything to put in their mouths at lunch time? :-) >> Although slavery deprives >> people of more fundamental freedoms, dependency on technology nowadays >> is growing the importance of the not-so-fundamental human rights that >> amount to the 4 essential freedoms of the Free Software definition. > Slavery is taking away choices. So is distributing software that has > choice-limiting restrictions. Slavery actually goes beyond that, it's taking away all choices. That's what makes it far more unacceptable than deprivation of software freedoms. However, not being able to adapt the software to one's own needs (just to cite one part of one of the four freedoms) is always choice-limiting, no matter how general the software is. So, per your definition, it would be slavery. I don't mind if you want to see it that way, although I perceive a difference in degree of wrongness. > Yes, but the freedom I want is the freedom to combine components > without restrictions. That's not any of the four essential freedoms. If the components are indeed separate independent works, copyright law won't get in your way given the permissions granted by the GPL, at least as far as the GPLed components are concerned. If the components are not separate independent works, then the GPL still won't prohibit you from combining the works. You have permission to combine them. What you can't do is to distribute the combination in a way that imposes further restrictions on the recipients' exercise of the four freedoms over the complete work you distributed. So, if you can't combine a GPLed work with another work that disrespects users' freedoms, take it up with the copyright holders of the other work and tell them to respect your freedoms and those you'd like to share the combination with. Unless you want to accept the unethical impositions from the copyright holders of the other work, and help them impose them on others (along with or separately from the GPLed work you'd like to combine with it), that's what you should do anyway. > The playing field would level itself if there were less restrictions > on being able to recombine components for any purpose. I'm no so sure about that. Power attracts more power, and imposing restrictions is a matter of power. Even if copyright law didn't exist, those willing to dictate terms on how their creative works could be used would still come up with other artifices to impose and enforce their wish. Contracts, for example, could take care of prohibiting a receiving party from passing on a work, even in the absence of copyright. Of course, once someone broke the contract and passed it on, the Pandora's box would be open, but the distributing party would still be held liable for the leak. And then, refraining from distributing source code could work quite well for the purpose of imposing and enforcing one's wish over what the software does, and it's mostly irrelevant as far as copyright law is concerned. But then, I don't quite see that publishing sourceless binaries fulfills the copyright bargain with society, for even when the work goes into the public domain (i.e., when the copyright holders pay back to society for the monopoly granted over their creation), it would still be mostly impossible for society to create derivative works. So why grant the monopoly in the first place? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sat Jun 14 17:15:42 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 14:15:42 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48534679.7040008@gmail.com> (Les Mikesell's message of "Fri\, 13 Jun 2008 23\:18\:01 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> Remember, the GPL doesn't prohibit combining or redistribution, it's >> the law that does; the GPL permits very broad cases of combination and >> redistribution that respect others' freedoms. > No, the viral nature of the GPL takes away anyone's freedom to > choose the copyright for their own work when improving something > with existing GPL'd code. There are a number of mistakes in your sentence above. 1. There's no such thing as a "viral nature of the GPL". That's a phrase coined by its opponents to confuse and mislead the audience. It's as nonsensical as 'intellectual property'. Viruses jump from one host to another by mere physical contact, after reproducing using the host's cellular infrastructure. The GPL doesn't do any such thing. It reproduces along with the host (a program licensed under it), and it is only passed on to descendants (derived works). A more fitting term would be 'the inherited nature of the GPL'. Although it's true that diseases can be inherited, inheritances are often welcome. 2. The phrase "choosing the copyright" does not make sense. Copyright is a legal monopoly granted through copyright law to induce the creation and publication of *more* creative works. By default, creative works would be available for anyone to use, modify and share if it wasn't for copyright law. Copyright law provides the incentive by granting a temporary copyright monopoly to the author, thereby delaying the general availability of the work for use, modification and sharing by anyone. In some jurisdictions, one can contribute a work to the public domain, thereby making it available to all for all these uses right away, rather than having to wait for the monopoly period to lapse. 3. I don't think you were talking about "choosing copyright over public domain", though. I guess you meant "choosing the license", i.e., choosing which permissions you're going to grant over the derived work that combines portions (or the entirety) of the GPLed work, any other works, and the results of your own creativity. The GPL doesn't stop you from granting whatever permissions you like to whomever you like over the results of your own creativity. But copyright law may stop you from granting some permissions over the works you based your combined work on. And the GPL only grants you permission to distribute the combined work if you grant the same permissions subject to the same conditions, i.e., if you don't deprive the recipients of the enjoyment of the permissions the author of the GPLed granted them over the work (modified or not), and that, if they choose to pass it on, they also do so (by force of copyright law) without depriving others from the enjoyment of these permissions. 4. If you could choose any terms you wanted for the combined work, you could deprive recipients from the permissions over the GPLed work that one of the co-authors meant them to have. You can't do that unilaterally, by force of copyright law. You have to negotiate with all the co-authors. But they have already granted you permission to distribute the work in certain ways. 5. If you could choose any terms you wanted for the combined work, you could grant recipients additional permissions over the GPLed work that would enable them to do 4. You can do that only for the portions for which you're the sole author. Otherwise, you could make room for other parties to take away from downstream recipients the freedoms that the co-authors of the work meant them to have. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From bruno at wolff.to Sat Jun 14 14:00:14 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 14 Jun 2008 09:00:14 -0500 Subject: Increasing the size of the available entropy pool for /dev/random in Fedora? In-Reply-To: <200806131726.m5DHQhAf013276@laptop13.inf.utfsm.cl> References: <6c0aa9500806130638g331d11dak5c8d3db2f7c5f766@mail.gmail.com> <200806131726.m5DHQhAf013276@laptop13.inf.utfsm.cl> Message-ID: <20080614140014.GA1722@wolff.to> On Fri, Jun 13, 2008 at 13:26:43 -0400, "Horst H. von Brand" wrote: > > [AFAIR, the random pool is only 512 bytes in size, so it can't contain more > "entropy" than that] I used to be able to recompile the kernel with a larger pool size, but I haven't done that in a long time. If the requests are bursty, but enough entropy is being generated over time to supply the amount needed without delay, then upping the poolsize might be worth doing to reduce delays. From aoliva at redhat.com Sat Jun 14 17:27:32 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 14:27:32 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213456044.26255.395.camel@pmac.infradead.org> (David Woodhouse's message of "Sat\, 14 Jun 2008 16\:07\:24 +0100") References: <484C5398.10800@gmail.com> <1212962483.2534.72.camel@shinybook.infradead.org> <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> Message-ID: On Jun 14, 2008, David Woodhouse wrote: > But there is no reasonable scope for different opinions on the question > of whether the GPL _may_, under copyright law, restrict your right to > incorporate the GPL'd Program in a collective work. Or rather refrain from granting you the permission you need in order to do so. > And it does _not_ require any kind of magic "power over unrelated > works". That phrase seems just to be a deliberate misdirection. Exactly. The same kind of misguided reasoning that the opponents of the anti-tivoization clauses in GPLv3 used. It's not power over anything else. It's power over how one can modify and distribute *our* work, nothing beyond that. If you're trying to do something that we find to be repulsive, we can't prohibit you from doing the repulsive thing, but we can demand you to leave our work out of it. You can still go ahead and do the repulsive thing using other works, of course. So there's no power over anything else, the only power is over our own work, and that's how copyright works. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Sat Jun 14 19:00:32 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 14 Jun 2008 14:00:32 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> Message-ID: <48541550.7040000@gmail.com> Alexandre Oliva wrote: > >> If you respect others you allow them to make their own choices instead >> of taking them away. > > Then take it up to the legislators that came up with copyright law. > Once they fix their act (so to speak) then it will be clear that what > you perceive as restrictions from the GPL are actually restrictions > from copyright law. Copyright law exists to encourage creation of works and competition among them. There is nothing wrong with that concept, although the original short protected life followed by passage to public domain seems much more in the public interest than the current incarnation. >> Aggressors counter each other through competition. > > And the strongest prevails and can then form a monopoly that achieves > the largest possible number of victims. Good outcome? Monopolies can only arise when there is something artificially making competition difficult or impossible. The relevant example would be OSX, now doing a reasonable job of competing with Microsoft even though they only used *bsd components in the base OS. Imagine how much harder it would be for MS to maintain their monopoly position if competitors were allowed to use components from Linux in commercial offerings, greatly lowering the bar to building usable alternatives that could include licensed copies of all other needed components. > I'd rather victims got together and demanded the aggressions to stop, > rather than having the aggressors compete to see who's the most > aggressive. > >>> Failure to resist violence does encourage the aggressor to keep on its >>> act, but being overpowered is not the victim's fault. > >> You aren't a victim when you make your own choices. > > Heh. It's not that simple, really. > > "Your wallet or your life." > > "Rape or murder?" > > "Poison or bullet?" You are confusing the value/moral judgement of the thing itself with a delivery mechanism. The thing being delivered could be food just as easily as poison in your example above, or lifejackets instead of bullets. >> there is no reason to assume that the source is correct or contains >> anything useful. Perhaps all the comments are misleading or it >> doesn't even work. > > If it's intentionally misleading, this would just make it yet another > case of unethical behavior. Like the way 'free' is redefined to mean restricted by the GPL? > If it's just misguided, then it might > still be fixable. What's misguided is your conviction that there is a moral value in the delivery channel at all. The value can only be defined by the recipient and the effect of the content. >> Do you assume a moral imperative for everyone to always share all >> information that they have? > > No. It's far more limited than that. It's more along the lines of > keeping information secret to excise control over what was given or > sold to others, to thereby excise control over others who were foolish > enough to trust the offender and accept the gift or make the purchase. And yet, you make no requirement that has anything to do with the content. That is, you are apparently perfectly willing to distribute broken or misleading content that will do much more harm than something that just works without requiring any other information. And you are making an uncalled-for value judgment in calling others foolish who may in fact have made the correct choices for their own situations. >> From my perspective it seems better to distribute working binaries >> than nothing > > It's better to give cigarettes to kids at school than to leave them > without anything to put in their mouths at lunch time? :-) The harm from cigarettes is due to the nature of the product, not the distribution. The product in question could as easily be milk. >> Slavery is taking away choices. So is distributing software that has >> choice-limiting restrictions. > > Slavery actually goes beyond that, it's taking away all choices. > That's what makes it far more unacceptable than deprivation of > software freedoms. Agreed - it is a bad analogy. But so is freedom in terms of restrictions on software. > However, not being able to adapt the software to one's own needs (just > to cite one part of one of the four freedoms) is always > choice-limiting, no matter how general the software is. So, per your > definition, it would be slavery. I don't mind if you want to see it > that way, although I perceive a difference in degree of wrongness. > >> Yes, but the freedom I want is the freedom to combine components >> without restrictions. > > That's not any of the four essential freedoms. Which is why I think they are entirely misguided. Reusing and recombining prior work is the basis of all knowledge and progress and any restrictions to inhibit that are harmful. And 'free' isn't so much the point as 'affordable'. In a practical sense, there's not much point in separating hardware and software since they must work together for any result. The total cost of the combined hardware and software balanced against the functionality of the combination is what matters. > If the components are indeed separate independent works, copyright law > won't get in your way given the permissions granted by the GPL, at > least as far as the GPLed components are concerned. But it does. You can't add your own work to a GPL'd part to make it link against a commercial library with no GPL'd equivalent, and redistribute that work of your own. > Unless you want to accept the unethical impositions from the copyright > holders of the other work, and help them impose them on others (along > with or separately from the GPLed work you'd like to combine with it), > that's what you should do anyway. I don't accept that the copyright holders of the other works necessarily make unethical impositions. They might, but whether they do or not is unrelated to their right to make them. On the other hand, the imposition that the GPL makes is clearly unethical even if having copyright provide the legal right to make that imposition. >> The playing field would level itself if there were less restrictions >> on being able to recombine components for any purpose. > > I'm no so sure about that. There's no guarantee, but I'm convinced that the restrictions in the GPL that prevent reuse in competitive works have made more money for Microsoft than anything Steve Balmer ever did. > And then, refraining from distributing source code could work quite > well for the purpose of imposing and enforcing one's wish over what > the software does, and it's mostly irrelevant as far as copyright law > is concerned. But then, I don't quite see that publishing sourceless > binaries fulfills the copyright bargain with society, for even when > the work goes into the public domain (i.e., when the copyright holders > pay back to society for the monopoly granted over their creation), it > would still be mostly impossible for society to create derivative > works. So why grant the monopoly in the first place? It isn't that monopolies are inherently a problem - there are many cases where having a single standard instance of something is a benefit - it is that they have the power to become a problem by creating artificial shortages or unreasonable prices. And the way to prevent those problems is not to try to keep them out of distribution channels, since that will just force everyone to avoid your distribution channel and go elsewhere. The way to prevent problems is to lower the bar to building competing alternatives that leave the choices up to the recipients. -- Les Mikesell lesmikesell at gmail.com From alan at redhat.com Sat Jun 14 19:05:15 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Jun 2008 15:05:15 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213456044.26255.395.camel@pmac.infradead.org> References: <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> Message-ID: <20080614190515.GA15664@devserv.devel.redhat.com> On Sat, Jun 14, 2008 at 04:07:24PM +0100, David Woodhouse wrote: > I was quoting the GPL, and very lightly paraphrasing it to help clear up > the confusion which you seem intent on seeding. I think the word you require is "interpreting" From aoliva at redhat.com Sat Jun 14 19:13:56 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 16:13:56 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4853F7CF.3050800@gmail.com> (Les Mikesell's message of "Sat\, 14 Jun 2008 11\:54\:39 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >>>> The other is, is the kernel separate from the device's firmware? >>> That's a different question, unrelated to how that firmware got into >>> the device. >> I know. I don't understand why you insist on this irrelevant point. > Because I think it is the only relevent point. It is only if the > combined works form a derivative work that restrictions can apply to > the combination differently than the components and whether a > derivative work is formed does not depend on how the components were > distribtuted. There are various possibilities here, let me summarize the ones that occur to me, in no particular order: a. one work is a derivative from the other, and they are distributed together b. one work is a derivative from the other, and they are distributed separately c. two unrelated works are distributed separately d. two works are combined into a single coherent work, undoubtedly a derivative from both, regardless of whether the two works were originally related, and then the derivative work is distributed e. two unrelated works are distributed together by mere aggregation in a single volume of storage or distribution medium If I understood your argument correctly, you appear to be proposing that, because cases such as (a-c) exist, the case at hand can't be (d), so it must be (e). I don't see how this conclusion can follow from the premises. Please clue me in? >> Execution is not what this is about. The GPL says running the program >> is not restricted, and by this it acknowledges that copyright does not >> restrict that. I'm talking about distribution. > It's about a derived work - which the FSF says is the same regardless > of the way the parts are distributed. Err... I thought you didn't agree it was a derived work. If you agree that it is, then the terms of the GPL are clear, and there's no reason for us to be holding this discussion. >> 1. The GPL doesn't establish restrictions. > If the GPL didn't establish restrictions, it would only be a grant to > use, copy, and redistribute. And that's pretty much what it is. And I say pretty much, rather than exactly, because 'use' needs no grant, and it also grants permissions to modify and distribute the modified versions. But the permissions are not unconstrained. It's like, if you come to my (hypothetical) house, the bathroom downstairs is being used by another guest and you need to use a bathroom. So I tell you: "yo may go upstairs and use the bathroom to your right". That I permitted you to go upstairs to use the bathroom doesn't grant you permission to go wandering into my bedroom. Now if there is a law that says "you can't go into a person's bedroom without her permission", you broke the law. What the GPL states are not prohibitions, they're merely describing in detail the granted permissions. This may be easier to explain and understand under Brazilian copyright law, where 'distribution' and 'publishing' require separate permissions. So a license could easily grant permission for the one without granting permission for the other without any traces of conditions: it would just say "I grant you permission to publish this work". Now, under other jurisdictions, the license would have to say "I grant you permission to distribute this work, but only if it is exposed in public places and offered under non-discriminatory pricing to any interested party" (or whatever the precise distinction between distribution and publication under Brazilian law is). So, if there was a word used in copyright law that stood for "distributing without denying others the permissions your were granted", let's say "freestribute", then the GPL could just say "you're granted permission to freestribute this program". You'd still be subject to all the restrictions of copyright law as to (other forms of) distribution, and there wouldn't be any such mislabeled restriction in the license. Wherever the GPL says "you may not" rather than "you may", it's clarifying provisions of copyright law, rather than imposing restrictions of its own. Go figure. > But it is not about how it is distributed. It is whether it becomes a > derived work. Indeed. It may be a derived work even it's distributed separately. I wouldn't argue against that. But since it's distributed together, discussing the case of its being distributed separately is irrelevant, isn't it? > But they included the head files which were verbatim copies of the > original values. How do you establish that one set of values are OK > but others aren't? I don't. Copyright law and court law do, AFAIK. And the rules don't always make sense when they're presented under a certain light. For example, numbers aren't copyrightable, right? But anything stored in digital form is ultimately a number. Can we conclude from this that nothing digital is copyrightable, and go about copying CDs, DVDs and software without any regard to copyright law? Likewise, the firmwares slipped into the kernel are "just numbers". But it's not the numbers per se that are copyrighted. It's the meaning, the expression. Now, if you can't understand them, are they still subject to copyright? If the fact that you can't understand them means they're not a form that enables one to make modifications to it (let alone the preferred form for making modifications to it), could it be redistributed under the GPL? >>> We know the GPL imposes restrictions. >> We don't. You think you do, but you're mistaken. Go read the GPL >> again. > I'm not mistaken. Everything in there except the conditional grant to > use, modify, distribute is a restriction. Like what? Tell me *anything* you could do in the absence of the GPL, that, by accepting the GPL, you can no longer do. That's what 'restriction' means, no? If the GPL lets you do something, but you cannot do other things because you're subject to other restrictions stemming from say copyright law, that's not a restriction from the GPL, it's a restriction from the law. > Go read a less restricted license to see the difference. You mean more permissive licenses, I suppose. Yup, they do exist. They grant you more permissions, removing more of the restrictions imposed by copyright law. How does this related with the claim that there's any restriction in the GPL? > divisive nature of the GPL. Another fallacy. "You can redistribute under the same license" doesn't divide, it has quite the opposite effect. It's permitting redistribution under any licenses that may lead to forks, including ones that don't permit further modifications. > If the combination is interpreted as a derived work, it doesn't matter > if they are distributed together or not. Agreed. > You still wouldn't be able to distribute them separately with the > intent to recombine them. Hopefully a court would see it that way, yes. > If you could, you would be able to add a component to a GPL'd work > that links to a commercial library that the end user is expected to > obtain separately. But you can do that already, as long as the commercial library is licensed under a GPL-compatible license. Or did you mean to imply that I'm not going to get my next pay check, and that the ones that preceded it are just a figment of my imagination? :-) Make that s/commercial/proprietary/, pretty please. Don't feed the FUD machine. >> And then, we're not talking about mere aggregation. We're talking >> about a combination in which at least one of the works had to be >> modified to make room for the other, and that, if you take out the >> other, it goes kaboom. > Yes, this part is the same even if the firmware is loaded by something > else or already exists in ROM. This would sound like a reasonable argument, if the kernel were modified in such a way that it was indeed indifferent to it. And then, it might be the case that it's still found to be a derived work, and so that it can't be distributed under the GPL. Well, too bad. But the law is the law. >> For modification, copyright law requires >> permission. So, yes, copyright law does restrict acts of aggregation >> that are not mere aggregation. (And the distribution of the result, >> be it mere aggregation or any other form of collective or derivative >> work.) > But whether it is aggregation or not doesn't depend on the container > or packaging for distribution - it is a separate concept. Now you lost me. Can you try to rephrase the point you're trying to make here in relation with my paragraph above, perhaps using other words and more sentences? As in, what is this separate concept of 'aggregation' you're talking about, and how does it compare with 'mere aggregation in a volume of storage or distribution media'? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From chabotc at xs4all.nl Sat Jun 14 19:15:45 2008 From: chabotc at xs4all.nl (Chris Chabot) Date: Sat, 14 Jun 2008 21:15:45 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <48541550.7040000@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> Message-ID: <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> Now i don't mean to interrupt this wonderful meeting of the minds, but i am wondering why mail box has been overflowing with an seemingly endless discussion between only, what, 3 or 4 people? In this open source world where attention and focus is our capital, do we really all need to be enlightened analogies that seem to frequently involve guns, poisons and other such very colorful statements.. to a casual observer it would seem it won't be long until we can evoke Godwin's law. I have to admit i did scan through today's and yesterday's emails and found very little that really related to fedora, even though the subject of the email and the mailing list would imply this should somehow be fedora related? Since this seems to now only involve a very few, but very vocal, people maybe you can take it off list and report back anything fedora related that may or may not come out of it? I'll leave you with maybe a refreshing point of view on such seeming heated discussions: http://lkml.org/lkml/2000/8/25/132 -- Chris From aoliva at redhat.com Sat Jun 14 20:29:21 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 17:29:21 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48541550.7040000@gmail.com> (Les Mikesell's message of "Sat\, 14 Jun 2008 14\:00\:32 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Copyright law exists to encourage creation of works and competition > among them. There is nothing wrong with that concept, although the > original short protected life followed by passage to public domain > seems much more in the public interest than the current incarnation. Looks like we're in full agreement about that. Are we also in agreement that it's (current) copyright law that imposes restrictions? That the GPL grants carefully delineated permissions for acts that would otherwise be restricted by copyright law, enough to ensure the 4 freedoms are respected, but not enough to lift all the restrictions imposed by copyright law? >>> Aggressors counter each other through competition. >> >> And the strongest prevails and can then form a monopoly that achieves >> the largest possible number of victims. Good outcome? > Monopolies can only arise when there is something artificially making > competition difficult or impossible. Or when they're established by decree. As it happens to be the case of copyright. "Authors have an exclusive right to..." > if competitors were allowed to use components from Linux in > commercial offerings They are. Want to see a copy of my paycheck? (disclaimer: this is not a real offer, the paycheck contains too much personal information :-) And competitors could do even more if it weren't because of restrictions imposed by others, in their licensing offers, which they can do because of (i) copyright law making certain acts prohibited by default, (ii) unethical imposition of restrictions, and (iii) acceptance and passing on of such restrictions from third parties. Your unsatisfaction with the situation is shared by me, but your blaming the GPL for unfortunate (and at times unethical) choices made by others is misguided. >>>> Failure to resist violence does encourage the aggressor to keep on its >>>> act, but being overpowered is not the victim's fault. >>> You aren't a victim when you make your own choices. >> Heh. It's not that simple, really. >> "Your wallet or your life." > You are confusing the value/moral judgement of the thing itself with a > delivery mechanism. No, I was just providing examples in which, in spite of being given choice, you're still an overpowered victim. >> If it's intentionally misleading, this would just make it yet another >> case of unethical behavior. > Like the way 'free' is redefined to mean restricted by the GPL? You appear to be confusing two different topics. The Free Software Definition is one thing, it encodes four essential freedoms for software users to be able to live in an ethical society that values solidarity. When the four freedoms are respected for a user, then the software is free for that user. The GPL is one of the various licenses that are regarded as Free Software licenses, because they don't disrespect any of the four freedoms. Having been granted the permissions in the GPL, in spite of the restrictions that remain from copyright law and other laws, you can run the software for any purpose, you can study the software's source code and adapt it to your needs, you can distribute the software as you received it, and you can improve the software and distribute your modifications. Sure, some of these permissions are delimited to implement copyleft (which is not a requirement for a license to qualify as a Free Software license, BTW), i.e., the delimitation in the permission to distribute that a distributor does not prevent recipients of the software and derived versions thereof from enjoying the permissions granted to them both through the license. This does not prohibit anyone from distributing the software in any way. If you end up unable to distribute a derived work, it's because you accepted a restriction from some other party that prevents you from distributing it. >> If it's just misguided, then it might still be fixable. > What's misguided is your conviction that there is a moral value in the > delivery channel at all. The value can only be defined by the > recipient and the effect of the content. Reordering a bit from your response to show the contradiction: >> It's better to give cigarettes to kids at school than to leave them >> without anything to put in their mouths at lunch time? :-) > The harm from cigarettes is due to the nature of the product, not the > distribution. The product in question could as easily be milk. See? If my conviction you disputed above is wrong, then the person who decides to distribute cigarettes to the kids instead of milk would be behaving in accordance with moral and ethics. Do you *really* think so? I mean, seriously, maybe you do, but... I honestly hope not. >>> Do you assume a moral imperative for everyone to always share all >>> information that they have? >> No. It's far more limited than that. It's more along the lines of >> keeping information secret to excise control over what was given or >> sold to others, to thereby excise control over others who were foolish >> enough to trust the offender and accept the gift or make the purchase. > And yet, you make no requirement that has anything to do with the > content. That is, you are apparently perfectly willing to distribute > broken or misleading content that will do much more harm than > something that just works without requiring any other information. I don't agree that incomplete content would do more harm. Given information, it could be completed and do good. In the absence of information, it makes no difference. Whereas including the vendor's bait in a product would turn me into an accomplice, and it would extend the long-term harm to more people, for it would be feeding the monster. As for misleading content, I'm against that on moral and ethical grounds. If source code is sufficiently misleading or abridged, it may indeed disrespect freedom #1, which is why I mentioned drivers developed under NDA in the message that started this thread. Ethics and morals are a lot about intentions, even when the practical end results are the same. If the information is missing because the developer just "didn't have time to add it in some meaningful format, here are my notes", that's not unethical. But if the information is missing because the developer had to sign an NDA to get the information, "so I can't share it with you", the developer is a bit of a victim and a vendor's accomplice, and the end user ends up hurt by the lack of ethics of the vendor in denying the information on how to make the developer's and end user's devices work to their own liking. > And you are making an uncalled-for value judgment in calling others > foolish who may in fact have made the correct choices for their own > situations. That they chose the best available options doesn't mean they couldn't have avoided being limited to those options, or negotiated a better deal, or made a different call for balance between short and long term. But regardless of the options, I don't see how trusting a vendor that denies technical information about their product can ever be a clever thing to do, even if you end up deciding to live with the product because it's the lesser of various evils. >>> Slavery is taking away choices. So is distributing software that has >>> choice-limiting restrictions. >> >> Slavery actually goes beyond that, it's taking away all choices. >> That's what makes it far more unacceptable than deprivation of >> software freedoms. > Agreed - it is a bad analogy. But so is freedom in terms of > restrictions on software. How about freedom of speech? Freedom to share? Freedom to help your neighbor? Freedom to control what acts on your behalf? Freedom to decide for yourself what's best for you? Aren't these freedoms? Aren't they worth fighting for? Don't you see that these are what the 4 essential software freedoms are about? >>> Yes, but the freedom I want is the freedom to combine components >>> without restrictions. >> That's not any of the four essential freedoms. > Which is why I think they are entirely misguided. Reusing and > recombining prior work is the basis of all knowledge and progress > and any restrictions to inhibit that are harmful. It's the "without restriction" that's misguided. You acknowledged the value of copyright in its original version (which was all about what you wrote above), yet it's that very copyright that imposes the restrictions you oppose. If there wasn't copyright law, you would be able to do just that, regardless of the GPL. Would we really be in a better place? I don't know, and I lean towards thinking that we wouldn't, because the GPL finds a balance that encourages cooperation and avoids some particularly harmful forms of free riding. More details here: http://www.lsd.ic.unicamp.br/~oliva/papers/free-software/BMind.pdf > In a practical sense, there's not much point in separating hardware > and software since they must work together for any result. You won't find opposition to that from me. >> If the components are indeed separate independent works, copyright law >> won't get in your way given the permissions granted by the GPL, at >> least as far as the GPLed components are concerned. > But it does. You can't add your own work to a GPL'd part to make it > link against a commercial library with no GPL'd equivalent, and > redistribute that work of your own. s/commercial/proprietary/ It only does when they aren't "indeed separate independent works". If one is derived from the other, they're not independent works. Inasmuch as your work is not derived from the GPLed part, the GPL has no claims on it. It only does when you combine it with the GPLed part forming a single derived work. >> Unless you want to accept the unethical impositions from the copyright >> holders of the other work, and help them impose them on others (along >> with or separately from the GPLed work you'd like to combine with it), >> that's what you should do anyway. > I don't accept that the copyright holders of the other works > necessarily make unethical impositions. They don't necessarily make them. They choose to. It's their choice. That, along with the fact that they're harmful, is what makes them unethical. > They might, but whether they do or not is unrelated to their right > to make them. Having a right is not a matter of ethics, it's a matter of law. There are many things that are legal and immoral or unethical, and there are many things that are moral and ethical but illegal. I don't dispute their right to make it (although at times I fight it), but I consider it unethical for them to do so. > On the other hand, the imposition that the GPL makes is clearly > unethical even if having copyright provide the legal right to make > that imposition. See? Since the GPL doesn't make impositions (it merely leaves some of the impositions of copyright law in place). So the law, the way it is worded today, is indeed unethical. Now, ask yourself why you can't say distributed the works you combined? The GPL doesn't say you can't. It says you can, if you do so in an ethical manner. On what is based your conclusion that you cannot distribute the combined work? What stops you from distributing it the way that is permitted by the GPL? Why are you complaining about the fix rather than about the problem? > There's no guarantee, but I'm convinced that the restrictions in the > GPL that prevent reuse in competitive works have made more money for > Microsoft than anything Steve Balmer ever did. You're mistaken to boot. The restrictions are from copyright law, not the GPL. They didn't stop Microsoft, and I doubt they would have had a negative impact on Microsoft if they didn't exist. For starters, Microsoft's EULAs are not mere copyright licenses, they're contracts. So the absence of copyright, or a more permissive GPL, would just enable Microsoft to milk software developers as much as it does computer users. And even if the lift had enabled other competitors to surface that didn't surface because of their commitment/requirement/determination to not respect their customers' freedoms, would they be any better than Microsoft, given the commitment? What good outcome would you expect from this? >> it would still be mostly impossible for society to create >> derivative works. So why grant the monopoly in the first place? > It isn't that monopolies are inherently a problem Indeed. > - there are many cases where having a single standard instance of > something is a benefit - Single standards don't have to be monopolies; in fact, the whole point of standardization is to avoid the formation of monopolies, to keep a level playing field and reduce the entrance barrier. And then, they shouldn't be controlled by monopolies. When they are, it just amplifies the harmful power of the monopoly. > it is that they have the power to become a problem by > creating artificial shortages or unreasonable prices. Which is why monopolies have to be carefully and closely regulated. If they become so powerful that they can bend and break rules and avoid punishment in spite of the law, or even buy "upgrades" to the law to suit their needs, everyone loses. And that's unfortunately not a different story. > And the way to prevent those problems is not to try to keep them out > of distribution channels, I can't quite relate your sentence with what I wrote, and since you went in what seems to me to be a tangent in after my previous use of "legal monopoly" to refer to copyrights, I guess you misunderstood what I mean, and I'm not following what you wrote. It's not just about commerce that I'm talking about. The legal monopolies are about being able to control how something is shared, used, modified, and yes, also sold. They're granted by society to benefit society. If they don't bring this benefit, they shouldn't be granted in the first place. > The way to prevent problems is to lower the bar to building > competing alternatives that leave the choices up to the recipients. As in, more of a bad thing is a good thing? :-) Because the GPL doesn't discourage more good things, it only discourages that good things be used to create bad things. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sat Jun 14 20:37:27 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Jun 2008 17:37:27 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> (Chris Chabot's message of "Sat\, 14 Jun 2008 21\:15\:45 +0200") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> Message-ID: On Jun 14, 2008, Chris Chabot wrote: > http://lkml.org/lkml/2000/8/25/132 Talk is cheap. Show me the code. Linus I'd be happy to. Unfortunately, even though it's allegedly GPLed, the sources are missing, so I can't. Sorry to disappoint you. :-) But you're right, Chris, this discussion is no longer related with Fedora any more. After all, who cares if it's legal or ethical or moral to distribute the kernel shipped in Fedora? Or Fedora as a whole, for that matter? Sure it wouldn't be a problem if we found that we can't distribute it any more, right? We could all keep happily developing it, each of us starting from our own local copies that we wouldn't be permitted to share any more, and we'd all live happily everafter. But don't you worry, I'm going to be mostly disconnected throughout most of next week. So I won't fill in your mailbox with "colorful analogies" then. Thanks for the hint. Take care, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Sun Jun 15 00:54:46 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 14 Jun 2008 19:54:46 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> Message-ID: <48546856.9050900@gmail.com> Alexandre Oliva wrote: > >>>> That's a different question, unrelated to how that firmware got into >>>> the device. > >>> I know. I don't understand why you insist on this irrelevant point. > >> Because I think it is the only relevent point. It is only if the >> combined works form a derivative work that restrictions can apply to >> the combination differently than the components and whether a >> derivative work is formed does not depend on how the components were >> distribtuted. > > There are various possibilities here, let me summarize the ones that > occur to me, in no particular order: > > a. one work is a derivative from the other, and they are distributed > together > > b. one work is a derivative from the other, and they are distributed > separately > > c. two unrelated works are distributed separately > > d. two works are combined into a single coherent work, undoubtedly a > derivative from both, regardless of whether the two works were > originally related, and then the derivative work is distributed > > e. two unrelated works are distributed together by mere aggregation in > a single volume of storage or distribution medium > > If I understood your argument correctly, you appear to be proposing > that, because cases such as (a-c) exist, the case at hand can't be > (d), so it must be (e). I don't see how this conclusion can follow > from the premises. Please clue me in? I'm proposing that in this scenario, if d is true, b would also be true if they weren't combined, so the transient combination for distribution is irrelevant. And if b wouldn't be true, then you are left with e. > >> It's about a derived work - which the FSF says is the same regardless >> of the way the parts are distributed. > > Err... I thought you didn't agree it was a derived work. If you > agree that it is, then the terms of the GPL are clear, and there's no > reason for us to be holding this discussion. I don't, but there are different interpretations. I don't see how the FSF stance on user-linked libraries would differ from code in ROM or pre-loaded firmware. >>>> We know the GPL imposes restrictions. > >>> We don't. You think you do, but you're mistaken. Go read the GPL >>> again. > >> I'm not mistaken. Everything in there except the conditional grant to >> use, modify, distribute is a restriction. > > Like what? Tell me *anything* you could do in the absence of the GPL, > that, by accepting the GPL, you can no longer do. Given (or knowing about) a library not covered by the GPL, I can write and distribute original work that uses the functions provided by that library, knowing that anyone can obtain their own copy of by my code and the additional library and use them together. Similarly, I can write code that uses the services of libraries covered by different licenses in the same work, or include code covered by less restrictive licenses. If a single line of the work is covered by the GPL, none of those things are possible, and a near-infinite set of combinations are prohibited from being distributed. >> divisive nature of the GPL. > > Another fallacy. "You can redistribute under the same license" > doesn't divide, it has quite the opposite effect. It's permitting > redistribution under any licenses that may lead to forks, including > ones that don't permit further modifications. You can't permit redistribution of something you have prohibited from existing in the first place. You are talking about the things that can exist. I'm talking about the ones that could exist without the GPL restrictions. >> If you could, you would be able to add a component to a GPL'd work >> that links to a commercial library that the end user is expected to >> obtain separately. > > But you can do that already, as long as the commercial library is > licensed under a GPL-compatible license. Or did you mean to imply > that I'm not going to get my next pay check, and that the ones that > preceded it are just a figment of my imagination? :-) > > Make that s/commercial/proprietary/, pretty please. Don't feed the > FUD machine. s/commercial/non-GPL/. The GPL is just as divisive regarding other code that permits redistribution if its requirements are different at all, for example the original BSD license which is about as far from proprietary as you can get. > >> But whether it is aggregation or not doesn't depend on the container >> or packaging for distribution - it is a separate concept. > > Now you lost me. Can you try to rephrase the point you're trying to > make here in relation with my paragraph above, perhaps using other > words and more sentences? As in, what is this separate concept of > 'aggregation' you're talking about, and how does it compare with 'mere > aggregation in a volume of storage or distribution media'? How the bits are stored isn't what determines whether a derived work is involved or not. I agree that the separation would be more obvious if the bits were not embedded as data in the kernel in whatever format the compiler decides to use, but it is just a technical detail if they are in a separate file or contained within a tar/zip/jar archive or pre-loaded by something other than the kernel. This is a mechanical difference, not related to creativity. You could probably modify the compiler to store data in a separate file instead of whatever embedded memory-loading format it currently uses but it wouldn't change the copyright status of the output. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Sun Jun 15 01:49:56 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 14 Jun 2008 20:49:56 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> Message-ID: <48547544.8060204@gmail.com> Alexandre Oliva wrote: > >> Copyright law exists to encourage creation of works and competition >> among them. There is nothing wrong with that concept, although the >> original short protected life followed by passage to public domain >> seems much more in the public interest than the current incarnation. > > Looks like we're in full agreement about that. Are we also in > agreement that it's (current) copyright law that imposes restrictions? > That the GPL grants carefully delineated permissions for acts that > would otherwise be restricted by copyright law, enough to ensure the 4 > freedoms are respected, but not enough to lift all the restrictions > imposed by copyright law? Yes, I agree that the initial author of a work has as much right to impose the harmful GPL as any other copyright holder has to choose a more or less restrictive license. I'm not so sure about additional contributors of original work who have this choice taken away in the GPL case only, though. Having the choice to contribute under the GPL or not at all resembles that "your money or your life" scenario you presented earlier. >> if competitors were allowed to use components from Linux in >> commercial offerings > > They are. Not in the general case. It would be unfeasible if not technically impossible to ship a Linux based OS containing licensed copies of all the components needed to match the functionality of commercial OS versions. > And competitors could do even more if it weren't because of > restrictions imposed by others, in their licensing offers, which they > can do because of (i) copyright law making certain acts prohibited by > default, (ii) unethical imposition of restrictions, and (iii) > acceptance and passing on of such restrictions from third parties. Those restrictions are a given, and not necessarily a problem on their own. Everyone involved may be perfectly happy to meet whatever those other restrictions might be, yet the GPL's harmful restrictions prevents the useful combination from being distributed. > Your unsatisfaction with the situation is shared by me, but your > blaming the GPL for unfortunate (and at times unethical) choices made > by others is misguided. How so? The harm isn't shared by less restrictive licenses. >>>> You aren't a victim when you make your own choices. > >>> Heh. It's not that simple, really. > >>> "Your wallet or your life." > >> You are confusing the value/moral judgement of the thing itself with a >> delivery mechanism. > > No, I was just providing examples in which, in spite of being given > choice, you're still an overpowered victim. But the concept of victim has a preconceived notion of harm, whereas meeting non-GPL terms may not cause harm at all. >>> If it's intentionally misleading, this would just make it yet another >>> case of unethical behavior. > >> Like the way 'free' is redefined to mean restricted by the GPL? > > You appear to be confusing two different topics. Perhaps, calling restricted software free is confusing. >> What's misguided is your conviction that there is a moral value in the >> delivery channel at all. The value can only be defined by the >> recipient and the effect of the content. > > Reordering a bit from your response to show the contradiction: > >>> It's better to give cigarettes to kids at school than to leave them >>> without anything to put in their mouths at lunch time? :-) > >> The harm from cigarettes is due to the nature of the product, not the >> distribution. The product in question could as easily be milk. > > See? If my conviction you disputed above is wrong, then the person > who decides to distribute cigarettes to the kids instead of milk would > be behaving in accordance with moral and ethics. > > Do you *really* think so? I mean, seriously, maybe you do, but... I > honestly hope not. Your reasoning requires you to know that cigarettes are harmful and there is a body of evidence for that, yet there is no such body of evidence that all software covered by non-GPL licenses is harmful, and it's not up to a distributor to make that kind of value judgment. They must respect the recipients right to make their own choices. >> And yet, you make no requirement that has anything to do with the >> content. That is, you are apparently perfectly willing to distribute >> broken or misleading content that will do much more harm than >> something that just works without requiring any other information. > > I don't agree that incomplete content would do more harm. Given > information, it could be completed and do good. In the absence of > information, it makes no difference. Whereas including the vendor's > bait in a product would turn me into an accomplice, and it would > extend the long-term harm to more people, for it would be feeding the > monster. You are making a value judgment there not only with no evidence, but one that's not yours to make. And if there really is an evil monster in the picture, by helping prevent a usable alternative you drive people directly to the monster even if it is with the pretense that you aren't involved at all. > As for misleading content, I'm against that on moral and ethical > grounds. If source code is sufficiently misleading or abridged, it > may indeed disrespect freedom #1, which is why I mentioned drivers > developed under NDA in the message that started this thread. > > Ethics and morals are a lot about intentions, even when the practical > end results are the same. If the information is missing because the > developer just "didn't have time to add it in some meaningful format, > here are my notes", that's not unethical. > > But if the information is missing because the developer had to sign an > NDA to get the information, "so I can't share it with you", the > developer is a bit of a victim and a vendor's accomplice, and the end > user ends up hurt by the lack of ethics of the vendor in denying the > information on how to make the developer's and end user's devices work > to their own liking. These out-of-context speculations don't make any sense to me. What if there is only one such device and the binary driver works perfectly and never needs a change? >> And you are making an uncalled-for value judgment in calling others >> foolish who may in fact have made the correct choices for their own >> situations. > > That they chose the best available options doesn't mean they couldn't > have avoided being limited to those options, or negotiated a better > deal, or made a different call for balance between short and long > term. But regardless of the options, I don't see how trusting a > vendor that denies technical information about their product can ever > be a clever thing to do, even if you end up deciding to live with the > product because it's the lesser of various evils. I don't have any different feelings about trusting a company to build hardware than to supply software. Nor do I see any reason I should. If they want to give away the materials needed to duplicate either, great, but there is no moral difference related to the type of component. >> Agreed - it is a bad analogy. But so is freedom in terms of >> restrictions on software. > > How about freedom of speech? Freedom to share? Yes, that's the problem. If I write code that links to a GPL library and to any other library, I can't share it, even with someone who already has both other libraries. > Freedom to help your > neighbor? Freedom to control what acts on your behalf? Freedom to > decide for yourself what's best for you? Aren't these freedoms? > Aren't they worth fighting for? Don't you see that these are what the > 4 essential software freedoms are about? No, I want the one that would allow me to share that code. >>> That's not any of the four essential freedoms. > >> Which is why I think they are entirely misguided. Reusing and >> recombining prior work is the basis of all knowledge and progress >> and any restrictions to inhibit that are harmful. > > It's the "without restriction" that's misguided. You acknowledged the > value of copyright in its original version (which was all about what > you wrote above), yet it's that very copyright that imposes the > restrictions you oppose. No, it is specifically the GPL's restriction that I oppose. It takes away your choice about obtaining each component independently or sharing a combined work. >>> If the components are indeed separate independent works, copyright law >>> won't get in your way given the permissions granted by the GPL, at >>> least as far as the GPLed components are concerned. > >> But it does. You can't add your own work to a GPL'd part to make it >> link against a commercial library with no GPL'd equivalent, and >> redistribute that work of your own. > > s/commercial/proprietary/ > > It only does when they aren't "indeed separate independent works". If > one is derived from the other, they're not independent works. > Inasmuch as your work is not derived from the GPLed part, the GPL has > no claims on it. It only does when you combine it with the GPLed part > forming a single derived work. Please show an example of a non-GPL'd work where there has ever been a copyright issue related to another original work being combined (linking in the case of a library) where it was clear that every instance involved the end user having his own licensed copy of both parts. >>> Unless you want to accept the unethical impositions from the copyright >>> holders of the other work, and help them impose them on others (along >>> with or separately from the GPLed work you'd like to combine with it), >>> that's what you should do anyway. > >> I don't accept that the copyright holders of the other works >> necessarily make unethical impositions. > > They don't necessarily make them. They choose to. Who does? > It's their choice. What choice? How do you determine that someone is harmed? > That, along with the fact that they're harmful, is what makes them > unethical. The GPL is harmful too. > Now, ask yourself why you can't say distributed the works you > combined? The GPL doesn't say you can't. It says you can, if you do > so in an ethical manner. On what is based your conclusion that you > cannot distribute the combined work? What stops you from distributing > it the way that is permitted by the GPL? > > Why are you complaining about the fix rather than about the problem? Take the case of the original BSD license. I did/do not consider its requirement for attribution to be unethical. I do consider the restriction of the GPL to not permit combinations with items covered by this license to be harmful and thus unethical. Likewise, I don't consider all commercial/proprietary distributions to be unethical. Some provide good value for their terms. >> There's no guarantee, but I'm convinced that the restrictions in the >> GPL that prevent reuse in competitive works have made more money for >> Microsoft than anything Steve Balmer ever did. > > You're mistaken to boot. The restrictions are from copyright law, not > the GPL. They didn't stop Microsoft, and I doubt they would have had > a negative impact on Microsoft if they didn't exist. You are speculating that in the absence of the GPL, no freely redistributable code would exist. That is rather clearly wrong, given the proliferation of less restricted code like apache, the *bsd's, MITs X, etc. The problem is that much of this code and subsequent work has been hijacked by the GPL which is a one-way trip, so drivers originally modified from the bsd versions and included in Linux took away the choice of subsequent contributors to use any other copyright and now can't be re-used, for example in OpenSolaris. This harms everyone. > For starters, Microsoft's EULAs are not mere copyright licenses, > they're contracts. So the absence of copyright, or a more permissive > GPL, would just enable Microsoft to milk software developers as much > as it does computer users. > > And even if the lift had enabled other competitors to surface that > didn't surface because of their commitment/requirement/determination > to not respect their customers' freedoms, would they be any better > than Microsoft, given the commitment? > > What good outcome would you expect from this? Competition, lower prices, better products, more choices. > Single standards don't have to be monopolies; in fact, the whole point > of standardization is to avoid the formation of monopolies, to keep a > level playing field and reduce the entrance barrier. So how does that work in the case of something like a blu-ray player? >> The way to prevent problems is to lower the bar to building >> competing alternatives that leave the choices up to the recipients. > > As in, more of a bad thing is a good thing? :-) Absolutely. You aren't going to find perfection, so your best bet is having choices among imperfect things. As people make those choices, the bad ones go away. > Because the GPL doesn't discourage more good things, it only > discourages that good things be used to create bad things. It not only discourages good things, it prohibits a near-infinite number of combinations of things that could have been good. -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Sun Jun 15 10:39:51 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Jun 2008 11:39:51 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> Message-ID: <1213526391.26255.436.camel@pmac.infradead.org> On Sat, 2008-06-14 at 17:37 -0300, Alexandre Oliva wrote: > On Jun 14, 2008, Chris Chabot wrote: > > > http://lkml.org/lkml/2000/8/25/132 > > Talk is cheap. Show me the code. http://git.infradead.org/users/dwmw2/firmware-2.6.git HTH -- dwmw2 From rawhide at fedoraproject.org Sun Jun 15 10:44:53 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 15 Jun 2008 10:44:53 +0000 (UTC) Subject: rawhide report: 20080615 changes Message-ID: <20080615104453.EB077209D0F@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080614/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080615/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff Updated Packages: PyQt4-4.4.2-2.fc10 ------------------ * Sat Jun 14 18:00:00 2008 Rex Dieter 4.4.2-2 - PyQt4 is built without QtWebKit support (#451490) clutter-0.6.4-1.fc10 -------------------- * Sat Jun 14 18:00:00 2008 Allisson Azevedo 0.6.4-1 - Update to 0.6.4 cvsps-2.2-0.1.b1.fc10 --------------------- * Sat Jun 14 18:00:00 2008 Ville Skytt?? - 2.2-0.1.b1 - 2.2b1. ekg-1.8-0.1.rc1.fc10 -------------------- * Sat Jun 14 18:00:00 2008 Fedora Release Engineering - 1.8-0.1.rc1 - updated to 1.8rc1 - moved ioctld to %{_libexecdir}/ekg/ioctld for consistency with ekg2 - dropped obsolete external libgadu patch freetype1-1.4-0.6.pre.fc10 -------------------------- * Sat Jun 14 18:00:00 2008 Hans de Goede 1.4-0.6.pre - Backport fixes for CVE-2008-1806, CVE-2008-1807 and CVE-2008-1808 to freetype 1 (where applicable, bz 450773, 450774) halevt-0.1.1-1.fc10 ------------------- * Sat Jun 14 18:00:00 2008 Patrice Dumas 0.1.1-1 - update to 0.1.1 * Mon Jun 9 18:00:00 2008 Patrice Dumas 0.1.0-2 - update to 0.1.0 hunspell-pl-0.20080614-1.fc10 ----------------------------- * Sat Jun 14 18:00:00 2008 Caolan McNamara - 0.20080614-1 - latest version jd-2.0.0-0.6.svn2129_trunk.fc10 ------------------------------- * Sun Jun 15 18:00:00 2008 Mamoru Tasaka - svn 2129 libnet10-1.0.2a-15.fc10 ----------------------- * Sun Jun 15 18:00:00 2008 Patrice Dumas - 1.0.2a-15 - copy config.* from rpm directory, those shpped with libnet10 are too old lm_sensors-3.0.1-6.fc10 ----------------------- * Sat Jun 14 18:00:00 2008 Hans de Goede 3.0.1-6 - Rebuild for new rrdtool mythes-de-0.20060614-1.fc10 --------------------------- * Sat Jun 14 18:00:00 2008 Caolan McNamara - 0.20060614-1 - latest version openvpn-2.1-0.26.rc8.fc10 ------------------------- * Sat Jun 14 18:00:00 2008 Steven Pritchard 2.1-0.26.rc8 - Update to 2.1_rc8. - Update License tag. perl-SVG-Graph-0.02-1.fc10 -------------------------- * Sat Jun 14 18:00:00 2008 Alex Lancaster - 0.02-1 - New upstream (0.02) - Licensing terms clarified: Artistic 2.0 php-magpierss-0.72-4.fc10 ------------------------- * Sat Jun 14 18:00:00 2008 Michael Stahnke - 0.72-4 - License Update php-pear-File-Passwd-1.1.6-3.fc10 --------------------------------- * Sat Jun 14 18:00:00 2008 Christopher Stone 1.1.6-3 - Rebuild for vendor tag (bz #451361) php-pear-File-SMBPasswd-1.0.2-2.fc10 ------------------------------------ * Sat Jun 14 18:00:00 2008 Christopher Stone 1.0.2-2 - Rebuild for vendor tag (bz #451362) php-pear-HTML-QuickForm-ElementGrid-0.1.1-2.fc10 ------------------------------------------------ * Sat Jun 14 18:00:00 2008 Christopher Stone 0.1.1-2 - Rebuild for vendor tag (bz #451364) php-pear-Net-Traceroute-0.21.1-3.fc10 ------------------------------------- * Sat Jun 14 18:00:00 2008 Remi Collet 0.21.1-3 - rebuild (fix Vendor, Bug #451372) - fix license pungi-2.0.0-1.fc10 ------------------ * Fri Jun 13 18:00:00 2008 Jesse Keating - 2.0.0-1 - New major release - Collapse the two classes into one Pungi class - Create a pypungi.util module for utility functions - Pass along repos/mirrorlists configured in ks file to buildinstall - Repo cost is now "cost" in pykickstart python-cherrypy2-2.3.0-4.fc10 ----------------------------- * Sat Jun 14 18:00:00 2008 Toshio Kuratomi 2.3.0-4 - Update README.fedora to fix some code examples and confusing wording. python-paste-1.7.1-1.fc10 ------------------------- * Sat Jun 14 18:00:00 2008 Luke Macken - 1.7.1-1 - Update to Paste 1.7.1 python-paste-deploy-1.3.2-1.fc10 -------------------------------- * Sat Jun 14 18:00:00 2008 Luke Macken - 1.3.2-3 - Update to PasteDeploy 1.3.2 qt-4.4.0-10.fc10 ---------------- ruby-gnome2-0.17.0-0.2.rc1.fc10 ------------------------------- * Sun Jun 15 18:00:00 2008 Mamoru Tasaka - 0.17.0-0.2.rc1 - gtk/gtkfilesystem.h is removed from GTK 2.13.3+, some symbols no longer available (bug 451402, thanks to Matthias) sofia-sip-1.12.9-1.fc10 ----------------------- * Sat Jun 14 18:00:00 2008 Jeffrey C. Ollie - 1.12.9-1 - Update to 1.12.9 - Disable building API documentation because it won't build on PPC/PPC64 (at least in a reasonable amount of time). tclchecker-1.4-6.20061030cvs.fc10 --------------------------------- * Fri Jun 13 18:00:00 2008 Wart 1.4-6.20061030cvs - Drop tbcload which does not work with Tcl 8.5 tcldebugger-1.4-8.20061030cvs.fc10 ---------------------------------- * Fri Jun 13 18:00:00 2008 Wart 1.4-8.20061030cvs - Drop dependency on tbcload which does not work with Tcl 8.5 tclpro-1.5.0-12.20061030cvs.fc10 -------------------------------- * Sat Jun 14 18:00:00 2008 Wart 1.5.0-12.20061030cvs - Remove the tclcompiler executable which doesn't work correctly with Tcl 8.5 zzuf-0.12-1.fc10 ---------------- * Sat Jun 14 18:00:00 2008 Ville Skytt?? - 0.12-1 - 0.12. Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 29 Broken deps for i386 ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From aph at redhat.com Sun Jun 15 11:14:18 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 15 Jun 2008 12:14:18 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> Message-ID: <4854F98A.20804@redhat.com> Chris Chabot wrote: > Now i don't mean to interrupt this wonderful meeting of the minds, > but i am wondering why mail box has been overflowing with an > seemingly endless discussion between only, what, 3 or 4 people? > > In this open source world where attention and focus is our capital, > do we really all need to be enlightened analogies that seem to > frequently involve guns, poisons and other such very colorful > statements.. to a casual observer it would seem it won't be long > until we can evoke Godwin's law. > > I have to admit i did scan through today's and yesterday's emails > and found very little that really related to fedora, even though the > subject of the email and the mailing list would imply this should > somehow be fedora related? Since this seems to now only involve a > very few, but very vocal, people maybe you can take it off list and > report back anything fedora related that may or may not come out of > it? I have to disagree with you here. Although this discussion is between only a few people, it is relevant and important to Fedora. The question of where Fedora stands with respect to the inclusion of unfree software is of key importance; indeed, I might be convinced that nothing is more important. Unlike discussion of particular packages and particular technical issues, this affects everyone and goes to the core of why I'm here, and why Fedora is worth the effort. I agree that analogies with guns and death don't help anyone, though. Andrew. From dwmw2 at infradead.org Sun Jun 15 11:35:34 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Jun 2008 12:35:34 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48546856.9050900@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> Message-ID: <1213529734.26255.458.camel@pmac.infradead.org> On Sat, 2008-06-14 at 19:54 -0500, Les Mikesell wrote: > Alexandre Oliva wrote: > > There are various possibilities here, let me summarize the ones that > > occur to me, in no particular order: > > > > a. one work is a derivative from the other, and they are distributed > > together > > > > b. one work is a derivative from the other, and they are distributed > > separately > > > > c. two unrelated works are distributed separately > > > > d. two works are combined into a single coherent work, undoubtedly a > > derivative from both, regardless of whether the two works were > > originally related, and then the derivative work is distributed > > > > e. two unrelated works are distributed together by mere aggregation in > > a single volume of storage or distribution medium > > > > If I understood your argument correctly, you appear to be proposing > > that, because cases such as (a-c) exist, the case at hand can't be > > (d), so it must be (e). I don't see how this conclusion can follow > > from the premises. Please clue me in? > > I'm proposing that in this scenario, if d is true, b would also be true > if they weren't combined, so the transient combination for distribution > is irrelevant. And if b wouldn't be true, then you are left with e. But (b) is permitted, while (d) is explicitly not permitted. You can't just say "oh, but if I wasn't doing (d) then I'd be doing (b), so that's OK". Let's consider (b) as 'you are carrying a knife' and (d) as 'you are stabbing me with your knife'. And your excuse as... "But officer, if (d) is true, then (b) would also be true if I weren't stabbing him. So the transient combination of the knife and his abdomen is irrelevant." The 'transient combination' is _far_ from being irrelevant. That combination for distribution is very thing that is not permitted. You do not have permission to distribute the GPL'd Program under the conditions described in (d), although you _do_ of course have permission to distribute it under the conditions described in (b). That's the whole point in the bit in the GPL which goes "...this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute those same sections as part of a while which a work based on the Program, the distribution of the whole must be on the terms of this License..." -- dwmw2 From aph at redhat.com Sun Jun 15 11:42:32 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 15 Jun 2008 12:42:32 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48547544.8060204@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> Message-ID: <48550028.70202@redhat.com> Les Mikesell wrote: > Alexandre Oliva wrote: > >>> if competitors were allowed to use components from Linux in >>> commercial offerings >> >> They are. > > Not in the general case. It would be unfeasible if not technically > impossible to ship a Linux based OS containing licensed copies of all > the components needed to match the functionality of commercial OS versions. I don't believe it. What on Earth is to stop anyone from shipping a Linux based OS containing licensed copies of everything needed? I suppose you might argue that device drivers with binary-only licences are needed, but that's a bit of a stretch. Anybody can replace all of userland with proprietary licensed alternatives if they wish. It would be an odd thing to do, but certainly neither unfeasible nor impossible. Andrew. From emmanuel.seyman at club-internet.fr Sun Jun 15 13:13:49 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sun, 15 Jun 2008 15:13:49 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <4854F98A.20804@redhat.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> <4854F98A.20804@redhat.com> Message-ID: <20080615131349.GA12672@orient.maison.lan> * Andrew Haley [15/06/2008 15:07] : > > I have to disagree with you here. Although this discussion is between > only a few people, it is relevant and important to Fedora. The I agree but this isn't the mailing list on which this discussion should take place. Please take to fedora-legal-list. Emmanuel From aph at redhat.com Sun Jun 15 13:21:10 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 15 Jun 2008 14:21:10 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080615131349.GA12672@orient.maison.lan> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <91ADA98B-DDAE-45BD-B8C1-64DCBFC0AD2B@xs4all.nl> <4854F98A.20804@redhat.com> <20080615131349.GA12672@orient.maison.lan> Message-ID: <48551746.5030000@redhat.com> Emmanuel Seyman wrote: > * Andrew Haley [15/06/2008 15:07] : >> I have to disagree with you here. Although this discussion is between >> only a few people, it is relevant and important to Fedora. The > > I agree but this isn't the mailing list on which this discussion should > take place. Please take to fedora-legal-list. But that's only for discussion of legal issues, isn't it? There's no description of that list on the mailman page, but that's what I'm guessing. Andrew. From dwmw2 at infradead.org Sun Jun 15 13:39:00 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Jun 2008 14:39:00 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080614190515.GA15664@devserv.devel.redhat.com> References: <484C5D39.5000308@gmail.com> <1212996568.32207.572.camel@pmac.infradead.org> <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> Message-ID: <1213537140.26255.469.camel@pmac.infradead.org> On Sat, 2008-06-14 at 15:05 -0400, Alan Cox wrote: > On Sat, Jun 14, 2008 at 04:07:24PM +0100, David Woodhouse wrote: > > I was quoting the GPL, and very lightly paraphrasing it to help clear up > > the confusion which you seem intent on seeding. > > I think the word you require is "interpreting" As you wish. I think you're being silly, as I was careful to ensure that there was nothing in my "interpretation" that you could reasonably find fault with -- but I'll stick to a direct quote instead... On Mon, 2008-06-09 at 16:43 -0400, Alan Cox wrote: > Bingo.. and copyright does not give you power over other works It is not the intent of [the GPL] to claim rights or contest your rights to work written entirely by you. Rather, the intent is to exercise the right to control the distribution of derivative or _collective_ works based on the Program. -- dwmw2 From ndbecker2 at gmail.com Sun Jun 15 13:58:53 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 15 Jun 2008 09:58:53 -0400 Subject: Help with build failure (updating mercurial) Message-ID: gmane.linux.network.networkmanager.devel http://koji.fedoraproject.org/koji/taskinfo?taskID=662698 ... error: File must begin with "/": unset error: File must begin with "/": DISPLAY Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/mercurial-1.0.1-3.fc10-root RPM build errors: File must begin with "/": unset File must begin with "/": DISPLAY What's causing this? I also tried to reproduce this locally, but running make mockbuild, but I only got an empty build log. From lightsolphoenix at gmail.com Sun Jun 15 14:04:54 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Sun, 15 Jun 2008 10:04:54 -0400 Subject: Keep getting crashes from X.org using Radeon 9200 and the radeon driver... Message-ID: <48552186.2020203@gmail.com> I'm attaching my Xorg log; I'd post a bug report at bugzilla, but I can't seem to figure out what the cause might be, and so I don't know if it's an existing bug or not. Anyway, the card in question is a Radeon 9200se, and I'm using the standard radeon driver in X. But it crashes, almost at random, at least once a day. I am running Rawhide, so I'm not really surprised there, but I figured it'd be a good idea to send the log to the list anyway. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log.old URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 15 14:22:05 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 15 Jun 2008 23:22:05 +0900 Subject: Help with build failure (updating mercurial) In-Reply-To: References: Message-ID: <4855258D.2030206@ioa.s.u-tokyo.ac.jp> Neal Becker wrote, at 06/15/2008 10:58 PM +9:00: > gmane.linux.network.networkmanager.devel > http://koji.fedoraproject.org/koji/taskinfo?taskID=662698 > ... > error: File must begin with "/": unset > error: File must begin with "/": DISPLAY > Checking for unpackaged > file(s): /usr/lib/rpm/check-files /var/tmp/mercurial-1.0.1-3.fc10-root > RPM build errors: > File must begin with "/": unset > File must begin with "/": DISPLAY > > What's causing this? > > I also tried to reproduce this locally, but running make mockbuild, but I > only got an empty build log. This seems okay. Index: mercurial.spec =================================================================== RCS file: /cvs/extras/rpms/mercurial/devel/mercurial.spec,v retrieving revision 1.48 diff -u -r1.48 mercurial.spec --- mercurial.spec 15 Jun 2008 12:52:43 -0000 1.48 +++ mercurial.spec 15 Jun 2008 14:19:40 -0000 @@ -3,7 +3,7 @@ Summary: A fast, lightweight distributed source control management system Name: mercurial Version: 1.0.1 -Release: 3%{?dist} +Release: 3%{?dist}.1 License: GPLv2 Group: Development/Tools URL: http://www.selenic.com/mercurial/ @@ -162,7 +162,7 @@ %{_libexecdir}/mercurial/ %{_sysconfdir}/mercurial/hgrc.d/hgk.rc -#%check +#%%check #cd tests && python run-tests.py %changelog ------------------------------------------------------------------ http://koji.fedoraproject.org/koji/taskinfo?taskID=662761 Regards, Mamoru From ndbecker2 at gmail.com Sun Jun 15 15:43:40 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 15 Jun 2008 11:43:40 -0400 Subject: automating updates Message-ID: I'm trying to automate the upstream updates of my packages (somewhat). The procedure seems to be: 1. In devel: 1.1 make new-sources 1.2 update .spec 1.3 cvs ci -m 'update to xxx' 1.4 make tag build 2. cp -l -f .spec sources .cvsignore ../F9 cp -l -f .spec sources .cvsignore ../F9 3. for n in 9 8; do ( cd F-$n; cvs ci -m 'update to 1.0.1' && make tag build && bodhi -n -r F$n -t enhancement mercurial-1.0.1-4.fc$n ); done What's not automated? Howto get the current tag (e.g., mercurial-1.0.1-4.fc9)? Optional - extract cvs ci message from spec changelog Howto get bodhi to stop asking for a password? From hun at n-dimensional.de Sun Jun 15 15:53:38 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 15 Jun 2008 17:53:38 +0200 Subject: automating updates In-Reply-To: References: Message-ID: <48553B02.9030507@n-dimensional.de> Neal Becker wrote: > I'm trying to automate the upstream updates of my packages (somewhat). The > procedure seems to be: > > 1. In devel: > 1.1 make new-sources > 1.2 update .spec > 1.3 cvs ci -m 'update to xxx' make clog && cvs commit -F clog > 1.4 make tag build > > 2. cp -l -f .spec sources .cvsignore ../F9 > cp -l -f .spec sources .cvsignore ../F9 Those two cp lines should probably end with F-9 and F-8, right? > 3. for n in 9 8; do ( cd F-$n; cvs ci -m 'update to 1.0.1' && make tag build > && bodhi -n -r F$n -t enhancement mercurial-1.0.1-4.fc$n ); done Shouldn't "make update" do some of the bodhi part? > What's not automated? "make help" may help. > Howto get the current tag (e.g., mercurial-1.0.1-4.fc9)? make verrel > Optional - extract cvs ci message from spec changelog make clog -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From vpivaini at cs.helsinki.fi Sun Jun 15 16:32:47 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 15 Jun 2008 19:32:47 +0300 Subject: Finnish spell checking packages and comps Message-ID: <200806151932.47768.vpivaini@cs.helsinki.fi> Hi, We now have the Enchant Voikko provider in Fedora (package enchant-voikko), which provides Finnish spell checking support in Enchant. I would like to add it in comps for F10 and F9, but it's (clearly) not a GUI app and enchant itself is not in comps at all. This is what I'd like to add under the "Finnish support" group: enchant-voikko Would that be ok? I see pretty much the same has been done for hunspell packages for different languages, but hunspell is in the Base group, enchant is not. What should I do? I also have a package called tmispell-voikko, which can be used as an ispell replacement for Finnish and it also has an ncurses "GUI". Technically it's a text mode app, but could I still add it? It would go under the "Finnish Support" group as well: tmispell-voikko -- Ville-Pekka Vainio From lesmikesell at gmail.com Sun Jun 15 17:22:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 12:22:34 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213529734.26255.458.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> Message-ID: <48554FDA.6040006@gmail.com> David Woodhouse wrote: >> I'm proposing that in this scenario, if d is true, b would also be true >> if they weren't combined, so the transient combination for distribution >> is irrelevant. And if b wouldn't be true, then you are left with e. > > But (b) is permitted, while (d) is explicitly not permitted. You can't > just say "oh, but if I wasn't doing (d) then I'd be doing (b), so that's > OK". > > Let's consider (b) as 'you are carrying a knife' and (d) as 'you are > stabbing me with your knife'. And your excuse as... > > "But officer, if (d) is true, then (b) would also be true if I weren't > stabbing him. So the transient combination of the knife and his abdomen > is irrelevant." No, to whatever extent an analogy works it would be that the stabbing occurs in both b & d scenarios and the difference is whether you carried the knife to the scene or it was already there. > The 'transient combination' is _far_ from being irrelevant. That > combination for distribution is very thing that is not permitted. Aggregations are explicitly permitted. > You do not have permission to distribute the GPL'd Program under the > conditions described in (d), although you _do_ of course have permission > to distribute it under the conditions described in (b). You do have permission to aggregate other items. If you have anything to quibble about here it should be about what methods of aggregation are permitted. > That's the whole point in the bit in the GPL which goes "...this > License, and its terms, do not apply to those sections when you > distribute them as separate works. But when you distribute those same > sections as part of a while which a work based on the Program, the > distribution of the whole must be on the terms of this License..." I don't really see anything there about details you have to observe to maintain a separation. If you want to make some up, go ahead. Maybe you can modify the compiler to do it for you. -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Sun Jun 15 18:07:40 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Jun 2008 19:07:40 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48554FDA.6040006@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> Message-ID: <1213553260.26255.510.camel@pmac.infradead.org> On Sun, 2008-06-15 at 12:22 -0500, Les Mikesell wrote: > David Woodhouse wrote: > >> I'm proposing that in this scenario, if d is true, b would also be true > >> if they weren't combined, so the transient combination for distribution > >> is irrelevant. And if b wouldn't be true, then you are left with e. > > > > But (b) is permitted, while (d) is explicitly not permitted. You can't > > just say "oh, but if I wasn't doing (d) then I'd be doing (b), so that's > > OK". > > > > Let's consider (b) as 'you are carrying a knife' and (d) as 'you are > > stabbing me with your knife'. And your excuse as... > > > > "But officer, if (d) is true, then (b) would also be true if I weren't > > stabbing him. So the transient combination of the knife and his abdomen > > is irrelevant." > > No, to whatever extent an analogy works it would be that the stabbing > occurs in both b & d scenarios and the difference is whether you carried > the knife to the scene or it was already there. No, I think you've completely missed the point. > > The 'transient combination' is _far_ from being irrelevant. That > > combination for distribution is very thing that is not permitted. > > Aggregations are explicitly permitted. Collective works are explicitly not permitted, under some circumstances. > > That's the whole point in the bit in the GPL which goes "...this > > License, and its terms, do not apply to those sections when you > > distribute them as separate works. But when you distribute those same > > sections as part of a while which a work based on the Program, the > > distribution of the whole must be on the terms of this License..." > > I don't really see anything there about details you have to observe to > maintain a separation. If you want to make some up, go ahead. Maybe > you can modify the compiler to do it for you. I have absolutely no clue what you're trying to say; I'm sorry. This is why I stopped responding to you before. On closer inspection, it seems that what I thought was a rare moment of lucidity from you was actually Alex's doing, so I should probably go back to ignoring you. Sorry. -- dwmw2 From moe at blagblagblag.org Sun Jun 15 18:44:54 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 15 Jun 2008 15:44:54 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080609213359.GA11775@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> Message-ID: <48556326.7010202@blagblagblag.org> Alan Cox wrote: > On Mon, Jun 09, 2008 at 10:11:33PM +0100, David Woodhouse wrote: >> distribute those _same_ sections as part of a whole which is a work >> based on the GPL'd Program... > > I do not believe they are "part of a whole which is a work based on..". In > this case I believe they are independant works that are merely aggregated. > The alternate position would be that a general interface between two > independent works somehow made them one. That would just as equally say that > firefox and the web are one work. > >> Do you believe that copyright law _prevents_ the GPL from making >> requirements about those separate works, in such a way that still lets >> you distribute the GPL'd work without complying with the licence? > > That would seem to be a "how often do you beat your wife" question. The > underlying falsehood being that the GPL licence is not being complied with > > I don't need your permission to copy the firmware for the tg3 driver I need > the permission of Broadcom. Perhaps you can clarify this for me. ** What license is linux-2.6.25/drivers/net/tg3.c distributed under? ** If it's not GPLv2, then people should stop saying the Linux kernel is GPv2L, since it isn't. If just part of the file is proprietary and the other part is GPLv2 how can it legally include things like this? #include which says is under the GPLv2. And if it's "mere aggregation" where does someone get two parts that are aggregated? You can't *simply* remove the firmware since they are so tied together in the tg3.c file (e.g. I tried to do that and broke the driver--it took Alexandre to do it right). (I should also note that I'm just talking about the source code--not what runs where, which is irrelevant to the source itself--I *never* have to even run the code to by bound by the GPL.) -Jeff From kwade at redhat.com Sun Jun 15 19:29:00 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Sun, 15 Jun 2008 12:29:00 -0700 Subject: documenting process for packages renamed upstream In-Reply-To: <4851C9B9.9060601@redhat.com> References: <4851C9B9.9060601@redhat.com> Message-ID: <1213558140.3866.526.camel@calliope.phig.org> On Fri, 2008-06-13 at 11:13 +1000, Jens Petersen wrote: > Is the process for renaming packages in fedora that have been renamed > upstream document on the wiki? I haven't been able to find any > description of our process in that case. > > I think it happens often enough that the process should be written down. > As I understand it a new package review is not required in the case but > cvsadmin requests are needed to create the new package. If you don't find this, can you draft a page under User:Petersen, then ... well, I suppose you submit it to the Packaging SIG? I think that group all have ACLs to update Packaging(.*). - Karsten -- Karsten Wade, Sr. 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 ville.skytta at iki.fi Sun Jun 15 20:32:58 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 15 Jun 2008 23:32:58 +0300 Subject: documenting process for packages renamed upstream In-Reply-To: <1213558140.3866.526.camel@calliope.phig.org> References: <4851C9B9.9060601@redhat.com> <1213558140.3866.526.camel@calliope.phig.org> Message-ID: <200806152332.59212.ville.skytta@iki.fi> On Sunday 15 June 2008, Karsten 'quaid' Wade wrote: > On Fri, 2008-06-13 at 11:13 +1000, Jens Petersen wrote: > > Is the process for renaming packages in fedora that have been renamed > > upstream document on the wiki? I haven't been able to find any > > description of our process in that case. > > > > I think it happens often enough that the process should be written down. > > As I understand it a new package review is not required in the case but > > cvsadmin requests are needed to create the new package. > > If you don't find this, can you draft a page under User:Petersen, > then ... well, I suppose you submit it to the Packaging SIG? I think > that group all have ACLs to update Packaging(.*). Wouldn't the general renaming guideline apply? https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages From kanarip at kanarip.com Sun Jun 15 21:04:13 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 15 Jun 2008 23:04:13 +0200 Subject: automating updates In-Reply-To: References: Message-ID: <485583CD.5070200@kanarip.com> Neal Becker wrote: > I'm trying to automate the upstream updates of my packages (somewhat). The > procedure seems to be: > > 1. In devel: > 1.1 make new-sources > 1.2 update .spec > 1.3 cvs ci -m 'update to xxx' > 1.4 make tag build > > 2. cp -l -f .spec sources .cvsignore ../F9 > cp -l -f .spec sources .cvsignore ../F9 > > 3. for n in 9 8; do ( cd F-$n; cvs ci -m 'update to 1.0.1' && make tag build > && bodhi -n -r F$n -t enhancement mercurial-1.0.1-4.fc$n ); done > > What's not automated? > Hmm... although I'm not much of a packager nor a frequent user of the CVS system: common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm cvs up cd devel; make build; cd .. cd F-9; make build; make update [options]^1; cd .. ^1: takes the latest completed koji build of the appropriate tag even without specifying the package name -doesn't it? Looks to me is a little easier to script... don't you think? Kind regards, Jeroen van Meeuwen -kanarip From lesmikesell at gmail.com Sun Jun 15 22:13:21 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 17:13:21 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213553260.26255.510.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> Message-ID: <48559401.80503@gmail.com> David Woodhouse wrote: >> > No, I think you've completely missed the point. The point is whether a derivative work exists, which won't depend on how the parts get to their end locations. If it is a derivative when the parts are aggregated for delivery it will be just as much a derivative if the parts are delivered separately. >>> The 'transient combination' is _far_ from being irrelevant. That >>> combination for distribution is very thing that is not permitted. >> Aggregations are explicitly permitted. > > Collective works are explicitly not permitted, under some circumstances. Do do have an exact definition of what is not permitted? Chunks of data carried along for the ride and dropped into separate devices strike me as "sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves". Before getting carried away, can you show how firmware would not fit this description? >>> That's the whole point in the bit in the GPL which goes "...this >>> License, and its terms, do not apply to those sections when you >>> distribute them as separate works. But when you distribute those same >>> sections as part of a while which a work based on the Program, the >>> distribution of the whole must be on the terms of this License..." >> I don't really see anything there about details you have to observe to >> maintain a separation. If you want to make some up, go ahead. Maybe >> you can modify the compiler to do it for you. > > I have absolutely no clue what you're trying to say; I'm sorry. This is > why I stopped responding to you before. Whatever mechanical translations you can do to something will not change its copyright status. If you make a tar file containing 2 different copyrighted works, they are still 2 separate works, but there is nothing magic about tar's format that relates to this concept. Any other way of aggregating the bits together would be the same, including having the compiler lump the bits in a spot where they can be extracted as cleanly as a 'tar -x' would do it. It is just a different way of mechanical aggregation of bits that have nothing to do with each other and are separated before use. -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Sun Jun 15 22:56:53 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Jun 2008 23:56:53 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48559401.80503@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> Message-ID: <1213570613.26255.576.camel@pmac.infradead.org> On Sun, 2008-06-15 at 17:13 -0500, Les Mikesell wrote: > Do do have an exact definition of what is not permitted? I pasted a precise definition of 'collective work' already, didn't I? It is a work in which a number of separate and independent works are assembled into one work. The very definition of 'collective work' is that it is an aggregation of other independent and separate works. In order to create a collective work, you need the permission of the copyright-holders of each of the constituent parts. If any _one_ of them denies you that permission, then you may not distribute that collective work. (I know some people like to make silly noises about 'power over unrelated other works', but those really are just silly noises. The GPL only needs to deny you permission to use the GPL'd work in that situation, and that's perfectly sufficient to stop you. It doesn't need extra magic powers over the other works that you wanted to include.) Now, the GPL explicitly says that collective works including the GPL'd Program are only permitted if the other independent and separate constituent parts of that whole are also available under the terms of the GPL. If they're not, then you're not granted permission to distribute GPL'd Program in that form. As you know, the GPL makes an exception for 'mere aggregation on a volume of a storage or distribution medium'. There is some scope for debate on precisely what is covered by that exception, but not a huge amount. It is fairly obvious that that exception doesn't excuse _all_ forms of aggregation, unconditionally. That's because _all_ collective works are an aggregation of sorts, by definition -- and it would be ridiculous to believe that the GPL contains those two paragraphs which explicitly state its intent to cover collective works, only to say "oh, actually I didn't really mean any of it" in the next paragraph. I've been talking generically so far. Getting back to the particular case of firmware and kernel drivers... these are claimed by the network driver maintainer to be "intimately tied" "pieces of a coherent whole". I really cannot see how that claim by an expert in the field can be reconciled with a claim that the presence of the firmware is 'mere aggregation on a volume of a storage medium'. But it's not particularly well-phrased, so there is a grey area, and no definitive 'right' answer until/unless it's been heard in court. There are only 'likely' answers. But any interpretation which includes _all_ collective works in that exception for 'mere aggregation on a volume of a storage or distribution medium' is not at all credible; it is clearly inconsistent with the explicitly stated intent of the GPL. > Chunks of data > carried along for the ride and dropped into separate devices strike me > as "sections of that work are not derived from the Program, > and can be reasonably considered independent and separate works in > themselves". Before getting carried away, can you show how firmware > would not fit this description? Of _course_ the firmware fits that description. That's what I've been saying all along -- and that's why I think you're missing the point. When you distribute the firmware blobs as separate works, of _course_ the GPL doesn't apply to them. But when you distribute those same blobs as part of a whole which is a work based on the GPL'd Program, the distribution of the whole must be on the terms of the GPL, whose permissions for other licensees extend to the entire whole, and thus to each and every part, regardless of who wrote it. Thus, it is not the intent of the GPL to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. -- dwmw2 From moe at blagblagblag.org Sun Jun 15 23:12:59 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 15 Jun 2008 20:12:59 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48559401.80503@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> Message-ID: <4855A1FB.7080205@blagblagblag.org> Les Mikesell wrote: > Whatever mechanical translations you can do to something will not change > its copyright status. If you make a tar file containing 2 different > copyrighted works, they are still 2 separate works, but there is nothing > magic about tar's format that relates to this concept. But what is the copyright status of drivers/net/tg3.c? What lines are GPL (if they are) and which lines are not GPL? I don't mean this as a theoretical exercise, I mean this *literally*. If you read tg3.c it *ONLY* says: /* * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) * Copyright (C) 2004 Sun Microsystems Inc. * Copyright (C) 2005-2007 Broadcom Corporation. * * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. */ It never mentions GPL *EXCEPT* here: MODULE_AUTHOR("David S. Miller (davem at redhat.com) and Jeff Garzik (jgarzik at pobox.com)"); MODULE_DESCRIPTION("Broadcom Tigon3 ethernet driver"); MODULE_LICENSE("GPL"); But tg3.o as distributed by RedHat/Fedora when it's compiled is *NOT* a GPL .o, it has the proprietary data in it. It isn't separate at all (like some firmware, say intel wireless, which is a completely separate file). I look at tg3.c and I can't tell where this "aggregation" begins and ends. It's the *SAME FILE*. Can you clearly say which line numbers are GPL and which line numbers are not GPL? Thanks, -Jeff From tibbs at math.uh.edu Sun Jun 15 23:23:42 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jun 2008 18:23:42 -0500 Subject: Proposal: bugzilla component for pre-review package development Message-ID: Occasionally we see a package review ticket opened for a package which really isn't ready for review. I'm not sure bugzilla is really best the place for coordinating packaging work, but some seem to want to use it for that and I don't really see it as being invalid. Some folks just want to drop a specfile but don't really want to stick around to maintain the package. Unfortunately when this happens, the "not ready for review" ticket shows up in the review queue, extremely scarce reviewer time is wasted on tickets that aren't reviewable, and the already huge queue gets even bigger. One way to deal with this is to just give these tickets their own bugzilla component. I'm not really sure what to call it, though. Maybe "Package Development", but that sounds a bit broad. Whatever the component is called, though, it would give these tickets a place to go that doesn't complicate the package review process. - J< From dwmw2 at infradead.org Sun Jun 15 23:24:31 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 00:24:31 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855A1FB.7080205@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> Message-ID: <1213572271.26255.586.camel@pmac.infradead.org> On Sun, 2008-06-15 at 20:12 -0300, jeff wrote: > But tg3.o as distributed by RedHat/Fedora when it's compiled is *NOT* a GPL .o, > it has the proprietary data in it. It isn't separate at all (like some > firmware, say intel wireless, which is a completely separate file). > > I look at tg3.c and I can't tell where this "aggregation" begins and ends. It's > the *SAME FILE*. Can you clearly say which line numbers are GPL and which line > numbers are not GPL? It is quite clearly a violation of the GPL. Feel free to submit a patch to shift the firmware out of that file and fix the driver to use request_firmware() for it. I'm collecting such patches in the git tree I referred to earlier. For now, we're shifting firmware blobs into the firmware/ directory and still letting people include them into their kernel image. But I strongly believe that's _still_ a GPL violation, because they are still being distributed 'as part of a whole which is a work based on the Program', rather than 'as separate works'. With all that that implies. So in the long run, we actually want to move the whole lot out of the firmware/ directory of the kernel source and into an entirely separate package. But we'll do things one step at a time; let's get the drivers fixed to use request_firmware() first, and then we can worry about the details of how that firmware gets shipped. -- dwmw2 From jonstanley at gmail.com Sun Jun 15 23:38:09 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 15 Jun 2008 19:38:09 -0400 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: On Sun, Jun 15, 2008 at 7:23 PM, Jason L Tibbitts III wrote: > Unfortunately when this happens, the "not ready for review" ticket > shows up in the review queue, extremely scarce reviewer time is > wasted on tickets that aren't reviewable, and the already huge queue > gets even bigger. One way to deal with this is to just give these > tickets their own bugzilla component. I'm not really sure what to > call it, though. Maybe "Package Development", but that sounds a bit > broad. Whatever the component is called, though, it would give these > tickets a place to go that doesn't complicate the package review > process. Maybe a trac instance on hosted? Or maybe a special status whiteboard that says "don't do anything with these" would be better than littering bugzilla with yet more irrelevant data :). From moe at blagblagblag.org Mon Jun 16 00:08:01 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 15 Jun 2008 21:08:01 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213572271.26255.586.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <1213572271.26255.586.camel@pmac.infrad! ead.org> Message-ID: <4855AEE1.70505@blagblagblag.org> David Woodhouse wrote: > On Sun, 2008-06-15 at 20:12 -0300, jeff wrote: >> But tg3.o as distributed by RedHat/Fedora when it's compiled is *NOT* a GPL .o, >> it has the proprietary data in it. It isn't separate at all (like some >> firmware, say intel wireless, which is a completely separate file). >> >> I look at tg3.c and I can't tell where this "aggregation" begins and ends. It's >> the *SAME FILE*. Can you clearly say which line numbers are GPL and which line >> numbers are not GPL? > > It is quite clearly a violation of the GPL. > > Feel free to submit a patch to shift the firmware out of that file and > fix the driver to use request_firmware() for it. I'm collecting such > patches in the git tree I referred to earlier. Well, I did do a patched kernel with the GPL violations removed--but my goal wasn't to make it so people could then re-add non-free software, so I don't think the request_firmware() path is the one I'd take. Alexandre Oliva is now maintaining this free software branch of the linux kernel (as you know) as he's far more competent at this than me... ==== The "GPLing" of the driver (MODULE_LICENSE("GPL")) and the inclusion of a chunk of non-free code occurred in commit [1] 2d8a9d3fd19147c808aa39ddc69a743d1c90f199. The commit shows David S. Miller (davem at redhat.com) and Jeff Garzik (jgarzik at mandrakesoft.com) as authors. If they have ever had it, couldn't they be sued for the source code like other companies that are violating the GPL? I suppose it would be RedHat itself that is liable, not them individually since presumably David Miller was working on RH time. But he also has commits with huge non-free chunks, such as b7fea8b8bd72166942e8b589e0e948af4aff3a37 coming from "davemloft.net" (others from "ninka.net"), so perhaps he would be individually responsible too. I haven't thought through the implications of it yet, but lines in the firmware itself get occassionally modified--it wasn't just a one time dump, so it appears the source is there somewhere and someone is hacking away at it. Perhaps Broadcom themselves (they added their copyright three years later, in b8d263683391ab74f5794657a4b4edc6d7632937) have to give over the source code if Miller and/or Garzik don't have it. Has RedHat ever had the source code to the driver? -Jeff [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git From tibbs at math.uh.edu Mon Jun 16 00:20:49 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jun 2008 19:20:49 -0500 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: >>>>> "JS" == Jon Stanley writes: JS> Maybe a trac instance on hosted? For every separate package, when the submitters often don't even have Fedora accounts? JS> Or maybe a special status whiteboard that says "don't do anything JS> with these" would be better than littering bugzilla with yet more JS> irrelevant data :). I don't see how a component differs from a status entry in that regard. Unless you're arguing that these things shouldn't be in bugzilla at all, which I don't agree with. If, however, you're saying that we (the reviewers) should still have to open a ticket and look at its whiteboard to know we shouldn't mess with it, then I contend that's a needless waste of a very limited resource (reviewer time). Putting tickets that don't contain packages for review under the "Package Review" component makes about as much sense as putting them under "kernel". - J< From tibbs at math.uh.edu Mon Jun 16 00:24:38 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jun 2008 19:24:38 -0500 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> I don't see how a component differs from a status entry in that JLT> regard. Unless you're arguing that these things shouldn't be in JLT> bugzilla at all, which I don't agree with. ^^^^^ Ugh, "don't DISagree with". - J< From lesmikesell at gmail.com Mon Jun 16 00:26:22 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 19:26:22 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213570613.26255.576.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> Message-ID: <4855B32E.8090803@gmail.com> David Woodhouse wrote: > On Sun, 2008-06-15 at 17:13 -0500, Les Mikesell wrote: >> Do do have an exact definition of what is not permitted? > > I pasted a precise definition of 'collective work' already, didn't I? That is unrelated to the question. > It is a work in which a number of separate and independent works are > assembled into one work. > > The very definition of 'collective work' is that it is an aggregation of > other independent and separate works. And aggregations are explicitly permitted which makes that discussion irrelevant. > In order to create a collective work, you need the permission of the > copyright-holders of each of the constituent parts. If any _one_ of them > denies you that permission, then you may not distribute that collective > work. And this part applies equally to every line of code and data. Having source or not doesn't change the requirement for permission to distribute - or give anyone more or less reason to question whether that permission has been given. > As you know, the GPL makes an exception for 'mere aggregation on a > volume of a storage or distribution medium'. There is some scope for > debate on precisely what is covered by that exception, but not a huge > amount. So the relevant discussion should be about whether there is a person that can identify the separate parts. > I've been talking generically so far. Getting back to the particular > case of firmware and kernel drivers... these are claimed by the network > driver maintainer to be "intimately tied" "pieces of a coherent whole". > I really cannot see how that claim by an expert in the field can be > reconciled with a claim that the presence of the firmware is 'mere > aggregation on a volume of a storage medium'. You could resolve that question by finding someone who can identify the separate parts. > But it's not particularly well-phrased, so there is a grey area, and no > definitive 'right' answer until/unless it's been heard in court. There > are only 'likely' answers. And at least in the US, copyright is a matter of civil law so it won't go to court unless the holder of the copyright that is violated takes it there. > When you distribute the firmware blobs as separate works, of _course_ > the GPL doesn't apply to them. > > But when you distribute those same blobs as part of a whole which is a > work based on the GPL'd Program, the distribution of the whole must be > on the terms of the GPL, whose permissions for other licensees extend to > the entire whole, and thus to each and every part, regardless of who > wrote it. Unless they consist of separate parts that have been aggregated together... But, I think you are the one missing the point at least from the perspective of the FSF or anyone likely to take legal action on behalf of the GPL. They claim that it doesn't matter if the components are distributed separately or not. For example, you can't modify a GPL'd component so that it needs a library under different terms even if the parts are never distributed together. > Thus, it is not the intent of the GPL to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Program. Whether it is a derivative or 'work as a whole' depends on the relationship of the parts, not temporary physical proximity. If the compiler keeps the parts separate so the downloading code can identify them to download the correct separate data to the correct separate device they are rather clearly separate things aggregated temporarily within a file. This might be more obvious if it were easier for a human to identify the parts, but that's a mechanical detail. The question of whether the relationship of the runtime code makes it a derived work might still remain, but it is unrelated to the bits of code and data having been aggregated as permitted. -- Les Mikesell lesmikesell at gmail.com From christoph.wickert at googlemail.com Mon Jun 16 00:06:59 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 16 Jun 2008 02:06:59 +0200 Subject: automating updates In-Reply-To: <485583CD.5070200@kanarip.com> References: <485583CD.5070200@kanarip.com> Message-ID: <1213574819.3843.13.camel@wicktop.localdomain> Am Sonntag, den 15.06.2008, 23:04 +0200 schrieb Jeroen van Meeuwen: > Neal Becker wrote: > > I'm trying to automate the upstream updates of my packages (somewhat). The > > procedure seems to be: > > > > 1. In devel: > > 1.1 make new-sources > > 1.2 update .spec > > 1.3 cvs ci -m 'update to xxx' As ?Ulrich already suggested yesterday: 1.3.1 make clog 1.3.2 cvs commit -F clog > > 1.4 make tag build > > > > 2. cp -l -f .spec sources .cvsignore ../F9 > > cp -l -f .spec sources .cvsignore ../F9 > > > > 3. for n in 9 8; do ( cd F-$n; cvs ci -m 'update to 1.0.1' && make tag build > > && bodhi -n -r F$n -t enhancement mercurial-1.0.1-4.fc$n ); done > > > > What's not automated? > > > > Hmm... although I'm not much of a packager nor a frequent user of the > CVS system: > > common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm > common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm ?Jeroen, please don't do that. We had this discussion back in Feb 2007 on the maintainers list, please search for the thread named "?Discourage cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting)". As a result of this discussion we set up a wiki page: ?https://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo ?Regards, Christoph From lesmikesell at gmail.com Mon Jun 16 00:38:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 19:38:47 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855A1FB.7080205@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> Message-ID: <4855B617.8020509@gmail.com> jeff wrote: > Les Mikesell wrote: >> Whatever mechanical translations you can do to something will not >> change its copyright status. If you make a tar file containing 2 >> different copyrighted works, they are still 2 separate works, but >> there is nothing magic about tar's format that relates to this concept. > > But what is the copyright status of drivers/net/tg3.c? What lines are > GPL (if they are) and which lines are not GPL? I don't mean this as a > theoretical exercise, I mean this *literally*. If you read tg3.c it > *ONLY* says: > > /* > * tg3.c: Broadcom Tigon3 ethernet driver. > * > * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) > * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) > * Copyright (C) 2004 Sun Microsystems Inc. > * Copyright (C) 2005-2007 Broadcom Corporation. > * > * Firmware is: > * Derived from proprietary unpublished source code, > * Copyright (C) 2000-2003 Broadcom Corporation. > * > * Permission is hereby granted for the distribution of this firmware > * data in hexadecimal or equivalent format, provided this copyright > * notice is accompanying it. > */ > > > It never mentions GPL *EXCEPT* here: > > MODULE_AUTHOR("David S. Miller (davem at redhat.com) and Jeff Garzik > (jgarzik at pobox.com)"); > MODULE_DESCRIPTION("Broadcom Tigon3 ethernet driver"); > MODULE_LICENSE("GPL"); > > > But tg3.o as distributed by RedHat/Fedora when it's compiled is *NOT* a > GPL .o, it has the proprietary data in it. It isn't separate at all > (like some firmware, say intel wireless, which is a completely separate > file). > > I look at tg3.c and I can't tell where this "aggregation" begins and > ends. It's the *SAME FILE*. Can you clearly say which line numbers are > GPL and which line numbers are not GPL? I don't know much about kernel drivers and I don't think ordinary humans are expected to. I'd approach the question more mechanically, on the same order as trying to establish if the elements within a tar file are separate things, or if the files represented within an iso image are separate things. If the compiler stores in a form that the loader can identify and download to the correct device, I'd be convinced that it is a separate thing regardless of any intermediate mechanical transformations or representations. -- Les Mikesell lesmikesell at gmail.com From christoph.wickert at googlemail.com Mon Jun 16 00:48:37 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 16 Jun 2008 02:48:37 +0200 Subject: Features that would be great for Fedora 10 In-Reply-To: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> References: <64b14b300806120130t6cde92c5i333031f0da3f001d@mail.gmail.com> Message-ID: <1213577317.3843.48.camel@wicktop.localdomain> Am Donnerstag, den 12.06.2008, 10:30 +0200 schrieb Valent Turkovic: > Here are just few features that I believe would be great for Fedora 10 to have: > > 1. RFE: Add desktop folder with examples of what "fedora thing" can do :) > https://bugzilla.redhat.com/show_bug.cgi?id=315171 [...] > 2. RFE: Desktop shortcut for joining Fedora IRC (aka "Get Live Help"): > https://bugzilla.redhat.com/show_bug.cgi?id=430217 and > https://bugzilla.redhat.com/show_bug.cgi?id=179703 Correct me if I'm wrong, but you already suggested these two ideas like a year ago, didn't you? And AFAIR the result of the discussion more or less ?was "Do it, if you want to." Please present us some content for the examples folder and tell us how the IRC link works. How do the Sabayon guys handle different IRC clients for example? How to get a registered nick? I think I already asked you this a year ago but I did not get a reply. :( > Fedora is about freedom+communication, right? [...] Yes, but Fedora also is about participation and working together. "Working together" still means WORKING in first place and not only filing RFEs. So please go for it! Kind Regards, Christoph From moe at blagblagblag.org Mon Jun 16 01:01:41 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 15 Jun 2008 22:01:41 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855B617.8020509@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> Message-ID: <4855BB75.50603@blagblagblag.org> Les Mikesell wrote: > jeff wrote: >> Les Mikesell wrote: >>> Whatever mechanical translations you can do to something will not >>> change its copyright status. If you make a tar file containing 2 >>> different copyrighted works, they are still 2 separate works, but >>> there is nothing magic about tar's format that relates to this concept. >> >> But what is the copyright status of drivers/net/tg3.c? What lines are >> GPL (if they are) and which lines are not GPL? I don't mean this as a >> theoretical exercise, I mean this *literally*. If you read tg3.c it >> *ONLY* says: >> >> /* >> * tg3.c: Broadcom Tigon3 ethernet driver. >> * >> * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller >> (davem at redhat.com) >> * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) >> * Copyright (C) 2004 Sun Microsystems Inc. >> * Copyright (C) 2005-2007 Broadcom Corporation. >> * >> * Firmware is: >> * Derived from proprietary unpublished source code, >> * Copyright (C) 2000-2003 Broadcom Corporation. >> * >> * Permission is hereby granted for the distribution of this >> firmware >> * data in hexadecimal or equivalent format, provided this copyright >> * notice is accompanying it. >> */ >> >> >> It never mentions GPL *EXCEPT* here: >> >> MODULE_AUTHOR("David S. Miller (davem at redhat.com) and Jeff Garzik >> (jgarzik at pobox.com)"); >> MODULE_DESCRIPTION("Broadcom Tigon3 ethernet driver"); >> MODULE_LICENSE("GPL"); >> >> >> But tg3.o as distributed by RedHat/Fedora when it's compiled is *NOT* >> a GPL .o, it has the proprietary data in it. It isn't separate at all >> (like some firmware, say intel wireless, which is a completely >> separate file). >> >> I look at tg3.c and I can't tell where this "aggregation" begins and >> ends. It's the *SAME FILE*. Can you clearly say which line numbers are >> GPL and which line numbers are not GPL? > > I don't know much about kernel drivers and I don't think ordinary humans > are expected to. Well ordinary humans don't post 20 times to fedora-devel arguing about kernel drivers either--but you have. You can't just cop out and plead ignorance now. How lame of you. > I'd approach the question more mechanically, on the > same order as trying to establish if the elements within a tar file are > separate things, Well, if that tar file is distributed as a GPL file, then everything in it would be GPL, no? > or if the files represented within an iso image are > separate things. If the entire ISO is distributed as GPL, it wouldn't be separate would it? > If the compiler stores in a form that the loader can > identify and download to the correct device, I'd be convinced that it is > a separate thing regardless of any intermediate mechanical > transformations or representations. But they are being *shipped together* in a package whose license says: GPLv2. $ rpm -qp --queryformat "%{LICENSE}\n" kernel-2.6.26-0.67.rc6.git1.fc10.src.rpm GPLv2 So RedHat is claiming they are shipping a GPLv2 kernel, when they clearly aren't (they are also doing it knowingly). Note, there are packages that have a mix of licenses, and this gets clearly pointed out in the LICENSE tag. If RedHat has the source to this driver, I believe they are obligated to turn it over to anyone they have distributed a kernel to--they shouldn't be able to add proprietary bits to the Linux kernel and keep the code to themselves. Same is true for broadcom. So you may be convinced that it is a separate thing (though you are really really really stretching things, when both tg3.c and tg3.o have everything combined), but by calling the whole thing GPL, it would encompass that firmware as well. They are not saying "GPLv2 and Proprietary firmware that is merely aggregated into the same .o".... -Jeff From moe at blagblagblag.org Mon Jun 16 01:39:41 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 15 Jun 2008 22:39:41 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855BB75.50603@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> Message-ID: <4855C45D.6080809@blagblagblag.org> jeff wrote: > If RedHat has the source to this driver, I believe they are obligated to > turn it over to anyone they have distributed a kernel to--they shouldn't > be able to add proprietary bits to the Linux kernel and keep the code to > themselves. Same is true for broadcom. In fact, if you go to Broadcom's site to download the driver[1,2], it says "The Broadcom Linux Ethernet drivers are licensed under the GNU GPL. The full text of the license is available in the driver archive." The LICENSE file included is the GPLv2. The .src.rpm that is included has the LICENSE tag GPL. To me it appears quite clear that Broadcom is distributing a GPL'd file, and thus has to turn over the source code. Now you may argue this exempts them from this (but it probably still doesn't): * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. But what about in versions distributed for years where that was not included? That text above is recent addition. To my surprise when I went to download the driver on their page I found I had an old ~/devel/broadcom directory with a file linux-7.3.5.zip containing files timestamped from 2004 (the above copyright was added in 2005). Here, the bcm5700-7.3.5-1.src.rpm file was tagged "GPL". It also contains bcm5700-7.3.5 directory with the single LICENSE file of the GPLv2 (making no mention of aggregation and such). The bcm5700-7.3.5-2.4.26.patch included with that LICENSE reads: +/******************************************************************************/ +/* */ +/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */ +/* Corporation. */ +/* All rights reserved. */ +/* */ +/* 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, located in the file LICENSE. */ and then contains a bunch of: +0x10000003, 0x0, 0xd, 0xd, +0x3c1d0800, 0x37bd3ffc, 0x3a0f021, 0x3c100800, +0x26100000, 0xe000018, 0x0, 0xd, +0x3c1d0800, 0x37bd3ffc, 0x3a0f021, 0x3c100800, +0x26100034, 0xe00021c, 0x0, 0xd, They make *NO* mention of a separate license. Can someone explain to me why they are *not* now required to distribute the source code to this? They have themselves clearly placed the file under the GPL and didn't write any 'exceptions' (which could be invalid anyway). They clearly state years later that it is "Derived from proprietary unpublished source code", so there *is* source code to this (as opposed to a bunch of register settings or whatever). Gimme the source! :) -Jeff [1] http://www.broadcom.com/support/ethernet_nic/netxtreme_desktop.php [2] http://www.broadcom.com/docs/driver_download/570x/linux-3.85l.zip From tcallawa at redhat.com Mon Jun 16 02:19:19 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 15 Jun 2008 22:19:19 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855C45D.6080809@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> Message-ID: <1213582759.3861.11.camel@localhost.localdomain> On Sun, 2008-06-15 at 22:39 -0300, jeff wrote: > To me it appears quite clear that Broadcom is distributing a GPL'd > file, and thus has to turn over the source code. I would encourage you to pursue this with Broadcom, as they are clearly the copyright holder for the firmware. ~spot From vonbrand at inf.utfsm.cl Mon Jun 16 02:42:01 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 15 Jun 2008 22:42:01 -0400 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> Message-ID: <200806160242.m5G2g1hC009999@laptop13.inf.utfsm.cl> Kevin Kofler wrote: > Christoph H??ger cs.tu-berlin.de> writes: > > It would be a great thing, if I could control all that from my own > > versioned repository copy with some 'make ' commands and > > finally merge my changes back especially when testing builds for > > multiple releases. > Why don't you just commit the changes even if you don't know yet whether > they build? Especially for a small package where you're the sole > maintainer, it won't really matter if CVS HEAD isn't always buildable. If you want do be able to do something like "git bisect" (sorry for the SCM mention) it is very useful if each (official, public) development point at least builds OK. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Jun 16 02:44:41 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 15 Jun 2008 22:44:41 -0400 Subject: Requirements gathering for new package source control In-Reply-To: References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> Message-ID: <200806160244.m5G2ifgg010136@laptop13.inf.utfsm.cl> Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > You don't have to tag to build. You can do scratch builds of HEAD in koji. > > But then you still have to issue a real build after the last scratch build > succeeded, so you have wasted one build, wasting both your time and Koji's > cycles. Much more efficient to always use non-scratch builds (unless you're > building something which really shouldn't end up in Rawhide any time soon). Can't a "scratch build" be just promoted to "official"? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From moe at blagblagblag.org Mon Jun 16 03:31:19 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 00:31:19 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213582759.3861.11.camel@localhost.localdomain> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> <1213582759.3861.11.camel@localhost.localdomain> Message-ID: <4855DE87.6020002@blagblagblag.org> Tom "spot" Callaway wrote: > On Sun, 2008-06-15 at 22:39 -0300, jeff wrote: >> To me it appears quite clear that Broadcom is distributing a GPL'd >> file, and thus has to turn over the source code. > > I would encourage you to pursue this with Broadcom, as they are clearly > the copyright holder for the firmware. Well, and RedHat too. They appear to be the ones that actually added it to the Linux kernel and likely work with Broadcom. Does RedHat have a copy of the source? -Jeff From vonbrand at inf.utfsm.cl Mon Jun 16 04:18:05 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 00:18:05 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> Message-ID: <200806160418.m5G4I5U6018437@laptop13.inf.utfsm.cl> Alexandre Oliva wrote: > On Jun 14, 2008, Les Mikesell wrote: > > Alexandre Oliva wrote: > > >>>> The other is, is the kernel separate from the device's firmware? > > >>> That's a different question, unrelated to how that firmware got into > >>> the device. > > >> I know. I don't understand why you insist on this irrelevant point. > > > Because I think it is the only relevent point. It is only if the > > combined works form a derivative work that restrictions can apply to > > the combination differently than the components and whether a > > derivative work is formed does not depend on how the components were > > distribtuted. > > There are various possibilities here, let me summarize the ones that > occur to me, in no particular order: > > a. one work is a derivative from the other, and they are distributed > together > > b. one work is a derivative from the other, and they are distributed > separately > > c. two unrelated works are distributed separately > > d. two works are combined into a single coherent work, undoubtedly a > derivative from both, regardless of whether the two works were > originally related, and then the derivative work is distributed If they were originally not related, just gluing them together doesn't make them derivatives of each other. > e. two unrelated works are distributed together by mere aggregation in > a single volume of storage or distribution medium > > If I understood your argument correctly, you appear to be proposing > that, because cases such as (a-c) exist, the case at hand can't be > (d), so it must be (e). I don't see how this conclusion can follow > from the premises. Please clue me in? (d) is impossible, so only (e) is left. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From lesmikesell at gmail.com Mon Jun 16 04:27:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 23:27:43 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855C45D.6080809@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> Message-ID: <4855EBBF.9030800@gmail.com> jeff wrote: > > > To me it appears quite clear that Broadcom is distributing a GPL'd file, > and thus has to turn over the source code. > > Now you may argue this exempts them from this (but it probably still > doesn't): > > * Firmware is: > * Derived from proprietary unpublished source code, > * Copyright (C) 2000-2003 Broadcom Corporation. > * > * Permission is hereby granted for the distribution of this firmware > * data in hexadecimal or equivalent format, provided this copyright > * notice is accompanying it. > > > > But what about in versions distributed for years where that was not > included? That text above is recent addition. To my surprise when I went > to download the driver on their page I found I had an old > ~/devel/broadcom directory with a file linux-7.3.5.zip containing files > timestamped from 2004 (the above copyright was added in 2005). > > Here, the bcm5700-7.3.5-1.src.rpm file was tagged "GPL". I'd take that to mean that they didn't understand the GPL when they originally used it and corrected the situation by removing it. So what you have is a non-gpl'd binary file with permission to redistribute - which is far from unique. -- Les Mikesell lesmikesell at gmail.com From vonbrand at inf.utfsm.cl Mon Jun 16 04:29:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 00:29:50 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48559401.80503@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> Message-ID: <200806160429.m5G4Toh6018959@laptop13.inf.utfsm.cl> Les Mikesell wrote: > David Woodhouse wrote: > >> > > No, I think you've completely missed the point. > The point is whether a derivative work exists, which won't depend on > how the parts get to their end locations. If it is a derivative when > the parts are aggregated for delivery it will be just as much a > derivative if the parts are delivered separately. Right. And it is derivative if one piece was built from the other piece, not just if they happen to work together or in a similar way. There is a complex test applied by the courts to see if something is a copy or not. What is to be understood by "mere aggregation" could very well be open to question, sure. But if you start questioning everything /before/ it makes any real difference, please refrain from computer programming at all: Unless all you write is "Hello, world!" you are sure to infringe on hundreds of patents. They might not be valid, but unless some court says so, they stay in force. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From lesmikesell at gmail.com Mon Jun 16 04:44:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 15 Jun 2008 23:44:01 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855BB75.50603@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> Message-ID: <4855EF91.10009@gmail.com> jeff wrote: > >>> I look at tg3.c and I can't tell where this "aggregation" begins and >>> ends. It's the *SAME FILE*. Can you clearly say which line numbers >>> are GPL and which line numbers are not GPL? >> >> I don't know much about kernel drivers and I don't think ordinary >> humans are expected to. > > Well ordinary humans don't post 20 times to fedora-devel arguing about > kernel drivers either--but you have. You can't just cop out and plead > ignorance now. How lame of you. My point is that the details of the aggregation are irrelevant and the format of the storage doesn't matter. The fact that the firmware loader can find the correct chunk of data to load for each separate device shows that the storage maintains the separation. >> I'd approach the question more mechanically, on the same order as >> trying to establish if the elements within a tar file are separate >> things, > > Well, if that tar file is distributed as a GPL file, then everything in > it would be GPL, no? It's the other way around. Putting things in the same container doesn't change the copyright of the separate parts. If anything is wrong, it is the label of the container. >> or if the files represented within an iso image are separate things. > > If the entire ISO is distributed as GPL, it wouldn't be separate would it? Likewise. >> If the compiler stores in a form that the loader can identify and >> download to the correct device, I'd be convinced that it is a separate >> thing regardless of any intermediate mechanical transformations or >> representations. > > But they are being *shipped together* in a package whose license says: > GPLv2. > > $ rpm -qp --queryformat "%{LICENSE}\n" > kernel-2.6.26-0.67.rc6.git1.fc10.src.rpm > GPLv2 > > So RedHat is claiming they are shipping a GPLv2 kernel, when they > clearly aren't (they are also doing it knowingly). Note, there are > packages that have a mix of licenses, and this gets clearly pointed out > in the LICENSE tag. Perhaps a valid issue - and perhaps mistakenly left over from when the broadcom portion was tagged as GPL. > So you may be convinced that it is a separate thing (though you are > really really really stretching things, when both tg3.c and tg3.o have > everything combined), but by calling the whole thing GPL, it would > encompass that firmware as well. They are not saying "GPLv2 and > Proprietary firmware that is merely aggregated into the same .o".... That would be a reasonable change. How is it done in drivers where the firmware has always been known to be non-GPL but redistributable? tg3 might be a special case due to its copyright change. -- Les Mikesell lesmikesell at gmail.com From vonbrand at inf.utfsm.cl Mon Jun 16 04:49:29 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 00:49:29 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855B32E.8090803@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> Message-ID: <200806160449.m5G4nTxS019826@laptop13.inf.utfsm.cl> Les Mikesell wrote: [...] > But, I think you are the one missing the point at least from the > perspective of the FSF or anyone likely to take legal action on behalf > of the GPL. Nobody can initiate legal action "on behalf of the GPL", only the kernel copyright holders could initiate such action here. And that would be ROTFLed out of court, as /they themselves/ created the kernel with the express, and widely documented, intention for it to be distributed widely. > They claim that it doesn't matter if the components are > distributed separately or not. For example, you can't modify a GPL'd > component so that it needs a library under different terms even if the > parts are never distributed together. Sure you can. In the heyday of GNU software it was /only/ run on propietary systems, and all that software was routinely modified with the express purpose of running on newer/changed versions of propietary systems (which were the only ones available, remember). > > Thus, it is not the intent of the GPL to claim rights or contest > > your rights to work written entirely by you; rather, the intent is to > > exercise the right to control the distribution of derivative or > > collective works based on the Program. > Whether it is a derivative or 'work as a whole' depends on the > relationship of the parts, not temporary physical proximity. Please state which laws or court decisions lead you to this conclusion, and exactly what "relationship" has to be involved here. This is /not/ about what you (or I) would like (or consider logical), given our computer (and other) background and preferences. Remember that this is an area of law originally designed for a completely different purpose (literary works and such, distributed as printed copies) pressed into service for something totally alien. As such, only someone really trained in this mess (i.e., a lawyer specializing in this area, hired for the purpose of looking into this) can give you somewhat credible guidance. > If the > compiler keeps the parts separate so the downloading code can identify > them to download the correct separate data to the correct separate > device they are rather clearly separate things aggregated temporarily > within a file. This might be more obvious if it were easier for a > human to identify the parts, but that's a mechanical detail. The > question of whether the relationship of the runtime code makes it a > derived work might still remain, but it is unrelated to the bits of > code and data having been aggregated as permitted. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From moe at blagblagblag.org Mon Jun 16 05:03:34 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 02:03:34 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855EBBF.9030800@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> <4855EBBF.9030800@gmail.com> Message-ID: <4855F426.3090007@blagblagblag.org> Les Mikesell wrote: > jeff wrote: >> >> >> To me it appears quite clear that Broadcom is distributing a GPL'd >> file, and thus has to turn over the source code. >> >> Now you may argue this exempts them from this (but it probably still >> doesn't): >> >> * Firmware is: >> * Derived from proprietary unpublished source code, >> * Copyright (C) 2000-2003 Broadcom Corporation. >> * >> * Permission is hereby granted for the distribution of this >> firmware >> * data in hexadecimal or equivalent format, provided this copyright >> * notice is accompanying it. >> >> >> >> But what about in versions distributed for years where that was not >> included? That text above is recent addition. To my surprise when I went >> to download the driver on their page I found I had an old >> ~/devel/broadcom directory with a file linux-7.3.5.zip containing >> files timestamped from 2004 (the above copyright was added in 2005). >> >> Here, the bcm5700-7.3.5-1.src.rpm file was tagged "GPL". > > > I'd take that to mean that they didn't understand the GPL when they > originally used it Pffft. "Oh, sorry, we didn't know what the license meant, we're just a billion dollar company with 100 lawyers". That doesn't mean they can suddenly un-GPL something. > and corrected the situation by removing it. So what > you have is a non-gpl'd binary file with permission to redistribute - > which is far from unique. And you're missing the other point: THEY ARE STILL DOING IT TODAY, as I mentioned earlier. Go to their website, it says it's GPL. As a side note, it was added by RedHat to the main kernel and RedHat is still shipping it under the GPL too. -Jeff From moe at blagblagblag.org Mon Jun 16 05:05:53 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 02:05:53 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855EF91.10009@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com > Message-ID: <4855F4B1.2080207@blagblagblag.org> Les Mikesell wrote: > jeff wrote: > That would be a reasonable change. How is it done in drivers where the > firmware has always been known to be non-GPL but redistributable? tg3 > might be a special case due to its copyright change. The firmware hasn't always been known to be non-GPL. It was distributed for years under the GPL, so it *is* GPL, but they are violating the GPL by not shipping the source code. Have you even looked at tg3.c or it's history? -Jeff From Matt_Domsch at dell.com Mon Jun 16 05:11:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 16 Jun 2008 00:11:46 -0500 Subject: Help with build failure (updating mercurial) In-Reply-To: References: Message-ID: <20080616051146.GA10259@auslistsprd01.us.dell.com> On Sun, Jun 15, 2008 at 09:58:53AM -0400, Neal Becker wrote: > gmane.linux.network.networkmanager.devel > http://koji.fedoraproject.org/koji/taskinfo?taskID=662698 > ... > error: File must begin with "/": unset > error: File must begin with "/": DISPLAY > Checking for unpackaged > file(s): /usr/lib/rpm/check-files /var/tmp/mercurial-1.0.1-3.fc10-root > RPM build errors: > File must begin with "/": unset > File must begin with "/": DISPLAY > > What's causing this? My guess is the commented out %check. This section generally would come before %files, after %build. Delete those lines, and it builds fine. --- mercurial.spec.orig 2008-06-16 00:02:53.000000000 -0500 +++ mercurial.spec 2008-06-16 00:04:37.000000000 -0500 @@ -162,9 +162,6 @@ rm -rf $RPM_BUILD_ROOT %{_libexecdir}/mercurial/ %{_sysconfdir}/mercurial/hgrc.d/hgk.rc -#%%check -#cd tests && python run-tests.py - %changelog * Sun Jun 15 2008 Neal Becker - 1.0.1-4 - Bitten by expansion of commented out macro (again) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From vonbrand at inf.utfsm.cl Mon Jun 16 05:21:22 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 01:21:22 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855F4B1.2080207@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.co! m > <4855F4B1.2080207@blagblagblag.org> Message-ID: <200806160521.m5G5LMW3021673@laptop13.inf.utfsm.cl> jeff wrote: > Les Mikesell wrote: > > jeff wrote: > > That would be a reasonable change. How is it done in drivers where > > the firmware has always been known to be non-GPL but > > redistributable? tg3 might be a special case due to its copyright > > change. > The firmware hasn't always been known to be non-GPL. It was > distributed for years under the GPL, so it *is* GPL, but they are > violating the GPL by not shipping the source code. So go sue them for not giving you the source. Most probably they will just tell you that it was *never* placed under GPL, that this "GPL distribution" was just a mistake (now fixed). > Have you even looked at tg3.c or it's history? Yes, no. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From moe at blagblagblag.org Mon Jun 16 05:34:15 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 02:34:15 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <484C0B49.5080600@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> Message-ID: <4855FB57.6050401@blagblagblag.org> Hans de Goede wrote: > If I get Alex correctly he is saying that, to his goal, which is 100% > Free software everywhere (including in his toothbrush), this is > counterproductive, as it may make it easier to distribute binary > firmware along with the kernel, as it now could be put in a seperate > tarbal removing GPL worries etc. > > As much as I admire Alex's goal's I'm very glad with the current > pragmatic approach Fedora has taken with regards to firmware. > > And when combining both these perspectives, David, you patch is > excellent and I'm very gratefull for all the work you've been doing on it. > > If the firmware truely gets put in a different tarbal (and thus > eventually in a different srpm), then it will be feasible to do a no > blobs included Fedora spin like gnewsense, which would be great. If you have to do a *SEPARATE* spin to do a free CD, why does the Fedora project spew crap like this everywhere: "We try to always do the right thing, and provide only free and open source software." [1] It's simply not true and the author of that (Rahul Sundaram I think--he writes it everywhere else too), *MUST* know that isn't true. It's one thing if the non-free software that fedora shipped was considered a bug that just hasn't been eradicated but shipping non-free software is fedora *policy*.[1] It's one thing to include some firmware, call a program GPL when it's not, ship non-free binaries etc., but at least don't lie about it on all your literature. Sheez. -Jeff [1] http://fedoraproject.org/wiki/Overview [2] http://fedoraproject.org/wiki/SIGs/FirmWare geez, you even have a special interest group in complete conflict with your supposed mission From j.w.r.degoede at hhs.nl Mon Jun 16 05:58:48 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jun 2008 07:58:48 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855FB57.6050401@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> Message-ID: <48560118.7090309@hhs.nl> jeff wrote: > Hans de Goede wrote: >> If I get Alex correctly he is saying that, to his goal, which is 100% >> Free software everywhere (including in his toothbrush), this is >> counterproductive, as it may make it easier to distribute binary >> firmware along with the kernel, as it now could be put in a seperate >> tarbal removing GPL worries etc. >> >> As much as I admire Alex's goal's I'm very glad with the current >> pragmatic approach Fedora has taken with regards to firmware. >> >> And when combining both these perspectives, David, you patch is >> excellent and I'm very gratefull for all the work you've been doing on >> it. >> >> If the firmware truely gets put in a different tarbal (and thus >> eventually in a different srpm), then it will be feasible to do a no >> blobs included Fedora spin like gnewsense, which would be great. > > If you have to do a *SEPARATE* spin to do a free CD, why does the Fedora > project spew crap like this everywhere: > > "We try to always do the right thing, and provide only free and open source > software." [1] > > It's simply not true and the author of that (Rahul Sundaram I think--he > writes it everywhere else too), *MUST* know that isn't true. It's one > thing if the non-free software that fedora shipped was considered a bug > that just hasn't been eradicated but shipping non-free software is > fedora *policy*.[1] > > It's one thing to include some firmware, call a program GPL when it's > not, ship non-free binaries etc., but at least don't lie about it on all > your literature. Sheez. It depends on your definition of software, according to Fedora's definitions firmware is not software it is content. I know this is a word game, but think about it, what is the definition of software? Are the bits included in a serial eeprom, which on powerup get read by an fpga, to make that fpga become a specific bit of hardware soft or hardware, what about the vhdl / verilog sources from which those bits were generated. What about a cpld, is that a processor running software or is it hardware? But it is coded in the same verilog / vhdl, which both are very much programming language-ish. What about a pcb, nowaday its fully automatic generated (compiled as you which) from instructions which take the form of a bunch of bits. Really you everything must be free people need to: 1) get a couple of years experience in electronics engineering and start to realize how deep down programmable hardware is going these days. Most hardware won't do anything without atleast having put the proper bits in a cpld somewhere. 2) Then stop making this weird difference between firmware which is in a rom shipped with the device, and firmware which is on a cd shipped with the device, what if the rom is on a socket and can be removed without soldering? 3) When you stop making the weird difference between different firmware distribution mechanisms, either realise that firmware is part of the hardware, or keep calling firmware software and demand that it is _all_ free, so also remove any drivers for hardware where the firmware is shipped with the hardware instead of with the OS, such as any motherboards which come with a non free BIOS, any CPU's which use microcode, etc. Good luck with that. Really, arguing that Fedora's stance is inconsistent, while in reality yours is doesn't gain you much respect. Either: 1) all firmware is software and must be free in which case support for evil hardware which comes with the firmware embedded must be removed from linux-libre! 2) all firmware is considered part of the hardware, independend of the distribution mechanism of that firmware (the Fedora pov). Regards, Hans From lesmikesell at gmail.com Mon Jun 16 06:01:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 01:01:27 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806160449.m5G4nTxS019826@laptop13.inf.utfsm.cl> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <200806160449.m5G4nTxS019826@laptop13.inf.utfs! m.cl> Message-ID: <485601B7.9050008@gmail.com> Horst H. von Brand wrote: > >> They claim that it doesn't matter if the components are >> distributed separately or not. For example, you can't modify a GPL'd >> component so that it needs a library under different terms even if the >> parts are never distributed together. > > Sure you can. In the heyday of GNU software it was /only/ run on propietary > systems, and all that software was routinely modified with the express > purpose of running on newer/changed versions of propietary systems (which > were the only ones available, remember). There's a special exception for the case of standard system software that doesn't apply in other situations - or if they are distributed together. >> Whether it is a derivative or 'work as a whole' depends on the >> relationship of the parts, not temporary physical proximity. > > Please state which laws or court decisions lead you to this conclusion, and > exactly what "relationship" has to be involved here. I'm not aware of any court ruling. It is the conclusion I drew from the FSF legal position regarding RIPEM that lead to the development of the generally useless fgmp library. It was long enough ago that google doesn't find many good references, but this one at least describes it: http://www.plex86.org/linux/Beyond-Compare--software-equivalent-in-linux-3686.html -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jun 16 06:07:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 01:07:35 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855F4B1.2080207@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com > <4855F4B1.2080207@blagblagblag.org> Message-ID: <48560327.4000109@gmail.com> jeff wrote: > Les Mikesell wrote: >> jeff wrote: >> That would be a reasonable change. How is it done in drivers where >> the firmware has always been known to be non-GPL but >> redistributable? tg3 might be a special case due to its copyright >> change. > > The firmware hasn't always been known to be non-GPL. It was distributed > for years under the GPL, so it *is* GPL, but they are violating the GPL > by not shipping the source code. > > Have you even looked at tg3.c or it's history? > Just a quick google to find the discussion here: http://wiki.debian.org/KernelFirmwareLicensing with its note that the corrected license was committed here: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 -- Les Mikesell lesmikesell at gmail.com From moe at blagblagblag.org Mon Jun 16 06:57:03 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 03:57:03 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48560118.7090309@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> Message-ID: <48560EBF.7050805@blagblagblag.org> Hans de Goede wrote: > Really, arguing that Fedora's stance is inconsistent, while in reality > yours is doesn't gain you much respect. Either: > > 1) all firmware is software and must be free in which case support for > evil hardware which comes with the firmware embedded must be removed > from linux-libre! No, because the goal of linux-libre is to have a kernel which doesn't distribute non-free software. > 2) all firmware is considered part of the hardware, independend of the > distribution mechanism of that firmware (the Fedora pov). ---> No, the difference is Fedora is *DISTRIBUTING* the non-free bits. <--- In fact, I don't even care that much that they are distributing the non-free bits (e.g. like RedHat), it just extra annoying when they *CLAIM* they are distributing free/open source software when they are not and they *KNOW* they are not. If they were distributing non-free hardware we would all complain to them, like many on this list do about nvidia and such. -Jeff From pingou at pingoured.fr Mon Jun 16 07:01:22 2008 From: pingou at pingoured.fr (pingou) Date: Mon, 16 Jun 2008 09:01:22 +0200 Subject: automating updates In-Reply-To: References: Message-ID: <48560FC2.8020608@pingoured.fr> Neal Becker wrote: > I'm trying to automate the upstream updates of my packages (somewhat). The > procedure seems to be: > > 1. In devel: > 1.1 make new-sources > 1.2 update .spec > 1.3 cvs ci -m 'update to xxx' > 1.4 make tag build > > 2. cp -l -f .spec sources .cvsignore ../F9 > cp -l -f .spec sources .cvsignore ../F9 > > 3. for n in 9 8; do ( cd F-$n; cvs ci -m 'update to 1.0.1' && make tag build > && bodhi -n -r F$n -t enhancement mercurial-1.0.1-4.fc$n ); done > > What's not automated? > > Howto get the current tag (e.g., mercurial-1.0.1-4.fc9)? > Optional - extract cvs ci message from spec changelog > > Howto get bodhi to stop asking for a password? > Not long ago I wrote a small python script for automatic update of package needing few work. You can find the new version there: http://pingoured.fr/public/updateCVS_0.2.py I also published it there http://pingoured.fr/blog/index.php?post/2008/06/01/UpdateCVSc_01 and Spot came with the answer to the "How to start build and not wait that he has finished ?" If that can help... Regards, Pierre From moe at blagblagblag.org Mon Jun 16 07:07:39 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 04:07:39 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48560118.7090309@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> Message-ID: <4856113B.9010004@blagblagblag.org> Hans de Goede wrote: > It depends on your definition of software, according to Fedora's > definitions firmware is not software it is content. I know this is a > word game, but think about it, what is the definition of software? From the Oxford English Dictionary: software 1. Computers. a. The programs and procedures required to enable a computer to perform a specific task, as opposed to the physical components of the system (see also quot. 1961). b. esp. The body of system programs, including compilers and library routines, required for the operation of a particular computer and often provided by the manufacturer, as opposed to program material provided by a user for a specific task. I didn't realize fedora was claiming that firmware isn't software. Now that is bullshit. You call it a word game, I'll call it what it is. *Content??!* It's obviously software. I mean, it can be copied, it can be rewritten (well, by the people in the castle with the code), it can be compiled, etc... Clearly software. I guess you need a PhD to delude yourself otherwise. Usually techs are so precise, I can't believe the doublethinking here. Oh, and you should let Broadcom know that they aren't distributing software then: * Derived from proprietary unpublished source code, -Jeff From moe at blagblagblag.org Mon Jun 16 07:13:36 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 04:13:36 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48560327.4000109@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com > <4855F4B1.2080207@blagblagblag.org> <48560327.4000109@gmail.com> Message-ID: <485612A0.9050104@blagblagblag.org> Les Mikesell wrote: > jeff wrote: >> Les Mikesell wrote: >>> jeff wrote: >>> That would be a reasonable change. How is it done in drivers where >>> the firmware has always been known to be non-GPL but >>> redistributable? tg3 might be a special case due to its copyright >>> change. >> >> The firmware hasn't always been known to be non-GPL. It was >> distributed for years under the GPL, so it *is* GPL, but they are >> violating the GPL by not shipping the source code. >> >> Have you even looked at tg3.c or it's history? >> > > Just a quick google to find the discussion here: > http://wiki.debian.org/KernelFirmwareLicensing with its note that the > corrected license was committed here: > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 They changed the kernel source then, but that doesn't mean they aren't under obligations of the GPL since they distributed it for *years* under the GPL. -Jeff From pbrobinson at gmail.com Mon Jun 16 07:16:39 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 16 Jun 2008 08:16:39 +0100 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: <5256d0b0806160016i190dd132pb3e302b1d52e184d@mail.gmail.com> >> Unfortunately when this happens, the "not ready for review" ticket >> shows up in the review queue, extremely scarce reviewer time is >> wasted on tickets that aren't reviewable, and the already huge queue >> gets even bigger. One way to deal with this is to just give these >> tickets their own bugzilla component. I'm not really sure what to >> call it, though. Maybe "Package Development", but that sounds a bit >> broad. Whatever the component is called, though, it would give these >> tickets a place to go that doesn't complicate the package review >> process. > > Maybe a trac instance on hosted? Or maybe a special status whiteboard > that says "don't do anything with these" would be better than > littering bugzilla with yet more irrelevant data :). Problem with that is that it moves from bugzilla to trac and then back to bugzilla once ready for review again.... even more admin work when the reason for the discussion has come around due to there not being enough time. At least with a new bugzilla component all the information remains and all the information is in the one ticket. Peter From nicolas.mailhot at laposte.net Mon Jun 16 07:17:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jun 2008 09:17:07 +0200 (CEST) Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: <28599.192.54.193.59.1213600627.squirrel@rousalka.dyndns.org> Le Lun 16 juin 2008 02:20, Jason L Tibbitts III a ?crit : > >>>>>> "JS" == Jon Stanley writes: > > JS> Maybe a trac instance on hosted? > > For every separate package, when the submitters often don't even have > Fedora accounts? Moving this stuff in trac is about the most backwards idea possible. It does not remove the problem, just shifts it to a braindamaged issue tracker with a tenth of bugzilla's possibilities that will need to be triaged the same way bugzilla is. That's the "hide stuff under the carpet where it will rot in peace" option. Except that's only good if you don't intend to be there when the carpet will start to stink. -- Nicolas Mailhot From dwmw2 at infradead.org Mon Jun 16 07:31:37 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 08:31:37 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855B32E.8090803@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> Message-ID: <1213601497.26255.619.camel@pmac.infradead.org> On Sun, 2008-06-15 at 19:26 -0500, Les Mikesell wrote: > David Woodhouse wrote: > > On Sun, 2008-06-15 at 17:13 -0500, Les Mikesell wrote: > >> Do do have an exact definition of what is not permitted? > > > > I pasted a precise definition of 'collective work' already, didn't I? > > That is unrelated to the question. No, it is the answer to your question. You asked what is not permitted. What's not permitted is distribution of a collective work including the GPL'd Program, where the other independent and separate parts of that work are not also available under the terms of the GPL. > > It is a work in which a number of separate and independent works are > > assembled into one work. > > > > The very definition of 'collective work' is that it is an aggregation of > > other independent and separate works. > > And aggregations are explicitly permitted which makes that discussion > irrelevant. Oh dear, you're back to that again. I thought we'd dealt with that, but we seem to be going round in circles. I'll try again, one last time: All collective work is aggregation. The GPL explicitly states that it covers collective work. The GPL explicitly talks about extending the permissions of the GPL to works which are independent and separate works in themselves, when those works are included in a collective work. Thus, it is not credible to believe that the 'mere aggregation on a volume of a storage or distribution medium' exception is intended to cover _all_ aggregation. That would mean that the GPL is just setting up all these conditions, only to immediately turn round and say "oh, actually I didn't really mean it" in the next paragraph. If you're willing to make that claim in public then I don't really know why I'm bothering to talk to you. Do you have no shame? > > In order to create a collective work, you need the permission of the > > copyright-holders of each of the constituent parts. If any _one_ of them > > denies you that permission, then you may not distribute that collective > > work. > > And this part applies equally to every line of code and data. Having > source or not doesn't change the requirement for permission to > distribute - or give anyone more or less reason to question whether that > permission has been given. > > > As you know, the GPL makes an exception for 'mere aggregation on a > > volume of a storage or distribution medium'. There is some scope for > > debate on precisely what is covered by that exception, but not a huge > > amount. > > So the relevant discussion should be about whether there is a person > that can identify the separate parts. No, that's another complete non-sequitur from you. Where on earth did _that_ idea come from? If you can identify the separate short stories in an anthology, do you think that somehow means that it isn't a collective work? Actually, don't bother to answer that. Because I'm sure you'll just come back with another complete non-sequitur rather than a real answer. Let's just give up, eh? -- dwmw2 From kanarip at kanarip.com Mon Jun 16 07:44:07 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 16 Jun 2008 09:44:07 +0200 Subject: automating updates In-Reply-To: <1213574819.3843.13.camel@wicktop.localdomain> References: <485583CD.5070200@kanarip.com> <1213574819.3843.13.camel@wicktop.localdomain> Message-ID: <485619C7.6020604@kanarip.com> Christoph Wickert wrote: > Am Sonntag, den 15.06.2008, 23:04 +0200 schrieb Jeroen van Meeuwen: >> Hmm... although I'm not much of a packager nor a frequent user of the >> CVS system: >> >> common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm >> common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm > > ???Jeroen, please don't do that. We had this discussion back in Feb 2007 > on the maintainers list, please search for the thread named "???Discourage > cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting)". > > As a result of this discussion we set up a wiki page: > ???https://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo > Euh, OK! ;-) -Jeroen From j.w.r.degoede at hhs.nl Mon Jun 16 08:08:06 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jun 2008 10:08:06 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <48560EBF.7050805@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> Message-ID: <48561F66.9070308@hhs.nl> jeff wrote: > Hans de Goede wrote: >> Really, arguing that Fedora's stance is inconsistent, while in reality >> yours is doesn't gain you much respect. Either: >> >> 1) all firmware is software and must be free in which case support for >> evil hardware which comes with the firmware embedded must be removed >> from linux-libre! > > No, because the goal of linux-libre is to have a kernel which doesn't > distribute non-free software. > Oh, but promoting the usage and buying of devices which contain non-free firmware by supporting those is ok, because it isn't non-free firmware that is evil. It is the distributing of non-free firmware that is evil. Yes a very consistent and logical pov for which I applaud you! Basicly the message you are sending is: people please by devices with firmware in rom, preferably otp rom, because then certainly there is no evil. Not being able to ever change the firmware is good, because as long as firmware never gets distributed separately from the hardware, we can pretend its not there and live our ignorance is bliss lifes thinking that we are in the all software in my house is free utopia. Because if I cannot see it it isn't there. Really that I didn't think of this before, it is so brilliant! I guess I should do away with all my PC's and instead switch to an internet appliance device, because then I no longer have to worry about whether I have any non-free software at all. Certainly if I don't need to install the software myself it isn't there at all then. >> 2) all firmware is considered part of the hardware, independend of the >> distribution mechanism of that firmware (the Fedora pov). > > > > > ---> No, the difference is Fedora is *DISTRIBUTING* the non-free bits. > <--- So the goal of linux-libre is to not distribute non-free software. Do you ever buy a PC / laptop? If so you're involved in a transaction which almost certainly involves the distribution of non-free firmware. Worse, not only are you involved in such a transaction, you are _paying_ for the system of which the non-free firmware is an integral part and thus you are paying for non-free firmware, thereby promoting the production of non-free firmware. Do you ever sell any of you PC hardware (motherboard, latop, printer) second hand and / or give it away to friends / family, then you are *DISTRIBUTING* non-free firmware. Really, they should put you in prison for that! Please stop being so hypocritical. Putting it simply there are 2 possible stances on non-free firmware: 1) Its evil and as such should be erradicated, therefor I will not buy or use any devices with it. Nor will I add support for any devices containing non-free firmware to my Free operating system 2) Its evil, but allas it is here, so although we are not in favor it we condone it. The its evil, but ok as long as not distributed vision is just plain hypocritical, so you are happy *USING* it, and passing device which contain it along to friends / family, but distributing it in a way where it is not hidden inside a device is not OK? Anyways this will be my last mail in this thread, I cannot argue against so much hypocrisy and bend around corners logic. Regards, Hans From nicolas.mailhot at laposte.net Mon Jun 16 08:23:17 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jun 2008 10:23:17 +0200 (CEST) Subject: automating updates In-Reply-To: <1213574819.3843.13.camel@wicktop.localdomain> References: <485583CD.5070200@kanarip.com> <1213574819.3843.13.camel@wicktop.localdomain> Message-ID: <54844.192.54.193.59.1213604597.squirrel@rousalka.dyndns.org> Le Lun 16 juin 2008 02:06, Christoph Wickert a ?crit : > > Am Sonntag, den 15.06.2008, 23:04 +0200 schrieb Jeroen van Meeuwen: >> Hmm... although I'm not much of a packager nor a frequent user of >> the >> CVS system: >> >> common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm >> common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm > > ?Jeroen, please don't do that. We had this discussion back in Feb 2007 > on the maintainers list, please search for the thread named > "?Discourage > cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting)". > > As a result of this discussion we set up a wiki page: > ?https://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Discourage does not mean forbid. For the record I do all my package changes with cvs-import.sh and I've never had a tenth of the tagging (or other) cvs problems people complain on the list every month. So do not use cvs-import.sh, it's discouraged (official line). That is unless you have no wish to be exposed to cvs quirks, and find cvs-import.sh a nice simple interface. -- Nicolas Mailhot From thomas.moschny at gmail.com Mon Jun 16 08:24:31 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Mon, 16 Jun 2008 10:24:31 +0200 Subject: automating updates In-Reply-To: <1213574819.3843.13.camel@wicktop.localdomain> References: <485583CD.5070200@kanarip.com> <1213574819.3843.13.camel@wicktop.localdomain> Message-ID: 2008/6/16 Christoph Wickert : > Am Sonntag, den 15.06.2008, 23:04 +0200 schrieb Jeroen van Meeuwen: >> Hmm... although I'm not much of a packager nor a frequent user of the >> CVS system: >> >> common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm >> common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm > > ?Jeroen, please don't do that. We had this discussion back in Feb 2007 > on the maintainers list, please search for the thread named "?Discourage > cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting)". Is using cvs-import for updating a package really discouraged? It is *really* handy, compared to the series of single steps that are to be done manually otherwise. Also, it does show a diff between old and new spec and auxiliary files and gives you the possibility to abort the import nowadays, so the main concern mentioned in that old thread doesn't seem to be valid anymore. Regards, Thomas From dwmw2 at infradead.org Mon Jun 16 08:49:09 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 09:49:09 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48561F66.9070308@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> Message-ID: <1213606149.26255.647.camel@pmac.infradead.org> On Mon, 2008-06-16 at 10:08 +0200, Hans de Goede wrote: > Putting it simply there are 2 possible stances on non-free firmware: > > 1) Its evil and as such should be erradicated, therefor I will not buy or use > any devices with it. Nor will I add support for any devices containing > non-free firmware to my Free operating system > > 2) Its evil, but allas it is here, so although we are not in favor it we > condone it. > > The its evil, but ok as long as not distributed vision is just plain > hypocritical, so you are happy *USING* it, and passing device which contain it > along to friends / family, but distributing it in a way where it is not hidden > inside a device is not OK? I wouldn't even say it's evil. It's just a fact of life. Unfortunate, perhaps, but not actually _evil_. Fedora is quite happy to ship firmware which is merely 'distributable' and not Free Software. However, we would like to support those who want to be able to make spins of Fedora which _don't_ include the firmware. Also, distributing proprietary code without source, as _part_ of a GPL'd work, is a clear violation of the GPL. That's why, in the case of the firmware which is currently in the kernel package itself, FESCo has agreed that we would like to ship that firmware _separately_ rather than as part of the kernel package. There's no hypocrisy in that, surely? Thus the git tree at git.infradead.org/users/dwmw2/firmware-2.6.git which is making progress on getting drivers to use request_firmware(). For now, this does keep the firmware in the same tree; we run 'make firmware_install' to make a separate kernel-firmware package. In time, it'd be nice to remove it to a separate source package altogether -- but we'll do things one step at a time. Please send patches :) -- dwmw2 From moe at blagblagblag.org Mon Jun 16 08:58:13 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 05:58:13 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48561F66.9070308@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> Message-ID: <48562B25.6060602@blagblagblag.org> Hans de Goede wrote: > jeff wrote: >> Hans de Goede wrote: >>> Really, arguing that Fedora's stance is inconsistent, while in >>> reality yours is doesn't gain you much respect. Either: >>> >>> 1) all firmware is software and must be free in which case support >>> for evil hardware which comes with the firmware embedded must be >>> removed from linux-libre! >> >> No, because the goal of linux-libre is to have a kernel which doesn't >> distribute non-free software. >> > > Oh, but promoting the usage and buying of devices which contain non-free > firmware by supporting those is ok, When have I ever done that??? You're just putting words in my mouth. > because it isn't non-free firmware > that is evil. It is the distributing of non-free firmware that is evil. > Yes a very consistent and logical pov for which I applaud you! I have never used the word evil wrt software. Again, you are putting words in my mouth. But not distributing non-free software is definitely a goal. It is also the supposed mission of Fedora. > Basicly the message you are sending is: people please by devices with > firmware in rom, preferably otp rom, because then certainly there is no > evil. That's the message I'm sending?>?!? Again, you're just putting words in my mouth. I've never said anything of the sort. > Not being able to ever change the firmware is good, because as > long as firmware never gets distributed separately from the hardware, we > can pretend its not there and live our ignorance is bliss lifes thinking > that we are in the all software in my house is free utopia. Because if I > cannot see it it isn't there. Uh, actually, I don't think that way at all. Again, you are just making things up that you say I am thinking. For one, I know I'd *love* to remove the non-free BIOS from my Eee, for example (and willing to pay developers to do that). You're just making shit up. > Really that I didn't think of this before, it is so brilliant! I guess I > should do away with all my PC's and instead switch to an internet > appliance device, because then I no longer have to worry about whether I > have any non-free software at all. Certainly if I don't need to install > the software myself it isn't there at all then. We're talking about * * * SOFTWARE THE FEDORA PROJECT IS ---> DISTRIBUTING <--- * * * not about the hardware people already have. >>> 2) all firmware is considered part of the hardware, independend of >>> the distribution mechanism of that firmware (the Fedora pov). >> >> >> >> >> ---> No, the difference is Fedora is *DISTRIBUTING* the non-free >> bits. <--- > > So the goal of linux-libre is to not distribute non-free software. Do > you ever buy a PC / laptop? Yes. > If so you're involved in a transaction which > almost certainly involves the distribution of non-free firmware. Worse, > not only are you involved in such a transaction, you are _paying_ for > the system of which the non-free firmware is an integral part and thus > you are paying for non-free firmware, thereby promoting the production > of non-free firmware. Yes, and that sucks. And stallman had to originally write emacs on SunOS or whatever he used. It doesn't mean we should stop trying to make things free. > Do you ever sell any of you PC hardware (motherboard, latop, printer) > second hand and / or give it away to friends / family, then you are > *DISTRIBUTING* non-free firmware. Really, they should put you in prison > for that! ... > Please stop being so hypocritical. I'm not being hypocritical. > Putting it simply there are 2 possible stances on non-free firmware: Only 2? > 1) Its evil Well, this is wrong from the start because I don't even believe in evil. Anyway. > and as such should be erradicated, therefor I will not buy > or use > any devices with it. Nor will I add support for any devices containing > non-free firmware to my Free operating system I see it more like RMS originally writing emacs on a proprietary system. Though removing devices that *only* run with proprietary firmware may be a possibility, though many devices run fine without the firmware (for example, the tg3 will run without the firmware that's in the kernel). > 2) Its evil, but allas it is here, so although we are not in favor it we > condone it. 3) non-free software sucks and we should do our best to not distribute it. But you're not *condoning* it you're ***DISTRIBUTING*** it. > The its evil, but ok as long as not distributed vision is just plain > hypocritical, so you are happy *USING* it, and passing device which > contain it along to friends / family, but distributing it in a way where > it is not hidden inside a device is not OK? But I'm not claiming that is free software if I hand someone a macbook or whatever. I'm also not happy if there is non-free software in there (but i'd just install free software on there). I think the "not OK" part comes in when you say that you are distributing free/open software when you aren't and you know it. > Anyways this will be my last mail in this thread, I cannot argue against > so much hypocrisy and bend around corners logic. So much hypocrisy? You just put tons of words in my mouth that I've never said. Pfft. -Jeff From jroth at linux.vnet.ibm.com Mon Jun 16 09:08:36 2008 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Mon, 16 Jun 2008 11:08:36 +0200 Subject: Need package reviewer and sponsor for libspe2 and Cell packages Message-ID: <48562D94.6030208@linux.vnet.ibm.com> Hi all, I need someone who volunteers to make the review for the libspe2 package. Libspe2 is the SPE Runtime Management Library for the Cell Broadband Engine Architecture. https://bugzilla.redhat.com/show_bug.cgi?id=442507 We have plans to add further Cell related packages to Fedora. I'll open up a discussion about the spu-gcc and spu-binutils packages on this list soon. Our goal is to have complete toolchain support for developing applications on the PS3 and Cell based systems. It will be my first package in Fedora, so I'd need a sponsor as well. Thanks for your help. -- Jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From varekova at redhat.com Mon Jun 16 09:09:54 2008 From: varekova at redhat.com (Ivana Varekova) Date: Mon, 16 Jun 2008 11:09:54 +0200 Subject: man-pages-da Message-ID: <48562DE2.5070900@redhat.com> Hello, I "own" man-pages-da and for now this package consists of 7 translated man-pages. I think it would be better if some Danish guy look after this package and perhaps try to translate more man-pages, I'm not sure whether there is no new man-pages-da upstream but I can't find any but I can't speak Danish - so some native speaker could be more successful. Is there anybody who is willing to look after this package? Thanks. Ivana Varekova From alan at redhat.com Mon Jun 16 09:12:36 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Jun 2008 05:12:36 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213537140.26255.469.camel@pmac.infradead.org> References: <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> Message-ID: <20080616091236.GB15790@devserv.devel.redhat.com> On Sun, Jun 15, 2008 at 02:39:00PM +0100, David Woodhouse wrote: > > Bingo.. and copyright does not give you power over other works > > Rather, the intent is to exercise the right to control the distribution > of derivative or _collective_ works based on the Program. See earlier discussion. Its your viewpoint that these are somehow derivative. I'm disagreeing. Please take the discussion to the GNU lists From kanarip at kanarip.com Mon Jun 16 09:12:16 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 16 Jun 2008 11:12:16 +0200 Subject: automating updates In-Reply-To: References: <485583CD.5070200@kanarip.com> <1213574819.3843.13.camel@wicktop.localdomain> Message-ID: <48562E70.6060201@kanarip.com> Thomas Moschny wrote: > 2008/6/16 Christoph Wickert : >> Am Sonntag, den 15.06.2008, 23:04 +0200 schrieb Jeroen van Meeuwen: >>> Hmm... although I'm not much of a packager nor a frequent user of the >>> CVS system: >>> >>> common/cvs-import.sh -b devel -m "update to x.x.x" /path/to/srpm >>> common/cvs-import.sh -b F-9 -m "update to x.x.x" /path/to/srpm >> ???Jeroen, please don't do that. We had this discussion back in Feb 2007 >> on the maintainers list, please search for the thread named "???Discourage >> cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting)". > > Is using cvs-import for updating a package really discouraged? > From the discussion I was pointed to it seems it has to do with having the maintainer(s) look at the diffs before they commit anything, and cvs-import.sh possibly nuking changes other people made... Someone with more knowledge on the topic might be able to tell us a little more or step in if I'm wrong; Afaics, cvs-import.sh forces me to look at a diff, so I'm not sure if this concern is still valid/current. -Jeroen From alan at redhat.com Mon Jun 16 09:18:52 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Jun 2008 05:18:52 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855AEE1.70505@blagblagblag.org> References: <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <1213572271.26255.586.camel@pmac.infrad!ead.org> <4855AEE1.70505@blagblagblag.org> Message-ID: <20080616091852.GC15790@devserv.devel.redhat.com> On Sun, Jun 15, 2008 at 09:08:01PM -0300, jeff wrote: > Has RedHat ever had the source code to the driver? There is no such thing as "RedHat" it is "Red Hat". This is a trademark so proper use matters. Any legal questions with regards to Red Hat matters and materials should be addressed to legal at redhat.com. Alan From j.w.r.degoede at hhs.nl Mon Jun 16 09:17:45 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jun 2008 11:17:45 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <48562B25.6060602@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> <48562B25.6060602@blagblagblag.org> Message-ID: <48562FB9.1090701@hhs.nl> jeff wrote: > Hans de Goede wrote: >> jeff wrote: >>> Hans de Goede wrote: >>>> Really, arguing that Fedora's stance is inconsistent, while in >>>> reality yours is doesn't gain you much respect. Either: >>>> >>>> 1) all firmware is software and must be free in which case support >>>> for evil hardware which comes with the firmware embedded must be >>>> removed from linux-libre! >>> >>> No, because the goal of linux-libre is to have a kernel which doesn't >>> distribute non-free software. >>> >> >> Oh, but promoting the usage and buying of devices which contain >> non-free firmware by supporting those is ok, > > When have I ever done that??? You're just putting words in my mouth. > Try reading my sentence again "promoting ... by supporting", as the kernel-libre package still supports hardware that contains non free firmware it is promoting the use of that hardware by _supporting_ that hardware. >> because it isn't non-free firmware that is evil. It is the >> distributing of non-free firmware that is evil. Yes a very consistent >> and logical pov for which I applaud you! > > I have never used the word evil wrt software. Again, you are putting > words in my mouth. > Evil is indeed my choice of words, I use it as a nice short way to describe everything wrong with non-free software, nothing more and nothing less. >> Basicly the message you are sending is: people please by devices with >> firmware in rom, preferably otp rom, because then certainly there is >> no evil. > > That's the message I'm sending?>?!? Again, you're just putting words in > my mouth. I've never said anything of the sort. > Well, you want Fedora to change so that it will only work out of the box with devices which have the firmware in rom, so yes that is the message you are sending. > We're talking about > > > > * * * SOFTWARE THE FEDORA PROJECT IS ---> DISTRIBUTING <--- * * * > That is one vision, another vision is we are talking about a bunch of bits, which are part of the hardware. In some cases these bits which are part of the hardware happen to be stored in a non-volatile storage on the hardware and put on a non-volatile medium which is not physically part of the hardware, in these cases the operating system needs to get this bits from the non-volatile medium and put them in the volatile medium in the hardware before it can use the hardware. That doesn't make these bits any more or less part of the hardware as when they were in a rom. So what you call software I call part of the hardware, see word game again. Note I'm not against the idea of having a variant of Fedora which does not contain firmware for those who want that, I actually support that idea! But saying that Fedora cannot call itself a Free OS because it doesn't match your definition of Free seriously rubs me the wrong way. Also these kind of posts are not helping your case at all, they only serve to alienate the few supporters you have within the Fedora development community. Regards, Hans From alan at redhat.com Mon Jun 16 09:22:12 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Jun 2008 05:22:12 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48560EBF.7050805@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> Message-ID: <20080616092212.GD15790@devserv.devel.redhat.com> On Mon, Jun 16, 2008 at 03:57:03AM -0300, jeff wrote: > ---> No, the difference is Fedora is *DISTRIBUTING* the non-free bits. <--- Please go read the Fedora policy on firmware. From bnocera at redhat.com Mon Jun 16 09:33:18 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 16 Jun 2008 10:33:18 +0100 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: <1213608798.3254.10.camel@cookie.hadess.net> On Sun, 2008-06-15 at 18:23 -0500, Jason L Tibbitts III wrote: > Occasionally we see a package review ticket opened for a package which > really isn't ready for review. I'm not sure bugzilla is really best > the place for coordinating packaging work, but some seem to want to > use it for that and I don't really see it as being invalid. Some > folks just want to drop a specfile but don't really want to stick > around to maintain the package. > > Unfortunately when this happens, the "not ready for review" ticket > shows up in the review queue, extremely scarce reviewer time is > wasted on tickets that aren't reviewable, and the already huge queue > gets even bigger. One way to deal with this is to just give these > tickets their own bugzilla component. I'm not really sure what to > call it, though. Maybe "Package Development", but that sounds a bit > broad. Whatever the component is called, though, it would give these > tickets a place to go that doesn't complicate the package review > process. Make the report less buggy and not show up reviews that have non-resolved dependencies. That'll remove gnome-lirc-properties from your list for example... From rawhide at fedoraproject.org Mon Jun 16 09:54:42 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 16 Jun 2008 09:54:42 +0000 (UTC) Subject: rawhide report: 20080616 changes Message-ID: <20080616095442.B97C6209D18@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080615/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080616/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package imsettings Delivery framework for general Input Method configuration Updated Packages: Miro-1.2.4-1.fc10 ----------------- * Sun Jun 15 18:00:00 2008 Alex Lancaster - 1.2.4-1 - Update to latest upstream (1.2.4) bouml-4.3.5-1.fc10 ------------------ * Sun Jun 15 18:00:00 2008 Debarshi Ray - 4.3.5-1 - Version bump to 4.3.5. Closes Red Hat Bugzilla bug #448520. cairo-dock-1.6.0-0.2.svn1101_trunk.fc10 --------------------------------------- * Sun Jun 15 18:00:00 2008 Mamoru Tasaka - svn 1101 crystal-project-20070620-5.fc10 ------------------------------- * Sun Jun 15 18:00:00 2008 Chitlesh Goorah 20070620-5 - Bug 440357: crystal-project: drop Requires: kdebase debootstrap-1.0.9-1.fc10 ------------------------ * Sun Jun 15 18:00:00 2008 Adam Goode - 1.0.9-1 - 1.0.9 eclipse-epic-0.6.24-2.fc10 -------------------------- * Sat Jun 14 18:00:00 2008 Mat Booth 0.6.24-2 - Fixed package ownership of feature directory. fvwm-2.5.26-1.fc10 ------------------ * Wed Jun 4 18:00:00 2008 Adam Goode - 2.5.26-1 - Upgrade to new release - Remove module_list patch, fixed in upstream gprolog-1.3.0-16.fc10 --------------------- * Sun Jun 15 18:00:00 2008 Jochen Schmitt - 1.3.0-16 - Fix FTBFS (#440495) * Wed Apr 9 18:00:00 2008 Jochen Schmitt - 1.3.0-15 - Exclude x86_64 because a build failure (#440945) * Tue Feb 19 17:00:00 2008 Fedora Release Engineering 1.3.0-14 - Autorebuild for GCC 4.3 * Sun Feb 10 17:00:00 2008 Jochen Schmitt 1.3.0-13 - Rebuild for gcc-4.3 gxine-0.5.903-1.fc10 -------------------- * Sun Jun 15 18:00:00 2008 Martin Sourada - 0.5.903-1 - new upstream version im-chooser-1.1.0-1.fc10 ----------------------- * Thu Jun 12 18:00:00 2008 Akira TAGOH - 1.1.0-1 - New upstream release. imageinfo-0.05-6.fc10 --------------------- * Sun Jun 15 18:00:00 2008 Brendt Wohlberg - 0.05-6 - Added patch to deal with autoconf changes in devel branch. * Sun Jun 15 18:00:00 2008 Brendt Wohlberg - 0.05-5 - Fixed application of patch in spec file (thanks for Dave Jones for pointing out the problem). kernel-2.6.26-0.72.rc6.git2.fc10 -------------------------------- * Sat Jun 14 18:00:00 2008 Dave Jones - 2.6.26-rc6-git2 * Sat Jun 14 18:00:00 2008 Chuck Ebbert - Enable Controller Area Networking (F8#451179) libmusicbrainz-2.1.5-7.fc10 --------------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 2.1.5-7 - Provides: libmusicbrainz2(-devel), prepare for libmusicbrainz3 libotr-3.2.0-1.fc10 ------------------- * Sun Jun 15 18:00:00 2008 Paul Wouters 3.2.0-1 - Upgraded to 3.2.0 lxpanel-0.3.7-1.fc10 -------------------- * Sun Jun 15 18:00:00 2008 Sebastian Vahl 0.3.7-1 - new upstream version: 0.3.7 mercurial-1.0.1-4.fc10 ---------------------- * Sun Jun 15 18:00:00 2008 Neal Becker - 1.0.1-4 - Bitten by expansion of commented out macro (again) * Sun Jun 15 18:00:00 2008 Neal Becker - 1.0.1-3 - Add BR pkgconfig * Sun Jun 15 18:00:00 2008 Neal Becker - 1.0.1-2 - Update to 1.0.1 - Fix emacs_version, etc macros (need expand) - Remove patch0 * Mon Jun 2 18:00:00 2008 Neal Becker - 1.0-15 - Bump release tag * Thu Apr 17 18:00:00 2008 Neal Becker - 1.0-14 - Oops, fix %files due to last change * Wed Apr 16 18:00:00 2008 Neal Becker - 1.0-13 - install mergetools.hgrc as mergetools.rc * Sat Apr 12 18:00:00 2008 Neal Becker - 1.0-12 - Remove xemacs pkg - this is moved to xemacs-extras - Own /{mercurial,hgext} dirs * Thu Apr 10 18:00:00 2008 Neal Becker - 1.0-11 - Use install -p to install .el{c} files - Don't (load mercurial) by default. * Wed Apr 9 18:00:00 2008 Neal Becker - 1.0-10 - Patch to hgk from Mads Kiilerich * Tue Apr 8 18:00:00 2008 Neal Becker - 1.0-9 - Add '-l mercurial.el' for emacs also ngspice-17-16.fc10 ------------------ * Sun Jun 15 18:00:00 2008 Chitlesh Goorah 17-16 - Bugfix: #449409: FTBFS ngspice-17-14.fc9 * Fri Apr 18 18:00:00 2008 Chitlesh Goorah 17-15 - rebuild obexftp-0.22-0.10.uctest.fc10 ----------------------------- * Sun Jun 15 18:00:00 2008 Dominik Mierzejewski - 0.22-0.10.uctest - latest test release, with iconv support - fix rpmlint warning pidgin-otr-3.2.0-1.fc10 ----------------------- * Sun Jun 15 18:00:00 2008 Paul Wouters 3.2.0-1 - Updated to 3.2.0 pyPdf-1.11-1.fc10 ----------------- * Sun Jun 15 18:00:00 2008 Felix Schwarz 1.11-1 - update to 1.11 scim-1.4.7-25.fc10 ------------------ * Mon Jun 16 18:00:00 2008 Jens Petersen - 1.4.7-25.fc10 - require imsettings instead of im-chooser uncrustify-0.47-1.fc10 ---------------------- * Sun Jun 15 18:00:00 2008 Neal Becker - 0.47-1 - Update to 0.47 wordwarvi-0.15-1.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Hans de Goede 0.15-1 - New upstream release 0.15 xchat-2.8.6-1.fc10 ------------------ * Sun Jun 15 18:00:00 2008 Kevin Kofler - 1:2.8.6-1 - update to 2.8.6 - drop upstream patches (already applied in 2.8.6) - set default charset to UTF-8 (2.8.6 changed it to Latin1) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 24 Broken deps for i386 ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot smart-0.52-54.fc9.ppc64 requires smart-config From moe at blagblagblag.org Mon Jun 16 10:09:33 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 07:09:33 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616091852.GC15790@devserv.devel.redhat.com> References: <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <1213572271.26255.586.camel@pmac.infrad!ead.org> <4855AEE1.70505@blagblagblag.org> <20080616091852.GC15790@devserv.devel.redhat.com> Message-ID: <48563BDD.6090900@blagblagblag.org> Alan Cox wrote: > On Sun, Jun 15, 2008 at 09:08:01PM -0300, jeff wrote: >> Has RedHat ever had the source code to the driver? > > There is no such thing as "RedHat" it is "Red Hat". This is a trademark so > proper use matters. But not to me! ;) > Any legal questions with regards to Red Hat matters and materials should > be addressed to legal at redhat.com. Thanks. I have written them. :) Though this does apply to Fedora too, since Fedora is also distributing the file under the GPL. -Jeff From dwmw2 at infradead.org Mon Jun 16 10:11:36 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 11:11:36 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616091236.GB15790@devserv.devel.redhat.com> References: <20080609092041.GB13454@devserv.devel.redhat.com> <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> <20080616091236.GB15790@devserv.devel.redhat.com> Message-ID: <1213611096.26255.678.camel@pmac.infradead.org> On Mon, 2008-06-16 at 05:12 -0400, Alan Cox wrote: > On Sun, Jun 15, 2008 at 02:39:00PM +0100, David Woodhouse wrote: > > > Bingo.. and copyright does not give you power over other works > > > > Rather, the intent is to exercise the right to control the distribution > > of derivative or _collective_ works based on the Program. > > See earlier discussion. Its your viewpoint that these are somehow derivative. > I'm disagreeing. Please take the discussion to the GNU lists It is indeed my viewpoint that the 'bzImage' kernel image we ship is either a derivative or collective work based on the GPL'd kernel source code. It is also my viewpoint that the Linux source tree, as a whole, is either a derivative or collective work based on the GPL'd kernel source code. I'm surprised you affect to disagree with either of those, but it doesn't seem that you're likely to change your mind -- so perhaps it's best we just leave it at that. -- dwmw2 From moe at blagblagblag.org Mon Jun 16 10:27:01 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 07:27:01 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48562FB9.1090701@hhs.nl> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> <48562B25.6060602@blagblagblag.org> <48562FB9.1090701@hhs.nl> Message-ID: <48563FF5.2020401@blagblagblag.org> Hans de Goede wrote: > jeff wrote: >> We're talking about >> >> >> >> * * * SOFTWARE THE FEDORA PROJECT IS ---> DISTRIBUTING <--- * * * >> > > That is one vision, another vision is we are talking about a bunch of bits, > which are part of the hardware. It's software. In the case of tg3.c there is software sitting on someone's hard drive, they edit that, run it through a compiler, and spit out non-free binaries which Fedora distributes. Just because it runs on hardware doesn't make it hardware. I can't believe you're actually arguing the files in foo-firmware.src.rpm are *HARDWARE*. What a crock. Fedora ships hardware thru the internet! A triumph! You certainly (or very much most likely) didn't get them from the hardware either--you probably got them via ftp. > In some cases these bits which are part > of the hardware happen to be stored in a non-volatile storage on the > hardware and put on a non-volatile medium which is not physically part > of the hardware, in these cases the operating system needs to get this > bits from the non-volatile medium and put them in the volatile medium in > the hardware before it can use the hardware. That doesn't make these > bits any more or less part of the hardware as when they were in a rom. Wow. I guess doublethinking requires such convoluted logic. Dude, if I can download it via FTP it isn't hardware. Get real. > So what you call software I call part of the hardware, see word game again. Ya, it's a word game for you apparently, and you are *clearly* on the bullshit side of the word game by calling what is software hardware. Since when is fedora a hardware company, then? pfft. Wouldn't they have to go thru a whole different regulatory scheme to distribute this "hardware". -Jeff From sundaram at fedoraproject.org Mon Jun 16 10:30:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 16 Jun 2008 16:00:10 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855FB57.6050401@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> Message-ID: <485640B2.9080201@fedoraproject.org> jeff wrote: > > "We try to always do the right thing, and provide only free and open source > software." [1] > > It's simply not true and the author of that (Rahul Sundaram I think--he > writes it everywhere else too) Sorry. That's not me. Don't blame me unnecessarily. Besides what is the right thing varies depending on the context and is a subjective thing. Rahul From dwmw2 at infradead.org Mon Jun 16 10:41:36 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 11:41:36 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <485640B2.9080201@fedoraproject.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> Message-ID: <1213612896.26255.684.camel@pmac.infradead.org> On Mon, 2008-06-16 at 16:00 +0530, Rahul Sundaram wrote: > jeff wrote: > > > > "We try to always do the right thing, and provide only free and open source > > software." [1] > > > > It's simply not true and the author of that (Rahul Sundaram I think--he > > writes it everywhere else too) > > Sorry. That's not me. Don't blame me unnecessarily. Besides what is the > right thing varies depending on the context and is a subjective thing. In this context, the 'right thing' seems quite clear. Fedora always requires an initrd anyway, and we gain no benefit by building this firmware into our kernel when it might as well be loaded from userspace. Please help by providing more patches to make drivers use request_firmware() :) -- dwmw2 From moe at blagblagblag.org Mon Jun 16 10:49:00 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 07:49:00 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616092212.GD15790@devserv.devel.redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <20080616092212.GD15790@devserv.devel.redhat.com> Message-ID: <4856451C.20200@blagblagblag.org> Alan Cox wrote: > On Mon, Jun 16, 2008 at 03:57:03AM -0300, jeff wrote: >> ---> No, the difference is Fedora is *DISTRIBUTING* the non-free bits. <--- > > Please go read the Fedora policy on firmware. http://fedoraproject.org/wiki/Packaging/LicensingGuidelines "Some applications and drivers require binary-only firmware to function. Fedora permits inclusion of these files as long as they meet the following requirements:" ... "The files are standalone, not embedded in executable or library code." Well, what about tg3.c? That's clearly not standalone, for one example. "The files must be necessary for the functionality of open source code being included in Fedora." Again, what about tg3.c? The non-free firmware in tg3.c is *not necessary* for the driver to work. We have linux-libre users using tg3 successfully without the firmware, for example. It seems to me that it fails on two counts of your own policy. The policy also states: "The License tag for any firmware that disallows modification must be set to: "Redistributable, no modification permitted"" To me it seems clear, /at a minimum/, that the LICENSE tag of the kernel in Fedora/RH is incorrect as it says it is "GPLv2", when there are more licenses involved than just that, some of which say "no modification permitted". Thanks, -Jeff From d.lesca at solinos.it Mon Jun 16 10:52:28 2008 From: d.lesca at solinos.it (Dario Lesca) Date: Mon, 16 Jun 2008 12:52:28 +0200 Subject: f8/f9 kernel 2.6.25.x problem In-Reply-To: <000001c8cf8f$509c9090$f1d5b1b0$@org> References: <000001c8cf8f$509c9090$f1d5b1b0$@org> Message-ID: <1213613548.6258.53.camel@lesca.home.solinos.it> Il giorno lun, 16/06/2008 alle 10.59 +0200, EH Netzwerkadmin ha scritto: > Hi, > > Did you get an answer regarding your kernel problem on the ProLiant > server? > > I also updated my system this weekend (DL320 G5) and now have the same > problems (F8). > Regarding to > http://www.kerneloops.org/version.php?start=1671168&end=1703935&version=25-release (pci_device_probe) this seems to be a kernel bug, unfortunately I could not find any posing on how to fix the bug. > Unfortunately on my server I have install f8. And i have NOT update kernel 2.6.25* Follow my previous message. Hope this help... > ------- Messaggio inoltrato ------- > Da: Dario Lesca > Rispondi-a: For users of Fedora > A: Fedora Project List > CC: Fedora Devel > Oggetto: f8/f9 kernel 2.6.25.x problem > Data: Fri, 06 Jun 2008 14:54:09 +0200 > > On a server HP Proliant DL380 G5 > > > http://www.smolts.org/client/show/pub_e04ad1d7-e691-4b54-a3b6-1a5ff974d5bd > > if I install f9-i386 (kernel 2.6.25) or install f8-i386+upgrade with > last kernel 2.6.25 > > I get this error: > > > invalid opcode: 0000 [#1] SMP > > Modules linked in: sg ipmi_si(+) hpwdt(+) ipmi_msghandler bnx2 button iTCO_wdt sr_mod pcspkr iTCO_vendor_support i5000_edac edac_core cdrom ata_piix libata cciss sd_mod scsi_mod dm_snapshot dm_zero dm_mirror dm_mod xfs uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] > > > > Pid: 1173, comm: modprobe Not tainted (2.6.25.4-10.fc8PAE #1) > > EIP: 0060:[] EFLAGS: 00210286 CPU: 3 > > EIP is at 0xf7c5edca > > EAX: 5f32335f EBX: 000f0000 ECX: 00cd0100 EDX: 00000000 > > ESI: d0ffffff EDI: c39bd09b EBP: f7c5eda8 ESP: f7c5ed78 > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > Process modprobe (pid: 1173, ti=f7c5e000 task=f6e08e70 task.ti=f7c5e000) > > Stack: f89c54a9 00000060 ffff007b 00200286 f7949000 ffffffed f7c5eda8 f7c5eda8 > > c00ffee0 00000000 000f1fff c00f0000 f7c5edc8 c00f0000 c00ffee0 f7c5edc8 > > c00f0000 f89c65d0 f89c65a0 f7949000 f7c5eddc c050659d f7949054 00000000 > > Call Trace: > > [] ? hpwdt_init_one+0x18b/0x3a3 [hpwdt] > > [] ? pci_device_probe+0x39/0x5b > > [] ? driver_probe_device+0xc0/0x137 > > [] ? __driver_attach+0x73/0xa9 > > [] ? bus_for_each_dev+0x37/0x5c > > [] ? driver_attach+0x14/0x16 > > [] ? __driver_attach+0x0/0xa9 > > [] ? bus_add_driver+0x90/0x1b7 > > [] ? driver_register+0x47/0xa2 > > [] ? __pci_register_driver+0x35/0x61 > > [] ? hpwdt_init+0x17/0x19 [hpwdt] > > [] ? sys_init_module+0x1610/0x177a > > [] ? do_page_fault+0x528/0x909 > > [] ? param_get_int+0x0/0x15 > > [] ? do_sync_read+0x0/0xe9 > > [] ? sys_read+0x3b/0x60 > > [] ? syscall_call+0x7/0xb > > ======================= > > Code: 00 ff 1f 0f 00 00 00 0f c0 c8 ed c5 f7 00 00 0f c0 e0 fe 0f c0 c8 ed c5 f7 00 00 0f c0 d0 65 9c f8 a0 65 9c f8 00 90 94 f7 dc ed f7 9d 65 50 c0 54 90 94 f7 00 00 00 00 d0 65 9c f8 f4 ed c5 > > EIP: [] 0xf7c5edca SS:ESP 0068:f7c5ed78 > > ---[ end trace 732bbc392f92b3f6 ]--- > > input: Ups Manufacturing RS232-USB converter as /class/input/input5 > > input,hidraw0: USB HID v1.00 Gamepad [Ups Manufacturing RS232-USB converter] on usb-0000:00:1d.2-2 > > usb 4-2: New USB device found, idVendor=0a6d, idProduct=0005 > > usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 4-2: Product: RS232-USB converter > > usb 4-2: Manufacturer: Ups Manufacturing > > usb 6-1: new full speed USB device using uhci_hcd and address 2 > > usb 6-1: configuration #1 chosen from 1 choice > > input: HP Virtual Keyboard as /class/input/input6 > > input,hidraw1: USB HID v1.01 Keyboard [HP Virtual Keyboard] on usb-0000:01:04.4-1 > > input: HP Virtual Keyboard as /class/input/input7 > > input,hidraw2: USB HID v1.01 Mouse [HP Virtual Keyboard] on usb-0000:01:04.4-1 > > usb 6-1: New USB device found, idVendor=03f0, idProduct=1027 > > usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 6-1: Product: Virtual Keyboard > > usb 6-1: Manufacturer: HP > > usb 6-2: new full speed USB device using uhci_hcd and address 3 > > usb 6-2: configuration #1 chosen from 1 choice > > hub 6-2:1.0: USB hub found > > hub 6-2:1.0: 7 ports detected > > usb 6-2: New USB device found, idVendor=03f0, idProduct=1327 > > usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 6-2: Product: Virtual Hub > > usb 6-2: Manufacturer: HP > > NET: Registered protocol family 10 > > lo: Disabled Privacy Extensions > > ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 23 (level, low) -> IRQ 23 > > device-mapper: multipath: version 1.0.5 loaded > > (this errore is grab from dmesg of f8+upd) > > F8 after a lot of timeout during the boot start, but f9+update or f9 > +update-testing or f9+update-rawhide (2.6.26) not start ... > > Is this a new issue for kernel 2.6.25 on this hardware? > > Someone have some suggest for test some options ? > > Many thanks -- Dario Lesca From moe at blagblagblag.org Mon Jun 16 10:57:56 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 07:57:56 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485640B2.9080201@fedoraproject.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> Message-ID: <48564734.10103@blagblagblag.org> Rahul Sundaram wrote: > jeff wrote: >> >> "We try to always do the right thing, and provide only free and open >> source >> software." [1] >> >> It's simply not true and the author of that (Rahul Sundaram I >> think--he writes it everywhere else too) > > Sorry. That's not me. Don't blame me unnecessarily. Besides what is the > right thing varies depending on the context and is a subjective thing. Ah, sorry, I took a quick look at the wiki history and saw your name there (but didn't pin down the actual line) and from memory recalled you writing similar stuff in lwn.net comments. Also, I wasn't arguing about the "right thing" part of it, but the "provide *ONLY* free and open source software" part. To be clear: Fedora does not *ONLY* provide free and open source software, they also ship non-free software which cannot be modified and for which the source code isn't available to the general public. This isn't an accident or a bug, but policy. -Jeff From moe at blagblagblag.org Mon Jun 16 11:13:14 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 08:13:14 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616091852.GC15790@devserv.devel.redhat.com> References: <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <1213572271.26255.586.camel@pmac.infrad!ead.org> <4855AEE1.70505@blagblagblag.org> <20080616091852.GC15790@devserv.devel.redhat.com> Message-ID: <48564ACA.4090401@blagblagblag.org> Alan Cox wrote: > On Sun, Jun 15, 2008 at 09:08:01PM -0300, jeff wrote: >> Has RedHat ever had the source code to the driver? > > Any legal questions with regards to Red Hat matters and materials should > be addressed to legal at redhat.com. Not any more. I got this back: ========================================================================= Thank you for your message. Please note the following: This email address has been deactivated. Email sent to this address IS NOT RECEIVED by a person at Red Hat. If you need to contact us regarding a legal issue, please send written correspondence to us at: Legal Affairs 1801 Varsity Drive Raleigh, NC 27606 Please be aware that the Legal Affairs department cannot give legal advice to parties outside of Red Hat. Therefore, Red Hat will not respond to requests for such advice, including but not limited to our licenses, products or intellectual property. If you have a question about our End User License Agreements, please refer to www.redhat.com/licenses for information. If you do not find the answer to your question there, please consult your attorney. If you do not have an attorney, we will be happy to provide you with a referral. ========================================================================= Though a developer would have a much better idea if Red Hat/Fedora has the source than a lawyer. The lawyer would just run around and ask the developers. ;) -Jeff From sundaram at fedoraproject.org Mon Jun 16 11:25:12 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 16 Jun 2008 16:55:12 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <48564734.10103@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> Message-ID: <48564D98.6050107@fedoraproject.org> jeff wrote: > Rahul Sundaram wrote: >> jeff wrote: >>> >>> "We try to always do the right thing, and provide only free and open >>> source >>> software." [1] >>> >>> It's simply not true and the author of that (Rahul Sundaram I >>> think--he writes it everywhere else too) >> >> Sorry. That's not me. Don't blame me unnecessarily. Besides what is >> the right thing varies depending on the context and is a subjective >> thing. > > Ah, sorry, I took a quick look at the wiki history and saw your name > there (but didn't pin down the actual line) I edit the wiki all the time but that doesn't mean all of the content there is written by me. You have to be more careful about who you attribute the source. > > Also, I wasn't arguing about the "right thing" part of it, but the > "provide *ONLY* free and open source software" part. Reading the whole thing in context helps. We are trying to. We might not be there just yet but we are a doing a hell lot better than most distributions. Pissing off your best allies isn't going to achieve your goal. Rahul From moe at blagblagblag.org Mon Jun 16 12:24:12 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 16 Jun 2008 09:24:12 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48564D98.6050107@fedoraproject.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> Message-ID: <48565B6C.3030902@blagblagblag.org> Rahul Sundaram wrote: > jeff wrote: >> Rahul Sundaram wrote: >>> jeff wrote: >>>> >>>> "We try to always do the right thing, and provide only free and open >>>> source >>>> software." [1] >>>> >>>> It's simply not true and the author of that (Rahul Sundaram I >>>> think--he writes it everywhere else too) >>> >>> Sorry. That's not me. Don't blame me unnecessarily. Besides what is >>> the right thing varies depending on the context and is a subjective >>> thing. >> >> Ah, sorry, I took a quick look at the wiki history and saw your name >> there (but didn't pin down the actual line) > > I edit the wiki all the time but that doesn't mean all of the content > there is written by me. You have to be more careful about who you > attribute the source. Well I did hedge it with "Rahul Sundaram I think". The edit history is actually lost since the wiki move (which looks soooo much nicer, btw). I was also thinking about this quote you wrote in lwn: "Fedora does not develop or use any proprietary software or service and doesn't have a non-free repository either."[1] You do know that Fedora uses and distributes proprietary software, right? Your repo itself is non-free since it contains non-free software. (And for people arguing for different definitions of "free" the Fedora Overview page links directly to the FSF's definition, so that's what Fedora itself is using.[2]) rahulsundaram on lwn.net: "Fedora does not even have a non-free repository."[3] "Fedora doesnt endorse non-free repositories in anyway."[4] "The Fedora Project builds a world-class Linux operating system, consisting of entirely free (meaning both zero-cost and full source code available) software"[5] "Fedora Project has explicit objectives (http://fedoraproject.org/wiki/Objectives) to be a Free and open source distribution."[6] "Kmod's are only going away in the official repository which was only including free and open source code anyway and hence for proprietary drivers the Fedora change makes no difference."[7] etc.... And that's just under the lwn.net domain... >> Also, I wasn't arguing about the "right thing" part of it, but the >> "provide *ONLY* free and open source software" part. > > Reading the whole thing in context helps. We are trying to. We might not > be there just yet but we are a doing a hell lot better than most > distributions. Oh I agree. I mean, xandros includes crap like skype, for instance. But it's also quite clear that Fedora *knows* it is distributing plenty of non-free software and they are OK with that--in fact, it's part of policy. > Pissing off your best allies isn't going to achieve your > goal. Well, I wasn't trying to piss you off, but I probably have now, by quoting you to you! sry. -Jeff [1] http://lwn.net/Articles/277038/ [2] http://www.gnu.org/philosophy/free-sw.html [3] http://lwn.net/Articles/274000/ [4] http://lwn.net/Articles/207240/ [5] http://lwn.net/Articles/259255/ (this from a list) [6] http://lwn.net/Articles/196693/ [7] http://lwn.net/Articles/277024/ From sundaram at fedoraproject.org Mon Jun 16 12:42:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 16 Jun 2008 18:12:40 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <48565B6C.3030902@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> <48565B6C.3030902@blagblagblag.org> Message-ID: <48565FC0.2040707@fedoraproject.org> jeff wrote: > > Well I did hedge it with "Rahul Sundaram I think". The edit history is > actually lost since the wiki move (which looks soooo much nicer, btw). The old wiki is still available. > You do know that Fedora uses and distributes proprietary software, > right? Fedora differentiates between different form of software as documented within the licensing guidelines. FSF itself draws such lines. http://www.gnu.org/philosophy/free-system-distribution-guidelines.html Certain forms of software being non modifiable is perfectly ok according to FSF. One could argue that FSF draws the lines correctly and Fedora does not but then it isn't merely free vs non-free anymore at that point. >> Pissing off your best allies isn't going to achieve your goal. > > Well, I wasn't trying to piss you off, but I probably have now, by > quoting you to you! sry. I wasn't talking about me personally. I am talking about Fedora as a whole but the point still stands. Fedora as a project has done more to promote free software than most mainstream distributions. We aren't perfect however and that is well known. Rahul From lesmikesell at gmail.com Mon Jun 16 12:42:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 07:42:25 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485612A0.9050104@blagblagblag.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com > <4855F4B1.2080207@blagblagblag.org> <48560327.4000109@gmail.com> <485612A0.9050104@blagblagblag.! org> Message-ID: <48565FB1.7080204@gmail.com> jeff wrote: > >>> Have you even looked at tg3.c or it's history? >>> >> >> Just a quick google to find the discussion here: >> http://wiki.debian.org/KernelFirmwareLicensing with its note that the >> corrected license was committed here: >> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 > > > They changed the kernel source then, but that doesn't mean they aren't > under obligations of the GPL since they distributed it for *years* under > the GPL. Mistakes happen. Should all old instances disappear when a correction is made? I doubt if it's the only correction that has been made on a copyright over the years. -- Les Mikesell lesmikesell at gmail.com From buc at odusz.so-cdu.ru Mon Jun 16 12:48:52 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 16 Jun 2008 16:48:52 +0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> Message-ID: <48566134.2040706@odu.neva.ru> Nigel Metheringham wrote: > > On 11 Jun 2008, at 16:06, Dmitry Butskoy wrote: > >> Nigel Metheringham wrote: >>> This looks good, but on a minimal system how many other packages >>> would be pulled in as dependancies over the existing mailx? > >> For now, "openssl" (or "nss") and "krb5-libs". Is it OK for a minimal >> system? > > Both of those ought to be on a system anyhow (openssh would need them). > > I was concerned that things like imap support could pull in a pile of > other deps Nope, all such are supported by nail itself. Regarding the minimal install -- Does it have Mozilla's nss library or not? For the "Security Consolidation" process, recently started in Fedora, we should build mailx/nail against nss (instead of openssl). On the other hand, if the current "minimal installs" don`t have nss, then IMHO we should still use openssl (at least while openssh uses it)... ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From cmadams at hiwaay.net Mon Jun 16 13:15:10 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Jun 2008 08:15:10 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855F4B1.2080207@blagblagblag.org> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <4855F4B1.2080207@blagblagblag.org> Message-ID: <20080616131510.GA1272613@hiwaay.net> Once upon a time, jeff said: > The firmware hasn't always been known to be non-GPL. It was distributed for > years under the GPL, so it *is* GPL, but they are violating the GPL by not > shipping the source code. They distributed a string of hex digits in a source file that said it was GPL. Where does it say they have to give you anything else? If I "dd if=/dev/random bs=16 count=1 | md5sum" and include the output in a GPL source file, you don't get to demand my entropy pool. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Mon Jun 16 13:17:03 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Jun 2008 08:17:03 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213611096.26255.678.camel@pmac.infradead.org> References: <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> <20080616091236.GB15790@devserv.devel.redhat.com> <1213611096.26255.678.camel@pmac.infradead.org> Message-ID: <20080616131703.GB1272613@hiwaay.net> Once upon a time, David Woodhouse said: > It is indeed my viewpoint that the 'bzImage' kernel image we ship is > either a derivative or collective work based on the GPL'd kernel source > code. The compiled kernel image is just a mechanical production from the source and does not have copyright of its own. This is no different than running mkisofs to build a CD; you can have GPL and non-GPL-compat software on the CD. It is mere aggregation. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwilson at redhat.com Mon Jun 16 13:18:13 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jun 2008 09:18:13 -0400 Subject: Someone please take over these packages Message-ID: <200806160918.13496.jwilson@redhat.com> For a variety of reasons, I have to entirely give up involvement in a number of packages. I've already tried to find new primary maintainers without success, but I really can't justify any time spent on these packages any longer, so I must orphan them ASAP, and hopefully, someone picks them up... emerald (compiz-fusion alternate windowing thingamajig) emerald-themes (themes for the above) ganglia (cluster monitoring software) numpy (numerical python) I've also got the following packages for which I've yet to solicit new maintainers for that I am also intending to orphan Real Soon Now: conman (console management software) connect-proxy (helper to use ssh through socks/squid proxy) dircproxy (detachable irc proxy) powerman (power management software) I'll keep myself on the cc for bugzillas for all of the above, and will try to help with any bugs filed, personal free time permitting. Most of these are relatively low on time investment required to maintain them, but volume adds up, particularly given that I only actually use two of these packages on any sort of regular basis these days (conman and dircproxy). -- Jarod Wilson jwilson at redhat.com From lesmikesell at gmail.com Mon Jun 16 13:18:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 08:18:02 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213601497.26255.619.camel@pmac.infradead.org> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> Message-ID: <4856680A.7070509@gmail.com> David Woodhouse wrote: > >>>> Do do have an exact definition of what is not permitted? >>> I pasted a precise definition of 'collective work' already, didn't I? >> That is unrelated to the question. > > No, it is the answer to your question. You asked what is not permitted. And you are ignoring the explicit permission for aggregation. > What's not permitted is distribution of a collective work including the > GPL'd Program, where the other independent and separate parts of that > work are not also available under the terms of the GPL. Except when the separate parts are identifiable and not derived. >>> The very definition of 'collective work' is that it is an aggregation of >>> other independent and separate works. >> And aggregations are explicitly permitted which makes that discussion >> irrelevant. > > Oh dear, you're back to that again. I thought we'd dealt with that, but > we seem to be going round in circles. I'll try again, one last time: > > All collective work is aggregation. But only certain ones are permitted. > The GPL explicitly states that it covers collective work. With a specific exception for aggregations. > The GPL explicitly talks about extending the permissions of the GPL to > works which are independent and separate works in themselves, when those > works are included in a collective work. > > Thus, it is not credible to believe that the 'mere aggregation on a > volume of a storage or distribution medium' exception is intended to > cover _all_ aggregation. That would mean that the GPL is just setting up > all these conditions, only to immediately turn round and say "oh, > actually I didn't really mean it" in the next paragraph. No, it is not credible to believe that they explicitly say that aggregating separate works together is permitted but they don't actually permit it. And it's particularly not credible to believe that the copyright holders believe the inclusion of these parts are a copyright violation for fairly obvious reasons. > If you're willing to make that claim in public then I don't really know > why I'm bothering to talk to you. Do you have no shame? No, I just can't ignore what the COPYING file actually says. >>> As you know, the GPL makes an exception for 'mere aggregation on a >>> volume of a storage or distribution medium'. There is some scope for >>> debate on precisely what is covered by that exception, but not a huge >>> amount. >> So the relevant discussion should be about whether there is a person >> that can identify the separate parts. > > No, that's another complete non-sequitur from you. Where on earth did > _that_ idea come from? You apparently didn't read the distinguishing factor: "If identifiable sections of that work are not derived from the Program ..." > If you can identify the separate short stories in an anthology, do you > think that somehow means that it isn't a collective work? "Collective work" is not a relevant issue. The question is whether or not it is a permitted aggregation, and the way to determine this is spelled out fairly clearly. I wouldn't expect everyone to be experts on both kernel code and firmware, so the first step is to find some who can identify the sections (like maybe the person who put them there...) and make a determination if they were "derived from the Program". We already know they are separate, since they get dumped into separate hardware. > Actually, don't bother to answer that. Because I'm sure you'll just come > back with another complete non-sequitur rather than a real answer. Quoting the text of the GPL is not a non-sequitur and should hardly be necessary at this point in the conversation. > Let's just give up, eh? Unless you want to talk about the actual GPL instead of ignoring part of it. There is room for interpretation about determining separate sections that are independent works, but so far you haven't addressed that and it is the only relevant question. -- Les Mikesell lesmikesell at gmail.com From cmadams at hiwaay.net Mon Jun 16 13:20:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Jun 2008 08:20:17 -0500 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <48566134.2040706@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> Message-ID: <20080616132017.GC1272613@hiwaay.net> Once upon a time, Dmitry Butskoy said: > Regarding the minimal install -- Does it have Mozilla's nss library or > not? For the "Security Consolidation" process, recently started in > Fedora, we should build mailx/nail against nss (instead of openssl). On > the other hand, if the current "minimal installs" don`t have nss, then > IMHO we should still use openssl (at least while openssh uses it)... Well, on a minimal F9 system, "yum remove nss" wants to remove rpm, so I'd say nss is pretty much integral at this point. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From limb at jcomserv.net Mon Jun 16 13:22:57 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Jun 2008 08:22:57 -0500 (CDT) Subject: Someone please take over these packages In-Reply-To: <200806160918.13496.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> Message-ID: <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> > For a variety of reasons, I have to entirely give up involvement in a > number > of packages. I've already tried to find new primary maintainers without > success, but I really can't justify any time spent on these packages any > longer, so I must orphan them ASAP, and hopefully, someone picks them > up... > > emerald (compiz-fusion alternate windowing thingamajig) > emerald-themes (themes for the above) > ganglia (cluster monitoring software) > numpy (numerical python) I'll be willing to take numpy, especially if you can suggest the direction you have in mind for 432194. If not, I'll take it anyway. > I've also got the following packages for which I've yet to solicit new > maintainers for that I am also intending to orphan Real Soon Now: > > conman (console management software) > connect-proxy (helper to use ssh through socks/squid proxy) > dircproxy (detachable irc proxy) > powerman (power management software) > > I'll keep myself on the cc for bugzillas for all of the above, and will > try to > help with any bugs filed, personal free time permitting. Most of these are > relatively low on time investment required to maintain them, but volume > adds > up, particularly given that I only actually use two of these packages on > any > sort of regular basis these days (conman and dircproxy). > > -- > Jarod Wilson > jwilson at redhat.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 dwmw2 at infradead.org Mon Jun 16 13:27:36 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 14:27:36 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616131703.GB1272613@hiwaay.net> References: <20080609204314.GA4009@devserv.devel.redhat.com> <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> <20080616091236.GB15790@devserv.devel.redhat.com> <1213611096.26255.678.camel@pmac.infradead.org> <20080616131703.GB1272613@hiwaay.net> Message-ID: <1213622856.26255.739.camel@pmac.infradead.org> On Mon, 2008-06-16 at 08:17 -0500, Chris Adams wrote: > The compiled kernel image is just a mechanical production from the > source and does not have copyright of its own. Excellent. So I can distribute that bzImage without heed to the provisions of copyright law? I don't need permission from the people who wrote it at all? The Windows kernel image is also just a mechanical production from the Windows source code. Does that not have a copyright either? Does that mean I can distribute Windows without heed to the provisions of copyright law too? As long as it's only the binaries, not the source? Complete nonsense. -- dwmw2 From jwilson at redhat.com Mon Jun 16 13:28:39 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jun 2008 09:28:39 -0400 Subject: Someone please take over these packages In-Reply-To: <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> References: <200806160918.13496.jwilson@redhat.com> <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> Message-ID: <200806160928.39620.jwilson@redhat.com> On Monday 16 June 2008 09:22:57 am Jon Ciesla wrote: > > For a variety of reasons, I have to entirely give up involvement in a > > number > > of packages. I've already tried to find new primary maintainers without > > success, but I really can't justify any time spent on these packages any > > longer, so I must orphan them ASAP, and hopefully, someone picks them > > up... > > > > emerald (compiz-fusion alternate windowing thingamajig) > > emerald-themes (themes for the above) > > ganglia (cluster monitoring software) > > numpy (numerical python) > > I'll be willing to take numpy, especially if you can suggest the direction > you have in mind for 432194. If not, I'll take it anyway. I've not really got a clue what direction to take on that bug, but I really haven't had any time to look into it -- which is directly related to why I need to give up the package. :) -- Jarod Wilson jwilson at redhat.com From rdieter at math.unl.edu Mon Jun 16 13:34:19 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 16 Jun 2008 08:34:19 -0500 Subject: Someone please take over these packages References: <200806160918.13496.jwilson@redhat.com> <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> Message-ID: Jon Ciesla wrote: > >> For a variety of reasons, I have to entirely give up involvement in a >> number >> of packages. I've already tried to find new primary maintainers without >> success, but I really can't justify any time spent on these packages any >> longer, so I must orphan them ASAP, and hopefully, someone picks them >> up... >> >> emerald (compiz-fusion alternate windowing thingamajig) >> emerald-themes (themes for the above) >> ganglia (cluster monitoring software) >> numpy (numerical python) > > I'll be willing to take numpy, especially if you can suggest the direction > you have in mind for 432194. If not, I'll take it anyway. I can help comaint numpy, got quite a number of local faculty here that use that. -- Rex From cmadams at hiwaay.net Mon Jun 16 13:35:28 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Jun 2008 08:35:28 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213622856.26255.739.camel@pmac.infradead.org> References: <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> <20080616091236.GB15790@devserv.devel.redhat.com> <1213611096.26255.678.camel@pmac.infradead.org> <20080616131703.GB1272613@hiwaay.net> <1213622856.26255.739.camel@pmac.infradead.org> Message-ID: <20080616133528.GD1272613@hiwaay.net> Once upon a time, David Woodhouse said: > On Mon, 2008-06-16 at 08:17 -0500, Chris Adams wrote: > > The compiled kernel image is just a mechanical production from the > > source and does not have copyright of its own. > > Excellent. So I can distribute that bzImage without heed to the > provisions of copyright law? I don't need permission from the people who > wrote it at all? No, just like a CD image, the copyright of the various source bits still applies. It is not a derivative work though, only a mere aggregation. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rjones at redhat.com Mon Jun 16 13:35:56 2008 From: rjones at redhat.com (Richard Jones) Date: Mon, 16 Jun 2008 09:35:56 -0400 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: Message-ID: <20080616133455.GA7646@thinkpad.bos.redhat.com> On Sun, Jun 15, 2008 at 06:23:42PM -0500, Jason L Tibbitts III wrote: > Occasionally we see a package review ticket opened for a package which > really isn't ready for review. I'm not sure bugzilla is really best > the place for coordinating packaging work, but some seem to want to > use it for that and I don't really see it as being invalid. Some > folks just want to drop a specfile but don't really want to stick > around to maintain the package. I sometimes do this (eg. https://bugzilla.redhat.com/show_bug.cgi?id=434560) really for packages which I would like to see or don't have the time yet to package. Debian has a concept of 'Intent To Package' and 'Request To Package'. ITP in particular seems like a similar thing, and they are treated like ordinary Debian bugs. Rich. From nicolas.mailhot at laposte.net Mon Jun 16 13:47:19 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jun 2008 15:47:19 +0200 (CEST) Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616133528.GD1272613@hiwaay.net> References: <20080614102642.GA4959@devserv.devel.redhat.com> <1213453269.26255.368.camel@pmac.infradead.org> <20080614143106.GA9770@devserv.devel.redhat.com> <1213456044.26255.395.camel@pmac.infradead.org> <20080614190515.GA15664@devserv.devel.redhat.com> <1213537140.26255.469.camel@pmac.infradead.org> <20080616091236.GB15790@devserv.devel.redhat.com> <1213611096.26255.678.camel@pmac.infradead.org> <20080616131703.GB1272613@hiwaay.net> <1213622856.26255.739.camel@pmac.infradead.org> <20080616133528.GD1272613@hiwaay.net> Message-ID: <46794.192.54.193.59.1213624039.squirrel@rousalka.dyndns.org> Le Lun 16 juin 2008 15:35, Chris Adams a ?crit : > > Once upon a time, David Woodhouse said: >> On Mon, 2008-06-16 at 08:17 -0500, Chris Adams wrote: >> > The compiled kernel image is just a mechanical production from the >> > source and does not have copyright of its own. >> >> Excellent. So I can distribute that bzImage without heed to the >> provisions of copyright law? I don't need permission from the people >> who wrote it at all? > > No, just like a CD image, the copyright of the various source bits > still > applies. It is not a derivative work though, only a mere aggregation. You don't get to decide what is "mere" aggregation and what is collective works no matter how convenient that may be for you. Just like the notion of "derived" works those are very specific legal terms and they are defined by the lawmaker intent not by the technical guy classification. What matters is not the tools used (a bunch of bytes on a common medium, a knife) but how they are used (mere aggregation/collective works, preparing a meal/wounding someone). Now can you all please stop stuffing the list and have your preferred lawyer give you a course on derived works, collective works and mere or not mere aggregation? -- Nicolas Mailhot From jkeating at j2solutions.net Mon Jun 16 13:50:19 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jun 2008 09:50:19 -0400 Subject: Finnish spell checking packages and comps In-Reply-To: <200806151932.47768.vpivaini@cs.helsinki.fi> References: <200806151932.47768.vpivaini@cs.helsinki.fi> Message-ID: <9339c38c0806160650u1ee6709es5fc2a2d22626311b@mail.gmail.com> On Sun, Jun 15, 2008 at 12:32 PM, Ville-Pekka Vainio < vpivaini at cs.helsinki.fi> wrote: > Hi, > > We now have the Enchant Voikko provider in Fedora (package enchant-voikko), > which provides Finnish spell checking support in Enchant. I would like to > add > it in comps for F10 and F9, but it's (clearly) not a GUI app and enchant > itself is not in comps at all. This is what I'd like to add under > the "Finnish support" group: > > requires="enchant">enchant-voikko > > Would that be ok? I see pretty much the same has been done for hunspell > packages for different languages, but hunspell is in the Base group, > enchant > is not. What should I do? > > I also have a package called tmispell-voikko, which can be used as an > ispell > replacement for Finnish and it also has an ncurses "GUI". Technically it's > a > text mode app, but could I still add it? It would go under the "Finnish > Support" group as well: > > tmispell-voikko > > Since these packages all seem extremely specific to Finnish, I don't necessarily see a problem with just listing them in Finnish-support, without any conditionals. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Mon Jun 16 13:53:28 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Jun 2008 08:53:28 -0500 (CDT) Subject: Someone please take over these packages In-Reply-To: References: <200806160918.13496.jwilson@redhat.com> <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> Message-ID: <56739.198.175.55.5.1213624408.squirrel@mail.jcomserv.net> > Jon Ciesla wrote: > >> >>> For a variety of reasons, I have to entirely give up involvement in a >>> number >>> of packages. I've already tried to find new primary maintainers without >>> success, but I really can't justify any time spent on these packages >>> any >>> longer, so I must orphan them ASAP, and hopefully, someone picks them >>> up... >>> >>> emerald (compiz-fusion alternate windowing thingamajig) >>> emerald-themes (themes for the above) >>> ganglia (cluster monitoring software) >>> numpy (numerical python) >> >> I'll be willing to take numpy, especially if you can suggest the >> direction >> you have in mind for 432194. If not, I'll take it anyway. > > I can help comaint numpy, got quite a number of local faculty here that > use > that. Beauty. Done and done. > -- 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 jkeating at j2solutions.net Mon Jun 16 13:44:03 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jun 2008 09:44:03 -0400 Subject: Requirements gathering for new package source control In-Reply-To: <200806160244.m5G2ifgg010136@laptop13.inf.utfsm.cl> References: <1213035578.30252.10.camel@localhost.localdomain> <1213038536.8383.8.camel@choeger6> <20080609230115.GA4252@mokona.greysector.net> <200806160244.m5G2ifgg010136@laptop13.inf.utfsm.cl> Message-ID: <9339c38c0806160644k265f33f1lc0a15e4e72744305@mail.gmail.com> On Sun, Jun 15, 2008 at 10:44 PM, Horst H. von Brand wrote: > Kevin Kofler wrote: > > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > > You don't have to tag to build. You can do scratch builds of HEAD in > koji. > > > > But then you still have to issue a real build after the last scratch > build > > succeeded, so you have wasted one build, wasting both your time and > Koji's > > cycles. Much more efficient to always use non-scratch builds (unless > you're > > building something which really shouldn't end up in Rawhide any time > soon). > > Can't a "scratch build" be just promoted to "official"? > Sortof. You can do a build that isn't scratch, but still doesn't get tagged. The build option is --skip-tag. I don't believe we have that hooked into any Make target just yet. If the build succeeded one could then issue a tag command (koji tag-pkg ) which would make the build "official". -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Mon Jun 16 14:17:47 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Jun 2008 15:17:47 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616131510.GA1272613@hiwaay.net> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <4855F4B1.2080207@blagblagblag.org> <20080616131510.GA1272613@hiwaay.net> Message-ID: <1213625867.26255.773.camel@pmac.infradead.org> On Mon, 2008-06-16 at 08:15 -0500, Chris Adams wrote: > Once upon a time, jeff said: > > The firmware hasn't always been known to be non-GPL. It was distributed for > > years under the GPL, so it *is* GPL, but they are violating the GPL by not > > shipping the source code. > > They distributed a string of hex digits in a source file that said it > was GPL. Where does it say they have to give you anything else? Section 3, where it says that you must provide, or offer to provide, the 'complete corresponding machine-readable source code' -- and clarifies that as follows: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." So if hex _really_ is the preferred form of the work for making modifications to it -- for example, if it's just a string of random bytes, then that's fine. If not, then it is not being distributed under the terms of the GPL. I know there are people who'll crawl out of the woodwork now, claiming that they _prefer_ to edit software in hex form rather than dealing with what normal people would call the 'source code'. It's amazing what nonsense people will come up with to justify what they want to believe. But they'd have to be fairly delusional if they want to claim that hex arrays really count as the 'the preferred form for modification' for most? of the 'blobs' we have in the kernel. And you'll note that when companies have lost court cases based on their GPL violations, they never even _tried_ the "but we _prefer_ editing our kernels in a hex editor" defence :) -- dwmw2 ? I say 'most' advisedly. Not _all_ of them, though -- when I went through the deblob script looking for drivers to convert to request_firmware(), I did point out a few which I believed to be false positives, like this kind of stuff in asilantfb.c: static struct chips_init_reg chips_init_cr[] = { {0x0c, 0x00}, /* Start address high */ {0x0d, 0x00}, /* Start address low */ {0x40, 0x00}, /* Extended Start Address */ {0x41, 0x00}, /* Extended Start Address */ {0x14, 0x00}, /* Underline location */ {0x17, 0xe3}, /* CRT mode control */ {0x70, 0x00} /* Interlace control */ I don't see anything wrong with _that_ at all. I've added hex stuff like that to the kernel and I _do_ believe it to be the preferred form for making modifications in some cases. From wolfy at nobugconsulting.ro Mon Jun 16 14:25:04 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 16 Jun 2008 17:25:04 +0300 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <48566134.2040706@odu.neva.ru> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> Message-ID: <485677C0.6010502@nobugconsulting.ro> Dmitry Butskoy wrote: > Nigel Metheringham wrote: >> >> On 11 Jun 2008, at 16:06, Dmitry Butskoy wrote: >> >>> Nigel Metheringham wrote: >>>> This looks good, but on a minimal system how many other packages >>>> would be pulled in as dependancies over the existing mailx? >> >>> For now, "openssl" (or "nss") and "krb5-libs". Is it OK for a minimal >>> system? >> >> Both of those ought to be on a system anyhow (openssh would need them). >> >> I was concerned that things like imap support could pull in a pile of >> other deps > > Nope, all such are supported by nail itself. > > > Regarding the minimal install -- Does it have Mozilla's nss library or > not? For the "Security Consolidation" process, recently started in > Fedora, we should build mailx/nail against nss (instead of openssl). > On the other hand, if the current "minimal installs" don`t have nss, > then IMHO we should still use openssl (at least while openssh uses it)... > > > ~buc > http://www.fedoraproject.org/wiki/DmitryButskoy > openssl is required by nash which is needed by mkinitrd which is in turn needed by kernel. so IMHO openssl is here to stay, too. From jwilson at redhat.com Mon Jun 16 14:25:58 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jun 2008 10:25:58 -0400 Subject: Someone please take over these packages In-Reply-To: <56739.198.175.55.5.1213624408.squirrel@mail.jcomserv.net> References: <200806160918.13496.jwilson@redhat.com> <56739.198.175.55.5.1213624408.squirrel@mail.jcomserv.net> Message-ID: <200806161025.58586.jwilson@redhat.com> On Monday 16 June 2008 09:53:28 am Jon Ciesla wrote: > > Jon Ciesla wrote: > >>> For a variety of reasons, I have to entirely give up involvement in a > >>> number > >>> of packages. I've already tried to find new primary maintainers without > >>> success, but I really can't justify any time spent on these packages > >>> any > >>> longer, so I must orphan them ASAP, and hopefully, someone picks them > >>> up... > >>> > >>> emerald (compiz-fusion alternate windowing thingamajig) > >>> emerald-themes (themes for the above) > >>> ganglia (cluster monitoring software) > >>> numpy (numerical python) > >> > >> I'll be willing to take numpy, especially if you can suggest the > >> direction > >> you have in mind for 432194. If not, I'll take it anyway. > > > > I can help comaint numpy, got quite a number of local faculty here that > > use > > that. > > Beauty. Done and done. Excellent, thanks much guys. -- Jarod Wilson jwilson at redhat.com From tibbs at math.uh.edu Mon Jun 16 14:27:49 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 09:27:49 -0500 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: <1213608798.3254.10.camel@cookie.hadess.net> References: <1213608798.3254.10.camel@cookie.hadess.net> Message-ID: >>>>> "BN" == Bastien Nocera writes: BN> Make the report less buggy and not show up reviews that have BN> non-resolved dependencies. "less buggy" is certainly loaded language. The report shows tickets in the "Package Review" component that have no 'fedora-review' flag set. It does that. I'm not sure how that behavior is somehow "buggy". In any case, that's certainly something to look it, but it's also quite orthogonal, since it doesn't really cover the majority of the tickets I'm looking at. Plus it's not really problematic to submit several interdependent review tickets. I guess the report could filter out reviews that are dependent on non-"Package Review" tickets, but that still doesn't solve the main problem. I'm kind of surprised there's reluctance to add a component since we add one for every single new package. Surely they're not a scarce resource. - J< From vonbrand at inf.utfsm.cl Mon Jun 16 16:03:57 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 12:03:57 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <485601B7.9050008@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <200806160449.m5G4nTxS019826@laptop13.inf.utfs! ! m.cl> <485601B7.9050008@gmail.com> Message-ID: <200806161603.m5GG3vck015531@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Horst H. von Brand wrote: [...] > >> Whether it is a derivative or 'work as a whole' depends on the > >> relationship of the parts, not temporary physical proximity. > > Please state which laws or court decisions lead you to this > > conclusion, and > > exactly what "relationship" has to be involved here. > I'm not aware of any court ruling. It is the conclusion I drew from > the FSF legal position regarding RIPEM that lead to the development of > the generally useless fgmp library. It was long enough ago that google > doesn't find many good references, but this one at least describes it: The FSF position is hardly authoritative here... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From gemi at bluewin.ch Mon Jun 16 16:04:33 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 16 Jun 2008 18:04:33 +0200 Subject: Orphaning skencil Message-ID: <1213632273.10922.10.camel@localhost.localdomain> Since skencil no longer works with tcltk 8.5, I will orphan it. It has been suggested to take up sK1 in its place. From lesmikesell at gmail.com Mon Jun 16 16:25:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 11:25:07 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806161603.m5GG3vck015531@laptop13.inf.utfsm.cl> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <200806160449.m5G4nTxS019826@laptop13.inf.utfs! ! m.cl> <485601B7.9050008@gmail.com> <200806161603.m5GG3vck015531@laptop13.inf.utfsm.cl> Message-ID: <485693E3.6060001@gmail.com> Horst H. von Brand wrote: > > [...] > >>>> Whether it is a derivative or 'work as a whole' depends on the >>>> relationship of the parts, not temporary physical proximity. >>> Please state which laws or court decisions lead you to this >>> conclusion, and >>> exactly what "relationship" has to be involved here. > >> I'm not aware of any court ruling. It is the conclusion I drew from >> the FSF legal position regarding RIPEM that lead to the development of >> the generally useless fgmp library. It was long enough ago that google >> doesn't find many good references, but this one at least describes it: > > The FSF position is hardly authoritative here... But it would be hard to claim that they would not be credible experts on the meaning of the GPL if an authoritative decision is ever necessary on this point. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Mon Jun 16 12:32:14 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 16 Jun 2008 09:32:14 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48547544.8060204@gmail.com> (Les Mikesell's message of "Sat\, 14 Jun 2008 20\:49\:56 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Yes, I agree that the initial author of a work has as much right to > impose the harmful GPL as any other copyright holder has to choose a > more or less restrictive license. I'm not so sure about additional > contributors of original work who have this choice taken away in the > GPL case only, though. Again, you're confused as to what the GPL does. It doesn't take any such choice away. It's copyright law that does. BTW, think of how many proprietary licenses used for non-libraries you know that permit the creation and distribution of derived works you might be interested in creating. Just to put things in perspective. > Having the choice to contribute under the GPL or not at all > resembles that "your money or your life" scenario you presented > earlier. Why do you dislike the idea of respecting others' freedoms just like yours were respected? I can see that it might be tempting to take away from others the rights that were given to you, but have you thought it through to the point of realizing this position is not only incoherent, it's immoral (as in, it evidently fails the golden rule, for starters) >>> if competitors were allowed to use components from Linux in >>> commercial offerings >> They are. > Not in the general case. They are. As long as they respect others' freedoms, abiding by the terms of the license, they can charge as much money as they like for distributing, supporting, or offering any other service related with the software, and run a successful commercial business. Why do you think this is not the case? > It would be unfeasible if not technically impossible to ship a Linux > based OS containing licensed copies of all the components needed to > match the functionality of commercial OS versions. I'm sorry, I can't make sense of what you're trying to say here. It appears that you're saying 'licensed copies' to refer to only proprietary software, and 'commercial OS' as proprietary operating system, but I wouldn't like to assume that's what you mean, because it still renders the meaning of your full claim nonsensical. Can you please try to rephrase what you wanted to say using different terms? > Everyone involved may be perfectly happy to meet whatever those > other restrictions might be, yet the GPL's harmful restrictions > prevents the useful combination from being distributed. You're mistaken. It's copyright law that prevents it, and it's not because of restrictions from the GPL, it's because of the other restrictions "everyone may be perfectly happy to meet". Evidently not everyone, since you're so unhappy about them that you're even trying to shift the blame onto a license that doesn't prohibit you from doing anything. >> Your unsatisfaction with the situation is shared by me, but your >> blaming the GPL for unfortunate (and at times unethical) choices made >> by others is misguided. > How so? The harm isn't shared by less restrictive licenses. I think we're miscommunicating. Please try to describe a specific situation and let's try to figure out what stops you from distributing the (theoretical) combined work you'd like to distribute. > But the concept of victim has a preconceived notion of harm, whereas > meeting non-GPL terms may not cause harm at all. That's true. There are many other Free Software licenses. GPL is not the only one. It's not even the only copyleft license. Now, when you accept a license that deprives you from any of the four essential freedoms, this harms you *and* everyone around. You're shooting your own foot, but the shrapnel hurts others. >> See? If my conviction you disputed above is wrong, then the person >> who decides to distribute cigarettes to the kids instead of milk would >> be behaving in accordance with moral and ethics. > Your reasoning requires you to know that cigarettes are harmful and > there is a body of evidence for that, Exactly! So, you now see that your claim that the delivery channel that makes a decision as to what to deliver is amoral didn't resist scrutiny. Good. > yet there is no such body of evidence that all software covered by > non-GPL licenses is harmful, And that's how it should be, because, again, there are many Free Software licenses. GPL is better than others for various reasons, but this doesn't make other Free Software licenses unethical, immoral or harmful. You may want to have a look at especially the 5th paragraph of http://www.fsfla.org/svnwiki/circular/2007-078#1 But there is a body of evidence that software that is not Free is harmful. I wouldn't think this is a place where people would dispute this, even if they fail to resist such software themselves. > and > it's not up to a distributor to make that kind of value judgment. > They must respect the recipients right to make their own choices. Err... Sounds like you're saying "sure, go ahead and give the kids milk and cigarettes!" I hope you never work at the school my daughter attends :-) > by helping prevent a usable alternative you drive > people directly to the monster There's a faulty assumption in your reasoning. What do you assume is not usable about this 100% Free operating system I've installed on my computer? Heck, even wireless works. And then, it's not like I'd drive people to the monster. If they're already prisoners, they might remain so a bit longer (like a former prisoner in Brazil who wanted to return to prison because life out there was too painful. Serious!, it actually happened), or they might join us in developing and promoting replacements, such that fewer people end up deciding to give up their freedoms because it's too difficult. Besides, it doens't even make sense. How would my preference for offering people the option of choosing freedom lead them to the monster any more than not offering them this option would? (I do acknowledge that switching from say MS-Windows to say Ubuntu or Fedora is a step towards freedom, but if it comes along with the notion that the non-Free Software in there is not something that one should try to get rid of ASAP, then it not fails to help people achieve freedom, it actually becomes an impediment for them to do so, inasmuch as it replaces the dependency on one evil, the completely non-Free OS, for the dependency on another, the non-Free Software added to make the OS "usable") > even if it is with the pretense that you aren't involved at all. I don't understand what you're trying to communicate or imply here. Do you think this is just a matter of "I don't want to be a part of this?" My personal choice is just a small drop in the ocean. The moral imperative for me to promote the idea of freedom for all software users goes far beyond whatever individualism you might be trying to imply here. > These out-of-context speculations don't make any sense to me. Drivers under NDA aren't speculations. > What if there is only one such device and the binary driver works > perfectly and never needs a change? And you complain about *my* speculations? Heh... Show me one piece of proprietary software, and you'll have a piece of software that doesn't work perfectly for all its users, and that at least some users would like to be able to improve and/or fix it. It has been like that for me, for every single piece of non-Free Software I've ever used. Every one of them. And whoever ever met a perfect piece of software, and still held the same opinion about it 10 years later, please throw the first rock. > I don't have any different feelings about trusting a company to build > hardware than to supply software. Me neither, actually. Unfortunately, there's a significant difference between hardware and software: hardware may be quite difficult to get into to improve, because the facilities needed to build it are extremely expensive. This is beginning to change with FPGAs and home printers of circuits, but it's still going to be a while until all the limitations are artificial, as it is with software. > If they want to give away the materials needed to duplicate either, > great, but there is no moral difference related to the type of > component. Agreed. However, the practical difference makes the moral difference less urgent. >>> Agreed - it is a bad analogy. But so is freedom in terms of >>> restrictions on software. >> >> How about freedom of speech? Freedom to share? > Yes, that's the problem. If I write code that links to a GPL library > and to any other library, I can't share it, even with someone who > already has both other libraries. Who's stopping you from distributing the code? I take it you think it's the GPL, but it's not. Look for anything in the GPL that tells you you can't do that. You won't find it. You'll only find passages that say "you can distribute it, as long as it's all under the GPL". Then you gotta think what it is that stops you from distributing the other library under the GPL. There are three possible answers: 1. the other library is licensed to you in a way that grants you some permissions (and no prohibitions), but none of which are enough to clear you from the prohibitions established by copyright law that, by default, won't suffice to enable you distribute the library the way you know you otherwise could 2. you accepted the other library under technical restrictions (such as lack of source code) that prevent you from distributing it the way you otherwise could, even if you're not under any legal constraints that would prevent you from doing so 3. you accepted the other library under a contract that prohibits you from distributing it the way you otherwise could, even if the copyright license you got over the library would have been enough for you to do so So, in cases 1. and 2., you see it's copyright law that gets in your way. If it weren't for copyright law, you could just put the program and library together and distribute them under whatever terms you liked, regardless of what the GPL might say. In cases 2. and 3., it was your decision to accept giving up your freedoms that prevents you from distributing the program. Why do you think any of these are GPL's faults? > Please show an example of a non-GPL'd work where there has ever been a > copyright issue related to another original work being combined > (linking in the case of a library) where it was clear that every > instance involved the end user having his own licensed copy of both > parts. Such proprietary works are licensed under severe prohibitions. Nobody in their right mind would take the risk of trying to subvert the prohibitions. Now, maybe you're thinking of libraries for developers. Those are still licensed under severe prohibitions, and at a premium for you to be able to create your own derived works. What are you trying to show here? What we all already know, that non-Free Software is evil, so evil that developers simply stay away from it unless they buy "protection"? >>>> Unless you want to accept the unethical impositions from the copyright >>>> holders of the other work, and help them impose them on others (along >>>> with or separately from the GPLed work you'd like to combine with it), >>>> that's what you should do anyway. >>> I don't accept that the copyright holders of the other works >>> necessarily make unethical impositions. >> >> They don't necessarily make them. They choose to. > Who does? The copyright holders of the other works. They could choose not to make unethical impositions, but they choose to make them. >> It's their choice. > What choice? How do you determine that someone is harmed? I know I have been, and I don't see why any other software users would have been harmed any less. >> That, along with the fact that they're harmful, is what makes them >> unethical. > The GPL is harmful too. Only under your nonsensical theory that the GPL prohibits you from doing anything. But we've already seen that it's not the GPL that prohibits you, it's copyright law. And we've already agreed that current copyright law is harmful. > Take the case of the original BSD license. I did/do not consider its > requirement for attribution to be unethical. I do consider the > restriction of the GPL to not permit combinations with items covered > by this license to be harmful and thus unethical. Why did you change the wording from "requirement" to "restriction"? It appears to me that it's this different perception about the conditions of the two licenses that's driving you to the wrong conclusion as to what stops you from making the uses you'd like of GPLed software. > Likewise, I don't consider all commercial/proprietary distributions > to be unethical. Some provide good value for their terms. Slavery was also profitable to the slave owners and advantageous to those who purchased products at lower prices. This doesn't make it ethical, though. In fact, this reasoning has *zero* to do with ethics. Bringing more benefit than harm doesn't make something ethical. It's not bringing intentional harm that does. >> You're mistaken to boot. The restrictions are from copyright law, not >> the GPL. They didn't stop Microsoft, and I doubt they would have had >> a negative impact on Microsoft if they didn't exist. > You are speculating that in the absence of the GPL, no freely > redistributable code would exist. No, I think we're failing to communicate. Such speculation wouldn't even make sense, given that there was an existing body of Free Software before even the GNU project started, which preceded the creation of the GNU GPL. > So how does that work in the case of something like a blu-ray player? Don't even get me started on DRM :-) >>> The way to prevent problems is to lower the bar to building >>> competing alternatives that leave the choices up to the recipients. >> As in, more of a bad thing is a good thing? :-) > Absolutely. You aren't going to find perfection, so your best bet is > having choices among imperfect things. As people make those choices, > the bad ones go away. Only when there are good choices to make. Consider blu-ray, or even the existing DVD DRM. You just can't find a DVD player that isn't part of the conspiracy. You have the feeling that you have choice, but in reality you don't, because no matter what you pick, you always end up with the same deprivation. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From bnocera at redhat.com Mon Jun 16 16:57:45 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 16 Jun 2008 17:57:45 +0100 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: References: <1213608798.3254.10.camel@cookie.hadess.net> Message-ID: <1213635465.2988.13.camel@cookie.hadess.net> On Mon, 2008-06-16 at 09:27 -0500, Jason L Tibbitts III wrote: > >>>>> "BN" == Bastien Nocera writes: > > BN> Make the report less buggy and not show up reviews that have > BN> non-resolved dependencies. > > "less buggy" is certainly loaded language. The report shows tickets > in the "Package Review" component that have no 'fedora-review' flag > set. It does that. I'm not sure how that behavior is somehow > "buggy". > > In any case, that's certainly something to look it, but it's also > quite orthogonal, since it doesn't really cover the majority of the > tickets I'm looking at. Plus it's not really problematic to submit > several interdependent review tickets. I guess the report could > filter out reviews that are dependent on non-"Package Review" tickets, > but that still doesn't solve the main problem. > > I'm kind of surprised there's reluctance to add a component since we > add one for every single new package. Surely they're not a scarce > resource. My point is that you could fix the report rather than change anything about the workflow. From Jochen at herr-schmitt.de Mon Jun 16 17:33:35 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 16 Jun 2008 19:33:35 +0200 Subject: Searching Revier for inadyn-mt Message-ID: <4856A3EF.4070606@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, becouse inatech doesn't host the source for the inadyn programm, I have searched for a successor project which I have found on sourceforge.net. During the request for renaming the application, I have got the advice to start a new review for the successor application, so I have started the following review request: https://bugzilla.redhat.com/show_bug.cgi?id=441899 Unfortunately, I didn't found any reviewer until now, so I want to ask on this place, if anyone is willing to take this review request. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhWo+MACgkQT2AHK6txfgwz8gCfTnnVddzawkXiwKAEVJWph6yW MuAAn2rsbQ13/Di9pMp2T1OJvCYpyxjg =mEQi -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon Jun 16 17:40:42 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jun 2008 19:40:42 +0200 Subject: Fonts SIG wiki migration cleanup & changes Message-ID: <1213638043.28703.26.camel@rousalka.okg> Hi all, After 10 days of work and about 850 changes the Fonts SIG wiki is operationnal again. (I don't know mediawiki, so I won't claim to have been efficient). The cleanup was accompagned by restructuring to take into account differing moin/mediawiki capabilities and the fact some pages had become huge and monstruous over time. The SIG home page has been moved to http://fedoraproject.org/wiki/Category:Fonts_SIG The old SIG pipeline and wishlist pages have been split in per-font articles to be more manageable: http://fedoraproject.org/wiki/Category:Packaged_fonts http://fedoraproject.org/wiki/Category:Font_wishlist The new SIG workflow is to create a new page per font and change the page category as the font progresses in the packaging process. A documented font page template is provided to ease this workflow. http://fedoraproject.org/wiki/Font_description_template If you're the maintainer of a font package, or if you've added a font to the wishlist, please check the corresponding font page exists and is as complete as possible. I've nuked the old SIG member list. It was incomplete and not up to date. If you wish to register your interest in the SIG please just add the Fonts_SIG_members category to your homepage to get listed there. http://fedoraproject.org/wiki/Category:Fonts_SIG_members Using categories means you get nice dynamic self-maintaining indexes all over the place. I hope the end result is clear and pleasant and will motivate more people to work on the big font wishlist. Remember: http://fedoraproject.org/wiki/Fedora_10_fonts_packaging_call 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 tibbs at math.uh.edu Mon Jun 16 17:57:03 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 12:57:03 -0500 Subject: Proposal: bugzilla component for pre-review package development In-Reply-To: <1213635465.2988.13.camel@cookie.hadess.net> References: <1213608798.3254.10.camel@cookie.hadess.net> <1213635465.2988.13.camel@cookie.hadess.net> Message-ID: >>>>> "BN" == Bastien Nocera writes: BN> My point is that you could fix the report rather than change BN> anything about the workflow. I'm not trying to change the workflow. (At least not with this proposal.) Actually it's the opposite; I'm trying to avoid having to change the review workflow to work around people who want to use bugzilla to track their package development and yet put those packages in the 'Package Review' component. - J< From stickster at gmail.com Mon Jun 16 18:11:10 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 16 Jun 2008 14:11:10 -0400 Subject: Fedora 7 End of Life Message-ID: <1213639870.24439.123.camel@victoria> As announced earlier[1], Fedora 7 has reached its end of life for updates. Fedora 8 will continue to receive updates until approximately one month after the release of Fedora 10. = = = [1] http://www.redhat.com/archives/fedora-announce-list/2008-April/msg00013.html -------------- next part -------------- A 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 vpivaini at cs.helsinki.fi Mon Jun 16 19:30:43 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Mon, 16 Jun 2008 22:30:43 +0300 Subject: Finnish spell checking packages and comps In-Reply-To: <9339c38c0806160650u1ee6709es5fc2a2d22626311b@mail.gmail.com> References: <200806151932.47768.vpivaini@cs.helsinki.fi> <9339c38c0806160650u1ee6709es5fc2a2d22626311b@mail.gmail.com> Message-ID: <200806162230.45226.vpivaini@cs.helsinki.fi> Jesse Keating wrote: > > > Since these packages all seem extremely specific to Finnish, I don't > necessarily see a problem with just listing them in Finnish-support, > without any conditionals. Here's what I've done now: I've added enchant-voikko as default for F10 and as optional for F9 (because I wasn't sure if you can/should add any "default" stuff after the release). I've also added tmispell-voikko as optional for F8-F10. I noticed F8 comps doesn't have openoffice.org-voikko yet, but I wasn't sure if I can add 'openoffice.org-voikko' to a stable release and if adding it as optional would work at all, as it really needs openoffice. About hunspell: The main Voikko maintainer has added some discussion points about not using hunspell to . From what I have understood from mailing list discussions, switching to hunspell would in practice mean worse spell checking results, losing hyphenation support and not having the possibility of implementing a grammar checker in the near future. -- Ville-Pekka Vainio From lesmikesell at gmail.com Mon Jun 16 20:02:22 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 15:02:22 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> Message-ID: <4856C6CE.4020107@gmail.com> Alexandre Oliva wrote: > >> Yes, I agree that the initial author of a work has as much right to >> impose the harmful GPL as any other copyright holder has to choose a >> more or less restrictive license. I'm not so sure about additional >> contributors of original work who have this choice taken away in the >> GPL case only, though. > > Again, you're confused as to what the GPL does. It doesn't take any > such choice away. It's copyright law that does. But copyright law applies blindly and equally. Applying the GPL is a deliberate and harmful choice. > BTW, think of how > many proprietary licenses used for non-libraries you know that permit > the creation and distribution of derived works you might be interested > in creating. Just to put things in perspective. I can't think of any, and I'm not sure they would be legal if they tried. Wouldn't that be approximately the modchip scenario just ruled legal in the UK? http://www.theinquirer.net/gb/inquirer/news/2008/06/13/uk-courts-declare-modchips >> Having the choice to contribute under the GPL or not at all >> resembles that "your money or your life" scenario you presented >> earlier. > > Why do you dislike the idea of respecting others' freedoms just like > yours were respected? It is neither respect nor freedom to take away all the choices except the one you happen to like. >>>> if competitors were allowed to use components from Linux in >>>> commercial offerings > >>> They are. > >> Not in the general case. > > They are. As long as they respect others' freedoms, abiding by the > terms of the license, they can charge as much money as they like for > distributing, supporting, or offering any other service related with > the software, and run a successful commercial business. Why do you > think this is not the case? I think it's not the case because they can't include other works under different licenses or patents as is necessary for a general purpose OS. As for charging money, the GPL prohibits any additional restrictions on redistribution so your first customer can give copies away or undercut your prices (although Red Hat seems to ignore this part and attach contract restrictions to what they distribute anyway). >> It would be unfeasible if not technically impossible to ship a Linux >> based OS containing licensed copies of all the components needed to >> match the functionality of commercial OS versions. > > I'm sorry, I can't make sense of what you're trying to say here. It > appears that you're saying 'licensed copies' to refer to only > proprietary software, and 'commercial OS' as proprietary operating > system, but I wouldn't like to assume that's what you mean, because it > still renders the meaning of your full claim nonsensical. Can you > please try to rephrase what you wanted to say using different terms? There are patented components that people need and components where the best implementation is under someone else's copyright. A Linux distribution can never include those things as part of the kernel even if the end user is willing to pay any required license fee. The only scenario where this would be possible is if someone would buy unlimited rights for unrestricted distribution along with source. But there is no business model to fund such a process. >> Everyone involved may be perfectly happy to meet whatever those >> other restrictions might be, yet the GPL's harmful restrictions >> prevents the useful combination from being distributed. > > You're mistaken. It's copyright law that prevents it, and it's not > because of restrictions from the GPL, it's because of the other > restrictions "everyone may be perfectly happy to meet". Evidently not > everyone, since you're so unhappy about them that you're even trying > to shift the blame onto a license that doesn't prohibit you from doing > anything. I've explained that the GPL prevents me from sharing original work that links to both GPL and non-GPL libraries. Please stop say it doesn't prohibit me from doing that. >>> Your unsatisfaction with the situation is shared by me, but your >>> blaming the GPL for unfortunate (and at times unethical) choices made >>> by others is misguided. > >> How so? The harm isn't shared by less restrictive licenses. > > I think we're miscommunicating. Please try to describe a specific > situation and let's try to figure out what stops you from distributing > the (theoretical) combined work you'd like to distribute. OK, a real example from the past: the wattcp library provided a TCP/IP interface for DOS programs with a 'redistributable but not modifiable' license and an aspi library provided scsi device access, I think with a 'must keep attribution' type license. Both were free of charge and available in source. I took the gnutar program (at the time not understanding that it had usurped the pdtar original or the implications thereof), prototyped it to compile under 16-bit DOS and made it use some magic device names to access the archive either on scsi tape or remotely over the network via rsh to another machine. DOS provided no way to separate these processes so all the code was necessarily linked into one 'work as a whole'. I thought this was a generally useful tool and tried to give it away, but could not because of the GPL restrictions prohibiting combinations with other licenses. And please don't try to say the problem was cause by those other licenses - they did not prevent anyone else from getting copies, nor would it have been a problem if I had started with pdtar. It was strictly a harmful effect of the GPL restrictions that had been applied to the pdtar base. I won't argue that this was illegal but it was certainly harmful and thus immoral to do. >> But the concept of victim has a preconceived notion of harm, whereas >> meeting non-GPL terms may not cause harm at all. > > That's true. There are many other Free Software licenses. GPL is not > the only one. It's not even the only copyleft license. You are deliberately avoiding the point that there is proprietary software which is worth what it costs and where the money paid for it goes toward improvements. > Now, when you accept a license that deprives you from any of the four > essential freedoms, this harms you *and* everyone around. You're > shooting your own foot, but the shrapnel hurts others. No, you are just making this up. Show that it is true for every piece of software or admit it is an overgeneralization. >>> See? If my conviction you disputed above is wrong, then the person >>> who decides to distribute cigarettes to the kids instead of milk would >>> be behaving in accordance with moral and ethics. > >> Your reasoning requires you to know that cigarettes are harmful and >> there is a body of evidence for that, > > Exactly! So, you now see that your claim that the delivery channel > that makes a decision as to what to deliver is amoral didn't resist > scrutiny. Good. No, I'm saying you have jumped to unwarranted conclusions. >> yet there is no such body of evidence that all software covered by >> non-GPL licenses is harmful, > > And that's how it should be, because, again, there are many Free > Software licenses. GPL is better than others for various reasons, but > this doesn't make other Free Software licenses unethical, immoral or > harmful. You may want to have a look at especially the 5th paragraph > of http://www.fsfla.org/svnwiki/circular/2007-078#1 > > But there is a body of evidence that software that is not Free is > harmful. I wouldn't think this is a place where people would dispute > this, even if they fail to resist such software themselves. I dispute it, and would go so far as to say most free software has copied much of its design from commercial/proprietary work (generally a good thing!), and quite a lot was actually originally developed to be proprietary work and later had the free license applied. Far from being harmful, I'd say that without the proprietary works, free software would barely exist and would have much less chance of future development. There are all sorts of variations on this theme like the X consortium producing free software funded by proprietary vendors. >> and >> it's not up to a distributor to make that kind of value judgment. >> They must respect the recipients right to make their own choices. > > Err... Sounds like you're saying "sure, go ahead and give the kids > milk and cigarettes!" No, I'm saying that there is a difference between milk and cigarettes and you are the one not making the distinction correctly since you are making your decision based on the terms, not the inherent value of the product. >> by helping prevent a usable alternative you drive >> people directly to the monster > > There's a faulty assumption in your reasoning. What do you assume is > not usable about this 100% Free operating system I've installed on my > computer? Heck, even wireless works. Can you play Netflix online content? Do you have the optimal video drivers for all available hardware? Will your wireless work with all available hardware? Can you play dvds with what was included? > And then, it's not like I'd drive people to the monster. Ummm, where do you expect them to go? > Besides, it doens't even make sense. How would my preference for > offering people the option of choosing freedom lead them to the > monster any more than not offering them this option would? As a separate even more restricted option doesn't make a difference. The GPL keeping many choices impossible, does. > (I do acknowledge that switching from say MS-Windows to say Ubuntu or > Fedora is a step towards freedom, but if it comes along with the > notion that the non-Free Software in there is not something that one > should try to get rid of ASAP, then it not fails to help people > achieve freedom, it actually becomes an impediment for them to do so, > inasmuch as it replaces the dependency on one evil, the completely > non-Free OS, for the dependency on another, the non-Free Software > added to make the OS "usable") More unwarranted conclusions. >> even if it is with the pretense that you aren't involved at all. > > I don't understand what you're trying to communicate or imply here. > Do you think this is just a matter of "I don't want to be a part of > this?" Yes, justified by claims that everything that doesn't do it your way is evil. > My personal choice is just a small drop in the ocean. The > moral imperative for me to promote the idea of freedom for all > software users goes far beyond whatever individualism you might be > trying to imply here. Are you sure you only think this about software - or is this a general political statement? > Show me one piece of proprietary software, and you'll have a piece of > software that doesn't work perfectly for all its users, and that at > least some users would like to be able to improve and/or fix it. How is this morally different from hardware? I have at least as many problems with hardware but I don't demand that the hardware vendors give me a factory. > It > has been like that for me, for every single piece of non-Free Software > I've ever used. Every one of them. And whoever ever met a perfect > piece of software, and still held the same opinion about it 10 years > later, please throw the first rock. I've had an equal amount of trouble with free software and having source has not meant that I could fix it. >> I don't have any different feelings about trusting a company to build >> hardware than to supply software. > > Me neither, actually. Unfortunately, there's a significant difference > between hardware and software: hardware may be quite difficult to get > into to improve, because the facilities needed to build it are > extremely expensive. This is beginning to change with FPGAs and home > printers of circuits, but it's still going to be a while until all the > limitations are artificial, as it is with software. But there's not a moral difference, nor a more or less evil intent in using the same terms. >>>> Agreed - it is a bad analogy. But so is freedom in terms of >>>> restrictions on software. >>> How about freedom of speech? Freedom to share? > >> Yes, that's the problem. If I write code that links to a GPL library >> and to any other library, I can't share it, even with someone who >> already has both other libraries. > > Who's stopping you from distributing the code? I take it you think > it's the GPL, but it's not. Look for anything in the GPL that tells > you you can't do that. It says I can't do that. > You won't find it. You'll only find passages > that say "you can distribute it, as long as it's all under the GPL". Precisely, and I can't put it under the GPL if it uses any other components. And since I consider applying those restrictions to be harmful, I wouldn't anyway, given any other choice. > Then you gotta think what it is that stops you from distributing the > other library under the GPL. There are three possible answers: There are just as many answers as there are other licenses. And it is the GPL that takes away your freedom to mix these and share them. > 1. the other library is licensed to you in a way that grants you some > permissions (and no prohibitions), but none of which are enough to > clear you from the prohibitions established by copyright law that, by > default, won't suffice to enable you distribute the library the way > you know you otherwise could Yes, nothing wrong with that. > 2. you accepted the other library under technical restrictions (such > as lack of source code) that prevent you from distributing it the way > you otherwise could, even if you're not under any legal constraints > that would prevent you from doing so Yes, nothing wrong with that. > 3. you accepted the other library under a contract that prohibits you > from distributing it the way you otherwise could, even if the > copyright license you got over the library would have been enough for > you to do so Yes, nothing wrong with that. (Hmmm, that one sounds sort of like what you'd have to accept to get a copy of RHEL, doesn't it?) > So, in cases 1. and 2., you see it's copyright law that gets in your > way. If it weren't for copyright law, you could just put the program > and library together and distribute them under whatever terms you > liked, regardless of what the GPL might say. > > In cases 2. and 3., it was your decision to accept giving up your > freedoms that prevents you from distributing the program. > > Why do you think any of these are GPL's faults? Because those others don't prohibit combinations. >> Please show an example of a non-GPL'd work where there has ever been a >> copyright issue related to another original work being combined >> (linking in the case of a library) where it was clear that every >> instance involved the end user having his own licensed copy of both >> parts. > > Such proprietary works are licensed under severe prohibitions. Nobody > in their right mind would take the risk of trying to subvert the > prohibitions. There are no such prohibitions. The point of getting a proprietary library is to be able to link other code with it. >> The GPL is harmful too. > > Only under your nonsensical theory that the GPL prohibits you from > doing anything. But we've already seen that it's not the GPL that > prohibits you, it's copyright law. No, it is the restrictions in the GPL. >> Take the case of the original BSD license. I did/do not consider its >> requirement for attribution to be unethical. I do consider the >> restriction of the GPL to not permit combinations with items covered >> by this license to be harmful and thus unethical. > > Why did you change the wording from "requirement" to "restriction"? > It appears to me that it's this different perception about the > conditions of the two licenses that's driving you to the wrong > conclusion as to what stops you from making the uses you'd like of > GPLed software. My conclusion isn't wrong and it doesn't matter whether you call it a requirement or restriction. It is only the GPL restriction that harmfully prohibits combining differently licensed code, taking away the freedom of the recipient to choose if terms of those other licenses are acceptable or not. >> Likewise, I don't consider all commercial/proprietary distributions >> to be unethical. Some provide good value for their terms. > > Slavery was also profitable to the slave owners and advantageous to > those who purchased products at lower prices. So is normal employment - bad analogy. > This doesn't make it > ethical, though. In fact, this reasoning has *zero* to do with > ethics. Bringing more benefit than harm doesn't make something > ethical. It's not bringing intentional harm that does. Which is why applying the GPL is unethical. >> So how does that work in the case of something like a blu-ray player? > > Don't even get me started on DRM :-) You can't avoid it. I'd even say it has a place given that everyone involved knows that it devalues the product when applied. Without it, you'd have a hard time making a business model out of streaming content or low priced subscription/rental access to content with a restricted time to live. As a consumer I want those options, although I don't want any usage restrictions on anything sold to me in the guise of a product. >>> As in, more of a bad thing is a good thing? :-) > >> Absolutely. You aren't going to find perfection, so your best bet is >> having choices among imperfect things. As people make those choices, >> the bad ones go away. > > Only when there are good choices to make. Consider blu-ray, or even > the existing DVD DRM. You just can't find a DVD player that isn't > part of the conspiracy. If by conspiracy you mean legal/licensed terms for intellectual property, that is correct whether we like it or not. > You have the feeling that you have choice, > but in reality you don't, because no matter what you pick, you always > end up with the same deprivation. The choice is to participate according to the law and licensing terms (which may be acceptable) or not. If free software divisively prevents participation, users will only have the choice of staying with the monopoly. -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Mon Jun 16 20:43:30 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 16 Jun 2008 22:43:30 +0200 Subject: /bin/mail replacement (next generation of mailx) References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> Message-ID: On 2008-06-16, 12:48 GMT, Dmitry Butskoy wrote: > IMHO we should still use openssl (at least while openssh uses > it)... Does it? [viklef ~]$ ldd /usr/bin/ssh |grep ssl [viklef ~]$ ldd /usr/bin/ssh |grep nss libnss3.so => /lib/libnss3.so (0x002f6000) libnssutil3.so => /lib/libnssutil3.so (0x00697000) [viklef ~]$ Mat?j From ihok at hotmail.com Mon Jun 16 20:46:31 2008 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 16 Jun 2008 20:46:31 +0000 (UTC) Subject: firefox plans for F9? Message-ID: F9 is on a build of Firefox circa Beta 5. Any plans for upgrading that? From lmacken at redhat.com Mon Jun 16 20:55:26 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 16 Jun 2008 16:55:26 -0400 Subject: Fedora 7 End of Life In-Reply-To: <1213639870.24439.123.camel@victoria> References: <1213639870.24439.123.camel@victoria> Message-ID: <20080616205526.GE8300@x300.hsd1.ma.comcast.net> On Mon, Jun 16, 2008 at 02:11:10PM -0400, Paul W. Frields wrote: > As announced earlier[1], Fedora 7 has reached its end of life for > updates. Fedora 8 will continue to receive updates until approximately > one month after the release of Fedora 10. For those interested in shiny graphs, I generated some metrics for Fedora 7 updates, which can be found here: http://lewk.org/blog/f7-updates luke From timo.jyrinki at gmail.com Mon Jun 16 21:07:06 2008 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Tue, 17 Jun 2008 00:07:06 +0300 Subject: Finnish spell checking packages and comps In-Reply-To: <200806162230.45226.vpivaini@cs.helsinki.fi> References: <200806151932.47768.vpivaini@cs.helsinki.fi> <9339c38c0806160650u1ee6709es5fc2a2d22626311b@mail.gmail.com> <200806162230.45226.vpivaini@cs.helsinki.fi> Message-ID: <68da43e00806161407u391f100fm76a562d7dbe7593c@mail.gmail.com> Jesse Keating wrote: > I'd like to add that the nature of languages is such that there is no way to have "one spellchecking backend for them all", if the backend makes any assumptions of the languages. What Fedora has actually done, implementing enchant support from existing patches etc. is just what should be done too, as Enchant is an abstraction library that does not make too much assumptions. The only exceptions to Enchant usage are openoffice.org and mozilla products, which is why currently separate Voikko extensions will be provided for them. Regarding Mozilla for example, they just finished switching to hunspell instead of enchant, possibly also believing that it would solve spell-checking problems because hunspell's developers have relatively actively touted its features. Hunspell _is_ a very good thing for eg. Indo-European languages, bringing ispell/aspell/myspell hopefully to an end, but it cannot be expected to be flexible enough for all languages. The updated Voikko architecture page linked in Ville-Pekka's post explains a few problems, possibly the other Enchant users like Zemberek (Turkish) or hspell (Hebrew) would have more insight too. -Timo From a.badger at gmail.com Mon Jun 16 21:33:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 17:33:27 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <4850E95C.8040707@googlemail.com> References: <483F7FDA.9000701@gmail.com> <1212440334.3133.13.camel@choeger6> <1212455733.3057.26.camel@ignacio.lan> <6dvnh5x3h4.ln2@ppp1053.in.ipex.cz> <484D60D7.70100@gmail.com> <484FAF26.3090002@gmail.com> <4850E95C.8040707@googlemail.com> Message-ID: <4856DC27.7020809@gmail.com> > Outstanding issues I saw: > > * There are some corner cases around unicode handling. 2.6.x with > from __future__ does translation so string literals ("Hello World") > become type ``unicode`` instead of type ``str``. In 3.0, the > implementation of ``str`` is what ``unicode`` is, ``unicode`` no > longer exists, and ``byte`` is what ``str`` was. Most things that > returned ``str`` will now return ``unicode``. This will have issues > for: > > * Code that checks for unicode type will run on 2.6 but break on 3.x. > This includes things like to_unicode()/to_utf8() functions that > translate between encodings of unicode and the ``unicode`` type. * > Code that loads data from a file, the network, or other source > external to python *might* break since there's a variety of different > ways this code can decide to return the data and the behaviour will > likely change:: > > 2.x 3.x Evaluation str byte Should happen if no decoding > of the bytes is done in the library. Means that things like "print > (output)" will no longer work right as this is now a sequence of > bytes rather than a string. > > unicode str Should happen if the library converts bytes to unicode > type already. > > str str Should only happen if the library is updated to > convert from raw bytes to unicode. If it doesn't, it's a bug in the > library. > > unicode byte Should only happen if the library drops support for > converting from bytes to unicode. > > Note that there's been updates to file io that may help this: The > default encoding is now utf-8 instead of ascii and files that are > read using: my_file = open(filename, 'r') will yield unicode lines > translated from utf-8 while my_file =open(filename, 'rb') will yield > arrays of type ``byte``. > > * There are incompatible changes to the standard library for 3.x. > These changes will affect programs which make use of those modules. > (This can happen between 2.x releases as well, just to a different > extent). > > * Similar to the above point, there have been some changes to > __builtins__ for 3.x. This means that file() works in 2.6.x but not > in 3.x, for instance. Another one: dict.keys() no longer returns a key. This will break code like:: my_dict = {'one': 1, 'two': 2, 'three': 3} for key in my_dict: if key == 'three': del(my_dict[key]) In python-2.6 this will work because we'll be iterating over a temporary list of keys. In python-3.0, we'll be iterating over something that's tied into the state of the dictionary.. so del() will change the state and python will raise an exception. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From vonbrand at inf.utfsm.cl Mon Jun 16 22:04:34 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 16 Jun 2008 18:04:34 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856C6CE.4020107@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> Message-ID: <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Alexandre Oliva wrote: > >> Yes, I agree that the initial author of a work has as much right to > >> impose the harmful GPL as any other copyright holder has to choose a > >> more or less restrictive license. I'm not so sure about additional > >> contributors of original work who have this choice taken away in the > >> GPL case only, though. > > Again, you're confused as to what the GPL does. It doesn't take any > > such choice away. It's copyright law that does. > But copyright law applies blindly and equally. Applying the GPL is a > deliberate and harmful choice. Doesn't parse. [...] > >> Having the choice to contribute under the GPL or not at all > >> resembles that "your money or your life" scenario you presented > >> earlier. > > Why do you dislike the idea of respecting others' freedoms just like > > yours were respected? > It is neither respect nor freedom to take away all the choices except > the one you happen to like. It is not "taking away", it is /allowing/ you to do certain things you aren't automatically entitled to do. If it doesn't include everything you'd like, tough luck. If anything is "taking away" here, it is copyright law. > >>>> if competitors were allowed to use components from Linux in > >>>> commercial offerings > >>> They are. > >> Not in the general case. > > They are. As long as they respect others' freedoms, abiding by the > > terms of the license, they can charge as much money as they like for > > distributing, supporting, or offering any other service related with > > the software, and run a successful commercial business. Why do you > > think this is not the case? > I think it's not the case because they can't include other works under > different licenses or patents as is necessary for a general purpose > OS. Thanks for the hint! *Now* I'm seeing clearly that I have been deluded all these years, thinking I was running a general purpose OS on assorted machines here! How could I have been /so/ blind for /so/ long is quite beyond me... > As for charging money, the GPL prohibits any additional > restrictions on redistribution so your first customer can give copies > away or undercut your prices (although Red Hat seems to ignore this > part and attach contract restrictions to what they distribute anyway). Has always been thusly, and several companies built successful business around it anyway... > >> It would be unfeasible if not technically impossible to ship a Linux > >> based OS containing licensed copies of all the components needed to > >> match the functionality of commercial OS versions. Please define "functionality of commercial OS versions". In any case, MacOS (with its BSD core) does come awfully near if you mean closed source userland... And I do have a Linux based OS containing fully licensed copies of all the components needed to match (and in many areas, widely surpass) the functionality I require from a "commercial OS version". It's called "Fedora". > > I'm sorry, I can't make sense of what you're trying to say here. It > > appears that you're saying 'licensed copies' to refer to only > > proprietary software, and 'commercial OS' as proprietary operating > > system, but I wouldn't like to assume that's what you mean, because it > > still renders the meaning of your full claim nonsensical. Can you > > please try to rephrase what you wanted to say using different terms? > There are patented components that people need Such as? > and components where > the best implementation is under someone else's copyright. So what? The best implementation of a C compiler is under the FSF copyright, and I have a few others lying aound here who belong to other people, my preferred kernel is under the copyright of a bunch of weirdos who hack around for fun (and often even get paid to do it!), some awesome games are under the copyright of still other parties, ... > A Linux > distribution can never include those things as part of the kernel even > if the end user is willing to pay any required license fee. The only > scenario where this would be possible is if someone would buy > unlimited rights for unrestricted distribution along with source. But > there is no business model to fund such a process. Why do you insist that the kernel must use restricted stuff? Please note that the kernel does include patented algorithms (RCU for one) for which it does have your "impossible" unrestricted rights for unlimited distribution (under GPL). > >> Everyone involved may be perfectly happy to meet whatever those > >> other restrictions might be, yet the GPL's harmful restrictions > >> prevents the useful combination from being distributed. > > You're mistaken. It's copyright law that prevents it, and it's not > > because of restrictions from the GPL, it's because of the other > > restrictions "everyone may be perfectly happy to meet". Evidently not > > everyone, since you're so unhappy about them that you're even trying > > to shift the blame onto a license that doesn't prohibit you from doing > > anything. > I've explained that the GPL prevents me from sharing original work > that links to both GPL and non-GPL libraries. Please stop say it > doesn't prohibit me from doing that. Copyright law (and the restrictions placed on the "other parts" by their owners) restrict creating and distributing a GPLed whole, not GPL. You are saying that e.g. GPL prevents you from sharing a chimera made out of Windows pieces + Linux pieces. It is the /Microsoft/ license which prohibits you creating such a thing in the first place, and if it did, it would prohibit sharing at least the Windows part of it freely; that said monstrosity can't be shared "because of GPL" is quite off the point then. [...] > OK, a real example from the past: the wattcp library provided a > TCP/IP interface for DOS programs with a 'redistributable but not > modifiable' license and an aspi library provided scsi device access, I > think with a 'must keep attribution' type license. Both were free of > charge and available in source. I took the gnutar program (at the > time not understanding that it had usurped the pdtar original or the > implications thereof), prototyped it to compile under 16-bit DOS and > made it use some magic device names to access the archive either on > scsi tape or remotely over the network via rsh to another machine. > DOS provided no way to separate these processes so all the code was > necessarily linked into one 'work as a whole'. I thought this was a > generally useful tool and tried to give it away, but could not because > of the GPL restrictions prohibiting combinations with other licenses. > And please don't try to say the problem was cause by those other > licenses - they did not prevent anyone else from getting copies, nor > would it have been a problem if I had started with pdtar. It was > strictly a harmful effect of the GPL restrictions that had been > applied to the pdtar base. I won't argue that this was illegal but it > was certainly harmful and thus immoral to do. Great. You can't satisfy all three licenses, and it is solely the fault of GPL? [...] > I dispute it, and would go so far as to say most free software has > copied much of its design from commercial/proprietary work (generally > a good thing!), and quite a lot was actually originally developed to > be proprietary work and later had the free license applied. Far from > being harmful, I'd say that without the proprietary works, free > software would barely exist and would have much less chance of future > development. There are all sorts of variations on this theme like the > X consortium producing free software funded by proprietary vendors. Nonsense. Much of what the Internet is all about has always been "free software" (even its standards, the RFCs, do count in that direction). The propietary packages used over Internet mostly came later (or never). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From wolfy at nobugconsulting.ro Mon Jun 16 22:38:26 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 17 Jun 2008 01:38:26 +0300 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> Message-ID: <4856EB62.2010107@nobugconsulting.ro> On 06/16/2008 11:43 PM, Matej Cepl wrote: > On 2008-06-16, 12:48 GMT, Dmitry Butskoy wrote: > >> IMHO we should still use openssl (at least while openssh uses >> it)... >> > > Does it? > > [viklef ~]$ ldd /usr/bin/ssh |grep ssl > [viklef ~]$ ldd /usr/bin/ssh |grep nss > libnss3.so => /lib/libnss3.so (0x002f6000) > libnssutil3.so => /lib/libnssutil3.so (0x00697000) > [viklef ~]$ > > Mat?j > > could you please try "yum remove openssl" ? -- -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting srl http://www.brainbench.com/transcript.jsp?pid=40317 From ivazqueznet at gmail.com Mon Jun 16 22:47:32 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 16 Jun 2008 18:47:32 -0400 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <4856EB62.2010107@nobugconsulting.ro> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> <4856EB62.2010107@nobugconsulting.ro> Message-ID: <1213656453.10118.90.camel@ignacio.lan> On Tue, 2008-06-17 at 01:38 +0300, Manuel Wolfshant wrote: > On 06/16/2008 11:43 PM, Matej Cepl wrote: > > On 2008-06-16, 12:48 GMT, Dmitry Butskoy wrote: > > > >> IMHO we should still use openssl (at least while openssh uses > >> it)... > >> > > > > Does it? > > > > [viklef ~]$ ldd /usr/bin/ssh |grep ssl > > [viklef ~]$ ldd /usr/bin/ssh |grep nss > > libnss3.so => /lib/libnss3.so (0x002f6000) > > libnssutil3.so => /lib/libnssutil3.so (0x00697000) > > [viklef ~]$ > > > > Mat?j > > > > > could you please try "yum remove openssl" ? Or better yet: repoquery --whatrequires --alldeps openssl -- 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 kevin.kofler at chello.at Mon Jun 16 22:54:39 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 16 Jun 2008 22:54:39 +0000 (UTC) Subject: Finnish spell checking packages and comps References: <200806151932.47768.vpivaini@cs.helsinki.fi> <9339c38c0806160650u1ee6709es5fc2a2d22626311b@mail.gmail.com> <200806162230.45226.vpivaini@cs.helsinki.fi> <68da43e00806161407u391f100fm76a562d7dbe7593c@mail.gmail.com> Message-ID: Timo Jyrinki gmail.com> writes: > The only exceptions to Enchant usage are openoffice.org and mozilla > products, which is why currently separate Voikko extensions will be > provided for them. There's also the original KSpell interface in KDE 3 and the compatibility K3Spell class in KDE 4. Those expect an ispell-compatible command-line interface. It is possible to use tmispell for this purpose, and in fact I have a patch for that already, though not applied yet, but each new spellchecker has to be added separately (which I already did for hunspell). (Unfortunately, enchant's command line is not usable for this purpose at all.) Changing the code to use Enchant as a library instead of running command-line spellcheckers would be a significant effort for that legacy code, so it is unlikely to happen. The future of spellchecking in KDE is of course Sonnet (which was called KSpell2 in KDE 3), which already uses Enchant, but it will take time until all the applications are ported, if it ever completely happens. Kevin Kofler From cra at WPI.EDU Mon Jun 16 22:59:55 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 16 Jun 2008 18:59:55 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855EF91.10009@gmail.com> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> Message-ID: <20080616225955.GC10754@angus.ind.WPI.EDU> On Sun, Jun 15, 2008 at 11:44:01PM -0500, Les Mikesell wrote: > My point is that the details of the aggregation are irrelevant and the > format of the storage doesn't matter. The fact that the firmware loader > can find the correct chunk of data to load for each separate device shows > that the storage maintains the separation. Would you then agree that this is a correct statement: "My point is that the details of the aggregation are irrelevant and the format of the storage doesn't matter. The fact that the [dynamic linker ld.so] can find the correct chunk of data to load for [the shared library] shows that the storage maintains the separation." If not, why? From lesmikesell at gmail.com Mon Jun 16 23:34:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 18:34:44 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080616225955.GC10754@angus.ind.WPI.EDU> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> Message-ID: <4856F894.8030802@gmail.com> Chuck Anderson wrote: > On Sun, Jun 15, 2008 at 11:44:01PM -0500, Les Mikesell wrote: >> My point is that the details of the aggregation are irrelevant and the >> format of the storage doesn't matter. The fact that the firmware loader >> can find the correct chunk of data to load for each separate device shows >> that the storage maintains the separation. > > Would you then agree that this is a correct statement: > > "My point is that the details of the aggregation are irrelevant and > the format of the storage doesn't matter. The fact that the [dynamic > linker ld.so] can find the correct chunk of data to load for [the > shared library] shows that the storage maintains the separation." > > If not, why? That's correct as far as the "identifiable sections" go, but if you would read the COPYING file, you'd see that there are more requirements for the permitted aggregations: "not derived from the Program" "reasonably considered independent and separate works". Does a chunk of code obtained from someone else, used with other operating systems as well, and dropped into separate specific hardware seem to meet these? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jun 16 23:42:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 18:42:07 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> Message-ID: <4856FA4F.9020300@gmail.com> Horst H. von Brand wrote: > >>> Again, you're confused as to what the GPL does. It doesn't take any >>> such choice away. It's copyright law that does. > >> But copyright law applies blindly and equally. Applying the GPL is a >> deliberate and harmful choice. > > Doesn't parse. The GPL selectively removes your choices. It makes sense for a company selling services (like Red Hat) or companies that sell their own enhanced version of the product (mysql, ghostscript, etc.) to apply a restrictive license to prevent others from improving the product and offering it in competition. It doesn't make sense to prevent those improved versions from being available in the general case. >>>> It would be unfeasible if not technically impossible to ship a Linux >>>> based OS containing licensed copies of all the components needed to >>>> match the functionality of commercial OS versions. > > Please define "functionality of commercial OS versions". In any case, MacOS > (with its BSD core) does come awfully near if you mean closed source > userland... Anything you are willing to pay for. No arbitrary restrictions. Yes, Mac OS X is a reasonable option, but they don't have to distribute the source of their Nvida and ATI drivers, do they? > And I do have a Linux based OS containing fully licensed copies of all the > components needed to match (and in many areas, widely surpass) the > functionality I require from a "commercial OS version". It's called "Fedora". Can you use it to play Netflix online content? >> and components where >> the best implementation is under someone else's copyright. > > So what? The best implementation of a C compiler is under the FSF > copyright, and I have a few others lying aound here who belong to other > people, You conveniently omitted pointers to benchmarks against Intel or Sun's compilers. >> A Linux >> distribution can never include those things as part of the kernel even >> if the end user is willing to pay any required license fee. The only >> scenario where this would be possible is if someone would buy >> unlimited rights for unrestricted distribution along with source. But >> there is no business model to fund such a process. > > Why do you insist that the kernel must use restricted stuff? Why do you insist that people not be free to use whatever they choose? Even stuff like zfs that is available to everyone who wants it as a separate component but not combined with Linux? Or that the work done on Linux drivers not be available to someone who chooses to run OpenSolaris? What's the point of this divisiveness? > Please note > that the kernel does include patented algorithms (RCU for one) for which it > does have your "impossible" unrestricted rights for unlimited distribution > (under GPL). You are paraphrasing badly here. I specifically said it was possible but under conditions that don't seem likely for everything. >> I've explained that the GPL prevents me from sharing original work >> that links to both GPL and non-GPL libraries. Please stop say it >> doesn't prohibit me from doing that. > > Copyright law (and the restrictions placed on the "other parts" by their > owners) restrict creating and distributing a GPLed whole, not GPL. Yet it is only the GPL restriction that prevents people from being able to get the combined work. > You are saying that e.g. GPL prevents you from sharing a chimera made out > of Windows pieces + Linux pieces. Or OpenSolaris, or the original BSD, or any number of other less restrictive licenses. > It is the /Microsoft/ license which > prohibits you creating such a thing in the first place, No it isn't - there is much more code running on Microsoft libraries than anything else - but there is an exclusion for the standard system libraries in the GPL anyway. > and if it did, it > would prohibit sharing at least the Windows part of it freely; And plenty of people already have the Windows parts. > that said > monstrosity can't be shared "because of GPL" is quite off the point then. No it isn't, that is the point. > >> OK, a real example from the past: the wattcp library provided a >> TCP/IP interface for DOS programs with a 'redistributable but not >> modifiable' license and an aspi library provided scsi device access, I >> think with a 'must keep attribution' type license. Both were free of >> charge and available in source. I took the gnutar program (at the >> time not understanding that it had usurped the pdtar original or the >> implications thereof), prototyped it to compile under 16-bit DOS and >> made it use some magic device names to access the archive either on >> scsi tape or remotely over the network via rsh to another machine. >> DOS provided no way to separate these processes so all the code was >> necessarily linked into one 'work as a whole'. I thought this was a >> generally useful tool and tried to give it away, but could not because >> of the GPL restrictions prohibiting combinations with other licenses. >> And please don't try to say the problem was cause by those other >> licenses - they did not prevent anyone else from getting copies, nor >> would it have been a problem if I had started with pdtar. It was >> strictly a harmful effect of the GPL restrictions that had been >> applied to the pdtar base. I won't argue that this was illegal but it >> was certainly harmful and thus immoral to do. > > Great. You can't satisfy all three licenses, and it is solely the fault of > GPL? Yes, very specifically. If pdtar had not had the restrictive GPL applied to turn it into gnutar, there would have been no such restriction on redistributing a program that combined those components. How can there be any question about that? Or that the GPL harmfully prohibits all possible and similarly useful combinations? >> I dispute it, and would go so far as to say most free software has >> copied much of its design from commercial/proprietary work (generally >> a good thing!), and quite a lot was actually originally developed to >> be proprietary work and later had the free license applied. Far from >> being harmful, I'd say that without the proprietary works, free >> software would barely exist and would have much less chance of future >> development. There are all sorts of variations on this theme like the >> X consortium producing free software funded by proprietary vendors. > > Nonsense. Much of what the Internet is all about has always been "free > software" (even its standards, the RFCs, do count in that direction). The > propietary packages used over Internet mostly came later (or never). Believe what you want. I don't believe Linux would exist without the SysV interface to emulate nor *bsd without the AT&T unix the early versions extended, X without funding from proprietary vendors, NFS without Sun, OpenOffice without StarOffice, etc. etc.. To believe otherwise is just too farfetched. I guess sendmail, ftp, emacs and vi are free-software originals, though. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Mon Jun 16 23:44:15 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 Jun 2008 15:44:15 -0800 Subject: Someone please take over these packages In-Reply-To: References: <200806160918.13496.jwilson@redhat.com> <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> Message-ID: <604aa7910806161644w5a7ecfbdn79572592d10d044f@mail.gmail.com> On Mon, Jun 16, 2008 at 5:34 AM, Rex Dieter wrote: > I can help comaint numpy, got quite a number of local faculty here that use > that. FYI there is an upstream person... Jarrod Milkman... that I need to re-ping who wants to take over both numpy and scipy long term. We just have to get him through the sponsorship process. -jef From rdieter at math.unl.edu Mon Jun 16 23:56:57 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 16 Jun 2008 18:56:57 -0500 Subject: firefox plans for F9? References: Message-ID: Jack Tanner wrote: > F9 is on a build of Firefox circa Beta 5. Any plans for upgrading that? My magic 8 ball says: check again later. how about now? ok, of course so. it's just a matter of when... and maybe that's what you were really after. :) -- Rex From peter at thecodergeek.com Tue Jun 17 00:31:13 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 16 Jun 2008 17:31:13 -0700 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856FA4F.9020300@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> <4856FA4F.9020300@gmail.com> Message-ID: <1213662673.7667.8.camel@werewolf> On Mon, 2008-06-16 at 18:42 -0500, Les Mikesell wrote: > It makes sense for a company selling services[...] to apply a > restrictive license to prevent others from improving the product and > offering it in competition. What? The GPL doesn't prevent this. It *encourages* and *enables* it. Have you actually _read_ the GPL?... -- 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 poelstra at redhat.com Tue Jun 17 00:50:18 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 16 Jun 2008 20:50:18 -0400 Subject: Fedora Release Engineering Meeting Recap 2008-06-09 Message-ID: <48570A4A.6040805@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jun-09 Please make corrections and clarifications to the wiki page. == Misc Open Topics from F13== * edited up sign_unsigned and managed to get a lot of speed increase out of it * F10 schedule looks okay * spam filter plugin going into Fedora hopefully today so that we can try to reduce the spam in our project space even more == Source Control Management (SCM) == * Solely a requirements gathering phase--no specific SCM will be identified * ideas so far of things that would be good to have: ** script triggers pre/post commit actions ** able to reliably disseminate commits as they happen to a selected group of people (per package & branch) ** having acls/multiple owners for things is implied, but might need to be explicit ** better integration with our environment in general, pkgdb, bodhi, bugzilla, etc.. ** able to clone for disconnected development ** able to create new branches cheaply ** exploded source trees and quilt like patch management vs just simple patch files--ideally our new system would allow for both, depending on how the owner of the module decides to do it ** easy between-branch merging for those who like to ship the same source rpm everywhere ** not rely on magic 'branch' files for the build & tag-fu to work == Fedora ia64 == * ia64 is almost ready to do an F9 release * they need an updated fedora-release package that has their GPG key in it **Seth is working on a yum change that will allow a single RPM gpg file hold multiple keys, so that we can just append the ia64 key to the current file. ** also talking with the yum guys about a possible change to how yum handles gpg files ** more discussion needed == Hardware Update == * blade center was installed by mmcgrath last week, and we'll soon have a bunch more builders in koji == IRC Transcript == From smparrish at shallowcreek.net Tue Jun 17 01:00:43 2008 From: smparrish at shallowcreek.net (Steven Parrish) Date: Mon, 16 Jun 2008 21:00:43 -0400 Subject: Someone please take over these packages In-Reply-To: <200806160918.13496.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> Message-ID: I can take over conman and powerman. Steven Parrish On Mon, Jun 16, 2008 at 9:18 AM, Jarod Wilson wrote: > For a variety of reasons, I have to entirely give up involvement in a number > of packages. I've already tried to find new primary maintainers without > success, but I really can't justify any time spent on these packages any > longer, so I must orphan them ASAP, and hopefully, someone picks them up... > > emerald (compiz-fusion alternate windowing thingamajig) > emerald-themes (themes for the above) > ganglia (cluster monitoring software) > numpy (numerical python) > > I've also got the following packages for which I've yet to solicit new > maintainers for that I am also intending to orphan Real Soon Now: > > conman (console management software) > connect-proxy (helper to use ssh through socks/squid proxy) > dircproxy (detachable irc proxy) > powerman (power management software) > > I'll keep myself on the cc for bugzillas for all of the above, and will try to > help with any bugs filed, personal free time permitting. Most of these are > relatively low on time investment required to maintain them, but volume adds > up, particularly given that I only actually use two of these packages on any > sort of regular basis these days (conman and dircproxy). > > -- > Jarod Wilson > jwilson at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From bpepple at fedoraproject.org Tue Jun 17 01:01:19 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 16 Jun 2008 21:01:19 -0400 Subject: FESCo Meeting Summary for 2008-06-12 Message-ID: <1213664480.10154.4.camel@kennedy> = 2008 June 12 FESCo Meeting = == Members == === Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Tom Callaway (spot) * Christian Iseli (c4chris) * Josh Boyer (jwb) === Absent === * Christopher Aillon (caillon) == Summary == === New Sponsors === * FESCo has approved the sponsor requests for: ** Ignacio Vazquez-Abrams (ivazquez) ** Nicolas Mailhot (nim-nim) * Note: Voting was delayed for Remi Collet, Axel Thimm, and G?rard Milmeister, so that we could verify that they wished to be made sponsors. === FUDCon FESCo meeting === * Next week's (2008-06-19) FESCo meeting will be a conference call, providing the FUDCon facilities has a speaker phone. If not, it will be held on IRC as usual. === FESCo Role === * FESCo defined the broad scope of the responsibilities as follows: ** Features, Sponsors, Packaging and SIG Oversight, Handling/Enforcement of Maintainer Issues, and other technical matters related to the distribution and its construction. * Next week's meeting will start working on details. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-06-12.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: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Tue Jun 17 01:59:12 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 16 Jun 2008 20:59:12 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213662673.7667.8.camel@werewolf> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> <4856FA4F.9020300@gmail.com> <1213662673.7667.8.camel@werewolf> Message-ID: <48571A70.6020901@gmail.com> Peter Gordon wrote: > On Mon, 2008-06-16 at 18:42 -0500, Les Mikesell wrote: >> It makes sense for a company selling services[...] to apply a >> restrictive license to prevent others from improving the product and >> offering it in competition. > > What? The GPL doesn't prevent this. It *encourages* and *enables* it. > > Have you actually _read_ the GPL?... You mean where it says, for example, that Linux and OpenSolaris can share the best of their features? No, I missed that part. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Tue Jun 17 02:11:11 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jun 2008 07:41:11 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <48571A70.6020901@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> <4856FA4F.9020300@gmail.com> <1213662673.7667.8.camel@werewolf> <48571A70.6020901@gmail.com> Message-ID: <48571D3F.5080007@fedoraproject.org> Les Mikesell wrote: > Peter Gordon wrote: >> On Mon, 2008-06-16 at 18:42 -0500, Les Mikesell wrote: >>> It makes sense for a company selling services[...] to apply a >>> restrictive license to prevent others from improving the product and >>> offering it in competition. >> >> What? The GPL doesn't prevent this. It *encourages* and *enables* it. >> Have you actually _read_ the GPL?... > > You mean where it says, for example, that Linux and OpenSolaris can > share the best of their features? No, I missed that part. This seems to be just trolling. GPL is hardly specific to Linux kernel so I don't see why it would talk two such operating systems explicitly. The licenses are incompatible due to a deliberate choice. http://lists.debian.org/debian-devel-announce/2006/09/msg00002.html Even if the licenses are compatible, there are other technological/design differences in between these operating systems (at the kernel level) preventing that from happening easily which is actually the major issue compared to the license. Rahul From cmadams at hiwaay.net Tue Jun 17 03:09:25 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Jun 2008 22:09:25 -0500 Subject: /bin/mail replacement (next generation of mailx) In-Reply-To: <4856EB62.2010107@nobugconsulting.ro> References: <484FE10B.1050404@odu.neva.ru> <484FE9EB.5090301@odu.neva.ru> <28CF4638-72D2-4766-AA96-F56E2871B7F1@dev.intechnology.co.uk> <48566134.2040706@odu.neva.ru> <4856EB62.2010107@nobugconsulting.ro> Message-ID: <20080617030925.GB1390513@hiwaay.net> Once upon a time, Manuel Wolfshant said: > could you please try "yum remove openssl" ? Somehow, on F9, OpenSSH is linked against both OpenSSL (libcrypto) and NSS (libnss3). The dependency stack is still deep; "yum remove nss" and "yum remove openssl" would both remove yum, but only "yum remove nss" would remove rpm. It is still a work in progress, but I would say if you have a choice, use NSS, as that is the target and appears to be "more integral". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From peter at thecodergeek.com Tue Jun 17 03:12:52 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 16 Jun 2008 20:12:52 -0700 Subject: Fedora Freedom and linux-libre In-Reply-To: <48571A70.6020901@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <200806162204.m5GM4Yhn016924@laptop13.inf.utfsm.cl> <4856FA4F.9020300@gmail.com> <1213662673.7667.8.camel@werewolf> <48571A70.6020901@gmail.com> Message-ID: <1213672372.9568.1.camel@werewolf> On Mon, 2008-06-16 at 20:59 -0500, Les Mikesell wrote: > You mean where it says, for example, that Linux and OpenSolaris can > share the best of their features? No, I missed that part. Solaris is irrelevant here: Its license is not GPL-compatible. I'll refrain from further feeding your trolling though... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at miketc.com Tue Jun 17 06:15:32 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 17 Jun 2008 01:15:32 -0500 Subject: Meeting Summary emails Message-ID: <1213683332.21524.5.camel@scrappy.miketc.com> I don't know if this is relevant, or at least important or anything, but would it be worth creating/using a template to send out meeting summary emails so they follow the same procedure and easier to understand or something? Not that these aren't or that I am complaining, just something I thought of when I saw two email summaries and how different they were and thought I would bring it up in case others might have thought of it as well. Keep up the good work :) -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From rawhide at fedoraproject.org Tue Jun 17 09:28:24 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 17 Jun 2008 09:28:24 +0000 (UTC) Subject: rawhide report: 20080617 changes Message-ID: <20080617092824.4B35B209D18@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080616/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080617/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package elice Elice is a PureBasic to C++ translator / compiler New package libcanberra Portable Sound Event Library New package lua-lpeg Parsing Expression Grammars for Lua New package perl-Panotools-Script Panorama Tools scripting New package phonon Multimedia framework api New package pspp A program for statistical analysis of sampled data New package sound-theme-freedesktop freedesktop.org sound theme Removed package opyum Updated Packages: blobAndConquer-0.95-1.fc10 -------------------------- * Mon Jun 16 18:00:00 2008 Hans de Goede 0.95-1 - New upstream release 0.95 bouml-doc-4.3.2-1 ----------------- * Mon Jun 16 18:00:00 2008 Debarshi Ray - 4.3.2-1 - Version bump to 4.3.2. Closes Red Hat Bugzilla bug#445559. cairo-dock-1.6.0-0.2.svn1105_trunk.fc10 --------------------------------------- * Tue Jun 17 18:00:00 2008 Mamoru Tasaka - svn 1105 cleanfeed-0.95.7b-22.fc10 ------------------------- * Mon Jun 16 18:00:00 2008 Roman Rakus - 0.95.7b-22 - Added dist to release tag coreutils-6.12-4.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Ondrej Vasik - 6.12-4 - print verbose output of chcon with newline after each message (#451478) cpanspec-1.77-1.fc10 -------------------- * Mon Jun 16 18:00:00 2008 Steven Pritchard 1.77-1 - Update to 1.77. * Mon Jun 16 18:00:00 2008 Steven Pritchard 1.76-1 - Update to 1.76. crystal-clear-20050622-7.fc10 ----------------------------- * Sun Jun 15 18:00:00 2008 Chitlesh Goorah 20050622-7 - Bugfix 440851 FTBFS crystal-clear-20050622-6.fc8 - Expanding user base by removing requires: kdebase ettercap-0.7.3-26.fc10 ---------------------- * Mon Jun 16 18:00:00 2008 Jon Ciesla - 0.7.3-26 - Fix for mitm CPU util bug. evolution-2.23.4-1.fc10 ----------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 2.23.4-1.fc10 - Update to 2.23.4 - Remove patches for RH bug #449925 (fixed upstream). evolution-data-server-2.23.4-1.fc10 ----------------------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 3.23.4-1.fc10 - Update to 2.23.4 evolution-exchange-2.23.4-1.fc10 -------------------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 2.23.4-1.fc10 - Update to 2.23.4 evolution-sharp-0.17.4-1.fc10 ----------------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 0.17.4-1.fc10 - Update to 0.17.4. ez-ipupdate-3.0.11-0.19.b8.fc10 ------------------------------- * Mon Jun 16 18:00:00 2008 Jeff Layton - 3.0.11-0.19.b8 - compile with -D_FILE_OFFSET_BITS=64 so we can handle 64-bit inode numbers in stat() calls filezilla-3.0.11-1.fc10 ----------------------- * Mon Jun 16 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.11-1 - Update to 3.0.11 - Create patch for a shared tinyxml. - Add support for hicolor icons. freecol-0.7.4-1.fc10 -------------------- * Mon Jun 16 18:00:00 2008 Hans de Goede 0.7.4-1 - New upstream release 0.7.4 glib2-2.17.2-2.fc10 ------------------- * Mon Jun 16 18:00:00 2008 Matthias Clasen - 2.17.2-2 - Fix a directory ownership oversight gnome-python2-2.22.1-2.fc10 --------------------------- * Tue Jun 17 18:00:00 2008 Matthew Barnes - 2.22.1-2.fc10 - Fix directory ownership (RH bug #451754). * Mon Jun 16 18:00:00 2008 Matthew Barnes - 2.22.1-1.fc10 - Update to 2.22.1 gnome-python2-desktop-2.23.0-1.fc10 ----------------------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 2.23.0-1.fc10 - Update to 2.23.0. gnuradio-3.1.2-2.fc9 -------------------- * Tue Jun 10 18:00:00 2008 Marek Mahut - 3.1.2-2 - Moving usrp header files to usrp-devel (reported by Philip Balister) * Fri Apr 4 18:00:00 2008 Marek Mahut - 3.1.2-1 - Upstream release - Modification of gnuradio-3.1.2-gcc34.patch to the new release gprolog-1.3.0-17.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Jochen Schmitt 1.3.0-17 - Remove TRAILSZ and GLOBALSZ environment variables gresistor-0.0.1-12.fc10 ----------------------- * Mon Jun 16 18:00:00 2008 Chitlesh Goorah - 0.0.1-12 - Bugfix 440866 FTBFS gresistor-0.0.1-11.fc8 gsl-1.11-1.fc10 --------------- * Mon Jun 16 18:00:00 2008 Ivana Varekova - 1.11-1 - update to 1.11 gtkhtml3-3.23.4-1.fc10 ---------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 3.23.4-1.fc10 - Update to 3.23.4 gyachi-1.1.35-6.fc10 -------------------- * Mon Jun 16 18:00:00 2008 Gregory D Hosler - 1.1.35-6 - Made Alsa driver a plugin, added pulseaudio support as a plugin. - Disabled pulseaudio plugin for F7 kdelibs-4.0.82-1.fc10 --------------------- * Fri Jun 13 18:00:00 2008 Than Ngo 4.0.82-1 - 4.0.82 kernel-xen-2.6-2.6.26-0.1.rc6.git2.fc10 --------------------------------------- * Mon Jun 16 18:00:00 2008 Mark McLoughlin - Rebase to kernel-2_6_26-0_72_rc6_git2_fc10 lesstif-0.95.0-25.fc10 ---------------------- * Mon Jun 16 18:00:00 2008 Hans de Goede 0.95.0-25 - Fix PutPixel32 crashing on 64 bit (bz 437133) * Mon May 12 18:00:00 2008 Patrice Dumas 0.95.0-24 - remove the BuildRequires: libGLw-devel, it leads to circular build dependency with no gain libcmpiutil-0.4-1.fc10 ---------------------- libsoup-2.23.1-3.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Matthew Barnes - 2.23.1-3 - Incorporate package review feedback (RH bug #226046). * Sun May 4 18:00:00 2008 Matthias Clasen - 2.23.1-2 - Fix source url man-pages-ru-0.97-3.fc10 ------------------------ * Mon Jun 16 18:00:00 2008 Ivana Varekova - 0.97-3 - rebuild - change license tag mod_wsgi-1.3-4.fc10 ------------------- * Mon Jun 16 18:00:00 2008 Ricky Zhou 1.3-4 - Build against the shared python lib. notification-daemon-0.3.7.90-0.svn3009.fc10 ------------------------------------------- * Tue Jun 10 18:00:00 2008 Colin Walters -0.3.7.90-0.svn3009 - Update to SVN snapshot 3009 (patches below are against it) - BR gnome-common so we can autogen - Add positioning patch - Add patch to fix the dist - Edit libsexy patch to adapt to the fact we're using an SVN export - Drop upstreamed summary patch - Add some code in install to delete notification-properties crapplet - BR libglade2-devel patch-2.5.4-34.fc10 ------------------- * Mon Jun 16 18:00:00 2008 Tim Waugh 2.5.4-34 - Only write simple backups for each file once during a run (bug #234822). plt-scheme-4.0-3.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Gerard Milmeister - 1:4.0-2 - fix builds for different architectures * Sat Jun 14 18:00:00 2008 Gerard Milmeister - 1:4.0-1 - new release 4.0 plymouth-0.3.2-2.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Ray Strode - 0.3.2-2 - dont go back to text mode on exit * Mon Jun 16 18:00:00 2008 Ray Strode - 0.3.2-1 - Update to version 0.3.2 - show gradient in spinfinity plugin - Drop fade out in spinfinity plugin - fix throbber placement - rename graphical.so to default.so pychecker-0.8.17-5 ------------------ * Mon Jun 16 18:00:00 2008 Vitezslav Crhonek - 0.8.17-5 - Rebuild Resolves: #451375 python-inotify-0.8.0-1.q.fc10 ----------------------------- * Mon Jun 16 18:00:00 2008 Terje Rosten - 0.8.0-1.q - 0.8.0q - Update url, license and source url rhythmbox-0.11.5-15.fc10 ------------------------ * Mon Jun 16 18:00:00 2008 - Bastien Nocera - 0.11.5-15 - Avoid crash on new iPods (#451547) roundcubemail-0.2-2.alpha.fc10 ------------------------------ * Mon Jun 16 18:00:00 2008 Jon Ciesla = 0.2-2.alpha - osx files removed upstream. * Mon Jun 16 18:00:00 2008 Jon Ciesla = 0.2-1.alpha - Fixed php-xml, php-mbstring Requires. BZ 451652. - Removing osx files, will be pulled from next upstream release. rrdtool-1.3.0-1.fc10 -------------------- * Mon Jun 16 18:00:00 2008 Chris Ricker 1.3.0-1 - Update to rrdtool 1.3.0 rxvt-unicode-9.05-1.fc10 ------------------------ * Mon Jun 16 18:00:00 2008 Andreas Bierfert - 9.05-1 - version upgrade sonata-1.5.2-1.fc10 ------------------- * Mon Jun 16 18:00:00 2008 Micha?? Bentkowski - 1.5.2-1 - 1.5.2 tree-1.5.2-1.fc10 ----------------- * Mon Jun 16 18:00:00 2008 Tim Waugh 1.5.2-1 - 1.5.2. - Dropped no-colour patch. vavoom-1.28-1.fc10 ------------------ * Mon Jun 16 18:00:00 2008 Hans de Goede 1.28-1 - New upstream release 1.28 Summary: Added Packages: 7 Removed Packages: 1 Modified Packages: 44 Broken deps for i386 ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.i386 requires libtds.so.5 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 pygsl-0.9.1-8.fc9.i386 requires gsl = 0:1.10 pygsl-devel-0.9.1-8.fc9.i386 requires gsl-devel = 0:1.10 smart-0.52-54.fc9.i386 requires smart-config Broken deps for x86_64 ---------------------------------------------------------- freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx 1:libgda-freetds-3.1.2-3.fc9.x86_64 requires libtds.so.5()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 pygsl-0.9.1-8.fc9.x86_64 requires gsl = 0:1.10 pygsl-devel-0.9.1-8.fc9.i386 requires gsl-devel = 0:1.10 pygsl-devel-0.9.1-8.fc9.x86_64 requires gsl-devel = 0:1.10 smart-0.52-54.fc9.x86_64 requires smart-config Broken deps for ppc ---------------------------------------------------------- 1:libgda-freetds-3.1.2-3.fc9.ppc requires libtds.so.5 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 pygsl-0.9.1-8.fc9.ppc requires gsl = 0:1.10 pygsl-devel-0.9.1-8.fc9.ppc requires gsl-devel = 0:1.10 pygsl-devel-0.9.1-8.fc9.ppc64 requires gsl-devel = 0:1.10 smart-0.52-54.fc9.ppc requires smart-config Broken deps for ppc64 ---------------------------------------------------------- emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 1:libgda-freetds-3.1.2-3.fc9.ppc64 requires libtds.so.5()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot pygsl-0.9.1-8.fc9.ppc64 requires gsl = 0:1.10 pygsl-devel-0.9.1-8.fc9.ppc64 requires gsl-devel = 0:1.10 smart-0.52-54.fc9.ppc64 requires smart-config From stlwrt at gmail.com Tue Jun 17 10:16:20 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 17 Jun 2008 13:16:20 +0300 Subject: firefox plans for F9? In-Reply-To: References: Message-ID: Firefox3 final will be released today. http://www.spreadfirefox.com/en-US/worldrecord On Tue, Jun 17, 2008 at 2:56 AM, Rex Dieter wrote: > Jack Tanner wrote: > >> F9 is on a build of Firefox circa Beta 5. Any plans for upgrading that? > > My magic 8 ball says: check again later. > > how about now? > ok, of course so. it's just a matter of when... and maybe that's what you were really after. :) > > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From lvillani at binaryhelix.net Tue Jun 17 11:12:43 2008 From: lvillani at binaryhelix.net (Lorenzo Villani) Date: Tue, 17 Jun 2008 13:12:43 +0200 Subject: PPC/PPC64 builders not working? Message-ID: <20080617131243.fe18a507.lvillani@binaryhelix.net> It seems that the PPC/PPC64 builders are stucked with our chainbuild: http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 As far as I can tell, it has been at least 6-7 hours now that those builders are processing kdepimlibs build. Regards -- Lorenzo Villani _______________________________________ Fedora Ambassador Kexi Web Forms developer http://www.binaryhelix.net http://blog.binaryhelix.net From benny+usenet at amorsen.dk Tue Jun 17 11:22:18 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 17 Jun 2008 13:22:18 +0200 Subject: Fedora Freedom and linux-libre References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <200806160449.m5G4nTxS019826@laptop13.inf.utfsm.cl> Message-ID: "Horst H. von Brand" writes: > Nobody can initiate legal action "on behalf of the GPL", only the kernel > copyright holders could initiate such action here. And that would be > ROTFLed out of court, as /they themselves/ created the kernel with the > express, and widely documented, intention for it to be distributed widely. Are there really no pieces of the Linux kernel source written for purposes other than being part of the kernel, but afterwards included in the kernel? Pieces which are licensed under the GPL, that is, not firmware blobs. The authors of such pieces are able to initiate action against any distributors of the Linux kernel. It's the only way we can get a definite answer. (It's obviously not a very productive use of everyone's time and money, but that is often the case with lawsuits.) /Benny From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jun 17 11:37:35 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 17 Jun 2008 20:37:35 +0900 Subject: PPC/PPC64 builders not working? In-Reply-To: <20080617131243.fe18a507.lvillani@binaryhelix.net> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> Message-ID: <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> Lorenzo Villani wrote, at 06/17/2008 08:12 PM +9:00: > It seems that the PPC/PPC64 builders are stucked with our chainbuild: > http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 > > As far as I can tell, it has been at least 6-7 hours now that those > builders are processing kdepimlibs build. > > Regards For at least 5 days ppc/ppc64 builds are stacked when "dot" command (in graphviz) (or doxygen?) is called, see: https://www.redhat.com/archives/fedora-devel-list/2008-June/msg00719.html Also: http://koji.fedoraproject.org/koji/taskinfo?taskID=659366 http://koji.fedoraproject.org/koji/taskinfo?taskID=663323 ppc/ppc64 specific bug in graphviz (or doxygen?) Regards, Mamoru From dwmw2 at infradead.org Tue Jun 17 12:21:17 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 13:21:17 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856F894.8030802@gmail.com> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> Message-ID: <1213705277.26255.1025.camel@pmac.infradead.org> I wasn't going to argue with Les any more, but since he's reverted to what could almost be considered a direct untruth rather than his normal illogical and unparseable nonsense, I suppose I should point that out in case he manages to trick anyone with it. On Mon, 2008-06-16 at 18:34 -0500, Les Mikesell wrote: > if you would read the COPYING file, you'd see that there are more > requirements for the permitted aggregations: > "not derived from the Program" > "reasonably considered independent and separate works". It's somewhat misleading to refer to those as 'requirements for the permitted aggregations', because those phrases actually form part of the GPL's explicit description of the aggregations which are _not_ permitted. The GPL explicitly says that it _does_ apply to sections of a collective work which meet both of the above requirements -- sections that are both "not derived from the Program", and "can be reasonably considered independent and separate works in themselves. It's not an _actual_ untruth -- strictly speaking, they _are_ part of the requirements for the 'mere aggregation on a volume of a storage or distribution medium' exception. But only because they're also requirements for the stated restriction which the exception relaxes. Of course you can't be exempted from something that didn't apply in the first place, so that makes them requirements for the exception, too :) We have something like 'if A and B, then the GPL applies. Unless C'. Les is saying that 'A and B' are requirements for that exception. Which in a sense they are. But it's a bit of a disingenuous way to phrase it :) -- dwmw2 From limb at jcomserv.net Tue Jun 17 12:25:34 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 17 Jun 2008 07:25:34 -0500 (CDT) Subject: Someone please take over these packages In-Reply-To: <604aa7910806161644w5a7ecfbdn79572592d10d044f@mail.gmail.com> References: <200806160918.13496.jwilson@redhat.com> <19099.198.175.55.5.1213622577.squirrel@mail.jcomserv.net> <604aa7910806161644w5a7ecfbdn79572592d10d044f@mail.gmail.com> Message-ID: <2464.198.175.55.5.1213705534.squirrel@mail.jcomserv.net> > On Mon, Jun 16, 2008 at 5:34 AM, Rex Dieter wrote: >> I can help comaint numpy, got quite a number of local faculty here that >> use >> that. > > > FYI there is an upstream person... Jarrod Milkman... that I need to > re-ping who wants to take over both numpy and scipy long term. We just > have to get him through the sponsorship process. I will happily move to co-maintainer of numpy when that happens. Ping me at that time. > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lesmikesell at gmail.com Tue Jun 17 12:47:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 17 Jun 2008 07:47:36 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213705277.26255.1025.camel@pmac.infradead.org> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> Message-ID: <4857B268.9070800@gmail.com> David Woodhouse wrote: > I wasn't going to argue with Les any more, but since he's reverted to > what could almost be considered a direct untruth rather than his normal > illogical and unparseable nonsense, I suppose I should point that out in > case he manages to trick anyone with it. > > On Mon, 2008-06-16 at 18:34 -0500, Les Mikesell wrote: >> if you would read the COPYING file, you'd see that there are more >> requirements for the permitted aggregations: >> "not derived from the Program" >> "reasonably considered independent and separate works". > > It's somewhat misleading to refer to those as 'requirements for the > permitted aggregations', because those phrases actually form part of the > GPL's explicit description of the aggregations which are _not_ > permitted. As the rest of the sentence continues to say "then this License, and its terms, do not apply to those sections" I think you are one being misleading here. There is some room for disagreement on the separateness but not about whether aggregations are permitted when those specified conditions are met. Here's the whole thing in context since you seem to be incapable of finding it in the thousands of COPYING files you must have: "If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works." So, the only reasonable issue is whether something that originated elsewhere with its only purpose being to drop into specific separate pieces of hardware is 'separate', even though it is temporarily encoded into the same file as some GPL'd material. -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Tue Jun 17 13:22:15 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 14:22:15 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <4857B268.9070800@gmail.com> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> Message-ID: <1213708935.26255.1058.camel@pmac.infradead.org> On Tue, 2008-06-17 at 07:47 -0500, Les Mikesell wrote: > As the rest of the sentence continues to say "then this License, and its > terms, do not apply to those sections" I think you are one being > misleading here. There is some room for disagreement on the > separateness but not about whether aggregations are permitted when those > specified conditions are met. > > Here's the whole thing in context since you seem to be incapable of > finding it in the thousands of COPYING files you must have: > > "If identifiable sections of that work are not derived from the Program, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works." That part is a simple statement of copyright law. as a prelude to what comes next. As it says, the GPL doesn't even _apply_ to those parts when you distribute them separately. How could it? The GPL only operates by giving you back permissions which copyright law took from you -- and the GPL _cannot_ apply to those parts, when you distribute them as separate works. But you seem to have 'accidentally' cut out the next sentence of the same paragraph: "...as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." Or are you trying to make the incredible claim that in fact, the firmware embedded somewhere in a bzImage file -- where we can't even find it to extract it -- _is_ being distributed as a separate work, rather than as a part of a whole which is based on the kernel? If so, you would have to be _very_ deluded. That's almost as silly as the 'but we _like_ to use hex editors on our kernel, so we _are_ providing it in the preferred form for modification' defence. :) -- dwmw2 From anders at trudheim.co.uk Tue Jun 17 13:36:58 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Tue, 17 Jun 2008 15:36:58 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213708935.26255.1058.camel@pmac.infradead.org> References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> Message-ID: <20080617133658.GF328@localhost.localdomain> * David Woodhouse [20080617 15:22]: [snip] Sounds to me like the argument circles around some warped interpretations of the conundrum if a hamburger in a cardboard box is a piece of the box or if it in fact, is a hamburger that can be eaten separately without having to eat the box too... Enjoy! -- Anders From rdieter at math.unl.edu Tue Jun 17 13:37:46 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 17 Jun 2008 08:37:46 -0500 Subject: PPC/PPC64 builders not working? References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: > Lorenzo Villani wrote, at 06/17/2008 08:12 PM +9:00: >> It seems that the PPC/PPC64 builders are stucked with our chainbuild: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 >> >> As far as I can tell, it has been at least 6-7 hours now that those >> builders are processing kdepimlibs build. >> >> Regards > > For at least 5 days ppc/ppc64 builds are stacked when > "dot" command (in graphviz) (or doxygen?) is called, see: > > https://www.redhat.com/archives/fedora-devel-list/2008-June/msg00719.html > > Also: > http://koji.fedoraproject.org/koji/taskinfo?taskID=659366 > http://koji.fedoraproject.org/koji/taskinfo?taskID=663323 > > ppc/ppc64 specific bug in graphviz (or doxygen?) any bugs filed yet? -- Rex From dwmw2 at infradead.org Tue Jun 17 13:44:27 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 14:44:27 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080617133658.GF328@localhost.localdomain> References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <20080617133658.GF328@localhost.localdomain> Message-ID: <1213710267.26255.1064.camel@pmac.infradead.org> On Tue, 2008-06-17 at 15:36 +0200, Anders Karlsson wrote: > Sounds to me like the argument circles around some warped > interpretations of the conundrum if a hamburger in a cardboard box is > a piece of the box or if it in fact, is a hamburger that can be eaten > separately without having to eat the box too... The analogy is slightly closer if you say 'bun' instead of 'box'. You're _intended_ to eat it all together, as a single unit. That's why they're combined together like that. But even then it's not quite right, because you _could_ separate those two if you tried. It's more like the horrid icky relish crap that you try to scape off, but you never manage to remove all of it... :) -- dwmw2 From a.badger at gmail.com Tue Jun 17 13:47:17 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 17 Jun 2008 09:47:17 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080617133658.GF328@localhost.localdomain> References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <20080617133658.GF328@localhost.localdomain> Message-ID: <4857C065.7060100@gmail.com> Anders Karlsson wrote: > * David Woodhouse [20080617 15:22]: > [snip] > > Sounds to me like the argument circles around some warped > interpretations of the conundrum if a hamburger in a cardboard box is > a piece of the box or if it in fact, is a hamburger that can be eaten > separately without having to eat the box too... > No. It's more along the lines of having a cheeseburger with lettuce, tomatoes, and onions in a carboard box. The box is the medium in which the cheeseburger is distributed. But are the pieces inside merely aggregated together or are they part of a single work? After all, you can take the cheeseburger apart and consume the bun, the burger, the lettuce, etc separately (or not at all). But the person who prepared it and distributed it to you didn't intend for that to happen. -Toshio "who will go back to ignoring this thread now" Kuratomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From bdwheele at indiana.edu Tue Jun 17 14:01:36 2008 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 17 Jun 2008 10:01:36 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080617133658.GF328@localhost.localdomain> References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <20080617133658.GF328@localhost.localdomain> Message-ID: <1213711296.14357.18.camel@nibbler.dlib.indiana.edu> On Tue, 2008-06-17 at 15:36 +0200, Anders Karlsson wrote: > * David Woodhouse [20080617 15:22]: > [snip] > > Sounds to me like the argument circles around some warped > interpretations of the conundrum if a hamburger in a cardboard box is > a piece of the box or if it in fact, is a hamburger that can be eaten > separately without having to eat the box too... > Actually, the whole argument (and this thread) is more like a sh*t sandwich[1]. If there is really a legal problem with the kernel including firmware, it seems like it would be much better discussed on lkml, a -legal list somewhere, or somewhere in the FSF realm. I'll go back to lurking now Brian [1] Not to be confused with Spinal Tap's "Shark Sandwich" > Enjoy! > > -- > Anders > From maximilianbianco at gmail.com Tue Jun 17 14:20:53 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 17 Jun 2008 10:20:53 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4857C065.7060100@gmail.com> References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <20080617133658.GF328@localhost.localdomain> <4857C065.7060100@gmail.com> Message-ID: <4857C845.6020103@gmail.com> Toshio Kuratomi wrote: > Anders Karlsson wrote: >> * David Woodhouse [20080617 15:22]: >> [snip] >> >> Sounds to me like the argument circles around some warped >> interpretations of the conundrum if a hamburger in a cardboard box is >> a piece of the box or if it in fact, is a hamburger that can be eaten >> separately without having to eat the box too... >> > No. It's more along the lines of having a cheeseburger with lettuce, > tomatoes, and onions in a carboard box. The box is the medium in which > the cheeseburger is distributed. But are the pieces inside merely > aggregated together or are they part of a single work? After all, you > can take the cheeseburger apart and consume the bun, the burger, the > lettuce, etc separately (or not at all). But the person who prepared it > and distributed it to you didn't intend for that to happen. > > -Toshio "who will go back to ignoring this thread now" Kuratomi > Wouldn't you have to have not been ignoring this thread to make that statement? -- Fortune favors the BOLD From seg at haxxed.com Tue Jun 17 14:21:58 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 17 Jun 2008 09:21:58 -0500 Subject: PackageKit UI In-Reply-To: <45450.192.54.193.59.1213344474.squirrel@rousalka.dyndns.org> References: <1213268950.3505.1.camel@hughsie-work> <1213294373.8892.3.camel@rousalka.okg> <1213343617.3291.8.camel@hughsie-work> <45450.192.54.193.59.1213344474.squirrel@rousalka.dyndns.org> Message-ID: <1218b5bc0806170721k7b493ab9pe6eb9d6b3fa6688e@mail.gmail.com> On Fri, Jun 13, 2008 at 3:07 AM, Nicolas Mailhot < nicolas.mailhot at laposte.net> wrote: > > [1] http://www.packagekit.org/temp/gpk-application-multiple.png > > I think your main problem was the tabs gallore on the right side. It's > probably better to have just one column with information presented > sequentially in it Yes, since its presenting information and not UI, use a collapsible tree. Like say, Wireshark's packet information display. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Tue Jun 17 15:00:11 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 16:00:11 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> Message-ID: <1213714811.26255.1077.camel@pmac.infradead.org> On Tue, 2008-06-17 at 08:37 -0500, Rex Dieter wrote: > Mamoru Tasaka wrote: > > > Lorenzo Villani wrote, at 06/17/2008 08:12 PM +9:00: > >> It seems that the PPC/PPC64 builders are stucked with our chainbuild: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 > >> > >> As far as I can tell, it has been at least 6-7 hours now that those > >> builders are processing kdepimlibs build. > >> > >> Regards > > > > For at least 5 days ppc/ppc64 builds are stacked when > > "dot" command (in graphviz) (or doxygen?) is called, see: > > > > https://www.redhat.com/archives/fedora-devel-list/2008-June/msg00719.html > > > > Also: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=659366 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=663323 > > > > ppc/ppc64 specific bug in graphviz (or doxygen?) > > any bugs filed yet? Just taking a moment to add 'strace -f' to the doxygen invocation in the libburn specfile shows interesting behaviour... [pid 1268] execve("/usr/bin/dot", ["dot"..., "libburn_8h__incl.dot"..., "-Tpng"..., "-o"..., "libburn_8h__incl.png"...], [/* 31 vars */] .... [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- [pid 1268] rt_sigreturn(0x4) = 0 [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- [pid 1268] rt_sigreturn(0x4) = 0 [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- Did anyone even bother to file that bug yet? If not, how do you expect it to get fixed? I'm used to having to explain the basic mechanisms of "first you tell us about the bug, and only _then_ can we fix it" to the Great Unwashed on #fedora, but I kind of expect better from you lot :) -- dwmw2 From lesmikesell at gmail.com Tue Jun 17 14:52:00 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 17 Jun 2008 09:52:00 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213708935.26255.1058.camel@pmac.infradead.org> References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> Message-ID: <4857CF90.2090602@gmail.com> David Woodhouse wrote: > >> As the rest of the sentence continues to say "then this License, and its >> terms, do not apply to those sections" I think you are one being >> misleading here. There is some room for disagreement on the >> separateness but not about whether aggregations are permitted when those >> specified conditions are met. >> >> Here's the whole thing in context since you seem to be incapable of >> finding it in the thousands of COPYING files you must have: >> >> "If identifiable sections of that work are not derived from the Program, >> and can be reasonably considered independent and separate works in >> themselves, then this License, and its terms, do not apply to those >> sections when you distribute them as separate works." > > That part is a simple statement of copyright law. as a prelude to what > comes next. As it says, the GPL doesn't even _apply_ to those parts when > you distribute them separately. How could it? The GPL only operates by > giving you back permissions which copyright law took from you -- and the > GPL _cannot_ apply to those parts, when you distribute them as separate > works. > > But you seem to have 'accidentally' cut out the next sentence of the > same paragraph: No, if you meet the criteria above, the rest is irrelevant. > Or are you trying to make the incredible claim that in fact, the > firmware embedded somewhere in a bzImage file -- where we can't even > find it to extract it -- _is_ being distributed as a separate work, > rather than as a part of a whole which is based on the kernel? It doesn't say _you_ have to be able to extract it. In the context of a computer program, I can only interpret the terms "identifiable sections" and "separate" in terms of the computer's handling of the sections, and I have no doubt that the data sections where these chunks of data are stored are identifiable (or the devices wouldn't work) and they are separate things from the kernel program code or even data used in calculations. The fact that they are temporarily compressed into some particular format or other should not affect the copyright status of the parts any more than printing something in the same font or on the same page as something else would make them the same thing. > If so, you would have to be _very_ deluded. I'd admit there's room for interpretation here, but so far you haven't made much of an argument other than proximity for why firmware would be part of "the Program", or what attributes you think are required to establish separateness. > That's almost as silly as > the 'but we _like_ to use hex editors on our kernel, so we _are_ > providing it in the preferred form for modification' defence. :) If it's silly, then you shouldn't have any problem showing where it is executed as part of "the Program", or defining exactly why it isn't a separate section, or perhaps why proximity matters. But you haven't done any of that yet. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Tue Jun 17 15:11:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jun 2008 11:11:29 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213714811.26255.1077.camel@pmac.infradead.org> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> Message-ID: <1213715489.13481.0.camel@localhost.localdomain> On Tue, 2008-06-17 at 16:00 +0100, David Woodhouse wrote: > > Just taking a moment to add 'strace -f' to the doxygen invocation in the > libburn specfile shows interesting behaviour... > > [pid 1268] execve("/usr/bin/dot", ["dot"..., "libburn_8h__incl.dot"..., "-Tpng"..., "-o"..., "libburn_8h__incl.png"...], [/* 31 vars */] > .... > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > [pid 1268] rt_sigreturn(0x4) = 0 > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > [pid 1268] rt_sigreturn(0x4) = 0 > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > > Did anyone even bother to file that bug yet? > > If not, how do you expect it to get fixed? > > I'm used to having to explain the basic mechanisms of "first you tell us > about the bug, and only _then_ can we fix it" to the Great Unwashed on > #fedora, but I kind of expect better from you lot :) To be fair, it likely requires a ppc host to be able to investigate the problem to this level, and that's just not something everybody has sitting on their desk. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From k.georgiou at imperial.ac.uk Tue Jun 17 15:20:48 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Tue, 17 Jun 2008 16:20:48 +0100 Subject: Someone please take over these packages In-Reply-To: <200806160918.13496.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> Message-ID: <20080617152047.GA28554@imperial.ac.uk> On Mon, Jun 16, 2008 at 09:18:13AM -0400, Jarod Wilson wrote: > ganglia (cluster monitoring software) I can take ganglia if nobody else is interested. From dwmw2 at infradead.org Tue Jun 17 15:27:12 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 16:27:12 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213715489.13481.0.camel@localhost.localdomain> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> Message-ID: <1213716432.26255.1084.camel@pmac.infradead.org> On Tue, 2008-06-17 at 11:11 -0400, Jesse Keating wrote: > On Tue, 2008-06-17 at 16:00 +0100, David Woodhouse wrote: > > > > Just taking a moment to add 'strace -f' to the doxygen invocation in the > > libburn specfile shows interesting behaviour... > > > > [pid 1268] execve("/usr/bin/dot", ["dot"..., "libburn_8h__incl.dot"..., "-Tpng"..., "-o"..., "libburn_8h__incl.png"...], [/* 31 vars */] > > .... > > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > > [pid 1268] rt_sigreturn(0x4) = 0 > > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > > [pid 1268] rt_sigreturn(0x4) = 0 > > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > > > > Did anyone even bother to file that bug yet? > > > > If not, how do you expect it to get fixed? > > > > I'm used to having to explain the basic mechanisms of "first you tell us > > about the bug, and only _then_ can we fix it" to the Great Unwashed on > > #fedora, but I kind of expect better from you lot :) > > To be fair, it likely requires a ppc host to be able to investigate the > problem to this level, and that's just not something everybody has > sitting on their desk. I can't reproduce it on any of my machines -- the above is from adding 'strace -f' to the specfile, and trying a scratch build. I suspect it's either 64KiB pages, or something trying to use Altivec when it shouldn't. Probably the latter, given the nature of the problem. Will try to reproduce on the POWER5, although I think one of the routers between me and it is dead so I can't reach it at the moment. -- dwmw2 From kevin.kofler at chello.at Tue Jun 17 15:19:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 17 Jun 2008 15:19:12 +0000 (UTC) Subject: PPC/PPC64 builders not working? References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > To be fair, it likely requires a ppc host to be able to investigate the > problem to this level, and that's just not something everybody has > sitting on their desk. Right, and that's why PPC (and PPC64 even more so) should be a secondary arch. When the most mainstream "computer" with a PPC CPU is the PS3, you know you have a problem. ;-) PPC as a primary arch made sense when Macs used it, not anymore. (Hmmm, who decides what arches are primary? The Board? FESCo? Somebody else?) Kevin Kofler From than at redhat.com Tue Jun 17 15:30:01 2008 From: than at redhat.com (Than Ngo) Date: Tue, 17 Jun 2008 17:30:01 +0200 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213714811.26255.1077.camel@pmac.infradead.org> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <1213714811.26255.1077.camel@pmac.infradead.org> Message-ID: <200806171730.02054.than@redhat.com> Am Dienstag, 17. Juni 2008 17:00:11 schrieb David Woodhouse: > On Tue, 2008-06-17 at 08:37 -0500, Rex Dieter wrote: > > Mamoru Tasaka wrote: > > > Lorenzo Villani wrote, at 06/17/2008 08:12 PM +9:00: > > >> It seems that the PPC/PPC64 builders are stucked with our chainbuild: > > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 > > >> > > >> As far as I can tell, it has been at least 6-7 hours now that those > > >> builders are processing kdepimlibs build. > > >> > > >> Regards > > > > > > For at least 5 days ppc/ppc64 builds are stacked when > > > "dot" command (in graphviz) (or doxygen?) is called, see: > > > > > > https://www.redhat.com/archives/fedora-devel-list/2008-June/msg00719.ht > > >ml > > > > > > Also: > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=659366 > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=663323 > > > > > > ppc/ppc64 specific bug in graphviz (or doxygen?) > > > > any bugs filed yet? > > Just taking a moment to add 'strace -f' to the doxygen invocation in the > libburn specfile shows interesting behaviour... > > [pid 1268] execve("/usr/bin/dot", ["dot"..., "libburn_8h__incl.dot"..., > "-Tpng"..., "-o"..., "libburn_8h__incl.png"...], [/* 31 vars */] .... > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > [pid 1268] rt_sigreturn(0x4) = 0 > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > [pid 1268] rt_sigreturn(0x4) = 0 > [pid 1268] --- SIGILL (Illegal instruction) @ 0 (0) --- > > Did anyone even bother to file that bug yet? > > If not, how do you expect it to get fixed? > > I'm used to having to explain the basic mechanisms of "first you tell us > about the bug, and only _then_ can we fix it" to the Great Unwashed on > #fedora, but I kind of expect better from you lot :) the backtrace shows the problem in dot which is part of graphviz. Than From jkeating at redhat.com Tue Jun 17 15:30:06 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jun 2008 11:30:06 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213716432.26255.1084.camel@pmac.infradead.org> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1213716432.26255.1084.camel@pmac.infradead.org> Message-ID: <1213716606.13481.2.camel@localhost.localdomain> On Tue, 2008-06-17 at 16:27 +0100, David Woodhouse wrote: > I can't reproduce it on any of my machines -- the above is from adding > 'strace -f' to the specfile, and trying a scratch build. This trick should likely be documented somewhere in our wiki to aid people in trying to debug build failures. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jun 17 15:31:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jun 2008 11:31:26 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> Message-ID: <1213716686.13481.5.camel@localhost.localdomain> On Tue, 2008-06-17 at 15:19 +0000, Kevin Kofler wrote: > > Right, and that's why PPC (and PPC64 even more so) should be a secondary arch. > When the most mainstream "computer" with a PPC CPU is the PS3, you know you > have a problem. ;-) PPC as a primary arch made sense when Macs used it, not > anymore. > > (Hmmm, who decides what arches are primary? The Board? FESCo? Somebody else?) PPC is scheduled to become a Secondary arch when we actually have a successful Secondary Arch system. We don't have that right now, so we can't move PPC into that slot. ia64 is getting very close to doing their first release, with a somewhat by hand Secondary Arch effort, paving the way (along with sparc) for a more automated system that would finally allow us to move PPC over. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Jun 17 15:37:58 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 17 Jun 2008 11:37:58 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> Message-ID: <1213717078.2679.1.camel@truman> On Tue, 2008-06-17 at 15:19 +0000, Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > To be fair, it likely requires a ppc host to be able to investigate the > > problem to this level, and that's just not something everybody has > > sitting on their desk. > > Right, and that's why PPC (and PPC64 even more so) should be a secondary arch. > When the most mainstream "computer" with a PPC CPU is the PS3, you know you > have a problem. ;-) PPC as a primary arch made sense when Macs used it, not > anymore. > > (Hmmm, who decides what arches are primary? The Board? FESCo? Somebody else?) FESCo made the decision a while back that once another arch was up and running as a secondary arch, PPC would be moved from a primary to a secondary arch. 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: 197 bytes Desc: This is a digitally signed message part URL: From ihok at hotmail.com Tue Jun 17 15:39:33 2008 From: ihok at hotmail.com (Jack Tanner) Date: Tue, 17 Jun 2008 15:39:33 +0000 (UTC) Subject: firefox plans for F9? References: Message-ID: Pavel Shevchuk gmail.com> writes: > Firefox3 final will be released today. Right. That may or may not affect caillon's plans for actually importing it into F9. Rawhide Firefox is on a build from May 22nd, which has the comment "Revert to 2008-04-16 trunk." F9 Firefox is on a build from April 30th, which seems to be based on a code drop from April 2nd. Don't take this the wrong way, I'm not trying to be a n00b pining for the latest and shiniest, and I don't mean to imply that caillon is somehow not doing his job. No doubt there are legitimate reasons for the divergence from trunk and for the lack of updates as of late. I just want to know what the plans are for Firefox in F9. From dwmw2 at infradead.org Tue Jun 17 15:32:08 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 16:32:08 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: <200806171730.02054.than@redhat.com> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <1213714811.26255.1077.camel@pmac.infradead.org> <200806171730.02054.than@redhat.com> Message-ID: <1213716728.26255.1086.camel@pmac.infradead.org> On Tue, 2008-06-17 at 17:30 +0200, Than Ngo wrote: > the backtrace shows the problem in dot which is part of graphviz. You have a backtrace? Can you show me, please? On what machine did you obtain that? -- dwmw2 From seg at haxxed.com Tue Jun 17 16:02:21 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 17 Jun 2008 11:02:21 -0500 Subject: PPC/PPC64 builders not working? In-Reply-To: References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> Message-ID: <1218b5bc0806170902x3e64f09cnc48dccbbb003fe61@mail.gmail.com> On Tue, Jun 17, 2008 at 10:19 AM, Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > To be fair, it likely requires a ppc host to be able to investigate the > > problem to this level, and that's just not something everybody has > > sitting on their desk. > > Right, and that's why PPC (and PPC64 even more so) should be a secondary > arch. > When the most mainstream "computer" with a PPC CPU is the PS3, you know you > have a problem. ;-) PPC as a primary arch made sense when Macs used it, not > anymore. I've not the time to dig up numbers, but I'd be willing to bet that the Xbox 360, PS3, and Nintendo Wii, all PPC based, have together sold more units in the few years they've existed than PPC Mac's Apple has sold in its entire history. For extra points add the Game Cube in as well, it was PPC based too. There's an immense installed base of brand new, (As in, not obsolete) PPC machines out there, although we're only officially allowed to run on the PS3 so far. It is rather shortsighted to discount this market. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Tue Jun 17 16:03:24 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 17 Jun 2008 12:03:24 -0400 Subject: Someone please take over these packages In-Reply-To: References: <200806160918.13496.jwilson@redhat.com> Message-ID: <200806171203.24965.jwilson@redhat.com> On Monday 16 June 2008 09:00:43 pm Steven Parrish wrote: > I can take over conman and powerman. Excellent, thanks much. Nothing to report in the way of any open bugs or impending releases, I already pushed and built powerman 2.0 a few weeks ago (iirc). > On Mon, Jun 16, 2008 at 9:18 AM, Jarod Wilson wrote: > > For a variety of reasons, I have to entirely give up involvement in a > > number of packages. I've already tried to find new primary maintainers > > without success, but I really can't justify any time spent on these > > packages any longer, so I must orphan them ASAP, and hopefully, someone > > picks them up... > > > > emerald (compiz-fusion alternate windowing thingamajig) > > emerald-themes (themes for the above) > > ganglia (cluster monitoring software) > > numpy (numerical python) > > > > I've also got the following packages for which I've yet to solicit new > > maintainers for that I am also intending to orphan Real Soon Now: > > > > conman (console management software) > > connect-proxy (helper to use ssh through socks/squid proxy) > > dircproxy (detachable irc proxy) > > powerman (power management software) > > > > I'll keep myself on the cc for bugzillas for all of the above, and will > > try to help with any bugs filed, personal free time permitting. Most of > > these are relatively low on time investment required to maintain them, > > but volume adds up, particularly given that I only actually use two of > > these packages on any sort of regular basis these days (conman and > > dircproxy). -- Jarod Wilson jwilson at redhat.com From kevin at scrye.com Tue Jun 17 16:14:10 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 17 Jun 2008 10:14:10 -0600 Subject: Someone please take over these packages In-Reply-To: <200806160918.13496.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> Message-ID: <20080617101410.33390171@ohm.scrye.com> On Mon, 16 Jun 2008 09:18:13 -0400 jwilson at redhat.com (Jarod Wilson) wrote: > For a variety of reasons, I have to entirely give up involvement in a > number of packages. I've already tried to find new primary > maintainers without success, but I really can't justify any time > spent on these packages any longer, so I must orphan them ASAP, and > hopefully, someone picks them up... > > emerald (compiz-fusion alternate windowing thingamajig) > emerald-themes (themes for the above) > ganglia (cluster monitoring software) > numpy (numerical python) > > I've also got the following packages for which I've yet to solicit > new maintainers for that I am also intending to orphan Real Soon Now: > > conman (console management software) > connect-proxy (helper to use ssh through socks/squid proxy) > dircproxy (detachable irc proxy) > powerman (power management software) > > I'll keep myself on the cc for bugzillas for all of the above, and > will try to help with any bugs filed, personal free time permitting. > Most of these are relatively low on time investment required to > maintain them, but volume adds up, particularly given that I only > actually use two of these packages on any sort of regular basis these > days (conman and dircproxy). I can take dircproxy, since I use it all the time... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jwilson at redhat.com Tue Jun 17 16:02:00 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 17 Jun 2008 12:02:00 -0400 Subject: Someone please take over these packages In-Reply-To: <20080617152047.GA28554@imperial.ac.uk> References: <200806160918.13496.jwilson@redhat.com> <20080617152047.GA28554@imperial.ac.uk> Message-ID: <200806171202.00316.jwilson@redhat.com> On Tuesday 17 June 2008 11:20:48 am Kostas Georgiou wrote: > On Mon, Jun 16, 2008 at 09:18:13AM -0400, Jarod Wilson wrote: > > ganglia (cluster monitoring software) > > I can take ganglia if nobody else is interested. Its all yours! The only real thing to note with ganglia is that a 3.1.0 release is coming Real Soon Now, and a pre-release snap has already been built in rawhide. Looks like an RC1 snap might be posted this week. -- Jarod Wilson jwilson at redhat.com From dwmw2 at infradead.org Tue Jun 17 16:36:06 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 17:36:06 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213716606.13481.2.camel@localhost.localdomain> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1213716432.26255.1084.camel@pmac.infradead.org> <1213716606.13481.2.camel@localhost.localdomain> Message-ID: <1213720566.26255.1092.camel@pmac.infradead.org> On Tue, 2008-06-17 at 11:30 -0400, Jesse Keating wrote: > On Tue, 2008-06-17 at 16:27 +0100, David Woodhouse wrote: > > I can't reproduce it on any of my machines -- the above is from > adding > > 'strace -f' to the specfile, and trying a scratch build. > > This trick should likely be documented somewhere in our wiki to aid > people in trying to debug build failures. Perhaps. Along with crap like this... @@ -49,9 +50,20 @@ features from the command line. %build %configure --disable-static -make %{?_smp_mflags} -doxygen doc/doxygen.conf - +#make %{?_smp_mflags} +expect < References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1218b5bc0806170902x3e64f09cnc48dccbbb003fe61@mail.gmail.com> Message-ID: <20080617125734.4bf349d7@vader.jdub.homelinux.org> On Tue, 17 Jun 2008 11:02:21 -0500 "Callum Lerwick" wrote: > On Tue, Jun 17, 2008 at 10:19 AM, Kevin Kofler > wrote: > > > Jesse Keating redhat.com> writes: > > > To be fair, it likely requires a ppc host to be able to investigate the > > > problem to this level, and that's just not something everybody has > > > sitting on their desk. > > > > Right, and that's why PPC (and PPC64 even more so) should be a secondary > > arch. > > When the most mainstream "computer" with a PPC CPU is the PS3, you know you > > have a problem. ;-) PPC as a primary arch made sense when Macs used it, not > > anymore. > > > I've not the time to dig up numbers, but I'd be willing to bet that the Xbox > 360, PS3, and Nintendo Wii, all PPC based, have together sold more units in > the few years they've existed than PPC Mac's Apple has sold in its entire > history. For extra points add the Game Cube in as well, it was PPC based > too. > > There's an immense installed base of brand new, (As in, not obsolete) PPC > machines out there, although we're only officially allowed to run on the PS3 > so far. It is rather shortsighted to discount this market. F8 and F9 both run on the PS3. I have no idea what you mean by "officially allowed." Sony even gives you the option to install another OS in their game firmware... josh From bos at serpentine.com Tue Jun 17 17:07:28 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 17 Jun 2008 10:07:28 -0700 Subject: Reviewer needed for haddock09 Message-ID: The latest, greatest version of GHC, the Glasgow Haskell Compiler, is set to be released within the next few days. I've got a spec file ready to build it with, save for one thing: the current version of Haddock (Haskell documentation extractor tool) doesn't work with it. I've revived an older, compatible version of Haddock as the haddock09 package. This is almost exactly the same package that we used to ship in the Fedora 7 era. The package needs no special Haskell expertise to review, and it will shortly block my ability to update GHC. If some kind soul would be willing to do a quick review on it, I'll gladly return the favour. https://bugzilla.redhat.com/show_bug.cgi?id=451142 Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Tue Jun 17 17:11:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jun 2008 13:11:28 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: <20080617125734.4bf349d7@vader.jdub.homelinux.org> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1218b5bc0806170902x3e64f09cnc48dccbbb003fe61@mail.gmail.com> <20080617125734.4bf349d7@vader.jdub.homelinux.org> Message-ID: <1213722688.13481.7.camel@localhost.localdomain> On Tue, 2008-06-17 at 12:57 -0400, Josh Boyer wrote: > F8 and F9 both run on the PS3. I have no idea what you mean by > "officially allowed." Sony even gives you the option to install > another OS in their game firmware... The PS3 is the only one where running another OS is allowed/encouraged. The other platforms you have to actually work hard to get something else on it, and you break the warranty along the way. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Tue Jun 17 17:20:13 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 17 Jun 2008 13:20:13 -0400 Subject: firefox plans for F9? In-Reply-To: References: Message-ID: <4857F24D.40109@redhat.com> Jack Tanner wrote: > F9 is on a build of Firefox circa Beta 5. Any plans for upgrading that? > Yes. F-9 builds are in progress. From jkeating at redhat.com Tue Jun 17 17:56:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jun 2008 13:56:59 -0400 Subject: Upcoming kernel build Message-ID: <1213725419.13481.25.camel@localhost.localdomain> We're doing something a little special for the next rawhide kernel. There is an ongoing bug regarding gcc and compiling the kernel, which leads to ext3 failures. https://bugzilla.redhat.com/show_bug.cgi?id=451068 In order to have a working kernel, but not make gcc go backwards by untagging it while the gcc folks are working out a fix, I've created a special buildroot to put the old gcc back into service so that we can build the kernel and move beyond the ext3 issues. This will be a short lived buildroot, only used by the kernel, so that we have something working for the next few days (somewhat critical given FUDCon). This is not something we normally do, but I wanted to announce it up front so that everybody knows whats going on. Cheers! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Tue Jun 17 18:00:25 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 19:00:25 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213720566.26255.1092.camel@pmac.infradead.org> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1213716432.26255.1084.camel@pmac.infradead.org> <1213716606.13481.2.camel@localhost.localdomain> <1213720566.26255.1092.camel@pmac.infradead.org> Message-ID: <1213725625.26255.1108.camel@pmac.infradead.org> On Tue, 2008-06-17 at 17:36 +0100, David Woodhouse wrote: > On Tue, 2008-06-17 at 11:30 -0400, Jesse Keating wrote: > > On Tue, 2008-06-17 at 16:27 +0100, David Woodhouse wrote: > > > I can't reproduce it on any of my machines -- the above is from > > adding > > > 'strace -f' to the specfile, and trying a scratch build. > > > > This trick should likely be documented somewhere in our wiki to aid > > people in trying to debug build failures. > > Perhaps. Along with crap like this... > > @@ -49,9 +50,20 @@ features from the command line. > > %build > %configure --disable-static > -make %{?_smp_mflags} > -doxygen doc/doxygen.conf > - > +#make %{?_smp_mflags} > +expect < +spawn gdb --args doxygen doc/doxygen.conf > +expect "(gdb)" > +send "set pagination off\n" > +expect "(gdb)" > +send "set follow-fork-mode child\n" > +expect "(gdb)" > +send "run\n" > +expect "(gdb)" > +send "bt\n" > +expect (gdb) > +send "quit\n" > +EOF > Which leads to this.... Program received signal SIGILL, Illegal instruction. [Switching to process 3824] 0x0f425434 in ?? () from /usr/lib/libpixman-1.so.0 Missing separate debuginfos, use: debuginfo-install graphviz.ppc (gdb) bt #0 0x0f425434 in ?? () from /usr/lib/libpixman-1.so.0 ... which in turn leads to https://bugzilla.redhat.com/show_bug.cgi?id=451831 No hardware access required :) -- dwmw2 From davej at redhat.com Tue Jun 17 18:11:28 2008 From: davej at redhat.com (Dave Jones) Date: Tue, 17 Jun 2008 14:11:28 -0400 Subject: incoming potential breakage in rawhide. Message-ID: <20080617181128.GA13192@redhat.com> Tomorrows rawhide enables something we've been saying "Hey, we should do that" for about 3-4 releases now. By default, booting up will enable glibc's malloc perturbing. * Apps that expect allocated memory to be zeroed which are calling malloc() instead of calloc() will break. * Apps using memory after it's been free()'d will break. All somewhat akin to the alloc debugging we enable in the kernel each rawhide. This will cause currently silent bugs to make apps abort() instead. There's slight performance overhead, but hey, it's rawhide, we'll turn it off again later. You'll be able to turn it off in /etc/sysconfig/mcheck But, if stuff starts breaking left and right for you, don't just disable this, please file bugs! There's one known bug which has been outstanding for a while, which is guaranteed to hit any fedora committer using x86-64. 'make upload' causes curl to break.. https://bugzilla.redhat.com/show_bug.cgi?id=429175 Hopefully we can finally get this fixed this release. Dave -- http://www.codemonkey.org.uk From jwboyer at gmail.com Tue Jun 17 18:33:35 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 17 Jun 2008 14:33:35 -0400 Subject: PPC/PPC64 builders not working? In-Reply-To: <1213722688.13481.7.camel@localhost.localdomain> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> <4857A1FF.2070602@ioa.s.u-tokyo.ac.jp> <1213714811.26255.1077.camel@pmac.infradead.org> <1213715489.13481.0.camel@localhost.localdomain> <1218b5bc0806170902x3e64f09cnc48dccbbb003fe61@mail.gmail.com> <20080617125734.4bf349d7@vader.jdub.homelinux.org> <1213722688.13481.7.camel@localhost.localdomain> Message-ID: <20080617143335.10a155a8@vader.jdub.homelinux.org> On Tue, 17 Jun 2008 13:11:28 -0400 Jesse Keating wrote: > On Tue, 2008-06-17 at 12:57 -0400, Josh Boyer wrote: > > F8 and F9 both run on the PS3. I have no idea what you mean by > > "officially allowed." Sony even gives you the option to install > > another OS in their game firmware... > > The PS3 is the only one where running another OS is allowed/encouraged. > The other platforms you have to actually work hard to get something else > on it, and you break the warranty along the way. Oh, I totally mis-read what Callum wrote. Ok, back to me being stupid. josh From jwilson at redhat.com Tue Jun 17 18:59:59 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 17 Jun 2008 14:59:59 -0400 Subject: Someone please take over these packages In-Reply-To: <20080617101410.33390171@ohm.scrye.com> References: <200806160918.13496.jwilson@redhat.com> <20080617101410.33390171@ohm.scrye.com> Message-ID: <200806171459.59488.jwilson@redhat.com> On Tuesday 17 June 2008 12:14:10 pm Kevin Fenzi wrote: > On Mon, 16 Jun 2008 09:18:13 -0400 > > jwilson at redhat.com (Jarod Wilson) wrote: > > For a variety of reasons, I have to entirely give up involvement in a > > number of packages. I've already tried to find new primary > > maintainers without success, but I really can't justify any time > > spent on these packages any longer, so I must orphan them ASAP, and > > hopefully, someone picks them up... > > > > emerald (compiz-fusion alternate windowing thingamajig) > > emerald-themes (themes for the above) > > ganglia (cluster monitoring software) > > numpy (numerical python) > > > > I've also got the following packages for which I've yet to solicit > > new maintainers for that I am also intending to orphan Real Soon Now: > > > > conman (console management software) > > connect-proxy (helper to use ssh through socks/squid proxy) > > dircproxy (detachable irc proxy) > > powerman (power management software) > > > > I'll keep myself on the cc for bugzillas for all of the above, and > > will try to help with any bugs filed, personal free time permitting. > > Most of these are relatively low on time investment required to > > maintain them, but volume adds up, particularly given that I only > > actually use two of these packages on any sort of regular basis these > > days (conman and dircproxy). > > I can take dircproxy, since I use it all the time... Much appreciated. Not much to report on dircproxy, upstream is mostly inactive most of the time, occasionally posts an updated beta (like, once every year and a half). I know there's one patch in the fedora build to fix a crash on receiving a zero-length message that I don't believe has made its way back upstream (my fault, forgot about it 'til now). Five down, three to go... C'mon people, you know you want emerald and emerald-themes... connect-proxy is dead-simple, but dunno how many people actually have use for it (I did 3 years ago, notsomuch anymore...). -- Jarod Wilson jwilson at redhat.com From maximilianbianco at gmail.com Tue Jun 17 19:11:33 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 17 Jun 2008 15:11:33 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856113B.9010004@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> Message-ID: <48580C65.5040208@gmail.com> jeff wrote: > Hans de Goede wrote: >> It depends on your definition of software, according to Fedora's >> definitions firmware is not software it is content. I know this is a >> word game, but think about it, what is the definition of software? > > From the Oxford English Dictionary: > > software > 1. Computers. a. The programs and procedures required to enable a > computer to perform a specific task, as opposed to the physical > components of the system (see also quot. 1961). b. esp. The body of > system programs, including compilers and library routines, required for > the operation of a particular computer and often provided by the > manufacturer, as opposed to program material provided by a user for a > specific task. > > > I didn't realize fedora was claiming that firmware isn't software. Now > that is bullshit. You call it a word game, I'll call it what it is. > *Content??!* It's obviously software. I mean, it can be copied, it can > be rewritten (well, by the people in the castle with the code), it can > be compiled, etc... Clearly software. I guess you need a PhD to delude > yourself otherwise. > > Usually techs are so precise, I can't believe the doublethinking here. > You are starting to work against yourself. Firmware usually comes with my devices, it is reloadable but it comes with the device when I make the purchase, I don't have to load firmware into a device to make it work in the first place. It is part of the hardware because the hardware requires it to run. I thought that was why software and firmware where two different terms. Firmware is software but the hardware relies on it to function and it is included in the purchase price of the hardware. Software is generally acquired separately from the hardware. Windows(software) comes preinstalled on many computers(hardware) but I can remove windows and still have functional hardware but if I remove the BIOS , windows nor linux will run. > Oh, and you should let Broadcom know that they aren't distributing > software then: > > * Derived from proprietary unpublished source code, > > > -Jeff > -- Fortune favors the BOLD From moe at blagblagblag.org Tue Jun 17 19:56:45 2008 From: moe at blagblagblag.org (jeff) Date: Tue, 17 Jun 2008 16:56:45 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48580C65.5040208@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> Message-ID: <485816FD.7000808@blagblagblag.org> max wrote: > jeff wrote: >> Hans de Goede wrote: >>> It depends on your definition of software, according to Fedora's >>> definitions firmware is not software it is content. I know this is a >>> word game, but think about it, what is the definition of software? >> >> From the Oxford English Dictionary: >> >> software >> 1. Computers. a. The programs and procedures required to enable >> a computer to perform a specific task, as opposed to the physical >> components of the system (see also quot. 1961). b. esp. The body of >> system programs, including compilers and library routines, required >> for the operation of a particular computer and often provided by the >> manufacturer, as opposed to program material provided by a user for a >> specific task. >> >> >> I didn't realize fedora was claiming that firmware isn't software. Now >> that is bullshit. You call it a word game, I'll call it what it is. >> *Content??!* It's obviously software. I mean, it can be copied, it can >> be rewritten (well, by the people in the castle with the code), it can >> be compiled, etc... Clearly software. I guess you need a PhD to delude >> yourself otherwise. >> >> Usually techs are so precise, I can't believe the doublethinking here. >> > > You are starting to work against yourself. Firmware usually comes with > my devices, it is reloadable but it comes with the device when I make > the purchase, I don't have to load firmware into a device to make it > work in the first place. It is part of the hardware because the hardware > requires it to run. I thought that was why software and firmware where > two different terms. Firmware is software but the hardware relies on it > to function and it is included in the purchase price of the hardware. > Software is generally acquired separately from the hardware. > Windows(software) comes preinstalled on many computers(hardware) but I > can remove windows and still have functional hardware but if I remove > the BIOS , windows nor linux will run. If you remove the non-free software from tg3.c the device will still work. "It is part of the hardware because the hardware requires it to run", you wrote. What does that make the non-free software in tg3.c? -Jeff From dwmw2 at infradead.org Tue Jun 17 20:35:04 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 21:35:04 +0100 Subject: PPC/PPC64 builders not working? In-Reply-To: <20080617131243.fe18a507.lvillani@binaryhelix.net> References: <20080617131243.fe18a507.lvillani@binaryhelix.net> Message-ID: <1213734904.26255.1113.camel@pmac.infradead.org> On Tue, 2008-06-17 at 13:12 +0200, Lorenzo Villani wrote: > > It seems that the PPC/PPC64 builders are stucked with our chainbuild: > http://koji.fedoraproject.org/koji/taskinfo?taskID=664653 > > As far as I can tell, it has been at least 6-7 hours now that those > builders are processing kdepimlibs build. Submit it again; it should work now that bug #451831 has been fixed. Of course, the bug didn't get _fixed_ until after it was filed... -- dwmw2 From lordmorgul at gmail.com Tue Jun 17 20:57:43 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 17 Jun 2008 13:57:43 -0700 Subject: PackageKit UI In-Reply-To: <1213275718.3968.3.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> <48510565.2090407@fedoraproject.org> <1213273983.3968.1.camel@hughsie-work> <48511992.9040806@fedoraproject.org> <1213275718.3968.3.camel@hughsie-work> Message-ID: <48582547.1020505@gmail.com> Richard Hughes wrote: > On Thu, 2008-06-12 at 18:11 +0530, Rahul Sundaram wrote: >> Richard Hughes wrote: >>> On Thu, 2008-06-12 at 16:45 +0530, Rahul Sundaram wrote: >>>> * Why are you not using the application icons in the left side >>>> instead >>>> of the right corner completely disconnected from the app itself? >>> The icons in the list change as you select them, for instance a trash >>> icon is overlaid when it's to be deleted. There's also a non-trivial >>> cost of looking up each themed icon which can slow the GUI down a lot. >> Can that be done async? > > Ohh, I guess so, yes. > >>>> * What about group installation and removals? >>> Still in the planning state, I've yet to find a good UI for any of this. >>> Yell if you can think of a good one. >> Pirut did it in the context menu and providing a button when you click >> on a group. You might want to check that out. > > Yes, I've checked it out and it didn't seem very obvious to me - it also > ties PackageKit into the native comps mapping which it already maps to > more abstract groups. Perhaps it would be good enough to provide a sub-menu in the left that is an abstract group 'Groups' and then have only the native comps listed in that filtered 'abstract group'? That should allow you to select and apply installation/removal of a 'Group' without any UI change at all really, as if the group was a package. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lordmorgul at gmail.com Tue Jun 17 20:59:54 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 17 Jun 2008 13:59:54 -0700 Subject: PackageKit UI In-Reply-To: <1218b5bc0806170721k7b493ab9pe6eb9d6b3fa6688e@mail.gmail.com> References: <1213268950.3505.1.camel@hughsie-work> <1213294373.8892.3.camel@rousalka.okg> <1213343617.3291.8.camel@hughsie-work> <45450.192.54.193.59.1213344474.squirrel@rousalka.dyndns.org> <1218b5bc0806170721k7b493ab9pe6eb9d6b3fa6688e@mail.gmail.com> Message-ID: <485825CA.4090308@gmail.com> Callum Lerwick wrote: > On Fri, Jun 13, 2008 at 3:07 AM, Nicolas Mailhot < > nicolas.mailhot at laposte.net> wrote: > >>> [1] http://www.packagekit.org/temp/gpk-application-multiple.png >> I think your main problem was the tabs gallore on the right side. It's >> probably better to have just one column with information presented >> sequentially in it > > > Yes, since its presenting information and not UI, use a collapsible tree. > Like say, Wireshark's packet information display. I hate having a center column so narrow it needs a scrollbar just to show the name of most packages. Thats just simply an unusable UI, even if the right side was collapsible. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lordmorgul at gmail.com Tue Jun 17 21:05:20 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 17 Jun 2008 14:05:20 -0700 Subject: PackageKit UI In-Reply-To: <544eb990806130238q5effdf01o86fee7fcc82da8d4@mail.gmail.com> References: <1213268950.3505.1.camel@hughsie-work> <20080612130942.GA59280@dspnet.fr.eu.org> <1213276937.3968.7.camel@hughsie-work> <20080612134119.GA64415@dspnet.fr.eu.org> <1213279585.4225.4.camel@hughsie-work> <3adc77210806120802h49d2c39v78523cc623c9930c@mail.gmail.com> <1213341042.3291.6.camel@hughsie-work> <544eb990806130238q5effdf01o86fee7fcc82da8d4@mail.gmail.com> Message-ID: <48582710.5070702@gmail.com> Bill Crawford wrote: > 2008/6/13 Richard Hughes : >> On Thu, 2008-06-12 at 16:02 +0100, Naheem Zaffar wrote: >>> Been using packagekit for Fedora 9, and I generally like what I see >>> (good work!) things that I think can be improved/current problems: >>> >>> 1. Do NOT list multiple versions of the same package. I see that in >>> current Fedora release too. At times the version numbers are not that >>> easy to compare package-x.y.1.y vs package-x.y.y.1 makes a person >>> think. Other times if both are uninstalled, selecting the wrong one >>> will probably lead to an updated available applet anywway... >> Sure. We've got a LATEST filter in PackageKit for this, but the yum >> backend doesn't seem to support it. I might hack on that today on the >> plane. >> >>> Solution: only list one - the latest one. If an update is available to >>> the installed version, use the corresponding update icon >>> (bugfix/enhancement/security) instead of an open or closed box. >> Sane. > > Disagree. If you installed something from updates-testing and want to > downgrade to original release or stable update, that should be listed > too (with an option to downgrade, preferably presented exactly the way > as for a newer one, but perhaps dimmed or something). > Perhaps it would be better not to list ANY updates available in the same listings as the packages you're installing... but rather to add a new abstract group 'Updates' to the left sub-menus. The currently installed package would be listed in its normal place, and any update to it would be listed in the sub-group. If you don't have it installed then only the newest available one would be listed in the normal place. To downgrade, you uninstall, turn off updates-testing, and then go install. Nothing more obvious than this is needed for the downgrade case since its only something software testers should need to do. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From maximilianbianco at gmail.com Tue Jun 17 21:25:48 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 17 Jun 2008 17:25:48 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <485816FD.7000808@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> Message-ID: <48582BDC.7090701@gmail.com> jeff wrote: > max wrote: >> jeff wrote: >>> Hans de Goede wrote: >>>> It depends on your definition of software, according to Fedora's >>>> definitions firmware is not software it is content. I know this is a >>>> word game, but think about it, what is the definition of software? >>> >>> From the Oxford English Dictionary: >>> >>> software >>> 1. Computers. a. The programs and procedures required to >>> enable a computer to perform a specific task, as opposed to the >>> physical components of the system (see also quot. 1961). b. esp. >>> The body of system programs, including compilers and library >>> routines, required for the operation of a particular computer and >>> often provided by the manufacturer, as opposed to program material >>> provided by a user for a specific task. >>> >>> >>> I didn't realize fedora was claiming that firmware isn't software. >>> Now that is bullshit. You call it a word game, I'll call it what it >>> is. *Content??!* It's obviously software. I mean, it can be copied, >>> it can be rewritten (well, by the people in the castle with the >>> code), it can be compiled, etc... Clearly software. I guess you need >>> a PhD to delude yourself otherwise. >>> >>> Usually techs are so precise, I can't believe the doublethinking here. >>> >> >> You are starting to work against yourself. Firmware usually comes with >> my devices, it is reloadable but it comes with the device when I make >> the purchase, I don't have to load firmware into a device to make it >> work in the first place. It is part of the hardware because the >> hardware requires it to run. I thought that was why software and >> firmware where two different terms. Firmware is software but the >> hardware relies on it to function and it is included in the purchase >> price of the hardware. Software is generally acquired separately from >> the hardware. Windows(software) comes preinstalled on many >> computers(hardware) but I can remove windows and still have functional >> hardware but if I remove the BIOS , windows nor linux will run. > > > If you remove the non-free software from tg3.c the device will still > work. Completely? no loss of functionality whatsoever? can you still interact with it? I need to be able to interact with a device in order for it to be useful to me. My car will run without a driver but its not going anywhere. My computer will run without an operator but human interaction is required at some point to make it useful to me, if only for initial setup. > "It is part of the hardware because the hardware requires it to > run", you wrote. I phrased it poorly in hindsight but its more or less true in most cases, or I should have said that its needed to interact with other hardware or software. At some point it has to be configurable by a person through some extension or another in order to be useful. I don't think manufacturers obsessed with the bottom line are hiring programmers to write unneeded firmware just to annoy free software advocates. >What does that make the non-free software in tg3.c? Unnecessary but is that the case in every instance? I am perfectly willing to be educated/corrected and I have heard arguments from both sides that have merit, I am tempted to send a copy of the GPL to my lawyer and get the interpretation of someone who doesn't have a horse in this race. From moe at blagblagblag.org Tue Jun 17 21:53:43 2008 From: moe at blagblagblag.org (jeff) Date: Tue, 17 Jun 2008 18:53:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48582BDC.7090701@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> Message-ID: <48583267.9010009@blagblagblag.org> max wrote: > jeff wrote: >> max wrote: >>> jeff wrote: >>>> Hans de Goede wrote: >>>>> It depends on your definition of software, according to Fedora's >>>>> definitions firmware is not software it is content. I know this is >>>>> a word game, but think about it, what is the definition of software? >>>> >>>> From the Oxford English Dictionary: >>>> >>>> software >>>> 1. Computers. a. The programs and procedures required to >>>> enable a computer to perform a specific task, as opposed to the >>>> physical components of the system (see also quot. 1961). b. esp. >>>> The body of system programs, including compilers and library >>>> routines, required for the operation of a particular computer and >>>> often provided by the manufacturer, as opposed to program material >>>> provided by a user for a specific task. >>>> >>>> >>>> I didn't realize fedora was claiming that firmware isn't software. >>>> Now that is bullshit. You call it a word game, I'll call it what it >>>> is. *Content??!* It's obviously software. I mean, it can be copied, >>>> it can be rewritten (well, by the people in the castle with the >>>> code), it can be compiled, etc... Clearly software. I guess you need >>>> a PhD to delude yourself otherwise. >>>> >>>> Usually techs are so precise, I can't believe the doublethinking here. >>>> >>> >>> You are starting to work against yourself. Firmware usually comes >>> with my devices, it is reloadable but it comes with the device when I >>> make the purchase, I don't have to load firmware into a device to >>> make it work in the first place. It is part of the hardware because >>> the hardware requires it to run. I thought that was why software and >>> firmware where two different terms. Firmware is software but the >>> hardware relies on it to function and it is included in the purchase >>> price of the hardware. Software is generally acquired separately from >>> the hardware. Windows(software) comes preinstalled on many >>> computers(hardware) but I can remove windows and still have >>> functional hardware but if I remove the BIOS , windows nor linux will >>> run. >> >> >> If you remove the non-free software from tg3.c the device will still >> work. > Completely? Yes. > no loss of functionality whatsoever? I think the firmware does some TCP offloading or something so more processing happens in the card instead of the kernel, but I'm really not certain what the firmware is doing. In fact, only the people with the source code know what it's doing, I supppose. But it works 100% fine as a regular network card without the firmware. > can you still interact > with it? Yes. > I need to be able to interact with a device in order for it to > be useful to me. My car will run without a driver but its not going > anywhere. My computer will run without an operator but human > interaction is required at some point to make it useful to me, if only > for initial setup. The card works fine with linux-libre, no firmware required. >> "It is part of the hardware because the hardware requires it to run", >> you wrote. > > I phrased it poorly in hindsight but its more or less true in most > cases, or I should have said that its needed to interact with other > hardware or software. So you meant "It is part of the hardware because its needed to interact with the hardware or software" ??? wtf? > At some point it has to be configurable by a > person through some extension or another in order to be useful. /sbin/ifconfig > I don't > think manufacturers obsessed with the bottom line are hiring programmers > to write unneeded firmware just to annoy free software advocates. I don't either. > >What does that make the non-free software in tg3.c? > > > Unnecessary but is that the case in every instance? Does it have to be? I'm just pointing out the things I see in the Linux kernel that are clearly not free software. > I am perfectly willing to be educated/corrected and I have heard > arguments from both sides that have merit, I am tempted to send a copy > of the GPL to my lawyer and get the interpretation of someone who > doesn't have a horse in this race. Please do. And show him a copy of tg3.c too please. :) -Jeff From dtimms at iinet.net.au Tue Jun 17 22:07:01 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 18 Jun 2008 08:07:01 +1000 Subject: installer leaves kernel to late in process... Message-ID: <48583585.4060801@iinet.net.au> Is there a legit reason that a basic anaconda install would install about 600 out of 900 packages, before installing the actual kernel ? If something goes wrong during install, and the installer hasn't at least installed the kernel and boot loader, user can be left in the crud. Preferably this would also include rpm and yum to be early installs... Is this a disk location optimization ? Would it be better for kernel to be the first thing on the disk {at least to get started - it going to change down the line anyway} ? DaveT. From dfisher at as.arizona.edu Tue Jun 17 22:34:11 2008 From: dfisher at as.arizona.edu (don fisher) Date: Tue, 17 Jun 2008 15:34:11 -0700 Subject: help understanding architecture of audio Message-ID: <48583BE3.6070405@as.arizona.edu> I am quite familiar with connecting arbitrarily complex audio systems. I have been trying to understand how the sections of the linux audio plug together. For sources I have a microphone, audio and video CDs, and MP3s. For output I have an audio jack, a bluetooth transmitter. Is there a mux (or preamp equivalent) that allows one to select and input and output path? Perhaps also set the gain, balance, base, treble and loudness. Is there a document that describes haw to turn on, and then access the various input and and output channels. Sorry if this is to basic a question. All of my searches have found pieces, but I am confident there must be an top down design document. don From maximilianbianco at gmail.com Tue Jun 17 23:03:59 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 17 Jun 2008 19:03:59 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48583267.9010009@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> Message-ID: <485842DF.9000902@gmail.com> jeff wrote: > max wrote: >> jeff wrote: >>> max wrote: >>>> jeff wrote: >>>>> Hans de Goede wrote: >>>>>> It depends on your definition of software, according to Fedora's >>>>>> definitions firmware is not software it is content. I know this is >>>>>> a word game, but think about it, what is the definition of software? >>>>> >>>>> From the Oxford English Dictionary: >>>>> >>>>> software >>>>> 1. Computers. a. The programs and procedures required to >>>>> enable a computer to perform a specific task, as opposed to the >>>>> physical components of the system (see also quot. 1961). b. esp. >>>>> The body of system programs, including compilers and library >>>>> routines, required for the operation of a particular computer and >>>>> often provided by the manufacturer, as opposed to program material >>>>> provided by a user for a specific task. >>>>> >>>>> >>>>> I didn't realize fedora was claiming that firmware isn't software. >>>>> Now that is bullshit. You call it a word game, I'll call it what it >>>>> is. *Content??!* It's obviously software. I mean, it can be copied, >>>>> it can be rewritten (well, by the people in the castle with the >>>>> code), it can be compiled, etc... Clearly software. I guess you >>>>> need a PhD to delude yourself otherwise. >>>>> >>>>> Usually techs are so precise, I can't believe the doublethinking here. >>>>> >>>> >>>> You are starting to work against yourself. Firmware usually comes >>>> with my devices, it is reloadable but it comes with the device when >>>> I make the purchase, I don't have to load firmware into a device to >>>> make it work in the first place. It is part of the hardware because >>>> the hardware requires it to run. I thought that was why software and >>>> firmware where two different terms. Firmware is software but the >>>> hardware relies on it to function and it is included in the purchase >>>> price of the hardware. Software is generally acquired separately >>>> from the hardware. Windows(software) comes preinstalled on many >>>> computers(hardware) but I can remove windows and still have >>>> functional hardware but if I remove the BIOS , windows nor linux >>>> will run. >>> >>> >>> If you remove the non-free software from tg3.c the device will still >>> work. >> Completely? > > Yes. > >> no loss of functionality whatsoever? > > I think the firmware does some TCP offloading or something so more > processing happens in the card instead of the kernel, but I'm really not > certain what the firmware is doing. In fact, only the people with the > source code know what it's doing, I supppose. > > But it works 100% fine as a regular network card without the firmware. > >> can you still interact with it? > > Yes. > >> I need to be able to interact with a device in order for it to be >> useful to me. My car will run without a driver but its not going >> anywhere. My computer will run without an operator but human >> interaction is required at some point to make it useful to me, if only >> for initial setup. > > The card works fine with linux-libre, no firmware required. > >>> "It is part of the hardware because the hardware requires it to run", >>> you wrote. >> >> I phrased it poorly in hindsight but its more or less true in most >> cases, or I should have said that its needed to interact with other >> hardware or software. > > So you meant "It is part of the hardware because its needed to interact > with the hardware or software" ??? wtf? > I said other hardware or software. I am thinking of PCI devices, like a graphics card, that contain additional code in ROM that is needed by the BIOS to properly initialize the card at boot time/ during POST. Though a driver might leverage such code as well for additional functionality perhaps, though off hand I don't have a specific reference for such an instance. Of course while you might say the line between hardware and software is distinct, I don't believe that is the case but that is my opinion. Technology is evolving everyday and if the line between hardware and software isn't already blurry, like I see it to be, then soon it will be because as technology evolves definitions have a tendency to change. >> At some point it has to be configurable by a person through some >> extension or another in order to be useful. > > /sbin/ifconfig > >> I don't think manufacturers obsessed with the bottom line are hiring >> programmers to write unneeded firmware just to annoy free software >> advocates. > > I don't either. > >> >What does that make the non-free software in tg3.c? >> >> >> Unnecessary but is that the case in every instance? > > Does it have to be? I'm just pointing out the things I see in the Linux > kernel that are clearly not free software. > No it doesn't and for the record I applaud your efforts. >> I am perfectly willing to be educated/corrected and I have heard >> arguments from both sides that have merit, I am tempted to send a copy >> of the GPL to my lawyer and get the interpretation of someone who >> doesn't have a horse in this race. > > Please do. And show him a copy of tg3.c too please. :) > > -Jeff > From ivazqueznet at gmail.com Tue Jun 17 23:09:16 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 17 Jun 2008 19:09:16 -0400 Subject: help understanding architecture of audio In-Reply-To: <48583BE3.6070405@as.arizona.edu> References: <48583BE3.6070405@as.arizona.edu> Message-ID: <1213744156.10118.149.camel@ignacio.lan> On Tue, 2008-06-17 at 15:34 -0700, don fisher wrote: > I am quite familiar with connecting arbitrarily complex audio systems. I > have been trying to understand how the sections of the linux audio plug > together. > > For sources I have a microphone, audio and video CDs, and MP3s. For > output I have an audio jack, a bluetooth transmitter. > > Is there a mux (or preamp equivalent) that allows one to select and > input and output path? Perhaps also set the gain, balance, base, treble > and loudness. > > Is there a document that describes haw to turn on, and then access the > various input and and output channels. > > Sorry if this is to basic a question. All of my searches have found > pieces, but I am confident there must be an top down design document. GStreamer. -- 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 dwmw2 at infradead.org Tue Jun 17 23:15:09 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 18 Jun 2008 00:15:09 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48583267.9010009@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> Message-ID: <1213744509.26255.1127.camel@pmac.infradead.org> On Tue, 2008-06-17 at 18:53 -0300, jeff wrote: > > I am perfectly willing to be educated/corrected and I have heard > > arguments from both sides that have merit, I am tempted to send a copy > > of the GPL to my lawyer and get the interpretation of someone who > > doesn't have a horse in this race. > > Please do. And show him a copy of tg3.c too please. :) Along with the quotes from one of its authors, who also happens to be the overall network driver maintainer for Linux, and has stated that each driver and its firmware are 'intimately tied... pieces of a single, cohesive whole'. -- dwmw2 From wolfy at nobugconsulting.ro Tue Jun 17 23:17:44 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jun 2008 02:17:44 +0300 Subject: Someone please take over these packages In-Reply-To: <200806171459.59488.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> <20080617101410.33390171@ohm.scrye.com> <200806171459.59488.jwilson@redhat.com> Message-ID: <48584618.2090503@nobugconsulting.ro> On 06/17/2008 09:59 PM, Jarod Wilson wrote: > On Tuesday 17 June 2008 12:14:10 pm Kevin Fenzi wrote: > >> On Mon, 16 Jun 2008 09:18:13 -0400 >> >> jwilson at redhat.com (Jarod Wilson) wrote: >> >>> For a variety of reasons, I have to entirely give up involvement in a >>> number of packages. I've already tried to find new primary >>> maintainers without success, but I really can't justify any time >>> spent on these packages any longer, so I must orphan them ASAP, and >>> hopefully, someone picks them up... >>> >>> emerald (compiz-fusion alternate windowing thingamajig) >>> emerald-themes (themes for the above) >>> ganglia (cluster monitoring software) >>> numpy (numerical python) >>> >>> I've also got the following packages for which I've yet to solicit >>> new maintainers for that I am also intending to orphan Real Soon Now: >>> >>> conman (console management software) >>> connect-proxy (helper to use ssh through socks/squid proxy) >>> dircproxy (detachable irc proxy) >>> powerman (power management software) >>> >>> I'll keep myself on the cc for bugzillas for all of the above, and >>> will try to help with any bugs filed, personal free time permitting. >>> Most of these are relatively low on time investment required to >>> maintain them, but volume adds up, particularly given that I only >>> actually use two of these packages on any sort of regular basis these >>> days (conman and dircproxy). >>> >> I can take dircproxy, since I use it all the time... >> > > Much appreciated. Not much to report on dircproxy, upstream is mostly inactive > most of the time, occasionally posts an updated beta (like, once every year > and a half). I know there's one patch in the fedora build to fix a crash on > receiving a zero-length message that I don't believe has made its way back > upstream (my fault, forgot about it 'til now). > > Five down, three to go... C'mon people, you know you want emerald and > emerald-themes... connect-proxy is dead-simple, but dunno how many people > actually have use for it (I did 3 years ago, notsomuch anymore...). > > Just for the record (after reading http://cvs.fedoraproject.org/viewcvs/rpms/connect-proxy/devel/connect-proxy.spec?rev=1.3&view=markup ) shouldn't %source be http://www.meadowy.org/~gotoh/ssh/connect.c rather than the filename that is used now ? From lesmikesell at gmail.com Tue Jun 17 23:43:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 17 Jun 2008 18:43:14 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213744509.26255.1127.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> Message-ID: <48584C12.3010502@gmail.com> David Woodhouse wrote: > On Tue, 2008-06-17 at 18:53 -0300, jeff wrote: >>> I am perfectly willing to be educated/corrected and I have heard >>> arguments from both sides that have merit, I am tempted to send a copy >>> of the GPL to my lawyer and get the interpretation of someone who >>> doesn't have a horse in this race. >> Please do. And show him a copy of tg3.c too please. :) > > Along with the quotes from one of its authors, who also happens to be > the overall network driver maintainer for Linux, and has stated that > each driver and its firmware are 'intimately tied... pieces of a single, > cohesive whole'. That would be a hard claim to support, knowing that at least some of the firmware comes from the hardware vendor, has nothing in particular to do with Linux, and may be also used by OS's that have no code in common. -- Les Mikesell lesmikesell at gmail.com From cmadams at hiwaay.net Wed Jun 18 01:16:10 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 17 Jun 2008 20:16:10 -0500 Subject: installer leaves kernel to late in process... In-Reply-To: <48583585.4060801@iinet.net.au> References: <48583585.4060801@iinet.net.au> Message-ID: <20080618011610.GA1523200@hiwaay.net> Once upon a time, David Timms said: > If something goes wrong during install, and the installer hasn't at > least installed the kernel and boot loader, user can be left in the > crud. Preferably this would also include rpm and yum to be early installs... The problem you have is the dependency chain. The Fedora kernel requires an initrd and modules (and the initrd is created in the RPM %post), so mkinitrd and module tools must be installed prior to the kernel package. They each also have a chain of dependencies (especially mkinitrd) that must be installed before they can run. You have similar issues for grub, rpm, and yum (especially yum, since it requires python). Really, if the installer craps out part way through, the system is broke and there's no reliable way to repair it. If it is an install, just start over. If it is an upgrade, there's no go answer today AFAIK. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwilson at redhat.com Wed Jun 18 04:36:38 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 18 Jun 2008 00:36:38 -0400 Subject: Someone please take over these packages In-Reply-To: <48584618.2090503@nobugconsulting.ro> References: <200806160918.13496.jwilson@redhat.com> <200806171459.59488.jwilson@redhat.com> <48584618.2090503@nobugconsulting.ro> Message-ID: <200806180036.38643.jwilson@redhat.com> On Tuesday 17 June 2008 07:17:44 pm Manuel Wolfshant wrote: > connect-proxy is dead-simple, but dunno how many people > > > actually have use for it (I did 3 years ago, notsomuch anymore...). > > > > ? > > Just for the record (after reading ? > http://cvs.fedoraproject.org/viewcvs/rpms/connect-proxy/devel/connect-proxy >.spec?rev=1.3&view=markup ) shouldn't %source ?be > http://www.meadowy.org/~gotoh/ssh/connect.c rather than the filename that > is used now ? Did you miss the two lines after the Source0 line? :) ----- Source0: connect-%{version}.c # Real source listed below, it was renamed for sanity's sake #Source0: http://www.taiyo.co.jp/~gotoh/ssh/connect.c ----- I find renaming it much less ugly to deal with multiple versions, particularly given the sucktitude of cvs. Does seem the urls are in need of an update though. And it'd be up to a new maintainer whether or not to keep that source file scheme or not. -- Jarod Wilson jwilson at redhat.com From rawhide at fedoraproject.org Wed Jun 18 09:45:04 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 18 Jun 2008 09:45:04 +0000 (UTC) Subject: rawhide report: 20080618 changes Message-ID: <20080618094505.08001209D18@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080617/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080618/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package cylindrix Cylindrix is a 3 degrees of freedom combat game New package perl-Catalyst-Plugin-Authentication Infrastructure plugin for the Catalyst authentication framework New package python-tempita A very small text templating language New package python-wsgiproxy HTTP proxying tools for WSGI apps New package sk2py Migrates Cadence Skill based PCells to Python PyCells Removed package scim-sinhala Updated Packages: bluez-hcidump-1.42-1.fc10 ------------------------- * Tue Jun 17 18:00:00 2008 - Bastien Nocera - 1.42-1 - Update to 1.42 cairo-dock-1.6.0-0.2.svn1106_trunk.fc10 --------------------------------------- cfengine-2.2.7-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Jeff Sheltren 2.2.7-1 - Update to upstream 2.2.7 clamav-0.93.1-1.fc10 -------------------- * Tue Jun 17 18:00:00 2008 Enrico Scholz - 0.93.1-1 - updated to 0.93.1 - rediffed -path patch - CVE-2008-2713 Invalid Memory Access Denial Of Service Vulnerability crystalspace-1.2-6.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Hans de Goede 1.2-6 - Fix building on ppc64, patch from David Woodhouse cups-1.3.7-9.fc10 ----------------- * Tue Jun 17 18:00:00 2008 Tim Waugh 1:1.3.7-9 - Don't overwrite the upstream snmp.conf file. * Tue Jun 17 18:00:00 2008 Tim Waugh 1:1.3.7-8 - Fixed bug #447200 again. * Tue Jun 17 18:00:00 2008 Tim Waugh 1:1.3.7-7 - Backported cupsGetNamedDest from 1.4 (bug #428086). dhcpv6-1.0.19-1.fc10 -------------------- * Tue Jun 17 18:00:00 2008 David Cantrell - 1.0.19-1 - Upgrade to dhcpv6-1.0.19, changes include: Write server PID file after configuration file is parsed Remove temporary file during resolv.conf updates Debug message cleanups Allow MAX_DEVICE number of devices Support multiple IA options Update internal status correctly for RENEW/REBIND msgs Man page and usage screen updates Handle signals correctly for daemon processes Make sure PID files are written for all daemons Add command line options to override PID file locations Perform case-insensitive DNS search domain comparisions Fix possible SIGSEGV in get_if_rainfo() When dhcp6c requests information only, don't configure iface Support s390 virtual interfaces on s390 platform Init script cleanups dvipdfmx-0-0.25.20080617cvs.fc10 -------------------------------- * Tue Jun 17 18:00:00 2008 Jonathan G. Underwood - 0-0.25.20080617cvs - Rework ebb-to-ebbx patch for latest CVS snapshot - Fix files section * Tue Jun 17 18:00:00 2008 Jonathan G. Underwood - 0-0.24.20080617cvs - Update to 20080617 CVS snapshot dynamite-0.1.1-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 0.1.1-1 - version upgrade eel2-2.23.4-1.fc10 ------------------ * Tue Jun 17 18:00:00 2008 Tomas Bzatek - 2.23.4-1 - Update to 2.23.4 eog-2.23.4.1-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4.1-1 - Update to 2.23.4.1 file-roller-2.23.3-1.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.3-1 - Update to 2.23.3 firefox-3.0-1.fc10 ------------------ * Tue Jun 17 18:00:00 2008 Christopher Aillon 3.0-1 - Firefox 3 Final freetds-0.82-2.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Dmitry Butskoy - 0.82-2 - Continue to provide an internal libtds library as public (patch from Hans de Goede, #451021). This shared library is needed for some existing applications (libgda etc.), which still use it directly. gcalctool-5.23.4-1.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 5.23.4-1 - Update to 5.23.4 gdb-6.8-11.fc10 --------------- * Tue Jun 17 18:00:00 2008 Jan Kratochvil - 6.8-11 - Fix the testsuite run for ia64 (where no -m64 is present). - Test a crash on libraries missing the .text section. - Protect development in the build tree by automatic Makefile dependencies. - Refuse creating watchpoints of an address value, suggested by Martin Stransky. - Disable randomization (such as by setarch -R), suggested by Jakub Jelinek. - Fix compatibility with recent glibc headers. gnome-desktop-2.23.4-1.fc10 --------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 gnome-icon-theme-2.23.2-1.fc10 ------------------------------ * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 gnome-menus-2.23.4-1.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 gnome-settings-daemon-2.23.3-2.fc10 ----------------------------------- * Tue Jun 17 18:00:00 2008 Colin Walters - 2.23.3-2 - Add (now upstreamed) patch to legacy ESD preference; see http://bugzilla.gnome.org/show_bug.cgi?id=533198 https://bugzilla.redhat.com/show_bug.cgi?id=430624 gstreamer-plugins-good-0.10.8-6.fc10 ------------------------------------ * Tue Jun 17 18:00:00 2008 - Bastien Nocera - 0.10.8-6 - Really fix the default audio output not being correct gucharmap-2.23.4-1.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 hunspell-1.2.4-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Caolan McNamara - 1.2.4-1 - latest version hunspell-sv-1.28-1.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Caolan McNamara - 1.28-1 - latest version imsettings-0.101.2-1.fc10 ------------------------- * Tue Jun 17 18:00:00 2008 Akira TAGOH - 0.101.2-1 - New upstream release. - Fix a typo in the help message. (#451739) - Fix a invalid memory access. (#451753) inn-2.4.4-3.fc10 ---------------- * Tue Jun 17 18:00:00 2008 Ondrej Vasik - 2.4.4-3 - Add news user. fixes bug #437462 kerneloops-0.11-1.fc10 ---------------------- * Tue Jun 17 18:00:00 2008 Chuck Ebbert 0.11-1 - kerneloops 0.11 * Wed Apr 2 18:00:00 2008 Chuck Ebbert 0.10-12 - Pass options from /etc/sysconfig/kerneloops kvm-70-1.fc10 ------------- * Tue Jun 17 18:00:00 2008 Glauber Costa - 70-1 - Update to kvm-70 - Added qemu-nbd command - gcc34 build dependency is gone leafnode-1.11.6-4.fc10 ---------------------- * Mon Jun 16 18:00:00 2008 Kevin Fenzi - 1.11.6-4 - Add news user. fixes bug #437462 libbonobo-2.23.0-1.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.0-1 - Update to 2.23.0 libbonoboui-2.23.4-1.fc10 ------------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 libburn-0.4.8-1.fc10 -------------------- * Wed Jun 11 18:00:00 2008 Denis Leroy - 0.4.8-1 - Update to upstream 0.4.8 libetpan-0.54-1.fc10 -------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 0.54-1 - version upgrade - fix #451025 libgadu-1.8.1-1.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Dominik Mierzejewski 1.8.1-1 - updated to 1.8.1 libgda-3.1.2-4.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Hans de Goede 1:3.1.2-4 - Rebuild against new freetds libgnome-2.23.4-1.fc10 ---------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 libgnomeui-2.23.4-1.fc10 ------------------------ * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 libgweather-2.23.4-1 -------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen 2.23.4-1 - Update to 2.23.4 libraw1394-2.0.0-0.1.20080430_git.fc10 -------------------------------------- * Tue Jun 17 18:00:00 2008 Jarod Wilson - 2.0.0-0.1.20080430_git - Update to pre-2.0.0 git tree, which features merged "juju" firewire stack support, enabled simultaneously with classic ieee1394 support * Tue Jun 17 18:00:00 2008 Jarod Wilson - 1.3.0-7 - Fully initialize data structures and plug dir leak. Resolves crashes when used with kino (Philippe Troin, #451727) libsynce-0.11.1-1.fc10 ---------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade libwnck-2.23.4-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 lua-logging-1.1.4-1.fc9 ----------------------- lua-posix-5.1.2-2.fc9 --------------------- lua-socket-2.0.2-2.fc9 ---------------------- lua-sql-2.1.1-4.fc9 ------------------- luadoc-3.0.1-1.fc9 ------------------ metacity-2.23.34-1.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 2.23.34-1 - Update to 2.23.34 mona-1.4r11-1.fc10 ------------------ * Tue Jun 17 18:00:00 2008 Jerry James - 1.4r11-1 - Update to 1.4-11 - Add the user manual to the main package docs nautilus-2.23.4-1.fc10 ---------------------- * Tue Jun 17 18:00:00 2008 Tomas Bzatek - 2.23.4-1 - Update to 2.23.4 offlineimap-6.0.0-1.fc10 ------------------------ * Wed Jun 18 18:00:00 2008 Till Maas - 6.0.0-1 - Update to latest release pam_mount-0.41-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Till Maas - 0.41-1 - Update to new version pango-1.21.3-1.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Matthias Clasen - 1.21.3-1 - Update to 1.21.3 perl-Class-MOP-0.61-1.fc10 -------------------------- * Tue Jun 17 18:00:00 2008 Chris Weyl 0.61-1 - update to 0.61 * Wed May 28 18:00:00 2008 Chris Weyl 0.57-1 - update to 0.57 perl-Config-General-2.39-1.fc10 ------------------------------- * Tue Jun 17 18:00:00 2008 Ville Skytt?? - 2.39-1 - 2.39. perl-Gtk2-Sexy-0.03-1.fc10 -------------------------- * Tue Jun 17 18:00:00 2008 Chris Weyl 0.03-1 - update to 0.03 pixman-0.11.4-3.fc10 -------------------- * Tue Jun 17 18:00:00 2008 David Woodhouse 0.11.4-3 - Fix Altivec detection breakage (#451831) pygsl-0.9.3-1.fc10 ------------------ * Tue Jun 17 18:00:00 2008 Jos?? Matos - 0.9.3-1 - New upstream release. repoman-0.9-5.fc10 ------------------ * Thu Apr 17 18:00:00 2008 David Cantrell - 0.9-4 - Run desktop-file-install correctly in %install (#440735) - Set License tag to GPLv2 per packaging guidelines - Remove the installed *.egg-info file rkhunter-1.3.2-4.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Kevin Fenzi - 1.3.2-4 - Fix cron script to only mail on warn/error - bug #450703 - Fix conditional to account for fc10 rsyslog rubygem-activeldap-1.0.1-1.fc10 ------------------------------- * Tue Jun 17 18:00:00 2008 Darryl Pierce - 1.0.1-1 - Release 1.0.1 of the gem. snake-0.11-0.7.fc10 ------------------- * Tue Jun 17 18:00:00 2008 James Laska 0.11-0.7 - ticket#56 - Fixed translate.py traceback for older python * Fri Jun 13 18:00:00 2008 James Laska 0.11-0.6 - ticket#37 - snake-server support for hosting http,ftp and nfs kickstarts - ticket#42 - snake/tui.py - add ksmethod selection screen - snake-install-tui should remember the selected tree - ticket#53 - Add snake-ks --ksmeta parameter to pass optional values to the python kickstart template. - Add snake-machine check to ensure xmlrpc server supports machine.* methods - Include /var/lib/snake/machines in spec file - ticket#11 - Removed xml support from compose.py and tree.py - Dropped snake-server labquery.py, labindex.py, and server.py sqlite-3.5.9-1.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Stepan Kasal - 3.5.9-1 - update to 3.5.9 stgit-0.14.3-1.fc10 ------------------- * Tue Jun 17 18:00:00 2008 James Bowes 0.14.3-1 - Update to 0.14.3 sylpheed-2.5.0-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Michael Schwendt - 2.5.0-1 - update to 2.5.0 final (a few translation updates) synaptics-0.14.6-9.fc10 ----------------------- * Tue Jun 17 18:00:00 2008 Adam Jackson 0.14.6-9 - Fix %fedora version comparison to be numeric not string. * Thu Apr 10 18:00:00 2008 Ville Skytt?? - 0.14.6-8 - Build with $RPM_OPT_FLAGS, fix debuginfo (#249979). unshield-0.5.1-1.fc10 --------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 0.5.1-1 - version upgrade wine-1.0-1.fc10 --------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 1.0-1 - version upgrade (#446311,#417161) - fix wine.desktop mime types (#448338) - add desktop package including desktop files and binary handler (#441310) - pull in some wine alsa/pulseaudio patches (#344281) * Mon Jun 16 18:00:00 2008 Andreas Bierfert - 1.0-0.5.rc5 - version upgrade wine-docs-1.0-1.fc10 -------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 1.0-1 - version upgrade xulrunner-1.9-1.fc10 -------------------- * Tue Jun 17 18:00:00 2008 Christopher Aillon 1.9-1 - Update to 1.9 final * Thu May 29 18:00:00 2008 Christopher Aillon 1.9-0.63 - Simplify PS/PDF operators zenity-2.23.3.1-1.fc10 ---------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.3.1-1 - Update to 2.23.3.1 Summary: Added Packages: 5 Removed Packages: 1 Modified Packages: 70 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 1:gnome-applets-2.23.2-2.fc10.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) 1:gnome-applets-2.23.2-2.fc10.x86_64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 1:gnome-applets-2.23.2-2.fc10.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) 1:gnome-applets-2.23.2-2.fc10.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From stlwrt at gmail.com Wed Jun 18 10:25:26 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 18 Jun 2008 13:25:26 +0300 Subject: help understanding architecture of audio In-Reply-To: <48583BE3.6070405@as.arizona.edu> References: <48583BE3.6070405@as.arizona.edu> Message-ID: JACK allows rewiring of software and devices. http://qjackctl.sourceforge.net/qjackctl-ss1.html On Wed, Jun 18, 2008 at 1:34 AM, don fisher wrote: > I am quite familiar with connecting arbitrarily complex audio systems. I > have been trying to understand how the sections of the linux audio plug > together. > > For sources I have a microphone, audio and video CDs, and MP3s. For output I > have an audio jack, a bluetooth transmitter. > > Is there a mux (or preamp equivalent) that allows one to select and input > and output path? Perhaps also set the gain, balance, base, treble and > loudness. > > Is there a document that describes haw to turn on, and then access the > various input and and output channels. > > Sorry if this is to basic a question. All of my searches have found pieces, > but I am confident there must be an top down design document. > > don > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From wolfy at nobugconsulting.ro Wed Jun 18 11:29:32 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jun 2008 14:29:32 +0300 Subject: Someone please take over these packages In-Reply-To: <200806180036.38643.jwilson@redhat.com> References: <200806160918.13496.jwilson@redhat.com> <200806171459.59488.jwilson@redhat.com> <48584618.2090503@nobugconsulting.ro> <200806180036.38643.jwilson@redhat.com> Message-ID: <4858F19C.3000600@nobugconsulting.ro> Jarod Wilson wrote: > On Tuesday 17 June 2008 07:17:44 pm Manuel Wolfshant wrote: > >> connect-proxy is dead-simple, but dunno how many people >> >> >>> actually have use for it (I did 3 years ago, notsomuch anymore...). >>> >>> >>> >> Just for the record (after reading >> http://cvs.fedoraproject.org/viewcvs/rpms/connect-proxy/devel/connect-proxy >> .spec?rev=1.3&view=markup ) shouldn't %source be >> http://www.meadowy.org/~gotoh/ssh/connect.c rather than the filename that >> is used now ? >> > > Did you miss the two lines after the Source0 line? :) > Yes, I did. I did not read the comments :) That should teach me to [re]act at 3 AM... > ----- > Source0: connect-%{version}.c > # Real source listed below, it was renamed for sanity's sake > #Source0: http://www.taiyo.co.jp/~gotoh/ssh/connect.c > ----- > > I find renaming it much less ugly to deal with multiple versions, particularly > given the sucktitude of cvs. only that this breaks the scripts which download the source from web and verify md5/sha1 > Does seem the urls are in need of an update > though. And it'd be up to a new maintainer whether or not to keep that source > file scheme or not. > From lemenkov at gmail.com Wed Jun 18 12:37:52 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 18 Jun 2008 16:37:52 +0400 Subject: Heads Up! Wavpack soname bump Message-ID: Hello All! I just prepared to update wavpack to latest version (4.50). Among some bugfixes it introduces minor soname-bump ( /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 ) Keeping in mind my infamous upgrade of Xerces-C from 2.7.0 to 2.8.0, I decided to secure against similar issues and want to ask - whether someone has objections against this upgrade? If not, then I'll upgrade wavpack ASAP. -- With best regards! From maximilianbianco at gmail.com Wed Jun 18 13:07:59 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 18 Jun 2008 09:07:59 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213744509.26255.1127.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> Message-ID: <485908AF.5050402@gmail.com> David Woodhouse wrote: > On Tue, 2008-06-17 at 18:53 -0300, jeff wrote: >>> I am perfectly willing to be educated/corrected and I have heard >>> arguments from both sides that have merit, I am tempted to send a copy >>> of the GPL to my lawyer and get the interpretation of someone who >>> doesn't have a horse in this race. >> Please do. And show him a copy of tg3.c too please. :) > > Along with the quotes from one of its authors, who also happens to be > the overall network driver maintainer for Linux, and has stated that > each driver and its firmware are 'intimately tied... pieces of a single, > cohesive whole'. > Why or how have they become "intimately tied"? -- "Hulk SMASH!!" From mschwendt at gmail.com Wed Jun 18 13:14:00 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 18 Jun 2008 15:14:00 +0200 Subject: Heads Up! Wavpack soname bump In-Reply-To: References: Message-ID: <20080618151400.ca503f9c.mschwendt@gmail.com> On Wed, 18 Jun 2008 16:37:52 +0400, Peter Lemenkov wrote: > Hello All! > I just prepared to update wavpack to latest version (4.50). Among some > bugfixes it introduces minor soname-bump ( > /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 ) > > Keeping in mind my infamous upgrade of Xerces-C from 2.7.0 to 2.8.0, I > decided to secure against similar issues and want to ask - whether > someone has objections against this upgrade? If not, then I'll upgrade > wavpack ASAP. What is the soname, libwavpack.so.1 or libwavpack.so.1.0.2? -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.36 1.41 1.57 From mlichvar at redhat.com Wed Jun 18 13:17:42 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 18 Jun 2008 15:17:42 +0200 Subject: Heads Up! Wavpack soname bump In-Reply-To: References: Message-ID: <20080618131742.GB19397@localhost> On Wed, Jun 18, 2008 at 04:37:52PM +0400, Peter Lemenkov wrote: > Hello All! > I just prepared to update wavpack to latest version (4.50). Among some > bugfixes it introduces minor soname-bump ( > /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 ) The soname stays at "libwavpack.so.1", so technically it's not a soname bump ;). Should be safe to upgrade. -- Miroslav Lichvar From maximilianbianco at gmail.com Wed Jun 18 13:22:27 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 18 Jun 2008 09:22:27 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48583267.9010009@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> Message-ID: <48590C13.9040603@gmail.com> jeff wrote: > max wrote: >> jeff wrote: >>> max wrote: >>>> jeff wrote: >>>>> Hans de Goede wrote: >>>>>> It depends on your definition of software, according to Fedora's >>>>>> definitions firmware is not software it is content. I know this is >>>>>> a word game, but think about it, what is the definition of software? >>>>> >>>>> From the Oxford English Dictionary: >>>>> >>>>> software >>>>> 1. Computers. a. The programs and procedures required to >>>>> enable a computer to perform a specific task, as opposed to the >>>>> physical components of the system (see also quot. 1961). b. esp. >>>>> The body of system programs, including compilers and library >>>>> routines, required for the operation of a particular computer and >>>>> often provided by the manufacturer, as opposed to program material >>>>> provided by a user for a specific task. >>>>> >>>>> >>>>> I didn't realize fedora was claiming that firmware isn't software. >>>>> Now that is bullshit. You call it a word game, I'll call it what it >>>>> is. *Content??!* It's obviously software. I mean, it can be copied, >>>>> it can be rewritten (well, by the people in the castle with the >>>>> code), it can be compiled, etc... Clearly software. I guess you >>>>> need a PhD to delude yourself otherwise. >>>>> >>>>> Usually techs are so precise, I can't believe the doublethinking here. >>>>> >>>> >>>> You are starting to work against yourself. Firmware usually comes >>>> with my devices, it is reloadable but it comes with the device when >>>> I make the purchase, I don't have to load firmware into a device to >>>> make it work in the first place. It is part of the hardware because >>>> the hardware requires it to run. I thought that was why software and >>>> firmware where two different terms. Firmware is software but the >>>> hardware relies on it to function and it is included in the purchase >>>> price of the hardware. Software is generally acquired separately >>>> from the hardware. Windows(software) comes preinstalled on many >>>> computers(hardware) but I can remove windows and still have >>>> functional hardware but if I remove the BIOS , windows nor linux >>>> will run. >>> >>> >>> If you remove the non-free software from tg3.c the device will still >>> work. >> Completely? > > Yes. > >> no loss of functionality whatsoever? > > I think the firmware does some TCP offloading or something so more > processing happens in the card instead of the kernel, but I'm really not > certain what the firmware is doing. In fact, only the people with the > source code know what it's doing, I supppose. > > But it works 100% fine as a regular network card without the firmware. > >> can you still interact with it? > > Yes. > >> I need to be able to interact with a device in order for it to be >> useful to me. My car will run without a driver but its not going >> anywhere. My computer will run without an operator but human >> interaction is required at some point to make it useful to me, if only >> for initial setup. > > The card works fine with linux-libre, no firmware required. > >>> "It is part of the hardware because the hardware requires it to run", >>> you wrote. >> >> I phrased it poorly in hindsight but its more or less true in most >> cases, or I should have said that its needed to interact with other >> hardware or software. > > So you meant "It is part of the hardware because its needed to interact > with the hardware or software" ??? wtf? > >> At some point it has to be configurable by a person through some >> extension or another in order to be useful. > > /sbin/ifconfig > >> I don't think manufacturers obsessed with the bottom line are hiring >> programmers to write unneeded firmware just to annoy free software >> advocates. > > I don't either. > >> >What does that make the non-free software in tg3.c? >> >> >> Unnecessary but is that the case in every instance? > > Does it have to be? I'm just pointing out the things I see in the Linux > kernel that are clearly not free software. > >> I am perfectly willing to be educated/corrected and I have heard >> arguments from both sides that have merit, I am tempted to send a copy >> of the GPL to my lawyer and get the interpretation of someone who >> doesn't have a horse in this race. > > Please do. And show him a copy of tg3.c too please. :) > BTW I never said he, you have made an unwarranted assumption:^) tsktsktsk -- Fortune favors the BOLD From kwizart at gmail.com Wed Jun 18 13:22:56 2008 From: kwizart at gmail.com (KH KH) Date: Wed, 18 Jun 2008 15:22:56 +0200 Subject: Heads Up! Wavpack soname bump In-Reply-To: References: Message-ID: 2008/6/18 Peter Lemenkov : > Hello All! > I just prepared to update wavpack to latest version (4.50). Among some > bugfixes it introduces minor soname-bump ( > /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 ) You can see if upstream has bumped the soname by running this # readelf -a /usr/lib64/libwavpack.so.1.0.1 |grep SONAME 0x000000000000000e (SONAME) Library soname: [libwavpack.so.1] Where the soname is libwavpack.so.1 On the other hand you can check if ABI has actually changed with rpmsodiff wavpack-4.41-1.fc10 wavpack-4.50-1.fc10 Now i'm not really sure of how can be read this output, since there might be symbol that have changed, but was not accessible from a public API (so they are symbols used internally which doesn't produce any ABI incompatibility). The case where ABI breaks is when symbol are removed that might be used by any dependent application. (As I expect). When symbols are only added, this would mean that ABI is preserved and the dependent application can optionally be rebuilt to use theses new symbols (if they are somehow used within the dependant application). It would be nice to have this kind of check from a wiki page. I only find thoses pages on the wiki, related to this subject. http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues http://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks#Application_binary_interface_changes_.28controversial.29 Nicolas (kwizart) From aph at redhat.com Wed Jun 18 13:38:16 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Jun 2008 14:38:16 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48583267.9010009@blagblagblag.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> Message-ID: <48590FC8.8090500@redhat.com> jeff wrote: > max wrote: >> jeff wrote: >>> If you remove the non-free software from tg3.c the device will still >>> work. >> Completely? > > Yes. > >> no loss of functionality whatsoever? > > I think the firmware does some TCP offloading or something so more > processing happens in the card instead of the kernel, but I'm really not > certain what the firmware is doing. In fact, only the people with the > source code know what it's doing, I supppose. > > But it works 100% fine as a regular network card without the firmware. So, let me summarize: we have a bit of binary-only fimware that does goodness knows what in a critical part of our systems. We don't actually need this firmware; it may or may not improve performance. Is this right? It sounds to me as though we're better off without it, regardless of its status with regard to the GPL. Andrew. From lemenkov at gmail.com Wed Jun 18 13:41:34 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 18 Jun 2008 17:41:34 +0400 Subject: Heads Up! Wavpack soname bump In-Reply-To: <20080618131742.GB19397@localhost> References: <20080618131742.GB19397@localhost> Message-ID: 2008/6/18 Miroslav Lichvar : > The soname stays at "libwavpack.so.1", so technically it's not a > soname bump ;). I thought so, but I decided to be more careful :) > Should be safe to upgrade. Good! -- With best regards! From seg at haxxed.com Wed Jun 18 13:49:07 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 18 Jun 2008 08:49:07 -0500 Subject: PackageKit UI In-Reply-To: <485825CA.4090308@gmail.com> References: <1213268950.3505.1.camel@hughsie-work> <1213294373.8892.3.camel@rousalka.okg> <1213343617.3291.8.camel@hughsie-work> <45450.192.54.193.59.1213344474.squirrel@rousalka.dyndns.org> <1218b5bc0806170721k7b493ab9pe6eb9d6b3fa6688e@mail.gmail.com> <485825CA.4090308@gmail.com> Message-ID: <1218b5bc0806180649h48c8e8caw33f8b89289e31a23@mail.gmail.com> On Tue, Jun 17, 2008 at 3:59 PM, Andrew Farris wrote: > Callum Lerwick wrote: > >> On Fri, Jun 13, 2008 at 3:07 AM, Nicolas Mailhot < >> nicolas.mailhot at laposte.net> wrote: >> >> [1] http://www.packagekit.org/temp/gpk-application-multiple.png >>>> >>> I think your main problem was the tabs gallore on the right side. It's >>> probably better to have just one column with information presented >>> sequentially in it >>> >> >> >> Yes, since its presenting information and not UI, use a collapsible tree. >> Like say, Wireshark's packet information display. >> > > I hate having a center column so narrow it needs a scrollbar just to show > the name of most packages. Thats just simply an unusable UI, even if the > right side was collapsible. Well yes, I don't really like the horizontal three panel thing either. Widescreen isn't *that* wide, and I'm not likely to have every last machine in my arsenal upgraded to widescreen for 5 more years, at best. My point about using a tree instead of tabs still stands. Think in terms of varying verbosity rather than flipping through pages... (This goes for yumex as well...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Jun 18 13:49:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 08:49:31 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <48590FC8.8090500@redhat.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> Message-ID: <4859126B.8000205@gmail.com> Andrew Haley wrote: > >>>> If you remove the non-free software from tg3.c the device will still >>>> work. >>> Completely? >> Yes. >> >>> no loss of functionality whatsoever? >> I think the firmware does some TCP offloading or something so more >> processing happens in the card instead of the kernel, but I'm really not >> certain what the firmware is doing. In fact, only the people with the >> source code know what it's doing, I supppose. >> >> But it works 100% fine as a regular network card without the firmware. > > So, let me summarize: we have a bit of binary-only fimware that does > goodness knows what in a critical part of our systems. We don't actually > need this firmware; it may or may not improve performance. Is this right? I don't know if this is correct or varies from device to device but my assumption was that most devices would have a version of firmware installed when shipped and the drivers are updating to current versions. > It sounds to me as though we're better off without it, regardless of its > status with regard to the GPL. Perhaps, if you like old buggy versions of firmware... -- Les Mikesell lesmikesell at gmail.com From dwmw2 at infradead.org Wed Jun 18 13:35:50 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 18 Jun 2008 14:35:50 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <485908AF.5050402@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> Message-ID: <1213796150.26255.1236.camel@pmac.infradead.org> On Wed, 2008-06-18 at 09:07 -0400, max wrote: > David Woodhouse wrote: > > Along with the quotes from one of its authors, who also happens to be > > the overall network driver maintainer for Linux, and has stated that > > each driver and its firmware are 'intimately tied... pieces of a single, > > cohesive whole'. > > > > Why or how have they become "intimately tied"? That's a question you'd have to direct to the author of that file, who said that they were. He ought to know. -- dwmw2 From pertusus at free.fr Wed Jun 18 13:34:29 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 18 Jun 2008 15:34:29 +0200 Subject: Heads Up! Wavpack soname bump In-Reply-To: References: Message-ID: <20080618133429.GE2619@free.fr> On Wed, Jun 18, 2008 at 03:22:56PM +0200, KH KH wrote: > You can see if upstream has bumped the soname by running this > > # readelf -a /usr/lib64/libwavpack.so.1.0.1 |grep SONAME > 0x000000000000000e (SONAME) Library soname: [libwavpack.so.1] > Where the soname is libwavpack.so.1 > > On the other hand you can check if ABI has actually changed with > rpmsodiff wavpack-4.41-1.fc10 wavpack-4.50-1.fc10 > > The case where ABI breaks is when symbol are removed that might be > used by any dependent application. > (As I expect). When symbols are only added, this would mean that ABI > is preserved and the dependent application can optionally be rebuilt > to use theses new symbols (if they are somehow used within the > dependant application). I know about 2 sources of information, for C there is the libtool manual regarding library versionning, http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning it isn't explicit, but can be retrieved from the guideline in http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info soname should change when symbols are removed. For C++ things seems to be more complicated, I know about this: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ -- Pat From jwilson at redhat.com Wed Jun 18 14:07:09 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 18 Jun 2008 10:07:09 -0400 Subject: Someone please take over these packages In-Reply-To: <4858F19C.3000600@nobugconsulting.ro> References: <200806160918.13496.jwilson@redhat.com> <200806180036.38643.jwilson@redhat.com> <4858F19C.3000600@nobugconsulting.ro> Message-ID: <200806181007.09130.jwilson@redhat.com> On Wednesday 18 June 2008 07:29:32 am Manuel Wolfshant wrote: > Jarod Wilson wrote: > > On Tuesday 17 June 2008 07:17:44 pm Manuel Wolfshant wrote: > >> connect-proxy is dead-simple, but dunno how many people > >> > >>> actually have use for it (I did 3 years ago, notsomuch anymore...). > >> > >> Just for the record (after reading > >> http://cvs.fedoraproject.org/viewcvs/rpms/connect-proxy/devel/connect-pr > >>oxy .spec?rev=1.3&view=markup ) shouldn't %source be > >> http://www.meadowy.org/~gotoh/ssh/connect.c rather than the filename > >> that is used now ? > > > > Did you miss the two lines after the Source0 line? :) > > Yes, I did. I did not read the comments :) That should teach me to > [re]act at 3 AM... :) > > ----- > > Source0: connect-%{version}.c > > # Real source listed below, it was renamed for sanity's sake > > #Source0: http://www.taiyo.co.jp/~gotoh/ssh/connect.c > > ----- > > > > I find renaming it much less ugly to deal with multiple versions, > > particularly given the sucktitude of cvs. > > only that this breaks the scripts which download the source from web and > verify md5/sha1 Using the full url the the unversioned source is prone to failure too. If there's a new connect.c posted, the checksums aren't going to match, and you're right back where we started. -- Jarod Wilson jwilson at redhat.com From billcrawford1970 at gmail.com Wed Jun 18 14:25:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 18 Jun 2008 15:25:26 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48590FC8.8090500@redhat.com> References: <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> Message-ID: <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> 2008/6/18 Andrew Haley : > So, let me summarize: we have a bit of binary-only fimware that does > goodness knows what in a critical part of our systems. We don't actually > need this firmware; it may or may not improve performance. Is this right? This sounds like most computer systems (BIOS, although we can usually do without it mostly after boot time) and their components e.g. most modern network interfaces, SCSI controllers and so on, lots of which have some sort of firmware embedded in some way on the card or the main device on it. The next point you make is a good one, ... > It sounds to me as though we're better off without it, regardless of its > status with regard to the GPL. Yes. Which is why we should stop supporting these "PCs" which aren't completely free. > Andrew. From maximilianbianco at gmail.com Wed Jun 18 14:26:33 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 18 Jun 2008 10:26:33 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213796150.26255.1236.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> Message-ID: <48591B19.6080108@gmail.com> David Woodhouse wrote: > On Wed, 2008-06-18 at 09:07 -0400, max wrote: >> David Woodhouse wrote: >>> Along with the quotes from one of its authors, who also happens to be >>> the overall network driver maintainer for Linux, and has stated that >>> each driver and its firmware are 'intimately tied... pieces of a single, >>> cohesive whole'. So the driver and its firmware are indistinct from the whole? You cannot tell where the driver and firmware begin and end? >>> >> Why or how have they become "intimately tied"? > > That's a question you'd have to direct to the author of that file, who > said that they were. He ought to know. > You based your argument around something you haven't confirmed? That hardly seems wise but I can't say I have never done the same, lets all try to avoid this in the future shall we, in such manner are asses made;^). The author is also a programmer yes? not a lawyer? I am not sure the author is qualified in the legal sense to make this determination. The rapid evolution of technologies makes these things especially difficult. Where can I find his quotes? Are they in the documentation? I ask because *if* I forward this along I'll get asked for all this info, it seems quite relevant depending on the basis for this judgement but IANAL (i have always found this combination of letters amusing because I think a good lawyer is anal retentive or I guess any thorough person really, and that's certainly a quality I'd want in my lawyer :^) -- Fortune favors the BOLD From aph at redhat.com Wed Jun 18 14:29:06 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Jun 2008 15:29:06 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> References: <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> Message-ID: <48591BB2.6080400@redhat.com> Bill Crawford wrote: > 2008/6/18 Andrew Haley : > >> So, let me summarize: we have a bit of binary-only fimware that does >> goodness knows what in a critical part of our systems. We don't actually >> need this firmware; it may or may not improve performance. Is this right? > > This sounds like most computer systems (BIOS, although we can usually > do without it mostly after boot time) I think we have to boot. > and their components e.g. most > modern network interfaces, SCSI controllers and so on, lots of which > have some sort of firmware embedded in some way on the card or the > main device on it. Really? We don't need this firmware? Are you sure about that? > The next point you make is a good one, ... >> It sounds to me as though we're better off without it, regardless of its >> status with regard to the GPL. > > Yes. Which is why we should stop supporting these "PCs" which aren't > completely free. I don't understand what you're saying here. Are you saying that we should stop supporting any PC that contains any firmware that isn't free? That seems rather extreme. Andrew. From billcrawford1970 at gmail.com Wed Jun 18 14:33:55 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 18 Jun 2008 15:33:55 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48591BB2.6080400@redhat.com> References: <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> <48591BB2.6080400@redhat.com> Message-ID: <544eb990806180733u3336f3f8lf9606b96e3f8efb1@mail.gmail.com> 2008/6/18 Andrew Haley : > Really? We don't need this firmware? Are you sure about that? We do need it, which was what I was getting at :o) this fuss is ... well, shipping replacements for those firmwares is IMO subtly different to shipping a binary driver to run on the cpu. There *is* an argument that for perfect security (or at least peace of mind) we should consider these a potential source of danger (bugs in firmware might mean random DMA-ing of your crypto keys into a network packet, etc etc but the real risk is likely zero). >> Yes. Which is why we should stop supporting these "PCs" which aren't >> completely free. > > I don't understand what you're saying here. Are you saying that we > should stop supporting any PC that contains any firmware that isn't > free? That seems rather extreme. I was joking :o) If we're content with on-board firmware, what's the harm in shipping replacement firmware to put on those devices when we boot? *shrug* > Andrew. From aph at redhat.com Wed Jun 18 14:42:25 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Jun 2008 15:42:25 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <544eb990806180733u3336f3f8lf9606b96e3f8efb1@mail.gmail.com> References: <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> <48591BB2.6080400@redhat.com> <544eb990806180733u3336f3f8lf9606b96e3f8efb1@mail.gmail.com> Message-ID: <48591ED1.2030907@redhat.com> Bill Crawford wrote: > 2008/6/18 Andrew Haley : > > >> Really? We don't need this firmware? Are you sure about that? > > We do need it, which was what I was getting at :o) Sure, but my argument was not about firmware that we need, it was about firmware that we don't need. > this fuss is ... > well, shipping replacements for those firmwares is IMO subtly > different to shipping a binary driver to run on the cpu. There *is* an > argument that for perfect security (or at least peace of mind) we > should consider these a potential source of danger (bugs in firmware > might mean random DMA-ing of your crypto keys into a network packet, > etc etc but the real risk is likely zero). >>> Yes. Which is why we should stop supporting these "PCs" which aren't >>> completely free. >> I don't understand what you're saying here. Are you saying that we >> should stop supporting any PC that contains any firmware that isn't >> free? That seems rather extreme. > > I was joking :o) But this is a complete non sequitur as a reply to my argument, which was about *unnecessary* firmware updates. I can understand why you say this, but I can't understand why you think it is an appropriate reply to what _I_ said. > If we're content with on-board firmware, what's the harm in shipping > replacement firmware to put on those devices when we boot? *shrug* Well, consider the alternative: every time a hardware manufacturer throws a random binary over the wall and asks us to put it into our kernel, we salute and say "Yes, sir!" Andrew. From maximilianbianco at gmail.com Wed Jun 18 14:36:28 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 18 Jun 2008 10:36:28 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> References: <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> Message-ID: <48591D6C.5030606@gmail.com> Bill Crawford wrote: > 2008/6/18 Andrew Haley : > >> So, let me summarize: we have a bit of binary-only fimware that does >> goodness knows what in a critical part of our systems. We don't actually >> need this firmware; it may or may not improve performance. Is this right? > > This sounds like most computer systems (BIOS, although we can usually > do without it mostly after boot time) and their components e.g. most If you need it at boot time then I don't think you can say you don't need it. However this does lead to another interesting point, Linux BIOS, I know there is the coreboot project : > http://www.coreboot.org/Welcome_to_coreboot I know some boards are supposed to be coming out with Linux BIOS What impact might this have on proprietary firmware and drivers and such? > modern network interfaces, SCSI controllers and so on, lots of which > have some sort of firmware embedded in some way on the card or the > main device on it. The next point you make is a good one, ... > >> It sounds to me as though we're better off without it, regardless of its >> status with regard to the GPL. > > Yes. Which is why we should stop supporting these "PCs" which aren't > completely free. > I'm all for it too but first you have to get completely free options on the market place. People cannot support what is not available. If you know of one then please post a link, I am thinking about a new box and completely free (not referring to price here obviously) would suit me just fine. >> Andrew. > -- The hell you say!! From anders at trudheim.co.uk Wed Jun 18 14:43:43 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Wed, 18 Jun 2008 16:43:43 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859126B.8000205@gmail.com> References: <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <4859126B.8000205@gmail.com> Message-ID: <20080618144343.GJ328@localhost.localdomain> * Les Mikesell [20080618 15:49]: > Andrew Haley wrote: [snip] >> So, let me summarize: we have a bit of binary-only fimware that does >> goodness knows what in a critical part of our systems. We don't actually >> need this firmware; it may or may not improve performance. Is this right? > > I don't know if this is correct or varies from device to device but my > assumption was that most devices would have a version of firmware > installed when shipped and the drivers are updating to current versions. > >> It sounds to me as though we're better off without it, regardless of its >> status with regard to the GPL. > > Perhaps, if you like old buggy versions of firmware... But Les, it's *much* better not to have the patched firmware. Apart from pissing off enterprise customers (and seriously, who cares about them, leeches and scum as they are, ignoring our high horses and principles) you also have benefits such as: * an excuse to rant, rave and throw stones at the _obviously_ incompetent NIC manufacturers that shipped the buggy firmware in EEPROM on the cards in the first place! (We never write buggy code, oh no Sir, and besides, if we write crap code and you complain about it, we can tell *you* to fix it, as you have the code!) * a justification to further spew bile on any and every mailing list in existance about the evilness of binary blobs, because they could never ever ever have been created with any other intent than take away or god-given right to have full access to everything! (But we won't argue that toss with the Government as they may shoot back.) /Anders From aoliva at redhat.com Wed Jun 18 15:12:31 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 12:12:31 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48580C65.5040208@gmail.com> (max's message of "Tue\, 17 Jun 2008 15\:11\:33 -0400") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> Message-ID: On Jun 17, 2008, max wrote: > jeff wrote: >> *Content??!* It's obviously software. I mean, it can be copied, it >> can be rewritten (well, by the people in the castle with the code), >> it can be compiled, etc... Clearly software. > Firmware usually comes with my devices, it is reloadable but it > comes with the device when I make the purchase, I don't have to load > firmware into a device to make it work in the first place. So, per this logic, MS-Windows OEM is not software. Right?!? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 15:14:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 10:14:19 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <48591B19.6080108@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> Message-ID: <4859264B.1050206@gmail.com> max wrote: > >> >> That's a question you'd have to direct to the author of that file, who >> said that they were. He ought to know. >> > You based your argument around something you haven't confirmed? That > hardly seems wise but I can't say I have never done the same, lets all > try to avoid this in the future shall we, in such manner are asses > made;^). The author is also a programmer yes? not a lawyer? I am not > sure the author is qualified in the legal sense to make this > determination. The rapid evolution of technologies makes these things > especially difficult. Where can I find his quotes? Are they in the > documentation? I ask because *if* I forward this along I'll get asked > for all this info, it seems quite relevant depending on the basis for > this judgement but IANAL (i have always found this combination of > letters amusing because I think a good lawyer is anal retentive or I > guess any thorough person really, and that's certainly a quality I'd > want in my lawyer :^) The place to start should probably be with CPU microcode that the kernel contains and installs. There's a pretty good argument that most of the other device firmware doesn't become part of 'the Program' and is a separate thing even when delivered by the kernel. That argument might be a little harder on the thing actually executing 'the Program', but if it works there, it should apply to everything else. My take on it is that it should be the same as downloading a song to an ipod or other player. Regardless of how you store or encode the bits of that song on the way to the device, it is still a separate, independent work and it's just someone else's data bits to the rest of the process even if that process has the GPL restrictions on its own components. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Wed Jun 18 15:28:25 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 12:28:25 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48565FB1.7080204@gmail.com> (Les Mikesell's message of "Mon\, 16 Jun 2008 07\:42\:25 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com > <4855F4B1.2080207@blagblagblag.org> <48560327.4000109@gmail.com> <485612A0.9050104@blagblagblag.! org> <48565FB1.7080204@gmail.com> Message-ID: On Jun 16, 2008, Les Mikesell wrote: > Mistakes happen. Should all old instances disappear when a correction > is made? If you keep on distributing GPL-violating code, you'll keep on losing your license to do so. So, yes, you should stop distributing the infringing versions to claim you have corrected such a problem. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 15:32:03 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 10:32:03 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> Message-ID: <48592A73.5070602@gmail.com> Alexandre Oliva wrote: > On Jun 17, 2008, max wrote: > >> jeff wrote: > >>> *Content??!* It's obviously software. I mean, it can be copied, it >>> can be rewritten (well, by the people in the castle with the code), >>> it can be compiled, etc... Clearly software. > >> Firmware usually comes with my devices, it is reloadable but it >> comes with the device when I make the purchase, I don't have to load >> firmware into a device to make it work in the first place. > > So, per this logic, MS-Windows OEM is not software. Right?!? Whether a certain chunk of bits is or isn't software isn't the point. Would that windows OEM have to become GPL'd if you updated the installed image with clonezilla or similar copying tool? -- Les Mikesell lesmikesell at gmail.com From ihok at hotmail.com Wed Jun 18 15:31:24 2008 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 18 Jun 2008 15:31:24 +0000 (UTC) Subject: firefox plans for F9? References: <4857F24D.40109@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > > Jack Tanner wrote: > > F9 is on a build of Firefox circa Beta 5. Any plans for upgrading that? > > > Yes. F-9 builds are in progress. > And there was much rejoicing. From steven.moix at axianet.ch Wed Jun 18 15:32:37 2008 From: steven.moix at axianet.ch (Steven Moix) Date: Wed, 18 Jun 2008 17:32:37 +0200 Subject: Need package reviewer and sponsor for php-pear-Net-IPv4 and php-pear-Net-DNS Message-ID: <1213803157.13458.13.camel@hp6710.axianet.ch> ?Hello all, I need someone who volunteers to review 2 small packages which are stuck in bugzilla since almost a month: ?php-pear-Net-IPv4: ?https://bugzilla.redhat.com/show_bug.cgi?id=448205 and ?php-pear-Net-DNS: ?https://bugzilla.redhat.com/show_bug.cgi?id=448204 These are PHP Pear libraries that I use in many projects to do network queries, so I thought that it would be a good idea to package them. As these are my first packages in Fedora, I need a sponsor as well. This is also my first post on this mailinglist, so...hi all. I'm Steven, a Swiss engineering student using Fedora since Core 1, wanting to give some of my time back to the community. Thanks for your help! Steven From moe at blagblagblag.org Wed Jun 18 15:49:24 2008 From: moe at blagblagblag.org (jeff) Date: Wed, 18 Jun 2008 12:49:24 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859264B.1050206@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> Message-ID: <48592E84.4020209@blagblagblag.org> Les Mikesell wrote: > max wrote: >> >>> >>> That's a question you'd have to direct to the author of that file, who >>> said that they were. He ought to know. >>> >> You based your argument around something you haven't confirmed? That >> hardly seems wise but I can't say I have never done the same, lets all >> try to avoid this in the future shall we, in such manner are asses >> made;^). The author is also a programmer yes? not a lawyer? I am not >> sure the author is qualified in the legal sense to make this >> determination. The rapid evolution of technologies makes these things >> especially difficult. Where can I find his quotes? Are they in the >> documentation? I ask because *if* I forward this along I'll get asked >> for all this info, it seems quite relevant depending on the basis for >> this judgement but IANAL (i have always found this combination of >> letters amusing because I think a good lawyer is anal retentive or I >> guess any thorough person really, and that's certainly a quality I'd >> want in my lawyer :^) > > The place to start should probably be with CPU microcode that the kernel > contains and installs. There's a pretty good argument that most of the > other device firmware doesn't become part of 'the Program' and is a > separate thing even when delivered by the kernel. That argument might > be a little harder on the thing actually executing 'the Program', but if > it works there, it should apply to everything else. > > My take on it is that it should be the same as downloading a song to an > ipod or other player. Regardless of how you store or encode the bits of > that song on the way to the device, it is still a separate, independent > work and it's just someone else's data bits to the rest of the process > even if that process has the GPL restrictions on its own components. But they've put the firmware itself under the GPL: +++ linux-2.6.7.patch/drivers/net/bcm/5701rls.h 2004-06-22 16:00:00.000000000 -0700 @@ -0,0 +1,198 @@ +/******************************************************************************/ +/* */ +/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */ +/* Corporation. */ +/* All rights reserved. */ +/* */ +/* 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, located in the file LICENSE. */ +/* */ +/* History: */ +/******************************************************************************/ + +typedef unsigned long U32; +int t3FwReleaseMajor = 0x0; +int t3FwReleaseMinor = 0x0; +int t3FwReleaseFix = 0x0; +U32 t3FwStartAddr = 0x08000000; +U32 t3FwTextAddr = 0x08000000; +int t3FwTextLen = 0x9c0; +U32 t3FwRodataAddr = 0x080009c0; +int t3FwRodataLen = 0x60; +U32 t3FwDataAddr = 0x08000a40; +int t3FwDataLen = 0x20; +U32 t3FwSbssAddr = 0x08000a60; +int t3FwSbssLen = 0xc; +U32 t3FwBssAddr = 0x08000a70; +int t3FwBssLen = 0x10; +U32 t3FwText[(0x9c0/4) + 1] = { +0x0, +0x10000003, 0x0, 0xd, 0xd, +0x3c1d0800, 0x37bd3ffc, 0x3a0f021, 0x3c100800, +0x26100000, 0xe000018, 0x0, 0xd, +0x3c1d0800, 0x37bd3ffc, 0x3a0f021, 0x3c100800, +0x26100034, 0xe00021c, 0x0, 0xd, +0x0, 0x0, 0x0, 0x27bdffe0, +0x3c1cc000, 0xafbf0018, 0xaf80680c, 0xe00004c, +0x241b2105, 0x97850000, 0x97870002, 0x9782002c, +0x9783002e, 0x3c040800, 0x248409c0, 0xafa00014, +0x21400, 0x621825, 0x52c00, 0xafa30010, +0x8f860010, 0xe52825, 0xe000060, 0x24070102, +0x3c02ac00, 0x34420100, 0x3c03ac01, 0x34630100, +0xaf820490, 0x3c02ffff, 0xaf820494, 0xaf830498, +0xaf82049c, 0x24020001, 0xaf825ce0, 0xe00003f, +0xaf825d00, 0xe000140, 0x0, 0x8fbf0018, ... more pages of hex I personally downloaded this file believing that I was getting a free GPL driver. Broadcom says so in the patch itself, in the included LICENSE file, and their website when you click to download it. Red Hat is shipping it as GPLv2. So either they have to provide the source (if they have it), stop shipping it, or *at least* stop saying they are shipping a GPLv2 kernel if they are unwilling/unable to provide the source. -Jeff From moe at blagblagblag.org Wed Jun 18 15:58:13 2008 From: moe at blagblagblag.org (jeff) Date: Wed, 18 Jun 2008 12:58:13 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859126B.8000205@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <4859126B.8000205@gmail.com> Message-ID: <48593095.9010405@blagblagblag.org> Les Mikesell wrote: > Andrew Haley wrote: >> It sounds to me as though we're better off without it, regardless of its >> status with regard to the GPL. > > Perhaps, if you like old buggy versions of firmware... Is that what is going on? I thought it was adding TCP offloading[1] or similar. I didn't think it was replacing anything on the card, but adding "features". But I'm guessing you have no real idea what it's doing and are just making up the assertion that it is replacing on board firmware. Of course, if we want to know what it's doing we can just look at the...oh nvm. -Jeff [1] http://en.wikipedia.org/wiki/TCP_Offload_Engine From dwmw2 at infradead.org Wed Jun 18 16:02:00 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 18 Jun 2008 17:02:00 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48591B19.6080108@gmail.com> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> Message-ID: <1213804920.26255.1302.camel@pmac.infradead.org> On Wed, 2008-06-18 at 10:26 -0400, max wrote: > David Woodhouse wrote: > > On Wed, 2008-06-18 at 09:07 -0400, max wrote: > >> David Woodhouse wrote: > >>> Along with the quotes from one of its authors, who also happens to be > >>> the overall network driver maintainer for Linux, and has stated that > >>> each driver and its firmware are 'intimately tied... pieces of a single, > >>> cohesive whole'. > > So the driver and its firmware are indistinct from the whole? You cannot > tell where the driver and firmware begin and end? You can't easily tell them apart in the kernel image, no. It's a bit easier in the driver source, of course. And of course even if you _can_ still identify the separate sections, that doesn't mean the GPL wouldn't apply to them. When the GPL talks about the independent sections which it extends to cover, it actually refers to them as "_identifiable_ sections of [the collective] work". Merely being able to _identify_ the various parts isn't sufficient to claim that they are being distributed 'as separate works'. When you see a book of short stories, do you claim that it's not a collective work just because you can tell where one ends and the next one starts? > >>> > >> Why or how have they become "intimately tied"? > > > > That's a question you'd have to direct to the author of that file, who > > said that they were. He ought to know. > > > You based your argument around something you haven't confirmed? Not at all; it doesn't _have_ to be 'intimately tied' for the GPL to apply to the whole work; my argument isn't at all based on the fact that they are 'intimately tied'. I think it's fairly obvious that what we're distributing is a single cohesive whole which combines both GPL'd kernel code and the firmware. The argument that they are actually being distributed "as separate works" is fairly insane, and the claim that it is "mere aggregation on a volume of a storage or distribution medium" is also extremely far-fetched, IMO. To call it 'intimately tied' is an even stronger assertion, and I was merely pointing out that that's the publicly stated opinion of an expert in the field (of these drivers), who has actually _created_ a number of these combined works of driver+firmware. The original copy is here: http://www.spinics.net/lists/netdev/msg65908.html cf. http://www.spinics.net/lists/netdev/msg65919.html -- dwmw2 From moe at blagblagblag.org Wed Jun 18 16:03:19 2008 From: moe at blagblagblag.org (jeff) Date: Wed, 18 Jun 2008 13:03:19 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <544eb990806180733u3336f3f8lf9606b96e3f8efb1@mail.gmail.com> References: <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> <48591BB2.6080400@redhat.com> <544eb990806180733u3336f3f8lf9606b96e3f8efb1@mail.gmail.com> Message-ID: <485931C7.7070308@blagblagblag.org> Bill Crawford wrote: > If we're content with on-board firmware, what's the harm in shipping > replacement firmware to put on those devices when we boot? *shrug* No harm if you don't mind proprietary software. Microsoft ships it all the time. But they don't say they are shipping a GPLv2 kernel in a completely free operating system, like Fedora does. -Jeff From paul at all-the-johnsons.co.uk Wed Jun 18 15:23:31 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 18 Jun 2008 16:23:31 +0100 Subject: dbus problems Message-ID: <20080618151215.M37637@all-the-johnsons.co.uk> Hi, I seem to be having some rather large problems with my x86 laptop. It looks like there is a problem with dbus somewhere. What happened was this. Last week, I ran file-roller as sudo to copy something into /usr/local. For some reason, most of the applets vanished and it looked like a gconf error. Everything hung. I restarted X, but all I got was the mouse pointer and the animated circle things. I restarted the machine and lots of things went wrong. avahi, mysql, httpd and haldaemon all fail to start. If I try to login, all I get is a message that there is no /home directory for a particular user. I can log in as root. If I try gconftool2 --spawn, everything seems fine. If I try to start haldaemon with /etc/init.d/haldaemon restart, it fails If I try to start mysqld with /etc/init.d/mysqld restart, I get a timed out error If I try to run lshal, all I get it error: dbus_bus_get: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Any suggestions on what to look for or alter? I'm running rawhide and updated today. TTFN Paul -- Programmer, GirlGamer www.girlgamer.com From walters at verbum.org Wed Jun 18 16:48:38 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 18 Jun 2008 12:48:38 -0400 Subject: dbus problems In-Reply-To: <20080618151215.M37637@all-the-johnsons.co.uk> References: <20080618151215.M37637@all-the-johnsons.co.uk> Message-ID: On Wed, Jun 18, 2008 at 11:23 AM, Paul F. Johnson < paul at all-the-johnsons.co.uk> wrote: > > error: dbus_bus_get: org.freedesktop.DBus.Error.NoServer: Failed to connect > to socket /var/run/dbus/system_bus_socket: Connection refused > It's possible that the system bus crashed. I wish I could tell you to look at the apport crash store. You should reboot. If it happens again, see: http://fedoraproject.org/wiki/StackTraces (until we integrate apport, then you won't need to do this manually) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aoliva at redhat.com Wed Jun 18 17:54:15 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 14:54:15 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856C6CE.4020107@gmail.com> (Les Mikesell's message of "Mon\, 16 Jun 2008 15\:02\:22 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> Message-ID: On Jun 16, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: > (although Red Hat seems to ignore this > part and attach contract restrictions to what they distribute anyway). Conclusion: you misunderstand both the GPL (as you already proved before) and the Red Hat service agreements. > There are patented components that people need Nothing in the GPL prevents them from getting them. If someone can't distribute software under the GPL that implements patents, that's because the patent holder didn't permit the software to be distributed under the GPL, not because the GPL didn't permit the work to be distributed under the GPL. > and components where > the best implementation is under someone else's copyright. Nothing in the GPL prevents anyone from distributing software under anyone else's copyrights. It's copyright law or third-party-imposed restrictions that do. > I've explained that the GPL prevents me from sharing original work > that links to both GPL and non-GPL libraries. And I've explained that it doesn't, and asked you to cite the passage of the GPL that prevents you from doing it. You haven't bothered to do it, and instead decided to keep insisting in this nonsensical claim. Please stop spreading lies. We're past the point in which you could claim ignorance as to this point. > You are deliberately avoiding the point that there is proprietary > software which is worth what it costs and where the money paid for it > goes toward improvements. I don't dispute that it costs money to farm tobacco, manufacture cigarettes and transport them to points of sale. This doesn't change the fact that smoking is bad for the smoker's health, and for those in the vicinity. I don't see that the points are even related. It's just as irrelevant as whether slavery-based businesses are more or less profitable. This is a matter of ethics and morals, not economics. >> Now, when you accept a license that deprives you from any of the four >> essential freedoms, this harms you *and* everyone around. You're >> shooting your own foot, but the shrapnel hurts others. > No, you are just making this up. Show that it is true for every piece > of software or admit it is an overgeneralization. ^ non-Free http://fsfla.org/svnwiki/blogs/lxo/draft/free-software-moral-proof http://fsfla.org/svnwiki/blogs/lxo/draft/flisol-libre-2008 >>>> See? If my conviction you disputed above is wrong, then the person >>>> who decides to distribute cigarettes to the kids instead of milk would >>>> be behaving in accordance with moral and ethics. >>> Your reasoning requires you to know that cigarettes are harmful and >>> there is a body of evidence for that, >> Exactly! So, you now see that your claim that the delivery channel >> that makes a decision as to what to deliver is amoral didn't resist >> scrutiny. Good. > No, I'm saying you have jumped to unwarranted conclusions. There are two different points here. 1. whether or not the distribution channel can be morally responsible for what's being distributed in the channel. You've admitted that, when there is a body of evidence that shows that a product is harmful, then the distribution channel that chooses to distribute that product is indeed in moral fault 2. whether or not non-Free Software is harmful I claimed you agreed to 1. You dispute this claim by disputing 2. This isn't logically sound. >> But there is a body of evidence that software that is not Free is >> harmful. I wouldn't think this is a place where people would dispute >> this, even if they fail to resist such software themselves. > I dispute it, and would go so far as to say most free software has > copied much of its design from commercial/proprietary work (generally > a good thing!), Most definitely a good thing, for it enables people who are emprisoned by the non-Free work to unchain themselves. > and quite a lot was actually originally developed to > be proprietary work and later had the free license applied. Reasonable people will eventually come to their senses, especially if they place "doing good" over "making profit". And that's a much simpler fix than having to rewrite it all. > I'd say that without the proprietary works, free software would > barely exist and would have much less chance of future development. You may be basing these guesses on recent past history. But turns out it's false both for early computing history and for recent computing history. A lot of the non-Free Software industry these days is holding up to their Improper Privileges and using that to stop advances in Free and non-Free competitors. And still we're gaining ground. > Can you play Netflix online content? No idea. What's Netflix? Is it available in Brazil? Why wouldn't I be able to play its content, does it use any secret formats that were not reverse engineered into Free Software implementations? (regardless of patents, most of the patents that cover file formats apply only in a few countries, so the software that implements them is Free Software) > Do you have the optimal video drivers for all available hardware? I'm happy enough with what I have, but there are times when I wish I wasn't denied the information that would have enabled me to use the video hardware better. > Will your wireless work with all available hardware? I don't see any reason why this USB stick wouldn't work on any USB-capable computer running the corresponding 100% Free Software driver. > Can you play dvds with what was included? I installed Free Software programs to do that. I wish Fedora could ship them, but unfortunately the US laws are unjust and Fedora decides not to accept the risk of distributing them. If I were to switch from Fedora to say BLAG, I'd have these programs right out of the box. >> And then, it's not like I'd drive people to the monster. > Ummm, where do you expect them to go? Away from the monster, evidently. http://fsfla.org/svnwiki/blogs/lxo/draft/freedom-eating-monster >> My personal choice is just a small drop in the ocean. The >> moral imperative for me to promote the idea of freedom for all >> software users goes far beyond whatever individualism you might be >> trying to imply here. > Are you sure you only think this about software - or is this a general > political statement? It is certainly more general, but I'm working on an area I happened to become competent on, which might presumably make me more effective in promoting these ideas. >> Show me one piece of proprietary software, and you'll have a piece of >> software that doesn't work perfectly for all its users, and that at >> least some users would like to be able to improve and/or fix it. > How is this morally different from hardware? It isn't, once someone finds a way that enables anyone to copy hardware (with or without modifications) at nearly-zero cost. Denying information that would enable someone to do so is just as unethical in one case as in the other. > I have at least as many problems with hardware but I don't demand > that the hardware vendors give me a factory. Respecting your freedom doesn't mean driving you around to wherever you like, it's about not putting chains and roadblocks to stop you from getting to some places you might want to go. > I've had an equal amount of trouble with free software and having > source has not meant that I could fix it. You could still hire someone to do so. You had the choice to do that or live with what you had. With non-Free Software, someone else makes that decision for you. That's the difference. >>> I don't have any different feelings about trusting a company to build >>> hardware than to supply software. >> Me neither, actually. > But there's not a moral difference, nor a more or less evil intent in > using the same terms. Agreed. >> Who's stopping you from distributing the code? I take it you think >> it's the GPL, but it's not. Look for anything in the GPL that tells >> you you can't do that. > It says I can't do that. Where? > I can't put it under the GPL if it uses any other components. And why can't you do that? > Yes, nothing wrong with that. (x3) And still, that's what prevents you from distributing the work you wanted to distribute, and you complain about it and decide it's GPL's fault for not bending over to respect your freedom more than others'. You seem to forget then one's freedom to move their hands ends as it approaches someone else's nose. Freedom is not about being able to do whatever you like. When you disrespect others' freedom, you're no longer operating within your own freedom, you're using power to impose your choices upon others. > Because those others don't prohibit combinations. Still, they aren't enough permission for you to distribute the work the way you want. Why do you focus your frustration on the GPL? > The point of getting a proprietary library is to be able to link > other code with it. Why do you limit yourself to libraries that are part of development packages? Most of the non-Free libraries out there are not distributed for purposes of development, they're just DLLs for sharing of code among multiple programs. > It is only the GPL restriction that harmfully prohibits combining > differently licensed code, taking away the freedom of the recipient > to choose if terms of those other licenses are acceptable or not. Repeating it won't make it true. Please quote the portion of the GPL that establishes this prohibition. >>> Likewise, I don't consider all commercial/proprietary distributions >>> to be unethical. Some provide good value for their terms. >> Slavery was also profitable to the slave owners and advantageous to >> those who purchased products at lower prices. > So is normal employment - bad analogy. Do you consider normal employment unethical? I don't. But I hope we both agree that slavery is. So, here's agreement that the same end result may be achievable in both ethical and unethical means. Thus, there's moral responsibility in that who makes the decision between behaving ethically or not. > Which is why applying the GPL is unethical. Once you realize that your frustration is misdirected, we'll both agree that current copyright law is unjust, and those who pushed it into becoming so unjust behaved unethically and immorally. >>> So how does that work in the case of something like a blu-ray player? >> >> Don't even get me started on DRM :-) > You can't avoid it. Actually, I can, because I'm lucky to live in a country in which copyright laws aren't so messed up. > I'd even say it has a place given that everyone > involved knows that it devalues the product when applied. Again, respecting one's freedom to shoot one's own foot doesn't involve enabling one to force others to get hurt with the shrapnel. > Without it, you'd have a hard time making a business model out of > streaming content or low priced subscription/rental access to > content with a restricted time to live. You're again mixing up ethics with economics. That a viable business model requires acting unethically doesn't make it any more acceptable or justifiable. It just makes it an unethical business, until someone devises a viable and ethical way to make money with it. > As a consumer I want those options, although I don't want any usage > restrictions on anything sold to me in the guise of a product. Like, "I want farmers to have the option of buying slaves, although I don't want to buy products manufactured with the participation of slaves"? > If by conspiracy you mean legal/licensed terms for intellectual > property, that is correct whether we like it or not. Don't get me started with showing that Intellectual Property is BS to get people to confuse copyrights, trademarks and patents as if they had anything to do with each other, and as if there was any resemblance between things you can only share by dividing and things you can share by multiplying. That's just part of the same conspiracy that is trying to impose DRM on us. > The choice is to participate according to the law and licensing terms > (which may be acceptable) or not. If free software divisively > prevents participation, users will only have the choice of staying > with the monopoly. That who prevents participation is that who imposes the restrictions that keep people divided and helpless, and keep them from sharing and building upon existing knowledge and contributing to the common good. Free Software is the exact opposite of this. Users have the choice of enslaving themselves to the monopoly, or starting their own, rather than joining our community, for sure, even if it's a poor choice. But they don't always get to use our code for that, because of the very laws that their selfish anti-social mindframe created. Cool, eh? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aph at redhat.com Wed Jun 18 18:02:49 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Jun 2008 19:02:49 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> Message-ID: <48594DC9.6080105@redhat.com> Alexandre Oliva wrote: > On Jun 16, 2008, Les Mikesell wrote: > >> I've explained that the GPL prevents me from sharing original work >> that links to both GPL and non-GPL libraries. > > And I've explained that it doesn't, and asked you to cite the passage > of the GPL that prevents you from doing it. You haven't bothered to > do it, and instead decided to keep insisting in this nonsensical > claim. Actually, he did reply to that, but perhaps you didn't see it. He had an unfree program (the wattcp library) and GNU tar and discovered that he wasn't allowed to ship a program that linked these two together. He then said, gloriously, "please don't try to say the problem was cause by those other licenses - they did not prevent anyone else from getting copies..." :-) OK Les, I promise not to say it. However... Andrew. From aoliva at redhat.com Wed Jun 18 18:05:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 15:05:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4857CF90.2090602@gmail.com> (Les Mikesell's message of "Tue\, 17 Jun 2008 09\:52\:00 -0500") References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> Message-ID: On Jun 17, 2008, Les Mikesell wrote: > If it's silly, then you shouldn't have any problem showing where it is > executed as part of "the Program", Execution is irrelevant, because copyright law doesn't apply to this act. It is *distributed* as part of the program, and that's what copyright law restricts by default. And it's distributed as inseparable part of the program while at that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 18:07:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 15:07:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213711296.14357.18.camel@nibbler.dlib.indiana.edu> (Brian Wheeler's message of "Tue\, 17 Jun 2008 10\:01\:36 -0400") References: <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <20080617133658.GF328@localhost.localdomain> <1213711296.14357.18.camel@nibbler.dlib.indiana.edu> Message-ID: On Jun 17, 2008, Brian Wheeler wrote: > or somewhere in the FSF realm. What does the FSF have to do with the kernel Linux? AFAIK it doesn't hold any copyrights over it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 18:29:31 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 15:29:31 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855C45D.6080809@blagblagblag.org> (jeff's message of "Sun\, 15 Jun 2008 22\:39\:41 -0300") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> Message-ID: On Jun 15, 2008, jeff wrote: > To me it appears quite clear that Broadcom is distributing a GPL'd > file, and thus has to turn over the source code. Actually, it doesn't have to do that, because they're (presumably) the copyright holders, rather than licensees that, because of copyright law, need a license to distribute the software, and who are thus subject to the conditions the GPL sets forth for distribution. > Can someone explain to me why they are *not* now required to > distribute the source code to this? When they distribute binaries under the GPL without offering sources, they're telling everyone else that redistribution is not permitted until the copyright expires or is outlawed. One might claim they're inducing copyright infringement of other GPLed packages though. Think of it this way: only the copyright holder has standing to enforce a copyright license. If Broadcom is the only copyright holder, why would they sue themselves and demand themselves to comply or stop distributing the program? Also note that it is extremely unlikely that a copyright infringement trial would ever come out with a ruling of "defendant must distribute complete corresponding source code under the GPL". A more likely ruling would be "defendant must cease infringement, and owes damages to the copyright holder". -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 18:33:40 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 15:33:40 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4855DE87.6020002@blagblagblag.org> (jeff's message of "Mon\, 16 Jun 2008 00\:31\:19 -0300") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855C45D.6080809@blagblagblag.org> <1213582759.3861.11.camel@localhost.localdomain> <4855DE87.6020002@blagblagblag.org> Message-ID: On Jun 16, 2008, jeff wrote: > Tom "spot" Callaway wrote: >> On Sun, 2008-06-15 at 22:39 -0300, jeff wrote: >>> To me it appears quite clear that Broadcom is distributing a GPL'd >>> file, and thus has to turn over the source code. >> >> I would encourage you to pursue this with Broadcom, as they are clearly >> the copyright holder for the firmware. > Well, and RedHat too. Yep. Anyone who would like to distribute this program needs to ask Broadcom for the source code to be able to distribute it in compliance with the terms of the license. Not doing so means exposing oneself to the possibility of a copyright infringement law suit from Broadcom. (FTR, I acknowledge it's not that simple, and then IANAL) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 18:35:51 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 13:35:51 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> Message-ID: <48595587.2010606@gmail.com> Alexandre Oliva wrote: > >> If it's silly, then you shouldn't have any problem showing where it is >> executed as part of "the Program", > > Execution is irrelevant, because copyright law doesn't apply to this > act. Does that mean you disagree with the FSF claim that it is not permitted to distribute non-GPL'd software that dynamically links to unique libraries only available under the GPL? And the GPL's 'work as a whole' concept doesn't apply to the running program? If it is actually permissible to deliver any combination of components separately under different licenses with tools to combine them at run time, then the GPL is not nearly as harmful as I've believed. > It is *distributed* as part of the program, and that's what copyright > law restricts by default. Which is irrelevant if you have permission to distribute all parts. It is only the weirdness of the GPL denying the right to distribute under many conditions that even makes this a question. > And it's distributed as inseparable part of > the program while at that. I don't see how you can say it is inseparable when the firmware downloader understands the separation perfectly - and nothing else really needs to. Or that it's a part of the program since it gets installed on different hardware - except maybe for the CPU microcode. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Wed Jun 18 18:42:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 15:42:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806160449.m5G4nTxS019826@laptop13.inf.utfsm.cl> (Horst H. von Brand's message of "Mon\, 16 Jun 2008 00\:49\:29 -0400") References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <200806160449.m5G4nTxS019826@laptop13.inf.utfsm.cl> Message-ID: On Jun 16, 2008, "Horst H. von Brand" wrote: > Les Mikesell wrote: >> They claim that it doesn't matter if the components are >> distributed separately or not. For example, you can't modify a GPL'd >> component so that it needs a library under different terms even if the >> parts are never distributed together. > Sure you can. In the heyday of GNU software it was /only/ run on > propietary systems, and all that software was routinely modified > with the express purpose of running on newer/changed versions of > propietary systems (which were the only ones available, remember). But the permission to distribute the combined works is presumably covered by the system library exception. I don't think it's enough to distribute a non-GPLed library separately to have permission under the GPL to distribute a program derived from it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 19:10:08 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:10:08 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806160429.m5G4Toh6018959@laptop13.inf.utfsm.cl> (Horst H. von Brand's message of "Mon\, 16 Jun 2008 00\:29\:50 -0400") References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <200806160429.m5G4Toh6018959@laptop13.inf.utfsm.cl> Message-ID: On Jun 16, 2008, "Horst H. von Brand" wrote: > Unless all you write is "Hello, world!" you are sure to infringe on > hundreds of patents. Dude. This discussion has nothing whatsoever to do with patents. Are you trying to make things confusing, or are you unable to tell the difference? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 19:15:47 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:15:47 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806160418.m5G4I5U6018437@laptop13.inf.utfsm.cl> (Horst H. von Brand's message of "Mon\, 16 Jun 2008 00\:18\:05 -0400") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <200806160418.m5G4I5U6018437@laptop13.inf.utfsm.cl> Message-ID: On Jun 16, 2008, "Horst H. von Brand" wrote: > Alexandre Oliva wrote: >> d. two works are combined into a single coherent work, undoubtedly a >> derivative from both, regardless of whether the two works were >> originally related, and then the derivative work is distributed > If they were originally not related, just gluing them together doesn't > make them derivatives of each other. I said the *collective* work is derived from both. You're disputing a straw man. I didn't claim they became derivatives of each other. This wouldn't make sense. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 19:16:41 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:16:41 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213625867.26255.773.camel@pmac.infradead.org> (David Woodhouse's message of "Mon\, 16 Jun 2008 15\:17\:47 +0100") References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <4855F4B1.2080207@blagblagblag.org> <20080616131510.GA1272613@hiwaay.net> <1213625867.26255.773.camel@pmac.infradead.org> Message-ID: On Jun 16, 2008, David Woodhouse wrote: > {0x14, 0x00}, /* Underline location */ > {0x17, 0xe3}, /* CRT mode control */ > {0x70, 0x00} /* Interlace control */ > I don't see anything wrong with _that_ at all. There isn't. It's the rest of the entries in the array, that are totally incomprehensible, that get in the way of the enjoyment of freedom #1. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 19:24:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:24:35 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48565FC0.2040707@fedoraproject.org> (Rahul Sundaram's message of "Mon\, 16 Jun 2008 18\:12\:40 +0530") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> <48565B6C.3030902@blagblagblag.org> <48565FC0.2040707@fedoraproject.org> Message-ID: On Jun 16, 2008, Rahul Sundaram wrote: > http://www.gnu.org/philosophy/free-system-distribution-guidelines.html > Certain forms of software being non modifiable is perfectly ok > according to FSF. Err... I'm sure there's some misunderstanding here somewhere. Where did you get that idea? Do you by any chance mistake 'non-functional data' (images, songs, etc) for software? > Fedora as a project has done more to promote free software than most > mainstream distributions. I think that's true, even though it has regressed in this regard in the past 2 or 3 releases. > We aren't perfect however and that is well known. We shouldn't claim otherwise, though, to avoid misguiding people and generating useless discussions between the well-known truth and claims that conflict with it, as much as we'd like the claims to be true and the well-known truth to be past mistakes long fixed. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 19:02:43 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:02:43 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4856680A.7070509@gmail.com> (Les Mikesell's message of "Mon\, 16 Jun 2008 08\:18\:02 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> Message-ID: On Jun 16, 2008, Les Mikesell wrote: > Except when the separate parts are identifiable and not derived. *and* *not* distributed as part of a single work derived from the Program. > No, I just can't ignore what the COPYING file actually says. And nevertheless you do ;-) > "If identifiable sections of that work are not derived from the Program ..." "... when you distribute them as separate works" that's the same sentence you started quoting, BTW. Do you dispute that e.g. tg3.c as it stands is part of a single work? And that it's derived from a (theoretical? unpublished?) earlier version of tg3.c that was entirely under the GPL? (Or, if you don't go for that, that the combination of tg3.c not entirely under the GPL with third-party code that was present in Linux before, under the GPL, created a derived work that could only be distributed in its entirety under the GPL?) >> If you can identify the separate short stories in an anthology, do you >> think that somehow means that it isn't a collective work? > "Collective work" is not a relevant issue. ... because you it would show you may be mistaken? But, sure, if you want to claim it's not a collective work, fine. It's clearly a single work. It's clearly derived from earlier works that were under the GPL. What would you claim in defense if you were sued by any of the Linux copyright holders from back when it was purely under the GPL? That the resulting work isn't a derived work? That it's a mere aggregation of a formerly-separate work with a derived work from the GPLed code base that hasn't been published as a separate work for several years, and that would require modifications to even make sense if you took out the supposedly-still-separate portions? Why would you even take the risk of being sued for that? > who can identify the sections (like maybe the person who put them > there...) and make a determination if they were "derived from the > Program". Do you dispute that tg3.c is derived from (i) earlier versions of Linux, and (ii) the firmware it contains? > We already know they are separate, since they get dumped > into separate hardware. As in, a movie is not a single work, but rather a mere aggregation of independent separate works in a single DVD, because the video gets processed by our eyes whereas the audio is processed by our ears? And, come to think of it, even the video is a mere aggregation in itself, because even though it's compressed, it's a mechanical transformation out of a sequence of clearly separate and independent pictures. Right? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 19:37:00 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 14:37:00 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <48594DC9.6080105@redhat.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> Message-ID: <485963DC.70308@gmail.com> Andrew Haley wrote: > >>> I've explained that the GPL prevents me from sharing original work >>> that links to both GPL and non-GPL libraries. >> And I've explained that it doesn't, and asked you to cite the passage >> of the GPL that prevents you from doing it. You haven't bothered to >> do it, and instead decided to keep insisting in this nonsensical >> claim. > > Actually, he did reply to that, but perhaps you didn't see it. > > He had an unfree program (the wattcp library) and GNU tar and > discovered that he wasn't allowed to ship a program that linked > these two together. He then said, gloriously, "please don't try > to say the problem was cause by those other licenses - > they did not prevent anyone else from getting copies..." :-) > > OK Les, I promise not to say it. However... I'm not sure what you are trying to imply here. I could redistribute copies of the other two components - but that's irrelevant since anyone could get them in source anyway (they were only unfree in the reverse way that the GPL redefines free to mean restricted). I could have redistributed the combination if I had started with the original pdtar instead of gnutar. There is no reasonable interpretation that anything but the GPL restrictions applied along with the changes between the pdtar and gnutar versions restricted distribution of my subsequent modification of the gnutar code. All of the other components were distributable except for my own work to combine them. Of course I was mistaken at the time in thinking that GPL'd code was suitable for re-use and sharing and know better now. At the time I was simply deceived by something that claimed to be free. -- Les Mikesell lesmikesell at gmail.com From s-t-rhbugzilla at wwwdotorg.org Wed Jun 18 19:38:53 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Wed, 18 Jun 2008 13:38:53 -0600 (MDT) Subject: fedora-politics mailing list Message-ID: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> Would it make sense to create a separate fedora-politics mailing list, to separate such discussions out of the -devel list? From dimi at lattica.com Wed Jun 18 19:40:13 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 18 Jun 2008 15:40:13 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> Message-ID: <1213818013.20650.60.camel@dimi.lattica.com> On Wed, 2008-06-18 at 16:02 -0300, Alexandre Oliva wrote: > > Except when the separate parts are identifiable and not derived. > > *and* *not* distributed as part of a single work derived from the > Program. FOR FSCKS SAKE, CAN YOU GUYS KNOCK IT OFF?!? This thread has been going on for at least 10x more then the worst offender in the past. -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Wed Jun 18 19:42:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jun 2008 01:12:44 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> <48565B6C.3030902@blagblagblag.org> <48565FC0.2040707@fedoraproject.org> Message-ID: <48596534.3040604@fedoraproject.org> Alexandre Oliva wrote: > On Jun 16, 2008, Rahul Sundaram wrote: > >> http://www.gnu.org/philosophy/free-system-distribution-guidelines.html > >> Certain forms of software being non modifiable is perfectly ok >> according to FSF. > > Err... I'm sure there's some misunderstanding here somewhere. Where > did you get that idea? > > Do you by any chance mistake 'non-functional data' (images, songs, > etc) for software? Not all game maps are purely non functional data for example. GFDL has non variant sections and so on. I am still working with FSF to clarify such details. Suffice to say there are lots of border line cases. Rahul From aoliva at redhat.com Wed Jun 18 19:49:37 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 16:49:37 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48561F66.9070308@hhs.nl> (Hans de Goede's message of "Mon\, 16 Jun 2008 10\:08\:06 +0200") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> Message-ID: On Jun 16, 2008, Hans de Goede wrote: > Basicly the message you are sending is: people please by devices with > firmware in rom, preferably otp rom, because then certainly there is > no evil. You can tell that for sure, but then the barrier that prevents people from making modifications is not an entirely artificial one, it's not a privilege that the vendor unethically chooses to keep to itself, to the detriment of those who paid for the privilege of using an artificially-restricted device. > Not being able to ever change the firmware is good, It's not. Being Free to change it would undoubtedly be better. > I should do away with all my PC's and instead switch to an internet > appliance device, because then I no longer have to worry about whether > I have any non-free software at all. Like myself, you may very well be surprised when you find out that the unmodifiable software in there is actually modifiable, and it may actually be modified behind your back. > So the goal of linux-libre is to not distribute non-free software. Do > you ever buy a PC / laptop? Yep. > If so you're involved in a transaction which almost certainly > involves the distribution of non-free firmware. That's true, much to my dismay. > Worse, not only are you involved in such a transaction, you > are _paying_ for the system of which the non-free firmware is an > integral part and thus you are paying for non-free firmware, thereby > promoting the production of non-free firmware. That's right. And I even wrote an article apologizing for having harmed all fellow computer users doing this and other things. http://www.fsfla.org/svnwiki/blogs/lxo/draft/flisol-libre-2008.en > Do you ever sell any of you PC hardware (motherboard, latop, printer) > second hand and / or give it away to friends / family, then you are > *DISTRIBUTING* non-free firmware. That is true. Shame on us. At least we're not further feeding the monster when we do this, even though we're inducing more people to accept the restrictions of firmwares they hadn't accepted before. > Really, they should put you in prison for that! We're already in prison. And some of us are trying really hard to get out of it. Meanwhile, most of the people tell us that it's pointless, why bother, we have food, shelter and work here, and it only costs us our freedom. Some people out there, who claim to care for us, even try to help us by bringing us mattresses, clothes, blinds and earplugs so that we don't get to the truth, that we were all born into bondage, in a prison that we can't smell or taste or touch. A prison for our minds. http://fsfla.org/~lxoliva/fsfla/whatisthematrix/ They think they're helping us by making us more comfortable, but in truth they're just making the prison less intolerable, so that fewer of us bother to work together to try to win our freedom back. Some even fight us when we discuss our plans about how to become free and what we're going to do out here, labeling us as hypocrites with nonsensical arguments such as, if we're not free, how could we possibly ask others to help us all escape prison? Others will even incite fear and doubts as to what's out there to discourage them from pursuing freedom. Sorry, I got a bit carried away here. What was your point, again? > Putting it simply there are 2 possible stances on non-free firmware: How about 3? 3) it's evil, it's here and (just like any non-Free Software) we should all do as much as we can to get rid of it and discourage this form of aggression, rather than inducing people to get more of it and further empower the aggressors. Refraining from distributing the non-Free Software won't stop anyone from getting to it and using it, if they choose to do so. But this is no excuse to help them do so. But distributing it may legitimize it, make people think it's acceptable, or even to fool themselves into thinking it respects them, even to the point of recommending it to others. And distributing it in a way that doesn't give people even the option of not installing it could make them seem absolutely necessary, which is even worse. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 20:01:38 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 17:01:38 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48546856.9050900@gmail.com> (Les Mikesell's message of "Sat\, 14 Jun 2008 19\:54\:46 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> Message-ID: On Jun 14, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >>> I'm not mistaken. Everything in there except the conditional grant to >>> use, modify, distribute is a restriction. >> Like what? Tell me *anything* you could do in the absence of the GPL, >> that, by accepting the GPL, you can no longer do. > Given (or knowing about) a library not covered by the GPL, I can write > and distribute original work that uses the functions provided by that > library, knowing that anyone can obtain their own copy of by my code > and the additional library and use them together. Assuming you have permission from the copyright holder of the library to do so. If you do, whether or not the library is also available under the GPL won't make any difference. I get the impression you misunderstood the question. I'm not asking something you could do if you had some other permissive license that you couldn't do with the GPL. What I'm asking is whether you know of anything that, in the absence of a copyright license, you could do with a work, that, after accepting the GPL, you could no longer do. This would be a prohibition of the GPL. Anything else that you might believe to be a prohibition of the GPL is actually a prohibition from copyright law, that the GPL refrains from lifting. >> Another fallacy. "You can redistribute under the same license" >> doesn't divide, it has quite the opposite effect. It's permitting >> redistribution under any licenses that may lead to forks, including >> ones that don't permit further modifications. > You can't permit redistribution of something you have prohibited from > existing in the first place. You could, but this doesn't apply to the GPL anyway. The GPL doesn't forbid [anything, not even] the creation of any derived works (and no permission is needed to create non-derived works). > for example the original BSD license which is about as far from > proprietary as you can get. Not true, in two senses. 1. the modified BSD license is even more permissive than the original BSD license, and it is GPL-compatible :-) 2. there is a lot of non-Free (as you say, proprietary) Software distributed in part or as a whole under the original and the modified BSD licenses > I agree that the separation would be more obvious > if the bits were not embedded as data in the kernel in whatever format > the compiler decides to use ... and the code hadn't been modified so as to require the presence of those bits in there and so on... > You could probably modify the compiler to store data in a separate > file instead of whatever embedded memory-loading format it currently > uses but it wouldn't change the copyright status of the output. Agreed. The resulting object file would be just as derived from both, and the source file modified to require the presence of the firmware would still be just as derived from both. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jspaleta at gmail.com Wed Jun 18 20:03:59 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 18 Jun 2008 12:03:59 -0800 Subject: fedora-politics mailing list In-Reply-To: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> References: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <604aa7910806181303p26d1016ake77ba81671ea14a5@mail.gmail.com> On Wed, Jun 18, 2008 at 11:38 AM, Stephen Warren wrote: > Would it make sense to create a separate fedora-politics mailing list, to > separate such discussions out of the -devel list? Huh? As long as the first topic is a discussion concerning Fedora officially endorsing Obama for US President. -jef From lesmikesell at gmail.com Wed Jun 18 20:10:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 15:10:24 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> Message-ID: <48596BB0.1080909@gmail.com> Alexandre Oliva wrote: > >> Except when the separate parts are identifiable and not derived. > > *and* *not* distributed as part of a single work derived from the > Program. Yes, those are true - it's not derived from 'the Program' and it is an identifiable separate section. It doesn't say everybody has to be able to identify the sections, but I'm sure someone can and the computer can. >> No, I just can't ignore what the COPYING file actually says. > > And nevertheless you do ;-) No, I even quoted it. >> "If identifiable sections of that work are not derived from the Program ..." > > "... when you distribute them as separate works" > > that's the same sentence you started quoting, BTW. > > Do you dispute that e.g. tg3.c as it stands is part of a single work? It is an aggregate of separate unrelated parts with origins and destinations in separate places. > And that it's derived from a (theoretical? unpublished?) earlier > version of tg3.c that was entirely under the GPL? Maybe, but the owner of the code can apply whatever license he wants. Removing the GPL restrictions makes sense to me. Otherwise it would be of little use. I think the old GPL marking on the tg3 code was a mistake and a red herring in this context anyway. Why not pursue this argument regarding the CPU microcode for a more generic disposition? > (Or, if you don't go for that, that the combination of tg3.c not > entirely under the GPL with third-party code that was present in Linux > before, under the GPL, created a derived work that could only be > distributed in its entirety under the GPL?) Putting two things together doesn't necessarily create a derived work. It may still be two separate things. What's your distinction between an aggregate stored together and a derived work? Being contained in the same file making them derived seems as wrong as two separate printed works being on the same page. >> "Collective work" is not a relevant issue. > > ... because you it would show you may be mistaken? No, because aggregates are permitted collective works. >> who can identify the sections (like maybe the person who put them >> there...) and make a determination if they were "derived from the >> Program". > > Do you dispute that tg3.c is derived from (i) earlier versions of > Linux, and (ii) the firmware it contains? Yes. The firmware it contained was a separate item then, and so is the version it contains now. >> We already know they are separate, since they get dumped >> into separate hardware. > > As in, a movie is not a single work, but rather a mere aggregation of > independent separate works in a single DVD, because the video gets > processed by our eyes whereas the audio is processed by our ears? Does not compute... But if you mean that songs used in the movie are still owned by the same entity that owned them before the movie, I think that is correct, and using a song in one section of the movie in no way affects the rights of a different one in another section. > And, come to think of it, even the video is a mere aggregation in > itself, because even though it's compressed, it's a mechanical > transformation out of a sequence of clearly separate and independent > pictures. > > Right? :-) Yes, the representation does not affect the underlying creative works. -- Les Mikesell lesmikesell at gmail.com From anders at trudheim.co.uk Wed Jun 18 20:13:38 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Wed, 18 Jun 2008 22:13:38 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <48592E84.4020209@blagblagblag.org> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> Message-ID: <20080618201338.GA9581@localhost.localdomain> * jeff [20080618 17:50]: [snip] > > ... more pages of hex > > > I personally downloaded this file believing that I was getting a free GPL > driver. Broadcom says so in the patch itself, in the included LICENSE > file, and their website when you click to download it. Red Hat is > shipping it as GPLv2. So either they have to provide the source (if they > have it), stop shipping it, or *at least* stop saying they are shipping a > GPLv2 kernel if they are unwilling/unable to provide the source. You missed the discussion where it was pointed out that some firmware is written in hex directly, as there is no compiler. Good luck with demanding the source to that dude... /Anders From anders at trudheim.co.uk Wed Jun 18 20:17:40 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Wed, 18 Jun 2008 22:17:40 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> Message-ID: <20080618201740.GB9581@localhost.localdomain> * Alexandre Oliva [20080618 21:50]: > On Jun 16, 2008, Hans de Goede wrote: [snip] > > Not being able to ever change the firmware is good, > > It's not. Being Free to change it would undoubtedly be better. So what's stopping you? Go buy the programming manual for the chip, or discuss with the chip manufacturer to get the specs as there may not be a programming manual along the line what you find with say an Intel CPU. As the firmware may be written from scratch in hex, that may be your *only* option. /Anders From mjs at clemson.edu Wed Jun 18 20:32:04 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Wed, 18 Jun 2008 16:32:04 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> Message-ID: <1213821124.11083.30.camel@valkyrie.localdomain> On Wed, 2008-06-18 at 14:54 -0300, Alexandre Oliva wrote: > On Jun 16, 2008, Les Mikesell wrote: > > > I've explained that the GPL prevents me from sharing original work > > that links to both GPL and non-GPL libraries. > > And I've explained that it doesn't, and asked you to cite the passage > of the GPL that prevents you from doing it. You haven't bothered to > do it, and instead decided to keep insisting in this nonsensical > claim. Please stop spreading lies. We're past the point in which you > could claim ignorance as to this point. Wait--Alexandre, are you saying that I could take a GPL library and, say, a CPL[1] library, write a program that links to both libraries to create new functionality and legally distribute source code or a statically or dynamically linked executable version of my program licensed under either the GPL or the CPL? How about the LGPL and the CPL? Please explain in detail with appropriate pointers to text from the GPL/LGPL showing how it permits this. I am not joining the argument on either side here--I am genuinely interested in the answer. I've long thought Les was right on this point, but I'd love to be proved wrong. Thanks very much. [1] The Common Public License is a free software license (yes, the FSF says it's a free software license) that the FSF considers incompatible with both GPLv2 and GPLv3. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From lesmikesell at gmail.com Wed Jun 18 20:39:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 15:39:41 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> Message-ID: <4859728D.8090309@gmail.com> Alexandre Oliva wrote: > > I get the impression you misunderstood the question. I'm not asking > something you could do if you had some other permissive license that > you couldn't do with the GPL. What I'm asking is whether you know of > anything that, in the absence of a copyright license, you could do > with a work, that, after accepting the GPL, you could no longer do. In the case I described, there was a more permissive license on an earlier work (pdtar), so the only relevant comparison is regarding the difference before and after the GPL was applied with the modifications that made it GNUtar, but if you insist we can pretend otherwise. Let's assume that I have obtained my copy of several components under any license but the GPL, and so have a lot of other people. In the actual case they were free and redistributable, but the terms aren't anyone else's business. With any other license, I could at least have done a diff against the original copies and my work and given that away (perhaps using line number references if the other work's license was so strict as to prohibit the copying involved in context diffs), letting others duplicate the results with their own copies of the components (well, assuming they had a compiler for DOS too - I really thought it would have been more helpful to give binaries away). The FSF says you can't do that if any of the parts are GPL'd and the resulting work as a whole can't be. This doesn't happen with any license but the GPL. > This would be a prohibition of the GPL. Yes, in case it wasn't clear before, the specific prohibition that I consider unethical is that it takes away my choice to share my own work. -- Les Mikesell lesmikesell at gmail.com From anders at trudheim.co.uk Wed Jun 18 20:38:09 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Wed, 18 Jun 2008 22:38:09 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> Message-ID: <20080618203809.GD9581@localhost.localdomain> Okay, time-out - Hitler and the Nazi's, Goodwins Law invoked. There, kill the thread already. * Alexandre Oliva [20080618 22:03]: > On Jun 14, 2008, Les Mikesell wrote: > > > Alexandre Oliva wrote: > >>> I'm not mistaken. Everything in there except the conditional grant to > >>> use, modify, distribute is a restriction. > > >> Like what? Tell me *anything* you could do in the absence of the GPL, > >> that, by accepting the GPL, you can no longer do. > > > Given (or knowing about) a library not covered by the GPL, I can write > > and distribute original work that uses the functions provided by that > > library, knowing that anyone can obtain their own copy of by my code > > and the additional library and use them together. > > Assuming you have permission from the copyright holder of the library > to do so. If you do, whether or not the library is also available > under the GPL won't make any difference. > > I get the impression you misunderstood the question. I'm not asking > something you could do if you had some other permissive license that > you couldn't do with the GPL. What I'm asking is whether you know of > anything that, in the absence of a copyright license, you could do > with a work, that, after accepting the GPL, you could no longer do. > > This would be a prohibition of the GPL. > > Anything else that you might believe to be a prohibition of the GPL is > actually a prohibition from copyright law, that the GPL refrains from > lifting. > > >> Another fallacy. "You can redistribute under the same license" > >> doesn't divide, it has quite the opposite effect. It's permitting > >> redistribution under any licenses that may lead to forks, including > >> ones that don't permit further modifications. > > > You can't permit redistribution of something you have prohibited from > > existing in the first place. > > You could, but this doesn't apply to the GPL anyway. > > The GPL doesn't forbid [anything, not even] the creation of any > derived works (and no permission is needed to create non-derived > works). > > > for example the original BSD license which is about as far from > > proprietary as you can get. > > Not true, in two senses. > > 1. the modified BSD license is even more permissive than the original > BSD license, and it is GPL-compatible :-) > > 2. there is a lot of non-Free (as you say, proprietary) Software > distributed in part or as a whole under the original and the modified > BSD licenses > > > I agree that the separation would be more obvious > > if the bits were not embedded as data in the kernel in whatever format > > the compiler decides to use > > ... and the code hadn't been modified so as to require the presence of > those bits in there and so on... > > > You could probably modify the compiler to store data in a separate > > file instead of whatever embedded memory-loading format it currently > > uses but it wouldn't change the copyright status of the output. > > Agreed. The resulting object file would be just as derived from both, > and the source file modified to require the presence of the firmware > would still be just as derived from both. > > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} > FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Anders Karlsson All-Round Linux Tinkerer & RHCE From anders at trudheim.co.uk Wed Jun 18 20:41:04 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Wed, 18 Jun 2008 22:41:04 +0200 Subject: fedora-politics mailing list In-Reply-To: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> References: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <20080618204104.GE9581@localhost.localdomain> * Stephen Warren [20080618 21:36]: > Would it make sense to create a separate fedora-politics mailing list, to > separate such discussions out of the -devel list? How about: fedora-holy-war fedora-arguments fedora-take-it-off-list fedora-I-want-a-pony I'm sure they'll be joyous places to hang out at... Not. /Anders From maximilianbianco at gmail.com Wed Jun 18 20:48:32 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 18 Jun 2008 16:48:32 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213804920.26255.1302.camel@pmac.infradead.org> References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <1213804920.26255.1302.camel@pmac.infradead.org> Message-ID: <485974A0.6050602@gmail.com> David Woodhouse wrote: > On Wed, 2008-06-18 at 10:26 -0400, max wrote: >> David Woodhouse wrote: >>> On Wed, 2008-06-18 at 09:07 -0400, max wrote: >>>> David Woodhouse wrote: >>>>> Along with the quotes from one of its authors, who also happens to be >>>>> the overall network driver maintainer for Linux, and has stated that >>>>> each driver and its firmware are 'intimately tied... pieces of a single, >>>>> cohesive whole'. >> So the driver and its firmware are indistinct from the whole? You cannot >> tell where the driver and firmware begin and end? > > You can't easily tell them apart in the kernel image, no. It's a bit > easier in the driver source, of course. > > And of course even if you _can_ still identify the separate sections, > that doesn't mean the GPL wouldn't apply to them. When the GPL talks > about the independent sections which it extends to cover, it actually > refers to them as "_identifiable_ sections of [the collective] work". > > Merely being able to _identify_ the various parts isn't sufficient to > claim that they are being distributed 'as separate works'. > > When you see a book of short stories, do you claim that it's not a > collective work just because you can tell where one ends and the next > one starts? > >>>> Why or how have they become "intimately tied"? >>> That's a question you'd have to direct to the author of that file, who >>> said that they were. He ought to know. >>> >> You based your argument around something you haven't confirmed? > > Not at all; it doesn't _have_ to be 'intimately tied' for the GPL to > apply to the whole work; my argument isn't at all based on the fact that > they are 'intimately tied'. > > I think it's fairly obvious that what we're distributing is a single > cohesive whole which combines both GPL'd kernel code and the firmware. > The argument that they are actually being distributed "as separate > works" is fairly insane, and the claim that it is "mere aggregation on a > volume of a storage or distribution medium" is also extremely > far-fetched, IMO. > > To call it 'intimately tied' is an even stronger assertion, and I was > merely pointing out that that's the publicly stated opinion of an expert > in the field (of these drivers), who has actually _created_ a number of > these combined works of driver+firmware. The original copy is here: > http://www.spinics.net/lists/netdev/msg65908.html > cf. http://www.spinics.net/lists/netdev/msg65919.html > Thanks for the links, I will see if I can't put them to good use. -- We are eternal, all this pain is an illusion. From cdahlin at redhat.com Wed Jun 18 20:45:34 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Wed, 18 Jun 2008 16:45:34 -0400 Subject: fedora-politics mailing list In-Reply-To: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> References: <1213817933.22105.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <485973EE.7080201@redhat.com> Stephen Warren wrote: > Would it make sense to create a separate fedora-politics mailing list, to > separate such discussions out of the -devel list? > > *facepalm* From aoliva at redhat.com Wed Jun 18 20:54:11 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 17:54:11 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48595587.2010606@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 13\:35\:51 -0500") References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> <48595587.2010606@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >>> If it's silly, then you shouldn't have any problem showing where it is >>> executed as part of "the Program", >> >> Execution is irrelevant, because copyright law doesn't apply to this >> act. > Does that mean you disagree with the FSF claim that it is not > permitted to distribute non-GPL'd software that dynamically links to > unique libraries only available under the GPL? I agree that the GPL doesn't grant permission for the distribution of such derived works under terms others than those specified in the GPL. > And the GPL's 'work as a whole' concept I don't know what you're talking about. "work as a whole" appears only once in the license, and there 'work' is not a verb, but rather part of the "modified work" phrase. > doesn't apply to the running program? In some jurisdictions, the copying from disk to RAM for purposes of execution requires permission from the copyright holder. I guess some might even accept claims such as that the mechanical processing of relocations at dynamic linking time amounts to modifying the work. But none have much to do with actually running the program. That's unrestricted by copyright law.a > If it is actually permissible to deliver any combination of > components separately under different licenses with tools to combine > them at run time, then the GPL is not nearly as harmful as I've > believed. If the GPLed work is not derived from the non-GPLed work, you might be able to present this as a defense in case someone sues you for distributing the two components artificially separately just to escape the requirements of the license. >> It is *distributed* as part of the program, and that's what copyright >> law restricts by default. > Which is irrelevant if you have permission to distribute all parts. If they form a coherent whole to the point of being regarded by a court, according to copyright law, as a derived/collective work, then it is relevant. And then, this is not the case we're talking about here. We're talking of a case in which one part became an integral, essential and inseparable part from the other, so the distinction is definitely no longer irrelevant, because it's a different case. > It is only the weirdness of the GPL denying the right to distribute > under many conditions that even makes this a question. -ENOQUOTE >> And it's distributed as inseparable part of >> the program while at that. > I don't see how you can say it is inseparable when the firmware > downloader understands the separation perfectly You got your facts wrong, I'm afraid. The code in question doesn't even use the firmware downloader. It absolutely requires the code to be part of the source code. > it's a part of the program since it gets > installed on different hardware - except maybe for the CPU microcode. So, when you use say Google Docs, just because some part of the program is shipped to your computer while another keeps on running on Google's servers, they're not part of the same program named "Google Docs"? Just because a program uses Java RMI to transfer classes from one process to another (that may be running on a different machine), the classes are not part of that program? Do you even have an argument here, or are you just saying it, to fill in the void? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From sandeen at redhat.com Wed Jun 18 21:20:18 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 18 Jun 2008 16:20:18 -0500 Subject: FYI: almost-ext4-capable e2fsprogs in rawhide Message-ID: <48597C12.4050100@redhat.com> I've put an e2fsprogs-1.41 pre-release snapshot into rawhide, e2fsprogs-1.41-0.WIP.0617.fc10. e2fsprogs-1.41 is intended to be the first fully ext4-capable e2fsprogs release, so for any of you brave souls who are testing ext4 in F9 or rawhide, you might consider using this release, give it a whirl and let me (or the linux-ext4 mailing list, or #ext4 on irc.oftc.net) know how it goes. Thanks! -Eric From lesmikesell at gmail.com Wed Jun 18 21:56:26 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 16:56:26 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> <48595587.2010606@gmail.com> Message-ID: <4859848A.3030808@gmail.com> Alexandre Oliva wrote: > >> If it's silly, then you shouldn't have any problem showing where it is >>>> executed as part of "the Program", >>> Execution is irrelevant, because copyright law doesn't apply to this >>> act. > >> Does that mean you disagree with the FSF claim that it is not >> permitted to distribute non-GPL'd software that dynamically links to >> unique libraries only available under the GPL? > > I agree that the GPL doesn't grant permission for the distribution of > such derived works under terms others than those specified in the GPL. OK, then the relevant question becomes whether the kernel or the firmware is a derived work, not whether they are distributed together or not. > >> And the GPL's 'work as a whole' concept > > I don't know what you're talking about. "work as a whole" appears > only once in the license, and there 'work' is not a verb, but rather > part of the "modified work" phrase. Once is enough - and it is the definitive requirement: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works." The question is, does taking some code and an opaque binary blob and sticking them in the same file make a 'work as a whole' or is it identifiable sections of code and separate data that are not derived from the Program? >>> It is *distributed* as part of the program, and that's what copyright >>> law restricts by default. > >> Which is irrelevant if you have permission to distribute all parts. > > If they form a coherent whole to the point of being regarded by a > court, according to copyright law, as a derived/collective work, then > it is relevant. And then, this is not the case we're talking about > here. How is it different? The question is whether firmware and microcode are part of the kernel 'work as a whole', which, I don't think depends on how they are distributed at all. > We're talking of a case in which one part became an integral, > essential and inseparable part from the other, so the distinction is > definitely no longer irrelevant, because it's a different case. Are you sure that the opaque blob of firmware can't be replaced by any other opaque blob of bits without affecting the other part? In which case it's just aggregated and along for the ride. >> I don't see how you can say it is inseparable when the firmware >> downloader understands the separation perfectly > > You got your facts wrong, I'm afraid. The code in question doesn't > even use the firmware downloader. It absolutely requires the code to > be part of the source code. Would the code continue to work if you replace those bits with something else that would work in the hardware it loads? >> it's a part of the program since it gets >> installed on different hardware - except maybe for the CPU microcode. > > So, when you use say Google Docs, just because some part of the > program is shipped to your computer while another keeps on running on > Google's servers, they're not part of the same program named "Google > Docs"? I wouldn't assume that. But why not stick to the CPU microcode example? I think it is the purest form of the issue in question. > Just because a program uses Java RMI to transfer classes from one > process to another (that may be running on a different machine), the > classes are not part of that program? Unless it is covered by the GPL with the 'work as a whole' restriction, the question doesn't make much sense, since a program can otherwise have any number of components under different licenses running together. And in the GPL case, I haven't seen even the FSF try to claim that things running on other machines or connected via pipes or sockets are covered parts of a 'work as a whole'. > Do you even have an argument here, or are you just saying it, to fill > in the void? :-) I would like to see a definitive answer to delimit the 'work as a whole' where the GPL restrictions of any component apply, particularly in cases like microcode downloads and how shared libs would differ from code in ROM or firmware in flash. I think your interpretation is wrong, and mine might be - but I suppose we aren't going to get one. -- Les Mikesell lesmikesell at gmail.com From aoliva at redhat.com Wed Jun 18 21:59:40 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 18:59:40 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859728D.8090309@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 15\:39\:41 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> I get the impression you misunderstood the question. I'm not asking >> something you could do if you had some other permissive license that >> you couldn't do with the GPL. What I'm asking is whether you know of >> anything that, in the absence of a copyright license, you could do >> with a work, that, after accepting the GPL, you could no longer do. > In the case I described, It's not relevant, it was in a different unrelated part of the conversation. The question was not about the case you described. It was a general question, to show that your notion that the GPL prohibits you from doing anything is a misunderstanding. The GPL only grants you rights, it only adds to the set of things you could do in its absence, it doesn't subtract anything from the set of things you could od in its absence. Whatever prohibitions you perceive stem from copyright law and from other restrictions you may have accepted. > Let's assume that I have obtained my copy of several components under > any license but the GPL, and so have a lot of other people. Still missing the point. Don't assuming you have a license that says other things. That would just show that there are other licenses that are more permissive. We know that. This is not related at all with whether the GPL prohibits you from doing anything. The way to tell whether the GPL prohibits you from doing anything is comparing what you can do once you accept the GPL with what you could do before you accepted it. > With any other license, I could at least have done a diff against > the original copies and my work and given that away As long as your original work is not a derived work. If it is, you still need permission from the copyright holders of the original work, to both create your derived work and to distribute the collective/derived work. > This doesn't happen with any license but the GPL. Sorry, I don't know how you came to this conclusion, but it's incorrect. Try to create a derived work based on say Microsoft Windows or Microsoft Word, if you happen to have them around, and to distribute it, and see what happens. >> This would be a prohibition of the GPL. > Yes, in case it wasn't clear before, the specific prohibition that I > consider unethical is that it takes away my choice to share my own > work. It doesn't. Your own original work can't possibly be a derived work. It does not grant you permission to distribute joint works you created by deriving works from others' works in certain ways, so the prohibition from copyright law remains in place. See, you didn't have that choice in the first place for the GPL to take away. That's the fundamental point that you're missing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:17:02 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:17:02 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48596BB0.1080909@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 15\:10\:24 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> <48596BB0.1080909@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >>> Except when the separate parts are identifiable and not derived. >> >> *and* *not* distributed as part of a single work derived from the >> Program. > Yes, those are true - it's not derived from 'the Program' The whole is derived from the Program and the firmware. You don't want it to be, I know, but repeating it won't make it any less false. > and it is an identifiable separate section. This doesn't matter once you realize it's part of a single copyrightable work. >>> "If identifiable sections of that work are not derived from the Program ..." >> >> "... when you distribute them as separate works" >> >> that's the same sentence you started quoting, BTW. >> >> Do you dispute that e.g. tg3.c as it stands is part of a single work? > It is an aggregate of separate unrelated parts with origins and > destinations in separate places. This doesn't answer the question. >> And that it's derived from a (theoretical? unpublished?) earlier >> version of tg3.c that was entirely under the GPL? > Maybe, but the owner of the code can apply whatever license he > wants. But in order to distribute it as part of a GPLed work, there's only one option for the license that applies to the whole. > I think the old GPL marking on the tg3 code > was a mistake and a red herring in this context anyway. Agreed. This doesn't ake the current marking (which is what I'm talking about) any more acceptable for inclusion in a GPLed program. > Why not pursue this argument regarding the CPU microcode for a more > generic disposition? Because the CPU microcode is not part of a single source file along with GPLed code (even though it is distributed by Fedora as part of a single package, allegedly under the GPL) > Putting two things together doesn't necessarily create a derived > work. I know. It's modifying them for integration that does. Or arranging them in a way that involves a creative process. Or selecting a sufficient number of them under creative criteria to the point that the collection is a creative work in itself. There are many ways to step away from the 'mere aggregation' case into the 'single derived work' case. > It may still be two separate things. What's your distinction > between an aggregate stored together and a derived work? It doesn't matter what I think it is. What matters is what the law says. > Being contained in the same file making them derived seems as wrong > as two separate printed works being on the same page. Nobody claimed it was a hard and fast rule. But then, this is not how tg3.c came to be. It would be trickier to make a call if it had been that simple. >>> "Collective work" is not a relevant issue. >> >> ... because you it would show you may be mistaken? > No, because aggregates are permitted collective works. Adn their distribution is permitted only under the terms of the GPL, unless it's "mere aggregation" (i.e., it doesn't amount to a single derived work) >> Do you dispute that tg3.c is derived from (i) earlier versions of >> Linux, and (ii) the firmware it contains? > Yes. The firmware it contained was a separate item then, and so is > the version it contains now. Dude! tg3.c *contains* the firmware, and it was modified to count on its being there. It can't possibly not be derived from it. >>> We already know they are separate, since they get dumped >>> into separate hardware. >> As in, a movie is not a single work, but rather a mere aggregation of >> independent separate works in a single DVD, because the video gets >> processed by our eyes whereas the audio is processed by our ears? > Does not compute... The fact that it gets to different hardware is irrelevant. The relevant point is that the whole forms a single work, and claiming it isn't just because portions of it are for your vision hardware and other portions are for your listening hardware doesn't make a difference. > But if you mean that songs used in the movie are > still owned by the same entity that owned them before the movie, I > think that is correct, I didn't mean that, but I agree it's correct. But this has ZERO to do with whether the movie in the DVD is a single work. Surely the song whose snippets play during the movie are not mere aggregation, they're an integral part of the creative work. > and using a song in one section of the movie in > no way affects the rights of a different one in another section. Nobody ever disputed that. Please don't insist on this point any further. It's irrelevant. This is not about any rights as to the separate work. This is about rights over the single work that integrates that formerly-separate work with a formerly-GPLed project by means of the tg3.c driver, derived from both. >> And, come to think of it, even the video is a mere aggregation in >> itself, because even though it's compressed, it's a mechanical >> transformation out of a sequence of clearly separate and independent >> pictures. >> >> Right? :-) > Yes, the representation does not affect the underlying creative works. I think this is enough to show that you're seriously missing information as to how copyright works, and it's become clear that you have no interest in obtaining such knowledge. Thanks for playing, take care, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:20:27 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:20:27 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48591D6C.5030606@gmail.com> (max's message of "Wed\, 18 Jun 2008 10\:36\:28 -0400") References: <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> <48591D6C.5030606@gmail.com> Message-ID: On Jun 18, 2008, max wrote: >> Yes. Which is why we should stop supporting these "PCs" which aren't >> completely free. > I'm all for it too but first you have to get completely free options > on the market place. Why does it have to be 'first'? Why can't we build up pressure such that vendors will have more of a reason to do it? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:28:55 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:28:55 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48596534.3040604@fedoraproject.org> (Rahul Sundaram's message of "Thu\, 19 Jun 2008 01\:12\:44 +0530") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> <48565B6C.3030902@blagblagblag.org> <48565FC0.2040707@fedoraproject.org> <48596534.3040604@fedoraproject.org> Message-ID: On Jun 18, 2008, Rahul Sundaram wrote: > Not all game maps are purely non functional data for example. That's fine. The exception is not for game maps. It's for non-functional data. > GFDL has non variant sections and so on. That's fine. As long as all invariant sections (if any) are non-functional, it's still ok. > Suffice to say there are lots of border line cases. There aren't, really, unless you take the examples for guidelines, instead of understanding the social, ethical and moral principles that led to the guidelines, for which a few examples are given. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:31:12 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:31:12 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080618201740.GB9581@localhost.localdomain> (Anders Karlsson's message of "Wed\, 18 Jun 2008 22\:17\:40 +0200") References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <48560118.7090309@hhs.nl> <48560EBF.7050805@blagblagblag.org> <48561F66.9070308@hhs.nl> <20080618201740.GB9581@localhost.localdomain> Message-ID: On Jun 18, 2008, Anders Karlsson wrote: > * Alexandre Oliva [20080618 21:50]: >> On Jun 16, 2008, Hans de Goede wrote: > [snip] >> > Not being able to ever change the firmware is good, >> >> It's not. Being Free to change it would undoubtedly be better. > So what's stopping you? Lack of information. > Go buy the programming manual for the chip, It's not available. > or discuss with the chip manufacturer to get the specs They don't want to provide them. > as there may not be a programming manual along the line what you > find with say an Intel CPU. There is, but they choose to keep it to themselves. > As the firmware may be written from scratch in hex, that may be your > *only* option. That's fine, as long as the firmware *is* written from scratch in hex. If not, the vendors are artificially and unethically depriving me of information. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:33:13 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:33:13 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213821124.11083.30.camel@valkyrie.localdomain> (Matthew Saltzman's message of "Wed\, 18 Jun 2008 16\:32\:04 -0400") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> Message-ID: On Jun 18, 2008, Matthew Saltzman wrote: > On Wed, 2008-06-18 at 14:54 -0300, Alexandre Oliva wrote: >> On Jun 16, 2008, Les Mikesell wrote: >> >> > I've explained that the GPL prevents me from sharing original work >> > that links to both GPL and non-GPL libraries. >> >> And I've explained that it doesn't, and asked you to cite the passage >> of the GPL that prevents you from doing it. You haven't bothered to >> do it, and instead decided to keep insisting in this nonsensical >> claim. Please stop spreading lies. We're past the point in which you >> could claim ignorance as to this point. > Wait--Alexandre, are you saying that I could take a GPL library and, > say, a CPL[1] library, write a program that links to both libraries to > create new functionality and legally distribute source code or a > statically or dynamically linked executable version of my program > licensed under either the GPL or the CPL? No. I'm just saying that it's not the GPL that prevents you from distributing it. It's copyright law. The GPL merely refrains from granting permission for you to do something that, without such permission from copyright holders, you can't do in the first place. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 22:38:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 17:38:34 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> Message-ID: <48598E6A.5020406@gmail.com> Alexandre Oliva wrote: > >> Let's assume that I have obtained my copy of several components under >> any license but the GPL, and so have a lot of other people. > > Still missing the point. Don't assuming you have a license that says > other things. I don't have to assume. I have other licenses. Only the GPL applies its restrictions to the 'work as a whole' instead of just itself. You are the one assuming that there might be something even more restrictive than the GPL and using that to excuse its harmful restrictions. > The way to tell whether the GPL prohibits you from doing anything is > comparing what you can do once you accept the GPL with what you could > do before you accepted it. > >> With any other license, I could at least have done a diff against >> the original copies and my work and given that away > > As long as your original work is not a derived work. If it is, you > still need permission from the copyright holders of the original work, > to both create your derived work and to distribute the > collective/derived work. No one but the FSF claims that a patch is a derived work - or a separate component that links 2 others together but doesn't contain a copy of the others. >> This doesn't happen with any license but the GPL. > > Sorry, I don't know how you came to this conclusion, but it's > incorrect. > > Try to create a derived work based on say Microsoft Windows or > Microsoft Word, if you happen to have them around, and to distribute > it, and see what happens. I'm not sure what you are talking about. It's a pretty safe bet that there is more code that relies on Microsoft libraries than anything else and Microsoft does not try to stop people from distributing it. If anything, they encourage it by making a lot of tools and libraries available. >>> This would be a prohibition of the GPL. > >> Yes, in case it wasn't clear before, the specific prohibition that I >> consider unethical is that it takes away my choice to share my own >> work. > > It doesn't. Your own original work can't possibly be a derived work. Difference of opinion, I guess. The FSF says otherwise and that if the resulting 'work as a whole' would be be a derived work, then the components, including my own work, can't be distributed unless all are restricted by the GPL. > It does not grant you permission to distribute joint works you created > by deriving works from others' works in certain ways, so the > prohibition from copyright law remains in place. See, you didn't have > that choice in the first place for the GPL to take away. That's the > fundamental point that you're missing. I'm not missing anything. I have my copy of a library, you have your copy. Without the GPL, I can give you a copy of my original work that links to that library without imposing the GPL restrictions on it and any other related components. With the GPL, I can't. And the same applies even if we both have source and I have made a patch. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed Jun 18 22:42:04 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jun 2008 04:12:04 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212882238.3269.9.camel@localhost.localdomain> <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <4855FB57.6050401@blagblagblag.org> <485640B2.9080201@fedoraproject.org> <48564734.10103@blagblagblag.org> <48564D98.6050107@fedoraproject.org> <48565B6C.3030902@blagblagblag.org> <48565FC0.2040707@fedoraproject.org> <48596534.3040604@fedoraproject.org> Message-ID: <48598F3C.3030608@fedoraproject.org> Alexandre Oliva wrote: > On Jun 18, 2008, Rahul Sundaram wrote: > >> Not all game maps are purely non functional data for example. > > That's fine. The exception is not for game maps. It's for > non-functional data. Sure but that was a specific example provided within the guidelines and the guidelines should reflect this better. I have already send more information which the FSF agrees with and is working on updating the guidelines so I won't be repeating everything here and arguing with you anymore. Rahul From aoliva at redhat.com Wed Jun 18 22:41:34 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:41:34 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485963DC.70308@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 14\:37\:00 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > I could have redistributed the combination if I had started with the > original pdtar instead of gnutar. pdtar was presumably under the public domain, i.e., copyright law didn't restrict its use. If you'd started with any other derived version of pdtar that wasn't in the public domain, or even one that was but that wasn't Free because you didn't have access to the source code, you'd need permission/help from the copyright/source holders of that particular version you started out from in order to be able to create the combined work and distribute it. > There is no reasonable interpretation that anything but the GPL > restrictions applied along with the changes between the pdtar and > gnutar versions restricted distribution of my subsequent modification > of the gnutar code. Not GPL. There isn't any part of the GPL that says you can't do it. Look for it and, if you find it, quote it here. What stops you from doing it is not the GPL. It's copyright law. Go figure. > Of course I was mistaken at the time in thinking that GPL'd code was > suitable for re-use and sharing and know better now. http://fsfla.org/svnwiki/blogs/lxo/draft/forking-and-license-patching -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 22:57:18 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 19:57:18 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859848A.3030808@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 16\:56\:26 -0500") References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> <48595587.2010606@gmail.com> <4859848A.3030808@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> I agree that the GPL doesn't grant permission for the distribution of >> such derived works under terms others than those specified in the GPL. > OK, then the relevant question becomes whether the kernel or the > firmware is a derived work, not whether they are distributed together > or not. Except that the GPL's exception distinguishes the cases in which they are distributed together and not. So, no, we can't make this simplification you suggested. >>> And the GPL's 'work as a whole' concept >> >> I don't know what you're talking about. "work as a whole" appears >> only once in the license, and there 'work' is not a verb, but rather >> part of the "modified work" phrase. > Once is enough - and it is the definitive requirement: Sorry, I misunderstood what you wrote. As it's probably clear from my response, it looked like you'd written 'works'. My fault. > "These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Program, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works." > The question is, does taking some code and an opaque binary blob and > sticking them in the same file make a 'work as a whole' or is it > identifiable sections of code and separate data that are not derived > from the Program? This only matters if you distribute them as separate works. When you distribute them as a whole, you don't get the exception. >>>> It is *distributed* as part of the program, and that's what copyright >>>> law restricts by default. >>> Which is irrelevant if you have permission to distribute all parts. >> If they form a coherent whole to the point of being regarded by a >> court, according to copyright law, as a derived/collective work, then >> it is relevant. And then, this is not the case we're talking about >> here. > How is it different? The question is whether firmware and microcode > are part of the kernel 'work as a whole', which, I don't think > depends on how they are distributed at all. Read again, very carefully, the sentence you quoted. Especially the "when you distribute them as separate works" part. > Are you sure that the opaque blob of firmware can't be replaced by any > other opaque blob of bits without affecting the other part? Quite the opposite is true. Doesn't change the fact that the combined work tg3.c, later integrated in linux, was created based on those two original works. > Would the code continue to work if you replace those bits with > something else that would work in the hardware it loads? Whether it works or not is not relevant to tell whether it's derived. I have no idea of what happens if you replace it with something else. Quite likely the hardware will crash or freeze or whatever results you might expect by throwing random bytes at a microprocessor. > But why not stick to the CPU microcode example? Because you got the facts wrong. It's not distributed even close to the kernel. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed Jun 18 23:05:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 18 Jun 2008 20:05:35 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48598E6A.5020406@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 17\:38\:34 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >>> Let's assume that I have obtained my copy of several components under >>> any license but the GPL, and so have a lot of other people. >> >> Still missing the point. Don't assuming you have a license that says >> other things. > I don't have to assume. I have other licenses. In this case they say nothing as to the case, they're just confusing you. Here, take this program here: http://www.lsd.ic.unicamp.br/~oliva/papers/vta/example.c What do you think you're entitled to do with it as it stands? Now, if I tell you, I license it to you under the GPL, and you accept it. what you you think you're no longer entitled to do with it? > No one but the FSF claims that a patch is a derived work How would you defend the claim that something that literally copies portions of a copyrightable work is not? > or a separate component that links 2 others together but doesn't > contain a copy of the others. Even dynamic linking copies portions of the dynamic libraries. We've covered that already. >> Try to create a derived work based on say Microsoft Windows or >> Microsoft Word, if you happen to have them around, and to distribute >> it, and see what happens. > I'm not sure what you are talking about. Try creating a work based on internal DLLs, for which you have no "developer" permissions. >>>> This would be a prohibition of the GPL. >>> Yes, in case it wasn't clear before, the specific prohibition that I >>> consider unethical is that it takes away my choice to share my own >>> work. >> It doesn't. Your own original work can't possibly be a derived work. > Difference of opinion, I guess. The FSF says otherwise No, it doesn't, and the GPL itself confirms that. There's a difference between "your own original work" and "the derived work you created out of a pre-existing third-party's work". The above is about the former, as you can probably tell from the similarity in spelling ;-) > if the resulting 'work as a whole' would be be a derived work, Then it's not "your own original work" > Without the GPL, I can give you a copy of my original work that > links to that library Only if the copyright holder of the library granted you permission to distribute your derived work. Same as with the GPL. That's how copyright law's restrictions work. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Wed Jun 18 23:07:57 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 18:07:57 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> <48596BB0.1080909@gmail.com> Message-ID: <4859954D.2080701@gmail.com> Alexandre Oliva wrote: > >> Why not pursue this argument regarding the CPU microcode for a more >> generic disposition? > > Because the CPU microcode is not part of a single source file along > with GPLed code (even though it is distributed by Fedora as part of a > single package, allegedly under the GPL) Do you think file boundaries are necessary to meet the 'separate sections' requirement? What about after it is compiled? >> It may still be two separate things. What's your distinction >> between an aggregate stored together and a derived work? > > It doesn't matter what I think it is. What matters is what the law > says. OK, but I don't think copyright law says anything about separate files. But what actually matters is what the GPL says anyway, since aside from anything else, it permits aggregates and it calls the parts 'sections'. >>> Do you dispute that tg3.c is derived from (i) earlier versions of >>> Linux, and (ii) the firmware it contains? > >> Yes. The firmware it contained was a separate item then, and so is >> the version it contains now. > > Dude! tg3.c *contains* the firmware, and it was modified to count on > its being there. It can't possibly not be derived from it. A container is a good description. You can build a box to contain some odd-shaped thing, but you can't support a general claim that the box is derived from the contents. There might be some special case for a distinctive and creative shape being duplicated in the container but I don't think 'x number of bits' would count. > The fact that it gets to different hardware is irrelevant. The > relevant point is that the whole forms a single work, But there is no evidence to support this claim other than that they are stuck in the same file. What specifically distinguishes if as a 'single work' as opposed to a container of some unrelated bits? A file can be just as much a container as a filesystem or a box. > and claiming it > isn't just because portions of it are for your vision hardware and > other portions are for your listening hardware doesn't make a > difference. Why not? What does make that difference? >> But if you mean that songs used in the movie are >> still owned by the same entity that owned them before the movie, I >> think that is correct, > > I didn't mean that, but I agree it's correct. But this has ZERO to do > with whether the movie in the DVD is a single work. Surely the song > whose snippets play during the movie are not mere aggregation, they're > an integral part of the creative work. I think you are overgeneralizing. The songs in "South Pacific" were creatively part of the work, but "Saturday Night Fever" just played songs that were already hits and happened to fit in the scenes. >> Yes, the representation does not affect the underlying creative works. > > I think this is enough to show that you're seriously missing > information as to how copyright works, and it's become clear that you > have no interest in obtaining such knowledge. I'm very interested in anything you have to support your theory that combining two sections in the same file makes a difference copyright-wise compared to two separate files. Please share the source of your knowlege about that. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed Jun 18 23:19:06 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 18:19:06 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> <48595587.2010606@gmail.com> <4859848A.3030808@gmail.com> Message-ID: <485997EA.1040402@gmail.com> Alexandre Oliva wrote: > >> The question is, does taking some code and an opaque binary blob and >> sticking them in the same file make a 'work as a whole' or is it >> identifiable sections of code and separate data that are not derived >> from the Program? > > This only matters if you distribute them as separate works. When you > distribute them as a whole, you don't get the exception. Separate sections. Not separate files, not separate media, not separate delivery carriers. Separate sections. Whatever that means, it is the way separate works are defined. >> How is it different? The question is whether firmware and microcode >> are part of the kernel 'work as a whole', which, I don't think >> depends on how they are distributed at all. > > Read again, very carefully, the sentence you quoted. Especially the > "when you distribute them as separate works" part. Note that it doesn't say anything about files there. >> Would the code continue to work if you replace those bits with >> something else that would work in the hardware it loads? > > Whether it works or not is not relevant to tell whether it's derived. How else could you tell if the parts are related or not, unless you were part of the creative process. >> But why not stick to the CPU microcode example? > > Because you got the facts wrong. It's not distributed even close to > the kernel. Does 'close' have something to do with whether it is a separate section or not? Isn't it in the same vmlinuz imaage somewhere? -- Les Mikesell lesmikesell at gmail.com From maximilianbianco at gmail.com Wed Jun 18 23:26:32 2008 From: maximilianbianco at gmail.com (max bianco) Date: Wed, 18 Jun 2008 19:26:32 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <4856113B.9010004@blagblagblag.org> <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <48590FC8.8090500@redhat.com> <544eb990806180725s441a430cy520aec74a1d39b9a@mail.gmail.com> <48591D6C.5030606@gmail.com> Message-ID: On Wed, Jun 18, 2008 at 6:20 PM, Alexandre Oliva wrote: > On Jun 18, 2008, max wrote: > >>> Yes. Which is why we should stop supporting these "PCs" which aren't >>> completely free. > >> I'm all for it too but first you have to get completely free options >> on the market place. > > Why does it have to be 'first'? Why can't we build up pressure such > that vendors will have more of a reason to do it? > Vendors are motivated by money, nothing more nothing less if you show them they can save money *and* not lose clients they will go for it. Inertia drives this market, the train is coming to a halt but it takes time to stop it and then of course you have to change direction. There is also the fact that most people don't know enough about the subject to care so if you don't put it front of them and maintain the price point they are used too then it is going to be especially difficult. These things take time, things are starting to change, I'd like everyone to suddenly wake up to what's going on around them too. > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} > FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} > -- If opinions were really like assholes we'd each have just one From mjs at clemson.edu Wed Jun 18 23:18:36 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Wed, 18 Jun 2008 19:18:36 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> Message-ID: <1213831117.11083.63.camel@valkyrie.localdomain> On Wed, 2008-06-18 at 19:33 -0300, Alexandre Oliva wrote: > On Jun 18, 2008, Matthew Saltzman wrote: > > > On Wed, 2008-06-18 at 14:54 -0300, Alexandre Oliva wrote: > >> On Jun 16, 2008, Les Mikesell wrote: > >> > >> > I've explained that the GPL prevents me from sharing original work > >> > that links to both GPL and non-GPL libraries. > >> > >> And I've explained that it doesn't, and asked you to cite the passage > >> of the GPL that prevents you from doing it. You haven't bothered to > >> do it, and instead decided to keep insisting in this nonsensical > >> claim. Please stop spreading lies. We're past the point in which you > >> could claim ignorance as to this point. > > > Wait--Alexandre, are you saying that I could take a GPL library and, > > say, a CPL[1] library, write a program that links to both libraries to > > create new functionality and legally distribute source code or a > > statically or dynamically linked executable version of my program > > licensed under either the GPL or the CPL? > > No. I'm just saying that it's not the GPL that prevents you from > distributing it. It's copyright law. The GPL merely refrains from > granting permission for you to do something that, without such > permission from copyright holders, you can't do in the first place. > OK I see. Then can we at least agree that there are sometimes unfortunate consequences to the GPL's failure to permit one to share a work combining two pieces of *free* software because of relatively minor[1] license incompatibilities? In fact, I think it's arguable that there are sometimes unfortunate consequences to the GPL's failure to permit one to share a work that makes use of a GPL library and a proprietary library. I understand some authors' desire not to permit that kind of sharing of their work, even if I don't necessarily agree with it. But I also think that there's lots of software released under the GPL by authors who don't think deeply about license issues and don't really understand the limits of what is permitted by the GPL. [1] We can certainly quibble about what constitutes "minor" incompatibility here, but let us take for granted that all authors involved are committed to the idea of FOSS, use FOSS licenses, and want to share their work. If all licenses involved are "free software licenses" according to the FSF (not even just "open-source licenses" according to the Open Source Initiative), then I think it's fair to characterize incompatibilities as minor compared to that. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From lesmikesell at gmail.com Wed Jun 18 23:43:06 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 18 Jun 2008 18:43:06 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> Message-ID: <48599D8A.8020507@gmail.com> Alexandre Oliva wrote: > > Here, take this program here: > > http://www.lsd.ic.unicamp.br/~oliva/papers/vta/example.c > > What do you think you're entitled to do with it as it stands? Assuming it is permitted for me to get a copy in the first place, then I have fair use of it. I could link my copy with anything else I wanted. And I could give away my work that called it and some other code. > Now, if I tell you, I license it to you under the GPL, and you accept > it. what you you think you're no longer entitled to do with it? Then I couldn't give my additional work away to other people to use with their own copies of your work and third party libraries. They could hire me to re-invent it, but I couldn't distribute my work. >> No one but the FSF claims that a patch is a derived work > > How would you defend the claim that something that literally copies > portions of a copyrightable work is not? It's fair use, but I'd settle for being able to do a line-numbered edit script that didn't not copy any original material. Or a completely separate work that linked two differently licensed libraries that are not included. >> or a separate component that links 2 others together but doesn't >> contain a copy of the others. > > Even dynamic linking copies portions of the dynamic libraries. We've > covered that already. Yes, we covered the fact that everyone else permits it. >>> Try to create a derived work based on say Microsoft Windows or >>> Microsoft Word, if you happen to have them around, and to distribute >>> it, and see what happens. > >> I'm not sure what you are talking about. > > Try creating a work based on internal DLLs, for which you have no > "developer" permissions. Again, I have never heard of any prohibition against sharing such a thing with anyone who has their own copy of all required components. >>> It doesn't. Your own original work can't possibly be a derived work. > >> Difference of opinion, I guess. The FSF says otherwise > > No, it doesn't, and the GPL itself confirms that. There's a > difference between "your own original work" and "the derived work you > created out of a pre-existing third-party's work". The above is about > the former, as you can probably tell from the similarity in spelling ;-) > >> if the resulting 'work as a whole' would be be a derived work, > > Then it's not "your own original work" Define whose work it is, then. Take the case of an original program that links with two other libraries. It is entirely conceivable and fairly likly that compatible GPL and non-GPL libraries will be available and it is the end users choice at compile/run time. Who owns this work? It is a matter of circumstance whether the alternatives exist or not and you may not even know. And such a bizarre definition changes from day to day. One day the RIPEM code was a derived work because it linked to the gmp library. With no changes to the code itself, it became not a derived work because the unrestricted fgmp library existed - even though no one really used it. > >> Without the GPL, I can give you a copy of my original work that >> links to that library > > Only if the copyright holder of the library granted you permission to > distribute your derived work. That's just not true. -- Les Mikesell lesmikesell at gmail.com From takebe_akio at jp.fujitsu.com Thu Jun 19 06:29:18 2008 From: takebe_akio at jp.fujitsu.com (Akio Takebe) Date: Thu, 19 Jun 2008 15:29:18 +0900 Subject: Japanese keyboard issue Message-ID: <4859FCBE.4030600@jp.fujitsu.com> Hi, all I'm using Fedora9 and Japanese keyboard(jp106). If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". The keymaps seems to be wrong. I could avoid this issue with the following way. # vim ~/.Xmodmap # cat ~/.Xmodmap keycode 51 = bracketright braceright # xmodmap ~/.Xmodmap How should I fix this issue properly? Best Regards, Akio Takebe From petersen at redhat.com Thu Jun 19 07:05:11 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 Jun 2008 17:05:11 +1000 Subject: Japanese keyboard issue In-Reply-To: <4859FCBE.4030600@jp.fujitsu.com> References: <4859FCBE.4030600@jp.fujitsu.com> Message-ID: <485A0527.2080204@redhat.com> Akio Takebe ????????: > I'm using Fedora9 and Japanese keyboard(jp106). > If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". > The keymaps seems to be wrong. : > How should I fix this issue properly? Did you try setting Japanese keyboard with system-config-keyboard? Jens ps fedora-list is the right place to ask questions about releases. From takebe_akio at jp.fujitsu.com Thu Jun 19 07:25:16 2008 From: takebe_akio at jp.fujitsu.com (Akio Takebe) Date: Thu, 19 Jun 2008 16:25:16 +0900 Subject: Japanese keyboard issue In-Reply-To: <485A0527.2080204@redhat.com> References: <4859FCBE.4030600@jp.fujitsu.com> <485A0527.2080204@redhat.com> Message-ID: <485A09DC.7090204@jp.fujitsu.com> Hi, Jens Jens Petersen wrote: > Akio Takebe wrote: > >> I'm using Fedora9 and Japanese keyboard(jp106). >> If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". >> The keymaps seems to be wrong. >> > : > >> How should I fix this issue properly? >> > > Did you try setting Japanese keyboard with system-config-keyboard? > > yes, I did. > Jens > > ps fedora-list is the right place to ask questions about releases Thank you for your advise. Best Regards, Akio Takebe From petersen at redhat.com Thu Jun 19 08:06:07 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 19 Jun 2008 18:06:07 +1000 Subject: Japanese keyboard issue In-Reply-To: <485A09DC.7090204@jp.fujitsu.com> References: <4859FCBE.4030600@jp.fujitsu.com> <485A0527.2080204@redhat.com> <485A09DC.7090204@jp.fujitsu.com> Message-ID: <485A136F.6090003@redhat.com> Akio Takebe ????????: >>> I'm using Fedora9 and Japanese keyboard(jp106). >>> If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". : >>> How should I fix this issue properly? >>> >> Did you try setting Japanese keyboard with system-config-keyboard? >> > yes, I did. Ok, you might try checking if you have XkbVariant in xorg.conf - someone communicated that it might help. Otherwise maybe check if you are not overriding the keyboard setting in gnome or your desktop. If can you reproduce systematically with a fresh user account, please file bug in bugzilla. Jens From takebe_akio at jp.fujitsu.com Thu Jun 19 08:10:13 2008 From: takebe_akio at jp.fujitsu.com (Akio Takebe) Date: Thu, 19 Jun 2008 17:10:13 +0900 Subject: Japanese keyboard issue In-Reply-To: <485A09DC.7090204@jp.fujitsu.com> References: <4859FCBE.4030600@jp.fujitsu.com> <485A0527.2080204@redhat.com> <485A09DC.7090204@jp.fujitsu.com> Message-ID: <485A1465.7010302@jp.fujitsu.com> Akio Takebe wrote: > Hi, Jens > > Jens Petersen wrote: > >> Akio Takebe wrote: >> >> >>> I'm using Fedora9 and Japanese keyboard(jp106). >>> If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". >>> The keymaps seems to be wrong. >>> >>> >> : >> >> >>> How should I fix this issue properly? >>> >>> >> Did you try setting Japanese keyboard with system-config-keyboard? >> >> >> > yes, I did. > > hmm... I did it with system-config-keyboard again. this issue gone away. FYI, the keymaps are below before I did it and after. # xmodmap -pke |grep bar keycode 51 = backslash bar keycode 94 = less greater bar brokenbar bar brokenbar keycode 133 = backslash bar # system-config-keyboard Loading /lib/kbd/keymaps/i386/qwerty/jp106.map.gz # xmodmap -pke |grep bar keycode 133 = backslash bar Anyway, thank you for your advice. Best Regards, Akio Takebe From takebe_akio at jp.fujitsu.com Thu Jun 19 08:18:41 2008 From: takebe_akio at jp.fujitsu.com (Akio Takebe) Date: Thu, 19 Jun 2008 17:18:41 +0900 Subject: Japanese keyboard issue In-Reply-To: <485A136F.6090003@redhat.com> References: <4859FCBE.4030600@jp.fujitsu.com> <485A0527.2080204@redhat.com> <485A09DC.7090204@jp.fujitsu.com> <485A136F.6090003@redhat.com> Message-ID: <485A1661.2040803@jp.fujitsu.com> Jens Petersen wrote: > Akio Takebe wrote: > >>>> I'm using Fedora9 and Japanese keyboard(jp106). >>>> If I use my keyboard on Xorg, "]" or "}" are change to "\" or "|". >>>> > : > >>>> How should I fix this issue properly? >>>> >>>> >>> Did you try setting Japanese keyboard with system-config-keyboard? >>> >>> >> yes, I did. >> > > Ok, you might try checking if you have XkbVariant in xorg.conf - someone > communicated that it might help. > > I don't have the value in it. > Otherwise maybe check if you are not overriding the keyboard setting in > gnome or your desktop. If can you reproduce systematically with a fresh > user account, please file bug in bugzilla. > Certainly, I check the reproducing a little bits, and would issue a bugzilla. Best Regards, Akio Takebe From pj.pandit at yahoo.co.in Thu Jun 19 08:30:55 2008 From: pj.pandit at yahoo.co.in (Prasad J Pandit) Date: Thu, 19 Jun 2008 14:00:55 +0530 (IST) Subject: Build server for ~/.plague-client.cfg Message-ID: <175160.19512.qm@web94608.mail.in2.yahoo.com> Hello there, Could you tell which build server to use in ~/.plague-client.cfg file? I did try https://buildsys.fedoraproject.org:8887 from http://fedoraproject.org/wiki/PackageMaintainers/UsingPlagueClientFaq#What_is_plague-client.3F but it's not working. I'm trying to build a package for EL-4, EL-5. Thank you! --- Regards -PJP PS: Please don't send me html/attachment/Fwd mails Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups/bestofyahoo/ From mschwendt at gmail.com Thu Jun 19 08:51:49 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 19 Jun 2008 10:51:49 +0200 Subject: Build server for ~/.plague-client.cfg In-Reply-To: <175160.19512.qm@web94608.mail.in2.yahoo.com> References: <175160.19512.qm@web94608.mail.in2.yahoo.com> Message-ID: <20080619105149.10760cac.mschwendt@gmail.com> On Thu, 19 Jun 2008 14:00:55 +0530 (IST), Prasad J Pandit wrote: > Hello there, > > Could you tell which build server to use in ~/.plague-client.cfg file? I did try https://buildsys.fedoraproject.org:8887 from > That's correct. > http://fedoraproject.org/wiki/PackageMaintainers/UsingPlagueClientFaq#What_is_plague-client.3F > > but it's not working. I'm trying to build a package for EL-4, EL-5. "it's not working" is far from a precise problem description. _What_ doesn't work? What error message do you see? What does your ~/.plague-client.cfg contain? Have you set up the certificates? Also take notice of epel-devel-list for EPEL. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.12 1.27 0.89 From aph at redhat.com Thu Jun 19 09:34:45 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jun 2008 10:34:45 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <485963DC.70308@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> Message-ID: <485A2835.4090109@redhat.com> Les Mikesell wrote: > Andrew Haley wrote: >> >>>> I've explained that the GPL prevents me from sharing original work >>>> that links to both GPL and non-GPL libraries. >>> And I've explained that it doesn't, and asked you to cite the passage >>> of the GPL that prevents you from doing it. You haven't bothered to >>> do it, and instead decided to keep insisting in this nonsensical >>> claim. >> >> Actually, he did reply to that, but perhaps you didn't see it. >> >> He had an unfree program (the wattcp library) and GNU tar and >> discovered that he wasn't allowed to ship a program that linked >> these two together. He then said, gloriously, "please don't try >> to say the problem was cause by those other licenses - >> they did not prevent anyone else from getting copies..." :-) >> >> OK Les, I promise not to say it. However... > > I'm not sure what you are trying to imply here. I could redistribute > copies of the other two components - but that's irrelevant since anyone > could get them in source anyway (they were only unfree in the reverse > way that the GPL redefines free to mean restricted). Err, one library according to you, was unfree in the sense that you weren't allowed to change it in any way; to enhance it, or to fix bugs. > I could have > redistributed the combination if I had started with the original pdtar > instead of gnutar. You could, but if what you said was true, you still wouldn't be able to fix bugs in one of the libraries. And if, to you, free software is that which is free (as in beer) but you aren't allowed to fix bugs, then you're welcome to it. Andrew. From skasal at redhat.com Thu Jun 19 09:37:07 2008 From: skasal at redhat.com (Stepan Kasal) Date: Thu, 19 Jun 2008 11:37:07 +0200 Subject: PackageKit UI In-Reply-To: <1213268950.3505.1.camel@hughsie-work> References: <1213268950.3505.1.camel@hughsie-work> Message-ID: <20080619093707.GA18683@camelia.ucw.cz> Hi, On Thu, Jun 12, 2008 at 12:09:10PM +0100, Richard Hughes wrote: > http://www.packagekit.org/temp/gpk-application.png I looked at the picture and my first impression was that the image of box, together with package name and summary, is too big. There should be an option to display each package on one line; without the painting and with name ans summary concatenated--perhaps the template should be "%{name} %{summary[0-88]} %{version}-%{release}" Sorry if this is mentioned elsewhere in the thread, I had not enough energy to scan it. Sorry again if this is not compatible with you GUI vision--I have a tendency to eliminate as much G from my UI as possible. Have a nice UI, Stepan From kzak at redhat.com Thu Jun 19 12:00:35 2008 From: kzak at redhat.com (Karel Zak) Date: Thu, 19 Jun 2008 14:00:35 +0200 Subject: PackageKit UI In-Reply-To: <20080619093707.GA18683@camelia.ucw.cz> References: <1213268950.3505.1.camel@hughsie-work> <20080619093707.GA18683@camelia.ucw.cz> Message-ID: <20080619120035.GH2933@nb.net.home> On Thu, Jun 19, 2008 at 11:37:07AM +0200, Stepan Kasal wrote: > Sorry again if this is not compatible with you > GUI vision--I have a tendency to eliminate as much G from my UI as > possible. http://linuxhaters.blogspot.com/2008/06/how-to-write-gnome-application.html :-))) Karel -- Karel Zak From rawhide at fedoraproject.org Thu Jun 19 12:39:41 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 19 Jun 2008 12:39:41 +0000 (UTC) Subject: rawhide report: 20080619 changes Message-ID: <20080619123941.DD2BD209D1A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080618/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080619/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package adonthell A 2D graphical RPG game New package ale Combines multiple inputs of the same scene New package fs_mark Benchmark synchronous/async file creation New package haddock09 Haskell documentation tool for annotated source code New package hdrprep Align digicam images and fix EXIF information New package lostlabyrinth Lost Labyrinth is a coffeebreak dungeon crawling game New package lostlabyrinth-graphics Lost Labyrinth graphics New package lostlabyrinth-sounds Lost Labyrinth sounds New package php-pear-HTTP-Client Easy way to perform multiple HTTP requests and process their results New package synce-hal Connection framework and dccm-implementation New package tlock Terminal lock New package w3lib GRIB1 (GRIdded Binary) encoder/decoder and search/indexing routines Updated Packages: PyKDE-3.16.1-2.fc10 ------------------- * Tue Jun 10 18:00:00 2008 Rex Dieter 3.16.1-2 - Provides: PyKDE3(-devel) - Requires: PyQt3(-devel) PyQt-3.17.4-5.fc10 ------------------ * Wed Jun 18 18:00:00 2008 Rex Dieter - 3.17.4-5 - Provides: PyQt3(-devel) amqp-1.0.666398-5.fc10 ---------------------- * Tue Jun 10 18:00:00 2008 Rafael Schloming - 0:1.0.666398-5 - Source update for MRG RC1 * Mon Jun 9 18:00:00 2008 Rafael Schloming - 0:1.0.665769-5 - Source update for MRG RC1 anaconda-11.4.1.6-1 ------------------- * Wed Jun 18 18:00:00 2008 Chris Lumens - 11.4.1.6-1 - Enable media check again, and let it check the boot.iso. (clumens) - Substitute the version from buildstamp for $releasever if needed. (clumens) - Remove the askmethod cmdline option. (clumens) - Lots of work to make loader only look for stage2.img, and stage2 do all the install method configuration. (clumens) - Add the --stage2= and --repo= options, deprecate --method=. (clumens) - Fix pkgorder to include deps of kernel early. (pjones) - Deal with udev losing udevcontrol/udevtrigger (katzj) - Boot in graphical mode if /usr/bin/kdm exists. (clumens) - bootProto isn't a global variable (#451689). (clumens) apmd-3.2.2-8.fc10 ----------------- * Wed Jun 18 18:00:00 2008 Zdenek Prikryl - 1:3.2.2-8 - cleaned spec file (#225252) balsa-2.3.25-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Pawel Salek - 2.3.25-1 - update to upstream 2.3.25. bluez-libs-3.33-1.fc10 ---------------------- * Wed Jun 18 18:00:00 2008 - Bastien Nocera - 3.33-1 - Update to 3.33 bluez-utils-3.33-1.fc10 ----------------------- * Wed Jun 18 18:00:00 2008 - Bastien Nocera - 3.33-1 - Update to 3.33 cairo-dock-1.6.0.1-1.date20080619.fc10 -------------------------------------- * Thu Jun 19 18:00:00 2008 Mamoru Tasaka - 1.6.0.1-1.date20080619 - 1.6.0.1 cheese-2.23.4-1.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen 2.23.4-1 - Update to 2.23.4 control-center-2.23.4-1.fc10 ---------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 cronie-1.1-3.fc10 ----------------- * Tue Jun 17 18:00:00 2008 Tomas Mraz - 1.1-3 - fix setting keycreate context - unify logging a bit - cleanup some warnings and fix a typo in TZ code - 450993 improve and fix inotify support curl-7.18.2-2.fc10 ------------------ * Wed Jun 18 18:00:00 2008 Jindrich Novy 7.18.2-2 - fix curl_multi_perform() over a proxy (#450140), thanks to Rob Crittenden digikam-0.9.4-0.3.rc1.fc10 -------------------------- * Wed Jun 18 18:00:00 2008 Rex Dieter - 0.9.4-0.3.rc1 - digikam-0.9.4-rc1 dovecot-1.0.14-4.fc10 --------------------- * Wed Jun 18 18:00:00 2008 Dan Horak - 1:1.0.14-4 - update init script (Resolves: #451838) e2fsprogs-1.41-0.WIP.0617.fc10 ------------------------------ * Wed Jun 18 18:00:00 2008 Eric Sandeen 1.41-0.WIP.0617 - New upstream snapshot release for ext4 capability evince-2.23.4-1.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 filesystem-2.4.16-1.fc10 ------------------------ * Wed Jun 18 18:00:00 2008 Phil Knirsch - 2.4.16-1 - Dropped /etc/news again as we're handling it now correctly (#437462) - Filesystem is now an official fedorahosted project, part of the review changes (#225752) - Removed duplicate entry in lang_exceptions for ca_ES at valencian (#225752) fsvs-1.1.16-1.fc10 ------------------ * Wed Jun 18 18:00:00 2008 David Fraser 1.1.16-1 - Upgraded to 1.1.16 - Updated with new upstream description and summary fwbackups-1.43.2-0.3.rc2.fc10 ----------------------------- * Wed Jun 18 18:00:00 2008 Stewart Adam 1.43.2-0.3.rc2 - Requires python-paramiko, not build requires! gallery2-2.2.5-1.fc10 --------------------- * Wed Jun 18 18:00:00 2008 John Berninger - 2.2.5-1 - update to upstream 2.2.5 for security vuln fixes glom-1.6.17-1.fc10 ------------------ * Tue Jun 17 18:00:00 2008 Denis Leroy - 1.6.17-1 - Update to 1.6.17 - gcc 4.3 patch upstreamed gnome-applets-2.23.3-2.fc10 --------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 1:2.23.3-1 - Update to 2.23.3 gnome-games-2.23.4-1.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 1:2.23.4-1 - Update to 2.23.4 gnome-panel-2.23.4-1.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 gnome-session-2.23.4.1-1.fc10 ----------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4.1-1 - Update to 2.23.4.1 gnome-settings-daemon-2.23.4-1.fc10 ----------------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 gnome-speech-0.4.20-1.fc10 -------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 0.4.20-1 - Update to 0.4.20 gnome-terminal-2.23.4.2-1.fc10 ------------------------------ * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4.2-1 - Update to 2.23.4.2 gnome-themes-2.23.4-1.fc10 -------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 gsl-1.11-2.fc10 --------------- * Wed Jun 18 18:00:00 2008 Ivana Varekova - 1.11-2 - Resolves: #451006 programs build with gcc 4.3 based on gsl require -fgnu89-inline gstreamer-0.10.20-1.fc10 ------------------------ * Wed Jun 18 18:00:00 2008 - Bastien Nocera - 0.10.20-1 - Update to 0.10.20 imsettings-0.101.2-2.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Akira TAGOH - 0.101.2-2 - Backport patch from upstream to solve issues. - always saying IM is running when no .xinputrc. - workaround for a delay of that IM is ready for XIM. ipa-1.1.0-2.fc10 ---------------- * Wed Jun 18 18:00:00 2008 Rob Crittenden - 1.1.0-2 - Add call to /usr/sbin/upgradeconfig to post install * Wed Jun 11 18:00:00 2008 Rob Crittenden - 1.1.0-1 - Update to upstream version 1.1.0 - Patch for indexing memberof attribute - Patch for indexing uidnumber and gidnumber - Patch to change DNA default values for replicas - Patch to fix uninitialized variable in ipa-getkeytab kdeaccessibility-4.0.82-1.fc10 ------------------------------ * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdeartwork-4.0.82-1.fc10 ------------------------ * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdebase-4.0.82-2.fc10 --------------------- * Mon Jun 16 18:00:00 2008 Than Ngo 4.0.82-2 - BR kdebase-workspace-devel (F9+) * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdebase-runtime-4.0.82-1.fc10 ----------------------------- * Tue Jun 24 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdebase-workspace-4.0.82-2.fc10 ------------------------------- * Tue Jun 17 18:00:00 2008 Rex Dieter 4.0.82-2 - +Provides: kdm * Sat Jun 14 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdebindings-4.0.82-3.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Rex Dieter 4.0.82-3 - revert, more borkage. * Tue Jun 17 18:00:00 2008 Kevin Kofler 4.0.82-2 - reenable smoke and ruby, set ENABLE_SMOKEKDEVPLATFORM=OFF (no kdevplatform) * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 - omit ruby, smoke (busted) => no -devel subpkg (for now) - PyKDE4(-devel) subpkgs kdeedu-4.0.82-1.fc10 -------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdegames-4.0.82-1.fc10 ---------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdemultimedia-4.0.82-1.fc10 --------------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 * Thu Jun 5 18:00:00 2008 Tom "spot" Callaway 4.0.80-3 - some of the libraries are clearly LGPLv2+, correct license tags for libs and devel * Thu Jun 5 18:00:00 2008 Rex Dieter 4.0.80-2 - License: GPLv2+ kdenetwork-4.0.82-1.fc10 ------------------------ * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdepim-4.0.82-1.fc10 -------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdepimlibs-4.0.82-1.fc10 ------------------------ * Sat Jun 14 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdesdk-4.0.82-1.fc10 -------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdetoys-4.0.82-1.fc10 --------------------- * Thu Jun 12 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdeutils-4.0.82-1.fc10 ---------------------- * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 libisofs-0.6.6-1.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Denis Leroy - 0.6.6-1 - Update to upstream 0.6.6 librapi-0.11.1-1.fc10 --------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade llvm-2.3-2.fc10 --------------- * Wed Jun 18 18:00:00 2008 Bryan O'Sullivan - 2.3-2 - Add dependency on groff * Wed Jun 18 18:00:00 2008 Bryan O'Sullivan - 2.3-1 - LLVM 2.3 * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 2.2-4 - fix license tags mailx-12.3-0.fc10 ----------------- * Wed Jun 18 18:00:00 2008 Dmitry Butskoy - 12.3-0 - Change the name from "nail" to upstream's "mailx". Merge with the ordinary "mailx" cvs tree for Fedora 10. Now this stuff supersedes the old ancient mailx-8.x in Feedora. - Build with nss instead of openssl, for "Security Consolidation" process. man-pages-3.00-1.fc10 --------------------- * Wed Jun 18 18:00:00 2008 Ivana Varekova - 3.00-1 - update to 3.00 - source files changes mkinitrd-6.0.54-1.fc10 ---------------------- * Wed Jun 18 18:00:00 2008 Peter Jones - 6.0.54-1 - More plymouth work (pjones, rstrode) - Update mkliveinitrd because udev's command line utilities changed (katzj) mousetweaks-2.23.4-1.fc10 ------------------------- * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 odccm-0.11.1-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade openobex-1.3-13.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Jiri Moskovcak 1.3-13 - fixed problem when ircp tries to write files to / - Resolves: #451493 orange-0.3.2-1.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 0.3.2-1 - version upgrade orca-2.23.4-1.fc10 ------------------ * Wed Jun 18 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 p7zip-4.58-1.fc10 ----------------- * Wed Jun 18 18:00:00 2008 Matthias Saou 4.58-1 - Update to 4.58. - Update norar patch. - Update install patch. perl-Moose-0.50-1.fc10 ---------------------- * Tue Jun 17 18:00:00 2008 Chris Weyl 0.50-1 - update to 0.50 - drop obviated test patch powerman-2.1-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Steven Parrish 2.1-1 - New upstream release pspp-0.6.0-6.fc10 ----------------- * Wed Jun 18 18:00:00 2008 Matej Cepl 0.6.0-6 - Bug 451006 has been resolved, so we don't have to munge CFLAGS anymore. pulseaudio-0.9.11-0.4.svn20080618.fc10 -------------------------------------- * Wed Jun 18 18:00:00 2008 Lennart Poettering 0.9.11-0.4.svn20080618 - New SVN snapshot python-qpid-0.2.668378-1.fc10 ----------------------------- * Mon Jun 16 18:00:00 2008 Rafael Schloming - 0.2.668378-1 - Source update for MRG RC1 * Mon Jun 16 18:00:00 2008 Rafael Schloming - 0.2.668345-1 - Source update for MRG RC1 * Tue Jun 10 18:00:00 2008 Rafael Schloming - 0.2.666398-12 - Source update for MRG RC1 * Mon Jun 9 18:00:00 2008 Rafael Schloming - 0.2.665776-12 - Source update for MRG RC1 rtpproxy-1.1-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Peter Lemenkov - 1.1-1 - Stable ver. 1.1 ruby-RMagick-2.5.0-1.fc10 ------------------------- * Thu Jun 19 18:00:00 2008 Mamoru Tasaka - 2.5.0-1 - 2.5.0 ruby-aws-0.3.2-1.fc10 --------------------- * Thu Jun 19 18:00:00 2008 Mamoru Tasaka - 0.3.2-1 - 0.3.2 ruby-marc-0.2.0-1.fc10 ---------------------- * Thu Jun 19 18:00:00 2008 Mamoru Tasaka - 0.2.0-1 - 0.2.0 rubygem-hoe-1.6.0-1.fc10 ------------------------ * Wed Jun 18 18:00:00 2008 Darryl Pierce - 1.6.0-1 - Release 1.6.0 of the gem. sudo-1.6.9p13-7.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Peter Vrabec 1.6.9p13-7 - build with newer autoconf-2.62 (#449614) synce-kpm-0.11.2-0.1.svn3491.fc10 --------------------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.2-0.1.svn3491 - pull svn version for hal support * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade synce-sync-engine-0.11.1-1.fc10 ------------------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade - drop pywbxml requires texlive-2007-32.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Jindrich Novy - 2007-32 - texlive-xetex now provides tex(xetex) (#451774) - attempt to fix lacheck segfault (#451513) - avoid multiple ownership of texconfig stuff (#442135) transmission-1.22-1.fc10 ------------------------ * Wed Jun 18 18:00:00 2008 Denis Leroy - 1.22-1 - Update to upstream 1.22 * Sat May 31 18:00:00 2008 Denis Leroy - 1.21-1 - Update to upstream 1.21 wavpack-4.50-1.fc10 ------------------- * Wed Jun 18 18:00:00 2008 Peter Lemenkov 4.50-1 - Version 4.50 wbxml2-0.9.2-14.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.9.2-14 - drop synce patches (not needed anymore, fixes #445130) xorg-x11-drv-radeonhd-1.2.1-3.1.20080618git.fc10 ------------------------------------------------ * Wed Jun 18 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.1.20080618git - New snapshot (upstream commit 1f65f354cfdda40578b222beb1dd6a48af451735): - 1f65f354: MC Fix build. - 357e232a: Add test for sideport memory on IGP. - 88e0c878: MC Add optiuon to turn off chipset features that have not been verified by ATI. - c6e75506: DIG,RS780 Fix test for LVDS/TMDS. - 6623271d: MC,RS780 Set the correct write enable bit for MC write access. Summary: Added Packages: 12 Removed Packages: 0 Modified Packages: 79 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libisofs.so.5 brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.x86_64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libisofs.so.5 brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.ppc64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From chris.stone at gmail.com Thu Jun 19 13:37:02 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 19 Jun 2008 06:37:02 -0700 Subject: Need package reviewer and sponsor for php-pear-Net-IPv4 and php-pear-Net-DNS In-Reply-To: <1213803157.13458.13.camel@hp6710.axianet.ch> References: <1213803157.13458.13.camel@hp6710.axianet.ch> Message-ID: On Wed, Jun 18, 2008 at 8:32 AM, Steven Moix wrote: > Hello all, > > I need someone who volunteers to review 2 small packages which are stuck > in bugzilla since almost a month: > > ?php-pear-Net-IPv4: ?https://bugzilla.redhat.com/show_bug.cgi?id=448205 > and > ?php-pear-Net-DNS: ?https://bugzilla.redhat.com/show_bug.cgi?id=448204 > > These are PHP Pear libraries that I use in many projects to do network > queries, so I thought that it would be a good idea to package them. > As these are my first packages in Fedora, I need a sponsor as well. > > This is also my first post on this mailinglist, so...hi all. I'm Steven, > a Swiss engineering student using Fedora since Core 1, wanting to give > some of my time back to the community. > > Thanks for your help! I can sponsor you. Can you access IRC? I prefer sponsoring people who can communicate on freenode.net IRC network channel #fedora-devel. https://fedoraproject.org/wiki/Communicate#IRC From lesmikesell at gmail.com Thu Jun 19 13:50:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 08:50:48 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A2835.4090109@redhat.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> Message-ID: <485A6438.6060000@gmail.com> Andrew Haley wrote: > > >>> He had an unfree program (the wattcp library) and GNU tar and >>> discovered that he wasn't allowed to ship a program that linked >>> these two together. He then said, gloriously, "please don't try >>> to say the problem was cause by those other licenses - >>> they did not prevent anyone else from getting copies..." :-) >>> >>> OK Les, I promise not to say it. However... >> I'm not sure what you are trying to imply here. I could redistribute >> copies of the other two components - but that's irrelevant since anyone >> could get them in source anyway (they were only unfree in the reverse >> way that the GPL redefines free to mean restricted). > > Err, one library according to you, was unfree in the sense that you weren't > allowed to change it in any way; to enhance it, or to fix bugs. That's not an accurate description, although it did have a restriction on distributing modified versions. I could, of course, change my own copy and submit bug fixes and enhancements to the author for incorporation - or make the source modifications available separately from the package. The restriction was more about preventing broken versions from being distributed than enhancements. >> I could have >> redistributed the combination if I had started with the original pdtar >> instead of gnutar. > > You could, but if what you said was true, you still wouldn't be able to > fix bugs in one of the libraries. And if, to you, free software is that > which is free (as in beer) but you aren't allowed to fix bugs, then > you're welcome to it. The best way to fix bugs is to get the fix incorporated in the base package so it can be properly tested, merged with other fixes, and provided to everyone using it. Otherwise you can s/fix/add/ in your description of what you want to be permitted to do followed by distributing them in a package someone else tries to support. How many broken TCP stacks do we really want on our networks where someone thinks cranking the retry timer gives it an advantage? There is the argument that if the author/maintainer stops updating, the package can die. Well, these were DOS libraries. The sooner that stuff died the better. Knowledge about TCP didn't start or end with that package and copies are probably still available in archives somewhere. -- Les Mikesell lesmikesell at gmail.com From aph at redhat.com Thu Jun 19 13:57:18 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jun 2008 14:57:18 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A6438.6060000@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> <485A6438.6060000@gmail.com> Message-ID: <485A65BE.2060209@redhat.com> Les Mikesell wrote: > Andrew Haley wrote: >> > >>>> He had an unfree program (the wattcp library) and GNU tar and >>>> discovered that he wasn't allowed to ship a program that linked >>>> these two together. He then said, gloriously, "please don't try >>>> to say the problem was cause by those other licenses - >>>> they did not prevent anyone else from getting copies..." :-) >>>> >>>> OK Les, I promise not to say it. However... >>> I'm not sure what you are trying to imply here. I could redistribute >>> copies of the other two components - but that's irrelevant since anyone >>> could get them in source anyway (they were only unfree in the reverse >>> way that the GPL redefines free to mean restricted). >> >> Err, one library according to you, was unfree in the sense that you >> weren't >> allowed to change it in any way; to enhance it, or to fix bugs. > > That's not an accurate description, although it did have a restriction > on distributing modified versions. I could, of course, change my own > copy and submit bug fixes and enhancements to the author for > incorporation - or make the source modifications available separately > from the package. The restriction was more about preventing broken > versions from being distributed than enhancements. Sure, but it had that effect, didn't it? If you're not allowed to distribute modified versions without someone else's consent, it's not free (as in freedom) software. >>> I could have >>> redistributed the combination if I had started with the original pdtar >>> instead of gnutar. >> >> You could, but if what you said was true, you still wouldn't be able to >> fix bugs in one of the libraries. And if, to you, free software is that >> which is free (as in beer) but you aren't allowed to fix bugs, then >> you're welcome to it. > > The best way to fix bugs is to get the fix incorporated in the base > package so it can be properly tested, merged with other fixes, and > provided to everyone using it. Otherwise you can s/fix/add/ in your > description of what you want to be permitted to do followed by > distributing them in a package someone else tries to support. How many > broken TCP stacks do we really want on our networks where someone thinks > cranking the retry timer gives it an advantage? There is the argument > that if the author/maintainer stops updating, the package can die. Quite. And, indeed, that's the inevitable consequence. Andrew. From rdieter at math.unl.edu Wed Jun 18 15:51:59 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 18 Jun 2008 10:51:59 -0500 Subject: kdebindings -> PyKDE4 split Message-ID: <48592F1F.1060303@math.unl.edu> kdebindings currently includes bindings for many languages, including python, ruby, etc, and currently bundled all together into a single monolithic package. The KDE SIG will be working to split these out (where it makes sense). The first one is python, which has been split into it's own PyKDE4 package (should land in the next rawhide iteration). This split will propogate back to F-9 when kde-4.1 is released (late July-ish) -- Rex _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lesmikesell at gmail.com Thu Jun 19 15:36:52 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 10:36:52 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A65BE.2060209@redhat.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> <485A6438.6060000@gmail.com> <485A65BE.2060209@redhat.com> Message-ID: <485A7D14.9030204@gmail.com> Andrew Haley wrote: > >>> Err, one library according to you, was unfree in the sense that you >>> weren't >>> allowed to change it in any way; to enhance it, or to fix bugs. >> That's not an accurate description, although it did have a restriction >> on distributing modified versions. I could, of course, change my own >> copy and submit bug fixes and enhancements to the author for >> incorporation - or make the source modifications available separately >> from the package. The restriction was more about preventing broken >> versions from being distributed than enhancements. > > Sure, but it had that effect, didn't it? If you're not allowed to > distribute modified versions without someone else's consent, it's not free > (as in freedom) software. It's not free the way the GPL redefines the word to mean restricted, but it doesn't interfere with your freedom to distribute your changes as patches, leaving it clear that it is something different from the original author's work that he supports. In more modern licenses, I'd prefer the ones where you are permitted to modify independently and distribute the forked copy if you change the package name, but it is only in odd circumstances that it even matters or that there is any effective difference. Even in GPL circles I think most people agree that the best process is to coordinate modifications into a single revision tree instead of forking wildly. >> There is the argument >> that if the author/maintainer stops updating, the package can die. > > Quite. And, indeed, that's the inevitable consequence. It's not at all inevitable since the copyright holder can transfer control at any time or might already be a foundation that will outlast any possible use for the product. But, in technology everyone is better off when an old package does die and is replaced by something new and improved, and the harm of the GPL is that it's 'work as a whole' requirement makes it difficult or impossible for these replacements to happen at the component level when the currently best component isn't encumbered by the GPL. -- Les Mikesell lesmikesell at gmail.com From buc at odusz.so-cdu.ru Thu Jun 19 15:47:18 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 19 Jun 2008 19:47:18 +0400 Subject: What changelog to preserve at untrivial merging? Message-ID: <485A7F86.2090502@odu.neva.ru> We've changed /bin/mail command source to the new upstream in rawhide (see https://www.redhat.com/archives/fedora-devel-list/2008-June/msg00628.html for more info). The new source was already in Fedora, under an alternative name of "nail". IOW, we currently have /bin/mail provided by mailx-8.1.1, and /usr/bin/nail, provided by nail-12.3. Since nail-12.3 supersedes all the features of the old undeveloped mailx-8.1.1 (and has the same upstream name of "mailx" now), we've decised to switch to it for /bin/mail as well. As a result, I've copied the "devel" branch of the "nail" package to the "devel" branch of the "mailx" package (with some adaptation needed). The question is: What changelog to preserve? Both packages have their own history. What changelog preserve in the new mailx in rawhide -- the old entries from mailx-8.x, the new entries from nail-12.3, or something else? Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From aoliva at redhat.com Thu Jun 19 15:59:11 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 12:59:11 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213831117.11083.63.camel@valkyrie.localdomain> (Matthew Saltzman's message of "Wed\, 18 Jun 2008 19\:18\:36 -0400") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> Message-ID: On Jun 18, 2008, Matthew Saltzman wrote: > Then can we at least agree that there are sometimes unfortunate > consequences to the GPL's failure to permit one to share a work > combining two pieces of *free* software because of relatively minor[1] > license incompatibilities? Yeah, it's unfortunate when this happens. In general, authors who use the GPL for its intended purpose (ensuring the 4 freedoms are respected for all users) won't object to the combination of their works with other works that respect users' freedoms, and will grant additional permissions for the combinations in spite of the license conflicts. Of course, not everyone does that, and some people who would like to create such combinations may even not realize that this possibility exists, or think it's not worth the effort. So, yeah, it's unfortunate, but I don't think it's really such a big deal. Nearly all Free Software *is* available under the GPL and compatible licenses anyway. > In fact, I think it's arguable that there are sometimes unfortunate > consequences to the GPL's failure to permit one to share a work that > makes use of a GPL library and a proprietary library. Sparing a user from becoming dependent on a piece of proprietary software might even be a sacrifice for the user, but it's actually an advantage for the user and for society in the long run. Anyhow, it is true that conquering freedom is not without its sacrifices. Like, one could argue that an army is a useless expense and sacrifice in times of peace, but if you don't work on your defenses proactively (and GPL is a license that not only respects the 4 freedoms, but also stands up to defend them), you become a sweeter target, more likely to be defeated and terminated. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aph at redhat.com Thu Jun 19 16:02:39 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jun 2008 17:02:39 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A7D14.9030204@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> <485A6438.6060000@gmail.com> <485A65BE.2060209@redhat.com> <485A7D14.9030204@gmail.com> Message-ID: <485A831F.8030803@redhat.com> Les Mikesell wrote: > Andrew Haley wrote: >>>> Err, one library according to you, was unfree in the sense that >>>> you weren't allowed to change it in any way; to enhance it, or to >>>> fix bugs. >>> That's not an accurate description, although it did have a >>> restriction on distributing modified versions. I could, of >>> course, change my own copy and submit bug fixes and enhancements >>> to the author for incorporation - or make the source modifications >>> available separately from the package. The restriction was more >>> about preventing broken versions from being distributed than >>> enhancements. >> Sure, but it had that effect, didn't it? If you're not allowed to >> distribute modified versions without someone else's consent, it's >> not free (as in freedom) software. > It's not free the way the GPL redefines the word to mean restricted, > but it doesn't interfere with your freedom to distribute your > changes as patches, leaving it clear that it is something different > from the original author's work that he supports. I think my meaning was clear. It's not free because you can't distribute modified versions. And no matter how much you try to define it away, this basic fact will not change. Yes, you can supply it with a bunch of patches, but you can't do the obvious thing and check it in to a public source code control system and work on it there, since that would mean sharing a modified version. You can't distribute a modified version as part of, for example, a Linux distro. It's not free in any sense, except free-as-in-beer. > In more modern licenses, I'd prefer the ones where you are permitted > to modify independently and distribute the forked copy if you change > the package name, Well, yes. Obviously. > but it is only in odd circumstances that it even matters or that > there is any effective difference. Even in GPL circles I think most > people agree that the best process is to coordinate modifications > into a single revision tree instead of forking wildly. Sure, but that's a matter of free choice. That's what freedom means: you can either fork the software yourself, or you can contribute to the trunk. The choice is up to *you*. And anyone to whom you give the software has that same choice, and you can't take that freedom away from them. >>> There is the argument that if the author/maintainer stops >>> updating, the package can die. >> >> Quite. And, indeed, that's the inevitable consequence. > > It's not at all inevitable since the copyright holder can transfer > control at any time or might already be a foundation that will outlast > any possible use for the product. Sure, or they might not choose to do so. You could say the same about any software supplied under a restrictive licence. > But, in technology everyone is better > off when an old package does die and is replaced by something new and > improved, and the harm of the GPL is that it's 'work as a whole' > requirement makes it difficult or impossible for these replacements to > happen at the component level when the currently best component isn't > encumbered by the GPL. Eh? This makes no sense. It's certainly not justified by this example, anyway. Andrew. From aoliva at redhat.com Thu Jun 19 16:26:45 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 13:26:45 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <48599D8A.8020507@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 18\:43\:06 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >> Here, take this program here: >> >> http://www.lsd.ic.unicamp.br/~oliva/papers/vta/example.c >> >> What do you think you're entitled to do with it as it stands? > Assuming it is permitted for me to get a copy in the first place, You don't need permission from a copyright holder to receive a copy. You don't get fined or go to jail if someone sends you spam containing a copyrighted work, or you pick up a piece of paper with copyrighted material thrown out of an airplane. > then I have fair use of it. Such as... > I could link my copy with anything else I wanted. Why do you think you could combine it with other works without my permission? > And I could give away my work that called it and some other code. Depending on how it calls my work, the work you created based on mine may amount to a derived joint work per copyright law, and then you'd need my permission to distribute it. >> Now, if I tell you, I license it to you under the GPL, and you accept >> it. what you you think you're no longer entitled to do with it? > Then I couldn't give my additional work away to other people to use > with their own copies of your work and third party libraries. No difference. > They could hire me to re-invent it, but I couldn't distribute my > work. If it is your work, you can. If it's our joint work, you'd need my permission as well, and you'd have permission to distribute it under the terms of the GPL. Besides, the GPL doesn't (and couldn't) take away any of your fair use rights, because it's not a contract (no reciprocation), it's a unilateral grant of permissions. >>> No one but the FSF claims that a patch is a derived work >> How would you defend the claim that something that literally copies >> portions of a copyrightable work is not? > It's fair use Why? How do you (or rather courts) draw the line? > but I'd settle for being able to do a line-numbered > edit script that didn't not copy any original material. Literal copying is not required to create a derived work. > Or a completely separate work that linked two differently licensed > libraries that are not included. Once it links with the other libraries, it contains portions of the libraries, so it is a joint work. Just like, it's not because you wrote a novel book that mentions some famous paintings that you're entitled to print in the book copies of those paintings, or even vague sketches thereof, and then distribute copies of the book. > Yes, we covered the fact that everyone else permits it. If someone permits it (definitely not everyone), it's presumable that such a permission is required. Indeed, copyright does require such permissions. You seem to believe it doesn't, but you're mistaken. >> Try creating a work based on internal DLLs, for which you have no >> "developer" permissions. > Again, I have never heard of any prohibition against sharing such a > thing with anyone who has their own copy of all required components. Not knowing or not understanding the law is not an excuse to not comply with it. >>> if the resulting 'work as a whole' would be be a derived work, >> >> Then it's not "your own original work" > Define whose work it is, then. It's a joint work. If you derive a work from mine, in the copyright sense, then both of us are authors, both of us have a say (veto power) on how it can be modified and distributed. > Take the case of an original program > that links with two other libraries. It is entirely conceivable and > fairly likly that compatible GPL and non-GPL libraries will be > available and it is the end users choice at compile/run time. Who > owns this work? Whoever owns the source code of the original program and that of the library whose (minor) portions got copied into the binary. You defend from a claim of infringement presenting another library and claiming you derived the distributed executable from it. Then you'd be bound by the terms of that other library. In theory, you could clean-room-develop just enough of a duplicate of the library to be able to create an executable that doesn't copy anything from the library. It might still be regarded as an infringement by a court, though, because at times what counts is the intention, even if the strict letter can be bent to support the facts. >>> Without the GPL, I can give you a copy of my original work that >>> links to that library >> Only if the copyright holder of the library granted you permission to >> distribute your derived work. > That's just not true. I'm afraid you got your facts wrong. Talk to your lawyer about distributing combined works. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aph at redhat.com Thu Jun 19 16:37:08 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jun 2008 17:37:08 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> Message-ID: <485A8B34.9060808@redhat.com> Alexandre Oliva wrote: > On Jun 18, 2008, Matthew Saltzman wrote: > >> Then can we at least agree that there are sometimes unfortunate >> consequences to the GPL's failure to permit one to share a work >> combining two pieces of *free* software because of relatively minor[1] >> license incompatibilities? > > Yeah, it's unfortunate when this happens. Definitely. It's something that GPL V3 has tried hard to fix, wherever possible. However, I must point out that in some cases post-GPL licences have *deliberately* been worded in a way that makes them incompatible with GPL code. Whatever the consequences, it's not appropriate to blame the GPL for those. >> In fact, I think it's arguable that there are sometimes unfortunate >> consequences to the GPL's failure to permit one to share a work that >> makes use of a GPL library and a proprietary library. > > Sparing a user from becoming dependent on a piece of proprietary > software might even be a sacrifice for the user, but it's actually an > advantage for the user and for society in the long run. Perhaps. I think we have to think about, for example, gcc ports. The fact that people who do ports of gcc are forced to ship the source for their changes has made a lot of free code available that wouldn't have been if they had been permitted to link proprietary code into gcc. Andrew. From vonbrand at inf.utfsm.cl Thu Jun 19 16:57:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 19 Jun 2008 12:57:50 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213831117.11083.63.camel@valkyrie.localdomain> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> Message-ID: <200806191657.m5JGvoNi020826@laptop13.inf.utfsm.cl> Matthew Saltzman wrote: > On Wed, 2008-06-18 at 19:33 -0300, Alexandre Oliva wrote: > > On Jun 18, 2008, Matthew Saltzman wrote: [...] > > > Wait--Alexandre, are you saying that I could take a GPL library and, > > > say, a CPL[1] library, write a program that links to both libraries to > > > create new functionality and legally distribute source code or a > > > statically or dynamically linked executable version of my program > > > licensed under either the GPL or the CPL? > > No. I'm just saying that it's not the GPL that prevents you from > > distributing it. It's copyright law. The GPL merely refrains from > > granting permission for you to do something that, without such > > permission from copyright holders, you can't do in the first place. > > OK I see. > > Then can we at least agree that there are sometimes unfortunate > consequences to the GPL's failure to permit one to share a work > combining two pieces of *free* software because of relatively minor[1] > license incompatibilities? Sure. > In fact, I think it's arguable that there are sometimes unfortunate > consequences to the GPL's failure to permit one to share a work that > makes use of a GPL library and a proprietary library. I understand some > authors' desire not to permit that kind of sharing of their work, even > if I don't necessarily agree with it. But I also think that there's > lots of software released under the GPL by authors who don't think > deeply about license issues and don't really understand the limits of > what is permitted by the GPL. Right. But to grant (or not) such permission is the copyright holder's decision. And it is not up to us to second guess their "real" intention. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Thu Jun 19 17:24:59 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 19 Jun 2008 13:24:59 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48598E6A.5020406@gmail.com> References: <1212917892.32207.488.camel@pmac.infradead.org> <484C0B49.5080600@hhs.nl> <1212959526.2534.62.camel@shinybook.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.c! om> Message-ID: <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Alexandre Oliva wrote: [...] > >> With any other license, I could at least have done a diff against > >> the original copies and my work and given that away Nope. The diff is very clearly a work derived from the original (you just can't cook up a difference to the original without the original; it doesn't really matter if it is a diff or a sequence of ed(1) commands, or instructions for a human to fix up the files). Creating such in the first place needs permission from the copyright holder, distributing it even more so. > > As long as your original work is not a derived work. If it is, you > > still need permission from the copyright holders of the original work, > > to both create your derived work and to distribute the > > collective/derived work. > No one but the FSF claims that a patch is a derived work - or a > separate component that links 2 others together but doesn't contain a > copy of the others. It isn't the FSF who claims that, they are just spelling out the relevant legal situation. > >> This doesn't happen with any license but the GPL. > > Sorry, I don't know how you came to this conclusion, but it's > > incorrect. > > Try to create a derived work based on say Microsoft Windows or > > Microsoft Word, if you happen to have them around, and to distribute > > it, and see what happens. > I'm not sure what you are talking about. It's a pretty safe bet that > there is more code that relies on Microsoft libraries than anything > else So? It /uses/ the libraries in the way the relevant license spells out, and you can the distribute what you build on them as said license allows. It isn't taking pieces of said libraries and distributing modified versions of them at all. Besides, you can get into hot water if you just ship your program with some libraries (AFAIR, MSFT C (or perhaps some other language, memory is a bit fuzzy) came with libraries that you had to get separate "runtime licenses" for each user of a program developed with them). > and Microsoft does not try to stop people from distributing it. > If anything, they encourage it by making a lot of tools and libraries > available. That they elect not to stop distribution is their own choice, they could choose otherwise. And they are claiming that running stuff using said libraries on a non-MSFT operating system is infringing... > >>> This would be a prohibition of the GPL. > >> Yes, in case it wasn't clear before, the specific prohibition that I > >> consider unethical is that it takes away my choice to share my own > >> work. > > It doesn't. Your own original work can't possibly be a derived work. > Difference of opinion, I guess. You guess wrong. If it is an original work of yours, it has absolutely no relation to whatever other pieces. > The FSF says otherwise and that if the > resulting 'work as a whole' would be be a derived work, then the > components, including my own work, can't be distributed unless all are > restricted by the GPL. Your own work, if it depends intimately on the original, is clearly a derived work. And you need the owner's permission to create it in the first place. If said owner grants that permission only under the condition that your modifications have to be distributed under GPL... > > It does not grant you permission to distribute joint works you created > > by deriving works from others' works in certain ways, so the > > prohibition from copyright law remains in place. See, you didn't have > > that choice in the first place for the GPL to take away. That's the > > fundamental point that you're missing. > I'm not missing anything. Here we go again... > I have my copy of a library, ... because you were granted the right of having a copy by the owner of the relevant rights, which you got under certain conditions. And presumably the owner of said rights allows you to create programs that use the library, but they very well could prohibit doing so. Not unheard of, in any case. > you have your > copy. Ditto. > Without the GPL, I can give you a copy of my original work that > links to that library without imposing the GPL restrictions on it and > any other related components. OK, as long as you both respect the conditions under which you got the library. I.e., if the conditions did include allowing you to create such programs, and then distributing them. > With the GPL, I can't. Wrong, you can just as before. > And the same > applies even if we both have source and I have made a patch. Using a library is one thing, taking its code and modifying it something quite different; and distributing a copy of the original or a modified version are yet again completely different. For each of those activities you need separate permissions. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From lesmikesell at gmail.com Thu Jun 19 17:27:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 12:27:09 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A831F.8030803@redhat.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> <485A6438.6060000@gmail.com> <485A65BE.2060209@redhat.com> <485A7D14.9030204@gmail.com> <485A831F.8030803@redhat.com> Message-ID: <485A96ED.1010603@gmail.com> Andrew Haley wrote: > >> It's not free the way the GPL redefines the word to mean restricted, >> but it doesn't interfere with your freedom to distribute your >> changes as patches, leaving it clear that it is something different >> from the original author's work that he supports. > > I think my meaning was clear. It's not free because you can't > distribute modified versions. It means you've defined free to mean what GPL advocates pretend it means. > And no matter how much you try to > define it away, this basic fact will not change. Yes, you can supply > it with a bunch of patches, but you can't do the obvious thing and > check it in to a public source code control system and work on it > there, since that would mean sharing a modified version. You can't generalize and say that can't be done, because the copyright owner may grant such permission - or do the generally better thing and coordinate the modifications himself. But note that you _can_ generalize and say that this is always impossible with any GPL covered material when the modification you want to make involves adding something that isn't GPL'd. > You can't > distribute a modified version as part of, for example, a Linux distro. And you can't modify a Linux disto, for example, by adding zfs to the kernel and distribute it. > It's not free in any sense, except free-as-in-beer. And GPL-encumbered material isn't free in any sense except for the rare dual-licensed things that cleverly avoid its entrapment. You are just ignoring the restrictions. >> but it is only in odd circumstances that it even matters or that >> there is any effective difference. Even in GPL circles I think most >> people agree that the best process is to coordinate modifications >> into a single revision tree instead of forking wildly. > > Sure, but that's a matter of free choice. That's what freedom means: > you can either fork the software yourself, or you can contribute to > the trunk. The choice is up to *you*. And anyone to whom you give > the software has that same choice, and you can't take that freedom > away from them. Sorry, but freedom does _not_ mean being restricted from using components together and forcing everyone else to follow that same restriction. >>>> There is the argument that if the author/maintainer stops >>>> updating, the package can die. >>> Quite. And, indeed, that's the inevitable consequence. >> It's not at all inevitable since the copyright holder can transfer >> control at any time or might already be a foundation that will outlast >> any possible use for the product. > > Sure, or they might not choose to do so. So don't claim it is inevitable one way or another. Those choices are what freedom is about. >> But, in technology everyone is better >> off when an old package does die and is replaced by something new and >> improved, and the harm of the GPL is that it's 'work as a whole' >> requirement makes it difficult or impossible for these replacements to >> happen at the component level when the currently best component isn't >> encumbered by the GPL. > > Eh? This makes no sense. It's certainly not justified by this > example, anyway. If it takes a current concrete example to make sense, swapping out reiserfs with zfs in the Linux kernel seems like a good idea. But we can't do that because the kernel is too free. -- Les Mikesell lesmikesell at gmail.com From moe at blagblagblag.org Thu Jun 19 17:50:45 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 19 Jun 2008 14:50:45 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080618201338.GA9581@localhost.localdomain> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> Message-ID: <485A9C75.3090204@blagblagblag.org> Anders Karlsson wrote: > * jeff [20080618 17:50]: > [snip] >> ... more pages of hex >> >> >> I personally downloaded this file believing that I was getting a free GPL >> driver. Broadcom says so in the patch itself, in the included LICENSE >> file, and their website when you click to download it. Red Hat is >> shipping it as GPLv2. So either they have to provide the source (if they >> have it), stop shipping it, or *at least* stop saying they are shipping a >> GPLv2 kernel if they are unwilling/unable to provide the source. > > You missed the discussion where it was pointed out that some firmware > is written in hex directly, as there is no compiler. Good luck with > demanding the source to that dude... ----> "Derived from proprietary unpublished source code" <---- linux-2.6.25/drivers/net/tg3.c: /* * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) * Copyright (C) 2004 Sun Microsystems Inc. * Copyright (C) 2005-2007 Broadcom Corporation. * * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. */ tg3.c is the example I have been using all along. Of course actually getting Red Hat or Broadcom to turn it over wouldn't be easy. Broadcom has some legal issues of their own right now, heh. -Jeff From lesmikesell at gmail.com Thu Jun 19 18:29:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 13:29:59 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> References: <1212917892.32207.488.camel@pmac.infradead.org> <20080609205528.GB4009@devserv.devel.redhat.com> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.c! om> <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> Message-ID: <485AA5A7.7010900@gmail.com> Horst H. von Brand wrote: > >>>> With any other license, I could at least have done a diff against >>>> the original copies and my work and given that away > > Nope. The diff is very clearly a work derived from the original (you just > can't cook up a difference to the original without the original; Perhaps, but it is not at all clear whether copyright restricts you from distributing such changes because there is an obvious conflict with your rights to use your copy in the ways you want. How would you relate what you are saying to the recent ruling in the UK that selling modified ROMS to someone who already has the original does not violate copyright law? http://www.techdirt.com/articles/20080612/0055131385.shtml That's not entirely universal and in the US the DMCA would make it illegal to break encryption for the purpose of circumventing copy protection whether or not the actual copying was legal - but it seems like the right approach to me. >> I'm not sure what you are talking about. It's a pretty safe bet that >> there is more code that relies on Microsoft libraries than anything >> else > > So? It /uses/ the libraries in the way the relevant license spells out, and > you can the distribute what you build on them as said license allows. It > isn't taking pieces of said libraries and distributing modified versions of > them at all. Again, this is not at all clear. >> The FSF says otherwise and that if the >> resulting 'work as a whole' would be be a derived work, then the >> components, including my own work, can't be distributed unless all are >> restricted by the GPL. > > Your own work, if it depends intimately on the original, is clearly a > derived work. And you need the owner's permission to create it in the first > place. No, I need the owner's permission to have my copy in the first place. I don't need his permission to use it or add my own changes to it. > If said owner grants that permission only under the condition that > your modifications have to be distributed under GPL... Once I have my copy, said owner has no more to say about what I can do with it. Copyright prevents subsequent redistribution without permission but it is not anyone else's business if I redistribute the work that I've added to my copy to someone else who also has a copy of the original work. > ... because you were granted the right of having a copy by the owner of the > relevant rights, which you got under certain conditions. There are no conditions to receiving a copy a copy under the GPL. And if there were, they would have to comply with the rights you have to use the copy you've gotten. > Using a library is one thing, taking its code and modifying it something > quite different; and distributing a copy of the original or a modified > version are yet again completely different. For each of those activities > you need separate permissions. Sometimes. Some of those things are basic rights, recognized differently in different places. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Jun 19 18:35:22 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 13:35:22 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> Message-ID: <485AA6EA.4020309@gmail.com> Alexandre Oliva wrote: > >> Then can we at least agree that there are sometimes unfortunate >> consequences to the GPL's failure to permit one to share a work >> combining two pieces of *free* software because of relatively minor[1] >> license incompatibilities? > > Yeah, it's unfortunate when this happens. In general, authors who use > the GPL for its intended purpose (ensuring the 4 freedoms are > respected for all users) won't object to the combination of their > works with other works that respect users' freedoms, and will grant > additional permissions for the combinations in spite of the license > conflicts. I don't believe that is generally true except for perl and the few other dual-licensed packages where the authors understood the issue from the start. And worse, there is no accounting for copyright ownership since anyone could have added code and most packages have no one who could grant such permission on current packages encumbered by the GPL. > So, yeah, it's unfortunate, but I don't think it's really such a big > deal. Nearly all Free Software *is* available under the GPL and > compatible licenses anyway. And there's where we differ. I think it is a big deal, has put free software decades behind where it might otherwise be, and has kept affordable alternatives to monopoly-ware out of the picture almost completely. > Sparing a user from becoming dependent on a piece of proprietary > software might even be a sacrifice for the user, but it's actually an > advantage for the user and for society in the long run. You can't be 'dependent' on software as long as there are alternate choices. The thing that is bad for society is unnecessary restrictions on how those choices can be produced and combined. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Jun 19 18:41:30 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 13:41:30 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A9C75.3090204@blagblagblag.org> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> Message-ID: <485AA85A.7010006@gmail.com> jeff wrote: > >>> >>> I personally downloaded this file believing that I was getting a free >>> GPL driver. Broadcom says so in the patch itself, in the included >>> LICENSE file, and their website when you click to download it. Red >>> Hat is shipping it as GPLv2. So either they have to provide the >>> source (if they have it), stop shipping it, or *at least* stop saying >>> they are shipping a GPLv2 kernel if they are unwilling/unable to >>> provide the source. >> >> You missed the discussion where it was pointed out that some firmware >> is written in hex directly, as there is no compiler. Good luck with >> demanding the source to that dude... > > > > > ----> "Derived from proprietary unpublished source code" <---- > > > > linux-2.6.25/drivers/net/tg3.c: > > /* > * tg3.c: Broadcom Tigon3 ethernet driver. > * > * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) > * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) > * Copyright (C) 2004 Sun Microsystems Inc. > * Copyright (C) 2005-2007 Broadcom Corporation. > * > * Firmware is: > * Derived from proprietary unpublished source code, > * Copyright (C) 2000-2003 Broadcom Corporation. > * > * Permission is hereby granted for the distribution of this firmware > * data in hexadecimal or equivalent format, provided this copyright > * notice is accompanying it. > */ > > > > tg3.c is the example I have been using all along. And note the difference between this and the earlier one you previously posted that (probably mistakenly) said it was GPL'd. > Of course actually getting Red Hat or Broadcom to turn it over wouldn't > be easy. That's probably not one of the choices. Demanding that distribution be stopped of everything containing the one claiming to be GPL might be, if that's what you want, but only the copyright holder could enforce that demand. -- Les Mikesell lesmikesell at gmail.com From moe at blagblagblag.org Thu Jun 19 18:54:21 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 19 Jun 2008 15:54:21 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485AA85A.7010006@gmail.com> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <485AA85A.7010006@gmail.com> Message-ID: <485AAB5D.90804@blagblagblag.org> Les Mikesell wrote: > jeff wrote: >> >>>> >>>> I personally downloaded this file believing that I was getting a >>>> free GPL driver. Broadcom says so in the patch itself, in the >>>> included LICENSE file, and their website when you click to download >>>> it. Red Hat is shipping it as GPLv2. So either they have to provide >>>> the source (if they have it), stop shipping it, or *at least* stop >>>> saying they are shipping a GPLv2 kernel if they are unwilling/unable >>>> to provide the source. >>> >>> You missed the discussion where it was pointed out that some firmware >>> is written in hex directly, as there is no compiler. Good luck with >>> demanding the source to that dude... >> >> >> >> >> ----> "Derived from proprietary unpublished source code" <---- >> >> >> >> linux-2.6.25/drivers/net/tg3.c: >> >> /* >> * tg3.c: Broadcom Tigon3 ethernet driver. >> * >> * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller >> (davem at redhat.com) >> * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) >> * Copyright (C) 2004 Sun Microsystems Inc. >> * Copyright (C) 2005-2007 Broadcom Corporation. >> * >> * Firmware is: >> * Derived from proprietary unpublished source code, >> * Copyright (C) 2000-2003 Broadcom Corporation. >> * >> * Permission is hereby granted for the distribution of this >> firmware >> * data in hexadecimal or equivalent format, provided this copyright >> * notice is accompanying it. >> */ >> >> >> >> tg3.c is the example I have been using all along. > > And note the difference between this and the earlier one you previously > posted that (probably mistakenly) said it was GPL'd. That's what's on there now--to point out it wasn't written in hex--there is source code *somewhere*. For years it was distributed without that line. For example: /******************************************************************************/ /* */ /* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */ /* Corporation. */ /* All rights reserved. */ /* */ /* 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, located in the file LICENSE. */ /* */ /* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED. */ /* */ /* Name: F W _ L S O 0 5. H */ /* Author : Kevin Tran */ /* Version: 1.2 */ /* */ /* Module Description: This file contains firmware binary code of TCP */ /* Segmentation firmware (BCM5705). */ /* */ /* History: */ /* 08/10/02 Kevin Tran Incarnation. */ /* 02/02/04 Kevin Tran Added Support for BCM5788. */ /******************************************************************************/ [lots of hex] If that is written at the top of a file *with no other disclaimers* (which is the case here), what license is the file under? Note, there is *no* other code in this file, just the firmware. To me it looks like they GPL'd it, no? If you say the license applies to just one section, which section is that, since there are no other sections? The file quoted above is fw_lso05.h as distributed by broadcom.com in linux-7.3.5.zip. -Jeff From sundaram at fedoraproject.org Thu Jun 19 18:57:36 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 20 Jun 2008 00:27:36 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A96ED.1010603@gmail.com> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <48594DC9.6080105@redhat.com> <485963DC.70308@gmail.com> <485A2835.4090109@redhat.com> <485A6438.6060000@gmail.com> <485A65BE.2060209@redhat.com> <485A7D14.9030204@gmail.com> <485A831F.8030803@redhat.com> <485A96ED.1010603@gmail.com> Message-ID: <485AAC20.2020803@fedoraproject.org> Les Mikesell wrote: > If it takes a current concrete example to make sense, swapping out > reiserfs with zfs in the Linux kernel seems like a good idea. But we > can't do that because the kernel is too free. I haven't seen any contributors claim that it is a good idea. Quite the opposite considering patent concerns and design differences. Assuming it is, CDDL has additional requirements incompatible with GPLv2 and it was designed that way and also because the kernel is very different between Linux and Solaris. The only way to allow absolute flexibility in terms of licensing is to put stuff in the public domain or very permissive licenses. Rahul From loganjerry at gmail.com Thu Jun 19 17:32:33 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 19 Jun 2008 11:32:33 -0600 Subject: Debugging audio problems Message-ID: <870180fe0806191032p1479fec5q590b6883e26d734@mail.gmail.com> Is there a guide somewhere to debugging audio problems? My son is mad at me, because I upgraded my home machine from F8 to F9, and now the sound is messed up on his favorite browser-based game (http://www.runescape.com/). F8 plays the background music and sound effects together. On F9, whenever a sound effect occurs, the background music stops, and the sound effects sometimes happen several seconds after they should have. It's like the two audio streams are fighting each other for control of the sound card, where they used to play together. I don't even know where to begin figuring out what is going wrong. Any advice is much appreciated. Thanks, -- Jerry James http://loganjerry.googlepages.com/ From lesmikesell at gmail.com Thu Jun 19 19:30:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 14:30:36 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485AAB5D.90804@blagblagblag.org> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <485AA85A.7010006@gmail.com> <485AAB5D.90804@blagblagblag.org> Message-ID: <485AB3DC.4020702@gmail.com> jeff wrote: > >>> tg3.c is the example I have been using all along. >> >> And note the difference between this and the earlier one you >> previously posted that (probably mistakenly) said it was GPL'd. > > That's what's on there now--to point out it wasn't written in hex--there > is source code *somewhere*. For years it was distributed without that line. Yes, the most likely explanation being that the GPL label was accidentally applied and the correct/current license lets you redistribute the binary/hex only. -- Les Mikesell lesmikesell at gmail.com From michael.wiktowy at gmail.com Thu Jun 19 17:51:50 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Thu, 19 Jun 2008 13:51:50 -0400 Subject: RPM compression format Message-ID: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> Hi, I just read http://www.linuxformat.co.uk/static/suse11.html where is mentions that OpenSuSe 11 went with a different compression algorithm for their rpms (LZMA instead of bz2) and have a few questions: 1) While every distro seems to be coming together on a package management GUI (PackageKit), does this represent a splintering of package formats? or is rpm compression algorithm agnostic? Is there any hope that the various rpm development will start pulling in the same direction? 2) LZMA appears to have some good characteristics for installation rpms (tighter compression, 50% decompression time ... at least as implemented by 7zip ref: http://www.maximumcompression.com/data/summary_mf4.php ). Is Fedora planing to follow this switch (or has it already and not advertised it as a prominent feature) or are there other considerations preventing that (patent issues?, not suitable for delta rpms?, 200% compression time)? /Mike From mjs at clemson.edu Thu Jun 19 19:32:24 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 19 Jun 2008 15:32:24 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> Message-ID: <1213903944.12452.23.camel@valkyrie.localdomain> On Thu, 2008-06-19 at 12:59 -0300, Alexandre Oliva wrote: > On Jun 18, 2008, Matthew Saltzman wrote: > > > Then can we at least agree that there are sometimes unfortunate > > consequences to the GPL's failure to permit one to share a work > > combining two pieces of *free* software because of relatively minor[1] > > license incompatibilities? > > Yeah, it's unfortunate when this happens. In general, authors who use > the GPL for its intended purpose (ensuring the 4 freedoms are > respected for all users) won't object to the combination of their > works with other works that respect users' freedoms, and will grant > additional permissions for the combinations in spite of the license > conflicts. > > Of course, not everyone does that, and some people who would like to > create such combinations may even not realize that this possibility > exists, or think it's not worth the effort. Would not the world then be a better place if the GPL permitted such combinations to start with? That would simplify this process enormously and help spread free software. > > So, yeah, it's unfortunate, but I don't think it's really such a big > deal. Nearly all Free Software *is* available under the GPL and > compatible licenses anyway. Maybe all the free software *you* use... PHP, for example, is not under GPL. When MySQL changed its free distribution from LGPL to GPL, that almost put an end to the php-mysql library. The end result was MySQL's free software exception clause, which they added to the GPL to create their license. I work on a free software project (very widely known in my field) that is primarily CPL. GPL compatibility is a problem for us. We also need to interface to proprietary libraries. I have little hope that I can get permission from all the contributors' employers to dual license. Plenty of companies that would be willing to release free software are leery of releasing it as GPL and of using GPL software. Whether their concerns are well founded or not, the compatibility issues are still there. > > > In fact, I think it's arguable that there are sometimes unfortunate > > consequences to the GPL's failure to permit one to share a work that > > makes use of a GPL library and a proprietary library. > > Sparing a user from becoming dependent on a piece of proprietary > software might even be a sacrifice for the user, but it's actually an > advantage for the user and for society in the long run. In the long run, we are all dead.[1] Meanwhile, we have to trade off the benefits of purity against the possibility of actually getting useful work done. If I can do so by combining works already created (even if proprietary) with new works I create, then I may have to be prepared to live with the necessary sacrifice of my principles, even while advancing those principles as best I can in other contexts. And it's a shame if I can't make the added benefits of the work I created available for others to use if they are prepared to acquire the other components or do the work to replace them. > > Anyhow, it is true that conquering freedom is not without its > sacrifices. Like, one could argue that an army is a useless expense > and sacrifice in times of peace, but if you don't work on your > defenses proactively (and GPL is a license that not only respects the > 4 freedoms, but also stands up to defend them), you become a sweeter > target, more likely to be defeated and terminated. > [1] John Maynard Keynes -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sundaram at fedoraproject.org Thu Jun 19 19:50:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 20 Jun 2008 01:20:34 +0530 Subject: RPM compression format In-Reply-To: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> Message-ID: <485AB88A.6020102@fedoraproject.org> Michael Wiktowy wrote: > Hi, > > I just read http://www.linuxformat.co.uk/static/suse11.html where is > mentions that OpenSuSe 11 went with a different compression algorithm > for their rpms (LZMA instead of bz2) and have a few questions: > > 1) While every distro seems to be coming together on a package > management GUI (PackageKit), does this represent a splintering of > package formats? or is rpm compression algorithm agnostic? Is there > any hope that the various rpm development will start pulling in the > same direction? Distribution have been shipping patches for a long while and that quantity against rpm seems to be dropping off now looking at SUSE, Mandriva etc. Compression algorithm doesn't affect the spec file format. > 2) LZMA appears to have some good characteristics for installation > rpms (tighter compression, 50% decompression time ... at least as > implemented by 7zip ref: > http://www.maximumcompression.com/data/summary_mf4.php ). Is Fedora > planing to follow this switch (or has it already and not advertised it > as a prominent feature) or are there other considerations preventing > that (patent issues?, not suitable for delta rpms?, 200% compression > time)? Refer to this RFE I filed a while back at https://bugzilla.redhat.com/show_bug.cgi?id=441110 Rahul From aoliva at redhat.com Thu Jun 19 19:59:36 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 16:59:36 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <4859954D.2080701@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 18\:07\:57 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <1213570613.26255.576.camel@pmac.infradead.org> <4855B32E.8090803@gmail.com> <1213601497.26255.619.camel@pmac.infradead.org> <4856680A.7070509@gmail.com> <48596BB0.1080909@gmail.com> <4859954D.2080701@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > You can build a box to contain some odd-shaped thing, but you can't > support a general claim that the box is derived from the contents. I didn't make this claim, ever. If you misunderstood it as such, that explains why you go in tangents every time we approach the relevant point. What I'm saying is more like that the box and the odd-shaped thing are offered as a single package. You don't get to go to a shop and purchase only the object that's inside the box, or just the box. They won't give you a discount just because you don't want them both. It's a single package, even if it's possible to separate them and throw away the part you're not interested in with some effort. Of course, if you have to rip the box open to take the object out, and what you wanted was the box, without the rip, then you won't end up with that, even if the box and the object are distinguishable objects. > What specifically distinguishes if as a single work' as opposed to a > container of some unrelated bits? Mainly the fact that they were put together to work together in a way that involved a creative process rather than some mechanical process. >> I didn't mean that, but I agree it's correct. But this has ZERO to do >> with whether the movie in the DVD is a single work. Surely the song >> whose snippets play during the movie are not mere aggregation, they're >> an integral part of the creative work. > I think you are overgeneralizing. The songs in "South Pacific" were > creatively part of the work, but "Saturday Night Fever" just played > songs that were already hits and happened to fit in the scenes. So what? Saturday Night Fever remains a separate, independent work, but that doesn't prevent a copy of it from being an integral part of a copy of another copyrightable work. But then again, whether it amounts to mere aggregation (say, a copy of a radio station transmission while they played a random selection of songs for some period of time) or a creative process (say, recording on a K7 tape a radio show that selected songs about a certain theme to evoke certain emotions). Movies are seldom the former case. But even when they are, the copyright holders of the movie still require permission from the copyright holders of the songs to be able to distribute it. >>> Yes, the representation does not affect the underlying creative works. >> I think this is enough to show that you're seriously missing >> information as to how copyright works, and it's become clear that you >> have no interest in obtaining such knowledge. > I'm very interested in anything you have to support your theory that > combining two sections in the same file makes a difference > copyright-wise compared to two separate files. How does this have anything to do with the above? You said the above in response to the ironical proposition that "a movie is a mere aggregation of separate pictures". Agreeing with this sets aside the entire creative process involved in creating the expression of the idea conveyed through not the messages individually, but by their exposition in a certain order at a certain pace with a certain accompanying audio (or not). This process is precisely what makes the whole a copyrightable work. Thus, you don't understand what copyright is about, even if "representation does not affect the underlying creative works" is true. And, to some extent, it is, but not in a way that supports the claim I proposed as reductio ad absurdum. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Thu Jun 19 20:07:26 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 17:07:26 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485997EA.1040402@gmail.com> (Les Mikesell's message of "Wed\, 18 Jun 2008 18\:19\:06 -0500") References: <1213529734.26255.458.camel@pmac.infradead.org> <48554FDA.6040006@gmail.com> <1213553260.26255.510.camel@pmac.infradead.org> <48559401.80503@gmail.com> <4855A1FB.7080205@blagblagblag.org> <4855B617.8020509@gmail.com> <4855BB75.50603@blagblagblag.org> <4855EF91.10009@gmail.com> <20080616225955.GC10754@angus.ind.WPI.EDU> <4856F894.8030802@gmail.com> <1213705277.26255.1025.camel@pmac.infradead.org> <4857B268.9070800@gmail.com> <1213708935.26255.1058.camel@pmac.infradead.org> <4857CF90.2090602@gmail.com> <48595587.2010606@gmail.com> <4859848A.3030808@gmail.com> <485997EA.1040402@gmail.com> Message-ID: On Jun 18, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >>> The question is, does taking some code and an opaque binary blob and >>> sticking them in the same file make a 'work as a whole' or is it >>> identifiable sections of code and separate data that are not derived >>> from the Program? >> This only matters if you distribute them as separate works. When you >> distribute them as a whole, you don't get the exception. > Separate sections. Yep. this License, and its terms, do not apply to those sections *when* you distribute them as *separate* works. But *when* you distribute the same sections as *part* of a *whole* which is a work based on the Program, the distribution of the *whole* *must* be on the terms of this License (emphasis mine) You can't just disregard the parts you don't like. >> Read again, very carefully, the sentence you quoted. Especially the >> "when you distribute them as separate works" part. > Note that it doesn't say anything about files there. Exactly. It talks about distributing them as separate works (not as separate sections, as you seem to read it), or as a whole work. Say, is the microcode_ctl package a copyrightable work? How about linux-2.6.25.tar.bz2? How about bzImage? >>> Would the code continue to work if you replace those bits with >>> something else that would work in the hardware it loads? >> Whether it works or not is not relevant to tell whether it's derived. > How else could you tell if the parts are related or not, unless you > were part of the creative process. It's trivial to tell there was a creative process in that expression, and that's enough to establish copyrightability. >>> But why not stick to the CPU microcode example? >> Because you got the facts wrong. It's not distributed even close to >> the kernel. > Does 'close' have something to do with whether it is a separate > section or not? Isn't it in the same vmlinuz imaage somewhere? No. You got your facts completely wrong. The CPU microcode you're talking about is in the package microcode_ctl. It's a separate rpm. Totally unrelated with the kernel rpm. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Thu Jun 19 20:13:05 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 17:13:05 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485AA6EA.4020309@gmail.com> (Les Mikesell's message of "Thu\, 19 Jun 2008 13\:35\:22 -0500") References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <485AA6EA.4020309@gmail.com> Message-ID: On Jun 19, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> Yeah, it's unfortunate when this happens. In general, authors who use >> the GPL for its intended purpose (ensuring the 4 freedoms are >> respected for all users) won't object to the combination of their >> works with other works that respect users' freedoms, and will grant >> additional permissions for the combinations in spite of the license >> conflicts. > I don't believe that is generally true except for perl and the few > other dual-licensed packages where the authors understood the issue > from the start. Your beliefs don't match facts. Look for GPLed packages with an additional exception to combine with say openssl, just as an example. > And worse, there is no accounting for copyright ownership since > anyone could have added code and most packages have no one who could > grant such permission Yeah, legal maintainability is important and it's sad that so many people prefer to disregard this aspect. Any ideas of how to improve this mindset? >> So, yeah, it's unfortunate, but I don't think it's really such a big >> deal. Nearly all Free Software *is* available under the GPL and >> compatible licenses anyway. > And there's where we differ. I think it is a big deal, has put free > software decades behind where it might otherwise be, and has kept > affordable alternatives to monopoly-ware out of the picture almost > completely. At the expense of its no longer being Free Software? What would the point be, again? >> Sparing a user from becoming dependent on a piece of proprietary >> software might even be a sacrifice for the user, but it's actually an >> advantage for the user and for society in the long run. > You can't be 'dependent' on software as long as there are alternate > choices. 'course not, sir :-), who'd have thunk :-) that OOXML doesn't describe the file formats actually used by MS-Office 2007 and that Microsoft holds patents that could prevent alternate choices from implementing compatibility with MS-Office 2007 (rather than with OOXML), eh? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From vonbrand at inf.utfsm.cl Thu Jun 19 20:29:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 19 Jun 2008 16:29:39 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <485A9C75.3090204@blagblagblag.org> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> Message-ID: <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> jeff wrote: > Anders Karlsson wrote: > > * jeff [20080618 17:50]: > > [snip] > >> ... more pages of hex > >> I personally downloaded this file believing that I was getting a > >> free GPL driver. Broadcom says so in the patch itself, in the > >> included LICENSE file, and their website when you click to download > >> it. Red Hat is shipping it as GPLv2. So either they have to provide > >> the source (if they have it), stop shipping it, or *at least* stop > >> saying they are shipping a GPLv2 kernel if they are > >> unwilling/unable to provide the source. > > You missed the discussion where it was pointed out that some firmware > > is written in hex directly, as there is no compiler. Good luck with > > demanding the source to that dude... > ----> "Derived from proprietary unpublished source code" <---- > > > > linux-2.6.25/drivers/net/tg3.c: > > /* > * tg3.c: Broadcom Tigon3 ethernet driver. > * > * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) > * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) > * Copyright (C) 2004 Sun Microsystems Inc. > * Copyright (C) 2005-2007 Broadcom Corporation. > * > * Firmware is: > * Derived from proprietary unpublished source code, > * Copyright (C) 2000-2003 Broadcom Corporation. > * > * Permission is hereby granted for the distribution of this firmware > * data in hexadecimal or equivalent format, provided this copyright > * notice is accompanying it. > */ > > > > tg3.c is the example I have been using all along. The above note clearly indicates the firmware is to be considered a separate piece, that just so happens is written as data inside this C file. > Of course actually getting Red Hat or Broadcom to turn it over > wouldn't be easy. Broadcom has some legal issues of their own right > now, heh. None at all. Broadcom is explicitly allowing distribution of the firmware in hex. In any case, it is their stuff, they can do as they please with it. Red Hat never had the source. If you sue them for it, they will tell you they have Broadcom's permission to distribute it (only) as stated above. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From moe at blagblagblag.org Thu Jun 19 20:58:49 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 19 Jun 2008 17:58:49 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> References: <48580C65.5040208@gmail.com> <485816FD.7000808@blagblagblag.org> <48582BDC.7090701@gmail.com> <48583267.9010009@blagblagblag.org> <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> Message-ID: <485AC889.5040409@blagblagblag.org> Horst H. von Brand wrote: > jeff wrote: >> Anders Karlsson wrote: >>> * jeff [20080618 17:50]: >>> [snip] >>>> ... more pages of hex > >>>> I personally downloaded this file believing that I was getting a >>>> free GPL driver. Broadcom says so in the patch itself, in the >>>> included LICENSE file, and their website when you click to download >>>> it. Red Hat is shipping it as GPLv2. So either they have to provide >>>> the source (if they have it), stop shipping it, or *at least* stop >>>> saying they are shipping a GPLv2 kernel if they are >>>> unwilling/unable to provide the source. >>> You missed the discussion where it was pointed out that some firmware >>> is written in hex directly, as there is no compiler. Good luck with >>> demanding the source to that dude... > >> ----> "Derived from proprietary unpublished source code" <---- >> >> >> >> linux-2.6.25/drivers/net/tg3.c: >> >> /* >> * tg3.c: Broadcom Tigon3 ethernet driver. >> * >> * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem at redhat.com) >> * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik at pobox.com) >> * Copyright (C) 2004 Sun Microsystems Inc. >> * Copyright (C) 2005-2007 Broadcom Corporation. >> * >> * Firmware is: >> * Derived from proprietary unpublished source code, >> * Copyright (C) 2000-2003 Broadcom Corporation. >> * >> * Permission is hereby granted for the distribution of this firmware >> * data in hexadecimal or equivalent format, provided this copyright >> * notice is accompanying it. >> */ >> >> >> >> tg3.c is the example I have been using all along. > > The above note clearly indicates the firmware is to be considered a > separate piece, that just so happens is written as data inside this C file. A separate piece which was itself distributed under the GPL (or at least firmware of the same family--broadcom ethernet): /******************************************************************************/ /* */ /* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */ /* Corporation. */ /* All rights reserved. */ /* */ /* 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, located in the file LICENSE. */ /* */ /* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED. */ /* */ /* Name: F W _ L S O 0 5. H */ /* Author : Kevin Tran */ /* Version: 1.2 */ /* */ /* Module Description: This file contains firmware binary code of TCP */ /* Segmentation firmware (BCM5705). */ /* */ /* History: */ /* 08/10/02 Kevin Tran Incarnation. */ /* 02/02/04 Kevin Tran Added Support for BCM5788. */ /******************************************************************************/ [tons of hex] This *only* includes the firmware in hex. So what license is this under? GPL,no? Linus (or the copyright holder) can't just say "oh cpu.c isn't GPL, it's actually $foolicense" and change the old copies of the file that were distributed for a decade or whatever. I don't see why broadcom / Red Hat can. >> Of course actually getting Red Hat or Broadcom to turn it over >> wouldn't be easy. Broadcom has some legal issues of their own right >> now, heh. > > None at all. (I was referring to their old CEO being charges with umpteen criminal acts related to stocks and putting extasy (drugs) in customers/suppliers drinks....) > Broadcom is explicitly allowing distribution of the firmware > in hex. In any case, it is their stuff, they can do as they please with it. Broadcom was explicitly allowing distribution of the firmware under the GPL too--but for someone to actually comply with that, they would have to provide the source code. > Red Hat never had the source. If you sue them for it, they will tell you > they have Broadcom's permission to distribute it (only) as stated above. Well, Red Hat added it to the Linux kernel before the "Derived from Proprietary Sources" line was added. How do you know Red Hat doesn't have or never had the source to it? I don't think they have it, but I've never seen them say they didn't. -Jeff P.S. No reason to CC me as I'm on the list. From vonbrand at inf.utfsm.cl Thu Jun 19 21:04:33 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 19 Jun 2008 17:04:33 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213903944.12452.23.camel@valkyrie.localdomain> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> Message-ID: <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> Matthew Saltzman wrote: > On Thu, 2008-06-19 at 12:59 -0300, Alexandre Oliva wrote: > > On Jun 18, 2008, Matthew Saltzman wrote: > > > > > Then can we at least agree that there are sometimes unfortunate > > > consequences to the GPL's failure to permit one to share a work > > > combining two pieces of *free* software because of relatively minor[1] > > > license incompatibilities? > > Yeah, it's unfortunate when this happens. In general, authors who use > > the GPL for its intended purpose (ensuring the 4 freedoms are > > respected for all users) won't object to the combination of their > > works with other works that respect users' freedoms, and will grant > > additional permissions for the combinations in spite of the license > > conflicts. > > Of course, not everyone does that, and some people who would like to > > create such combinations may even not realize that this possibility > > exists, or think it's not worth the effort. > Would not the world then be a better place if the GPL permitted such > combinations to start with? That would simplify this process enormously > and help spread free software. ... into all sorts of non-free combinations. The GPL is as it is for a purpose, else the BSD/MIT license (or just public domain) would be enough. > > So, yeah, it's unfortunate, but I don't think it's really such a big > > deal. Nearly all Free Software *is* available under the GPL and > > compatible licenses anyway. > Maybe all the free software *you* use... Most of what is out there, by all surveys I've seen. > PHP, for example, is not under GPL. When MySQL changed its free > distribution from LGPL to GPL, that almost put an end to the php-mysql > library. The end result was MySQL's free software exception clause, > which they added to the GPL to create their license. Fixed. See? > I work on a free software project (very widely known in my field) that > is primarily CPL. GPL compatibility is a problem for us. We also need > to interface to proprietary libraries. I have little hope that I can > get permission from all the contributors' employers to dual license. No simple answers there. In any case, GPL /allows/ you to do certain things, and you are getting this software because people feel confortable distributing under GPL. At least it is interoperable in itself. > Plenty of companies that would be willing to release free software are > leery of releasing it as GPL Why? > and of using GPL software. Now that is completely unwarranted. > Whether their > concerns are well founded or not, the compatibility issues are still > there. But they are way less than trying to combine stuff under the typical assortment of privative licenses in any case... have you looked in detail at that kind of mess? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From anders at trudheim.co.uk Thu Jun 19 21:48:16 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Thu, 19 Jun 2008 23:48:16 +0200 Subject: Fedora Freedom and linux-libre In-Reply-To: <485AC889.5040409@blagblagblag.org> References: <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> <485AC889.5040409@blagblagblag.org> Message-ID: <20080619214816.GI9581@localhost.localdomain> * jeff [20080619 23:00]: [snip] > Well, Red Hat added it to the Linux kernel before the "Derived from > Proprietary Sources" line was added. How do you know Red Hat doesn't have > or never had the source to it? I don't think they have it, but I've never > seen them say they didn't. Can you provide the commit ID showing that it was Red Hat that committed it to the upstream Linux kernel source tree? I'm actually curious to have a look at that commit. /Anders From bnocera at redhat.com Thu Jun 19 22:31:18 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 19 Jun 2008 23:31:18 +0100 Subject: Debugging audio problems In-Reply-To: <870180fe0806191032p1479fec5q590b6883e26d734@mail.gmail.com> References: <870180fe0806191032p1479fec5q590b6883e26d734@mail.gmail.com> Message-ID: <1213914678.2746.79.camel@cookie.hadess.net> On Thu, 2008-06-19 at 11:32 -0600, Jerry James wrote: > Is there a guide somewhere to debugging audio problems? My son is mad > at me, because I upgraded my home machine from F8 to F9, and now the > sound is messed up on his favorite browser-based game > (http://www.runescape.com/). F8 plays the background music and sound > effects together. On F9, whenever a sound effect occurs, the > background music stops, and the sound effects sometimes happen several > seconds after they should have. It's like the two audio streams are > fighting each other for control of the sound card, where they used to > play together. I don't even know where to begin figuring out what is > going wrong. Any advice is much appreciated. Thanks, Is libflashsupport installed? Is pulseaudio running and working? From mjs at clemson.edu Thu Jun 19 22:42:06 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 19 Jun 2008 18:42:06 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> References: <484D6276.4000308@gmail.com> <48534679.7040008@gmail.com> <48541550.7040000@gmail.com> <48547544.8060204@gmail.com> <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> Message-ID: <1213915327.17201.22.camel@valkyrie.localdomain> On Thu, 2008-06-19 at 17:04 -0400, Horst H. von Brand wrote: > Matthew Saltzman wrote: > > On Thu, 2008-06-19 at 12:59 -0300, Alexandre Oliva wrote: > > > On Jun 18, 2008, Matthew Saltzman wrote: > > > > > > > Then can we at least agree that there are sometimes unfortunate > > > > consequences to the GPL's failure to permit one to share a work > > > > combining two pieces of *free* software because of relatively minor[1] > > > > license incompatibilities? > > > > Yeah, it's unfortunate when this happens. In general, authors who use > > > the GPL for its intended purpose (ensuring the 4 freedoms are > > > respected for all users) won't object to the combination of their > > > works with other works that respect users' freedoms, and will grant > > > additional permissions for the combinations in spite of the license > > > conflicts. > > > > Of course, not everyone does that, and some people who would like to > > > create such combinations may even not realize that this possibility > > > exists, or think it's not worth the effort. > > > Would not the world then be a better place if the GPL permitted such > > combinations to start with? That would simplify this process enormously > > and help spread free software. > > ... into all sorts of non-free combinations. The GPL is as it is for a > purpose, else the BSD/MIT license (or just public domain) would be enough. No, I'm only referring to compatibility of free/open-source software licenses here. Interestingly, the Modified BSD license and the X11 (MIT) license are GPL compatible. > > > > So, yeah, it's unfortunate, but I don't think it's really such a big > > > deal. Nearly all Free Software *is* available under the GPL and > > > compatible licenses anyway. > > > Maybe all the free software *you* use... > > Most of what is out there, by all surveys I've seen. Surveys are only as reliable as their sample selection processes. And in any case, it's no consolation to know that "most" free software is GPL if the program you need is not. > > > PHP, for example, is not under GPL. When MySQL changed its free > > distribution from LGPL to GPL, that almost put an end to the php-mysql > > library. The end result was MySQL's free software exception clause, > > which they added to the GPL to create their license. > > Fixed. See? Do you remember the sturm und drang involved in accomplishing that? It is in no sense easy to accomplish these kinds of changes after the fact. And MySQL is at least a single entity. If you were to try doing this with almost any distributed development project with more than a handful of developers, you'd almost certainly fail and quite possibly sacrifice your sanity in the process. > > > I work on a free software project (very widely known in my field) that > > is primarily CPL. GPL compatibility is a problem for us. We also need > > to interface to proprietary libraries. I have little hope that I can > > get permission from all the contributors' employers to dual license. > > No simple answers there. In any case, GPL /allows/ you to do certain > things, and you are getting this software because people feel confortable > distributing under GPL. Or because they don't think too hard about it. > At least it is interoperable in itself. Ooh, the possibilities boggle the mind! > > > Plenty of companies that would be willing to release free software are > > leery of releasing it as GPL > > Why? You'd have to ask their lawyers. But it's a fact. > > > and of using GPL software. > > Now that is completely unwarranted. You'd have to tell their lawyers. But it's a fact. > > > Whether their > > concerns are well founded or not, the compatibility issues are still > > there. > > But they are way less than trying to combine stuff under the typical > assortment of privative licenses in any case... have you looked in detail > at that kind of mess? No doubt. But "better than a steaming pile" is not in itself a very compelling recommendation. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From michel.sylvan at gmail.com Thu Jun 19 22:57:30 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 19 Jun 2008 18:57:30 -0400 Subject: PackageKit UI In-Reply-To: <20080619120035.GH2933@nb.net.home> References: <1213268950.3505.1.camel@hughsie-work> <20080619093707.GA18683@camelia.ucw.cz> <20080619120035.GH2933@nb.net.home> Message-ID: <485AE45A.1050401@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karel Zak wrote: > On Thu, Jun 19, 2008 at 11:37:07AM +0200, Stepan Kasal wrote: >> Sorry again if this is not compatible with you >> GUI vision--I have a tendency to eliminate as much G from my UI as >> possible. > > http://linuxhaters.blogspot.com/2008/06/how-to-write-gnome-application.html > > :-))) > That was quite hilarious. Sadly, like any good parody, it is partly based on reality. Thankfully, Vala is coming to the rescue on the OO and Mono front. - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkha5FoACgkQWt0J3fd+7ZBqNgCfbnwKrEfD+GAneDEGVFEj0DDm xJ4AnihDDiSAK+BKrciGN6YpEqbP2Tjj =DBmK -----END PGP SIGNATURE----- From hedayat at grad.com Thu Jun 19 23:46:30 2008 From: hedayat at grad.com (Hedayat Vatnakhah) Date: Fri, 20 Jun 2008 04:16:30 +0430 Subject: rpmlint warnings Message-ID: <485AEFD6.7030701@grad.com> Hi all, I've a question about an rpmlint warning message: when I run rpmlint against my package (http://www.assembla.com/spaces/hedayat/documents/ctTQqMpLur3BrOab7jnrAJ/download/rcssserver3d-devel-0.6-0.1.20080620cvs.fc9.i386.rpm) (Or you may try this link: http://www.assembla.com/file/hedayat/1_rcssserver3d-devel-0.6-0.1.20080620cvs.fc9.i386.rpm) It'll print a set of dangling-relative-symlink errors like this: rcssserver3d-devel.i386: W: dangling-relative-symlink /usr/lib/rcssserver3d/librcssnet3D.so librcssnet3D.so.0.0.0 I don't know what are these warnings for, since the symlinks are correct (their target file is available in the main package). It's a -devel package and so it contains only the .so symlinks. I'd like to know what are these warnings for; and how can I prevent them. Thanks a lot, Hedayat From s-t-rhbugzilla at wwwdotorg.org Fri Jun 20 00:07:17 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Thu, 19 Jun 2008 18:07:17 -0600 (MDT) Subject: rpmlint warnings In-Reply-To: <485AEFD6.7030701@grad.com> References: <485AEFD6.7030701@grad.com> Message-ID: <1213920437.28011.TMDA@tmda.severn.wwwdotorg.org> On Thu, June 19, 2008 5:46 pm, Hedayat Vatnakhah wrote: > Hi all, > > I've a question about an rpmlint warning message: when I run rpmlint > against my package > ... > It'll print a set of dangling-relative-symlink errors like this: > > rcssserver3d-devel.i386: W: dangling-relative-symlink > /usr/lib/rcssserver3d/librcssnet3D.so librcssnet3D.so.0.0.0 Does the -devel package require the main package, and by exact version number? From aoliva at redhat.com Fri Jun 20 00:17:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 19 Jun 2008 21:17:35 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485AA5A7.7010900@gmail.com> (Les Mikesell's message of "Thu\, 19 Jun 2008 13\:29\:59 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.c! om> <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> <485AA5A7.7010900@gmail.com> Message-ID: On Jun 19, 2008, Les Mikesell wrote: > How would you relate what you are saying to the recent ruling in the > UK that selling modified ROMS to someone who already has the > original does not violate copyright law? > http://www.techdirt.com/articles/20080612/0055131385.shtml The question was not for me, but I'll chime in anyway. Seems like the above is an interesting case about fair use, about limiting the power of copyright holders over their works, for the sake of the public interest. Excellent! Now, would you have any reason to expect such a ruling to not have been upheld should the software in the chips have been licensed under the GPL without source code, a la Broadcom? Do you think it would it make any difference if the software in the chips had been distributed under the GPL with source code? > No, I need the owner's permission to have my copy in the first place. This claim is in conflict with the legislations of various jurisdictions I'm relatively familiar with. Where in the world do you claim this to be true? > I don't need his permission to use it As in, reading the book or listening to the song or watching the movie or running the program, yes, correct. > or add my own changes to it. No, in order to modify a work you need permission from the copyright holder and, in some jurisdictions, also from the author (in case the author is allowed by law to assign the copyright to other parties while retaining moral rights, one of which is to object to modifications; this may sound alien to US-centered folks, but it's in the Berne convention and implemented in various legislations around the world) >> If said owner grants that permission only under the condition that >> your modifications have to be distributed under GPL... > Once I have my copy, said owner has no more to say about what I can do > with it. Copyright prevents subsequent redistribution without > permission but it is not anyone else's business if I redistribute the > work that I've added to my copy to someone else who also has a copy of > the original work. You should definitely discuss this matter with a lawyer to get this straightened out. You seem to have misunderstood what the "use the work however you want" phrase you probably heard or read about somewhere amounted to. It's not use as in "create derived works based on", it's use as in "enjoy". That's not regulated by copyright (at least it wasn't before 1996 or so, when provisions that ended up implemented and exaggerated in the DMCA and various other anti-social legislations around the world, were mandated by the WTO, rather than adopted voluntarily by signatory countries at the WIPO. > There are no conditions to receiving a copy a copy under the GPL. That's correct (save for the dupe :-), and that's how copyright works. Just imagine how you'd possibly be able to refrain from breaking the law if someone could just put an illegal copy in your hands while you were asleep, or at your table while you were distracted reading the newspaper at a coffee shop, or some such. It's that who gives you the copy that breaks the law, in case distributing the copy is not permitted by law. The GPL merely restates what most copyright legislations take for granted. This makes leaves room in case some diverge, like GPLv3 does to cover Brazilian software law, that requires a license to be even entitled to run a program. >> Using a library is one thing, taking its code and modifying it >> something quite different; and distributing a copy of the original >> or a modified version are yet again completely different. For each >> of those activities you need separate permissions. > Sometimes. Some of those things are basic rights, recognized > differently in different places. That's correct, fair use exists as court law in some jurisdictions, uses that don't infringe on copyright are explicitly mentioned in copyright laws in others, and these are things you can do regardless of whatever the GPL or any other pure license (i.e., pure grant of permissions, rather than contract) might say. For example, per fair use, you can take a small portion of a pre-existing work and use it in another work that you can then distribute under your own terms. How much a small portion is varies. For example, in Brazil, it was perfectly legal for me to create this: http://www.lsd.ic.unicamp.br/~oliva/fsfla/whatisthematrix/ In the US, it might not have been, because laws have upheld far shorter limits on reuse of portions of movies. But then, it's a reinterpretation, which might again make it fair use as a parody. It sure is a grey area. Unlike Brazilian law, in which copyright law explicitly mentions some uses you can count on regardless of licenses, fair use in US is a strict matter of jurisprudence, so it remains a grey area until there's a court ruling on the matter. It used to be the case that one could copy an entire work for personal use in Brazil, up to 1998. It no longer is, now you can only copy small portions, and only for the personal use of the person performing the copy. So universities that want to promote culture rather than sell out to the powerful copyright holders permit students to operate photo-copying machines at libraries, as long as they only copy no more than one or two chapters at a time. But this doesn't mean students are entitled to take their copied chapters, replace some passages, write a preface, bind it all and give (or lend, or sell) it to their friends. If you think you can do these things, and count on their being fair use rights all over the place, you're up for unfortunate surprises. I hope not, and I wish it wasn't so, but unfortunately corporate greed has accummulated so much power that they can buy up legislation in detriment of everyone else, while they can claim to not be above the law. And some people still believe their mind-washing BS about copyrights, patents and trademarks holding any similarity, existing to protect their investment rather than the public interest, and their violation bearing any resemblance to stealing. While they're stealing our rights from right under our noses, while we nod along because they call it "property" and we believe in respecting property (without quotes). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From seg at haxxed.com Fri Jun 20 00:31:32 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 19 Jun 2008 19:31:32 -0500 Subject: What changelog to preserve at untrivial merging? In-Reply-To: <485A7F86.2090502@odu.neva.ru> References: <485A7F86.2090502@odu.neva.ru> Message-ID: <1218b5bc0806191731t4c7fb720l39e5569df3af7b83@mail.gmail.com> On Thu, Jun 19, 2008 at 10:47 AM, Dmitry Butskoy wrote: > Both packages have their own history. What changelog preserve in the new > mailx in rawhide -- the old entries from mailx-8.x, the new entries from > nail-12.3, or something else? I would consider it a package rename, nail -> mailx, thus the nail changelog should be preserved. Would it have been more appropriate to just have nail obsolete mailx? What is the actual upstream name? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Fri Jun 20 00:45:30 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 19 Jun 2008 17:45:30 -0700 Subject: Submission: httpd-mod_proxy_html.spec Message-ID: <485AFDAA.1060808@redfish-solutions.com> Can I please get a code review of this? I'm trying to debug it (an x64 FC7 install current w/ httpd-2.2.8) against a build/install I just did. I used FC7 and the current version (3.0.0). Joe suggested I contact the list. Having some issues testing it, however. But that just might be brain-damage on behalf of the embedded device I'm trying to talk to (it's Boa/0.94.14rc18 apparently)... a Honeywell environmental controller. If anyone wants to volunteer some configuration advice, please email me out-of-band. Thanks, -Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd-mod_proxy_html-3.0.0-1.fc7.src.rpm Type: application/octet-stream Size: 23684 bytes Desc: not available URL: From moe at blagblagblag.org Fri Jun 20 01:50:31 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 19 Jun 2008 22:50:31 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <20080619214816.GI9581@localhost.localdomain> References: <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> <485AC889.5040409@blagblagblag.org> <20080619214816.GI9581@localhost.localdomain> Message-ID: <485B0CE7.4030904@blagblagblag.org> Anders Karlsson wrote: > * jeff [20080619 23:00]: > [snip] > >> Well, Red Hat added it to the Linux kernel before the "Derived from >> Proprietary Sources" line was added. How do you know Red Hat doesn't have >> or never had the source to it? I don't think they have it, but I've never >> seen them say they didn't. > > Can you provide the commit ID showing that it was Red Hat that > committed it to the upstream Linux kernel source tree? I'm actually > curious to have a look at that commit. Somewhere else in this thread, jeff wrote: > The "GPLing" of the driver (MODULE_LICENSE("GPL")) and the inclusion of > a chunk of non-free code occurred in commit [1] > 2d8a9d3fd19147c808aa39ddc69a743d1c90f199. > > The commit shows David S. Miller (davem at redhat.com) and Jeff Garzik > (jgarzik at mandrakesoft.com) as authors. > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git -Jeff From lesmikesell at gmail.com Fri Jun 20 03:32:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 19 Jun 2008 22:32:35 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485B0CE7.4030904@blagblagblag.org> References: <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> <485AC889.5040409@blagblagblag.org> <20080619214816.GI9581@localhost.localdomain> <485B0CE7.4030904@blagblagblag.org> Message-ID: <485B24D3.2030106@gmail.com> jeff wrote: > Anders Karlsson wrote: >> * jeff [20080619 23:00]: >> [snip] >> >>> Well, Red Hat added it to the Linux kernel before the "Derived from >>> Proprietary Sources" line was added. How do you know Red Hat doesn't >>> have or never had the source to it? I don't think they have it, but >>> I've never seen them say they didn't. >> >> Can you provide the commit ID showing that it was Red Hat that >> committed it to the upstream Linux kernel source tree? I'm actually >> curious to have a look at that commit. > > Somewhere else in this thread, jeff wrote: > > The "GPLing" of the driver (MODULE_LICENSE("GPL")) and the inclusion of > > a chunk of non-free code occurred in commit [1] > > 2d8a9d3fd19147c808aa39ddc69a743d1c90f199. > > > > The commit shows David S. Miller (davem at redhat.com) and Jeff Garzik > > (jgarzik at mandrakesoft.com) as authors. > > > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git > > -Jeff > Per the debian discussion on this topic at http://wiki.debian.org/KernelFirmwareLicensing this was fixed in this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 (i.e. the GPL indication removed). -- Les Mikesell lesmikesell at gmail.com From loganjerry at gmail.com Fri Jun 20 03:52:37 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 19 Jun 2008 21:52:37 -0600 Subject: Debugging audio problems In-Reply-To: <1213914678.2746.79.camel@cookie.hadess.net> References: <870180fe0806191032p1479fec5q590b6883e26d734@mail.gmail.com> <1213914678.2746.79.camel@cookie.hadess.net> Message-ID: <870180fe0806192052h4efe5301lb6ed09a05bc85a52@mail.gmail.com> On Thu, Jun 19, 2008 at 4:31 PM, Bastien Nocera wrote: > Is libflashsupport installed? Is pulseaudio running and working? Yes, libflashsupport is installed. However, I have not installed Adobe's rpm. I'm using swfdec-mozilla. Pulseaudio is running and working, as evidenced by the fact that I can play music with audacious both before and after he plays his game, and I see a pulseaudio process in the ps output. -- Jerry James http://loganjerry.googlepages.com/ From jnovy at redhat.com Fri Jun 20 06:47:39 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 20 Jun 2008 08:47:39 +0200 Subject: RPM compression format In-Reply-To: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> Message-ID: <20080620064739.GA7083@localhost.localdomain> On Thu, Jun 19, 2008 at 01:51:50PM -0400, Michael Wiktowy wrote: > Hi, > > I just read http://www.linuxformat.co.uk/static/suse11.html where is > mentions that OpenSuSe 11 went with a different compression algorithm > for their rpms (LZMA instead of bz2) and have a few questions: > > 1) While every distro seems to be coming together on a package > management GUI (PackageKit), does this represent a splintering of > package formats? or is rpm compression algorithm agnostic? Is there > any hope that the various rpm development will start pulling in the > same direction? Yes. We already have the LZMA bits in the upstream RPM for a while. So the support for the LZMA payload compression will occur as soon as the head RPM lands in rawhide. Support for old gz/bz2 payload remains, so no regressions will be introduced. > > 2) LZMA appears to have some good characteristics for installation > rpms (tighter compression, 50% decompression time ... at least as > implemented by 7zip ref: > http://www.maximumcompression.com/data/summary_mf4.php ). Is Fedora > planing to follow this switch (or has it already and not advertised it > as a prominent feature) or are there other considerations preventing > that (patent issues?, not suitable for delta rpms?, 200% compression > time)? Agreed, LZMA shows amazing compression results better that bzip2 with faster decompression than bz2 in most cases. OTOH it consumes more memory and compression takes longer, but seems to be feasible with the -7 compression level (default). The exact timing for the new rpm release is not clear yet, but there would be a need of mass rebuild to fully take advantage of the new compression. > /Mike > > -- > 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 michel.sylvan at gmail.com Fri Jun 20 06:51:27 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 20 Jun 2008 02:51:27 -0400 Subject: xulrunner and silent breakage of downstream apps Message-ID: <485B536F.7050503@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The recent push of xulrunner-1.9 and Firefox 3 broke Miro and devhelp (https://admin.fedoraproject.org/updates/F9/pending/devhelp-0.19.1-2.fc9) again. Is there a way to declare these kinds of dependencies that we are not using right now? Should Miro and devhelp specifically require xulrunner = %{version}-%{release} -- or perhaps a more administrative solution; block a non-security release of xulrunner for at least one day and automatically notify the maintainers of its dependents? Thanks, - -- Michel Salim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhbU2YACgkQWt0J3fd+7ZAzWwCghYaOeH4ezMyTa5r3bsktUWxV 9boAn1wzfFY/v0k8bTJeEn1masgkQC7F =Pt25 -----END PGP SIGNATURE----- From lesmikesell at gmail.com Fri Jun 20 06:59:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 20 Jun 2008 01:59:10 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.c! om> <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> <485AA5A7.7010900@gmail.com> Message-ID: <485B553E.3040209@gmail.com> Alexandre Oliva wrote: > >> or add my own changes to it. > > No, in order to modify a work you need permission from the copyright > holder and, in some jurisdictions, also from the author (in case the > author is allowed by law to assign the copyright to other parties > while retaining moral rights, one of which is to object to > modifications; this may sound alien to US-centered folks, but it's in > the Berne convention and implemented in various legislations around > the world) It turns out, "this depends...". You specifically have the right, in the US, at least, to make changes that are "an essential step in the utilization of the computer program". Which turns out to include adding improvements you need. http://www.techlawjournal.com/topstories/2005/20051107.asp And the court noted that no damage was done to the copyright holder by someone else modifying their own copy of a work. -- Les Mikesell lesmikesell at gmail.com From nigel.metheringham at dev.intechnology.co.uk Fri Jun 20 07:47:27 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Fri, 20 Jun 2008 08:47:27 +0100 Subject: RPM compression format In-Reply-To: <20080620064739.GA7083@localhost.localdomain> References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> <20080620064739.GA7083@localhost.localdomain> Message-ID: On 20 Jun 2008, at 07:47, Jindrich Novy wrote: > The exact timing for the new rpm release is not clear yet, but there > would be a need of mass rebuild to fully take advantage of the new > compression. I guess we also need to stage things appropriately so that those updating to Fedora x (where x is the LZMA supported distro) by using on-line update (yeah I know its not supported as such but its always worked well in the past), are able to get the initial upgrade requirements onto their box (which I guess would be rpm, yum & fedora- release) without being stymied by an rpm for those packages being compressed with LZMA when their own rpm cannot cope with it... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From pertusus at free.fr Fri Jun 20 07:55:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Jun 2008 09:55:56 +0200 Subject: What changelog to preserve at untrivial merging? In-Reply-To: <1218b5bc0806191731t4c7fb720l39e5569df3af7b83@mail.gmail.com> References: <485A7F86.2090502@odu.neva.ru> <1218b5bc0806191731t4c7fb720l39e5569df3af7b83@mail.gmail.com> Message-ID: <20080620075556.GA2591@free.fr> On Thu, Jun 19, 2008 at 07:31:32PM -0500, Callum Lerwick wrote: > On Thu, Jun 19, 2008 at 10:47 AM, Dmitry Butskoy > wrote: > > > Both packages have their own history. What changelog preserve in the new > > mailx in rawhide -- the old entries from mailx-8.x, the new entries from > > nail-12.3, or something else? > > > I would consider it a package rename, nail -> mailx, thus the nail changelog > should be preserved. > > Would it have been more appropriate to just have nail obsolete mailx? What > is the actual upstream name? mailx could be kept in fedora, nail doesn't really obsolete it, like a rename do. I think that the issue here is that a virtual provide should be used for mail (or a file provide like /bin/mail) such that the package providing mail can change in time. -- Pat From denis at poolshark.org Fri Jun 20 08:23:15 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 20 Jun 2008 10:23:15 +0200 Subject: xulrunner and silent breakage of downstream apps In-Reply-To: <485B536F.7050503@gmail.com> References: <485B536F.7050503@gmail.com> Message-ID: <485B68F3.9050804@poolshark.org> Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The recent push of xulrunner-1.9 and Firefox 3 broke Miro and devhelp > (https://admin.fedoraproject.org/updates/F9/pending/devhelp-0.19.1-2.fc9) > again. > > Is there a way to declare these kinds of dependencies that we are not > using right now? Should Miro and devhelp specifically require xulrunner > = %{version}-%{release} -- or perhaps a more administrative solution; > block a non-security release of xulrunner for at least one day and > automatically notify the maintainers of its dependents? It broke galeon as well, but this has to be a bug in xulrunner which didn't maintain binary compatibility when it was supposed to, no ? From michel.sylvan at gmail.com Fri Jun 20 08:52:11 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 20 Jun 2008 04:52:11 -0400 Subject: xulrunner and silent breakage of downstream apps In-Reply-To: <485B68F3.9050804@poolshark.org> References: <485B536F.7050503@gmail.com> <485B68F3.9050804@poolshark.org> Message-ID: <485B6FBB.8030807@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Denis Leroy wrote: > Michel Salim wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> The recent push of xulrunner-1.9 and Firefox 3 broke Miro and devhelp >> (https://admin.fedoraproject.org/updates/F9/pending/devhelp-0.19.1-2.fc9) >> again. >> >> Is there a way to declare these kinds of dependencies that we are not >> using right now? Should Miro and devhelp specifically require xulrunner >> = %{version}-%{release} -- or perhaps a more administrative solution; >> block a non-security release of xulrunner for at least one day and >> automatically notify the maintainers of its dependents? > > It broke galeon as well, but this has to be a bug in xulrunner which > didn't maintain binary compatibility when it was supposed to, no ? > It is indeed, but since it happens rather frequently (arguably, most of the recent breakages have been because we're tracking an unstable target, so hopefully things get better from now on), perhaps there ought to be a mechanism to handle similar situations. One cool way would be if two package maintainers independently find a silent API breakage due to the same dependency, an automatic rebuild is triggered on all other dependents of that library* * or rather, all dependents who are opted in for auto-updating - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhbb7oACgkQWt0J3fd+7ZAzcgCeP/dFLKCA9RD2QCnJ/LgxPZL4 qiUAn079LLOYnIfXVJJuZKczp1szyKkP =5aE/ -----END PGP SIGNATURE----- From kwizart at gmail.com Fri Jun 20 11:03:36 2008 From: kwizart at gmail.com (KH KH) Date: Fri, 20 Jun 2008 13:03:36 +0200 Subject: RPM compression format In-Reply-To: References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> <20080620064739.GA7083@localhost.localdomain> Message-ID: > I guess we also need to stage things appropriately so that those updating to > Fedora x (where x is the LZMA supported distro) by using on-line update > (yeah I know its not supported as such but its always worked well in the > past), are able to get the initial upgrade requirements onto their box > (which I guess would be rpm, yum & fedora-release) without being stymied by > an rpm for those packages being compressed with LZMA when their own rpm > cannot cope with it... > > Nigel. I think that's already done, on transaction, rpm (yum and co.) always search for updated version of themselves first. Well, indeed, rpm compressed with lzma aren't compatible with Fedora yet. Maybe that's the point we need to fix. Because we cannot install rpm from SuSE on Fedora (even if that doesn't really make sense unless for pure contents and we can always package it for Fedora ). If download size matter, I think it would be better to answear with deltarpms instead. Now maybe we can split the question of the lzma "support" in rpm itself with the question to "use" lzma in rpm, distro wide. Anyone ever submitted a RFC bug about this ? Nicolas (kwizart) From dominik at greysector.net Fri Jun 20 11:07:38 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 20 Jun 2008 13:07:38 +0200 Subject: RPM compression format In-Reply-To: References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> <20080620064739.GA7083@localhost.localdomain> Message-ID: <20080620110737.GA21873@mokona.greysector.net> On Friday, 20 June 2008 at 13:03, KH KH wrote: > > I guess we also need to stage things appropriately so that those updating to > > Fedora x (where x is the LZMA supported distro) by using on-line update > > (yeah I know its not supported as such but its always worked well in the > > past), are able to get the initial upgrade requirements onto their box > > (which I guess would be rpm, yum & fedora-release) without being stymied by > > an rpm for those packages being compressed with LZMA when their own rpm > > cannot cope with it... > > > > Nigel. > > I think that's already done, on transaction, rpm (yum and co.) always > search for updated version of themselves first. I've never heard of such behaviour. Is that a fact? > Well, indeed, rpm compressed with lzma aren't compatible with Fedora yet. > Maybe that's the point we need to fix. Because we cannot install rpm > from SuSE on Fedora (even if that doesn't really make sense unless for > pure contents and we can always package it for Fedora ). > If download size matter, I think it would be better to answear with > deltarpms instead. > Now maybe we can split the question of the lzma "support" in rpm > itself with the question to "use" lzma in rpm, distro wide. Indeed, it would make sense to first introduce support for LZMA and then, once that's in place, switch to actually using it to compress rpms' contents. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pbrobinson at gmail.com Fri Jun 20 11:12:38 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 20 Jun 2008 12:12:38 +0100 Subject: xulrunner and silent breakage of downstream apps In-Reply-To: <485B536F.7050503@gmail.com> References: <485B536F.7050503@gmail.com> Message-ID: <5256d0b0806200412i67263f0en8a911cf0eec3caf3@mail.gmail.com> On Fri, Jun 20, 2008 at 7:51 AM, Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The recent push of xulrunner-1.9 and Firefox 3 broke Miro and devhelp > (https://admin.fedoraproject.org/updates/F9/pending/devhelp-0.19.1-2.fc9) > again. > > Is there a way to declare these kinds of dependencies that we are not > using right now? Should Miro and devhelp specifically require xulrunner > = %{version}-%{release} -- or perhaps a more administrative solution; > block a non-security release of xulrunner for at least one day and > automatically notify the maintainers of its dependents? xulrunner was suppose to stop this from happening with a stable api. I suspect that prior to v1.9 final there was no guarantee of this but now its stable you should be able to require >= 1.9 and 1.9.0.x until at leat 1.9.1 (Firefox 3.1) comes out. The idea of xulrunner in Fedora being that if there's a security bug in gecko they can ship a new version of xulrunner and all the apps that use it that are shipped in Fedora are automatically secured. Peter From rawhide at fedoraproject.org Fri Jun 20 11:41:42 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 20 Jun 2008 11:41:42 +0000 (UTC) Subject: rawhide report: 20080620 changes Message-ID: <20080620114142.225FB209D21@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080619/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080620/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package collectl A utility to collect various linux performance data New package fbpanel A lightweight X11 desktop panel New package gambit-c Gambit-C Scheme programming system New package lazarus Lazarus Component Library and IDE for Freepascal New package libpst Utilities to convert Outlook .pst files to other formats New package libwfut Software updater tool for WorldForge applications New package perl-parent Establish an ISA relationship with base classes at compile time New package tex-fonts-hebrew Culmus Hebrew fonts support for LaTeX New package trickle Portable lightweight userspace bandwidth shaper Updated Packages: Miro-1.2.4-2.fc10 ----------------- * Wed Jun 18 18:00:00 2008 Alex Lancaster - 1.2.4-2 - Rebuild for xulrunner-1.9 final. MySQL-python-1.2.2-7.fc10 ------------------------- * Thu Jun 19 18:00:00 2008 Tom Lane 1.2.2-7 - Fix broken escape() method Resolves: #331021 PackageKit-0.2.3-4.20080618.fc10 -------------------------------- * Wed Jun 18 18:00:00 2008 Richard Hughes - 0.2.3-4.20080618 - Pull in a new snapshot from the unstable branch. - Add the font installing provide hooks cairo-dock-1.6.0.1-2.date20080619.fc10 -------------------------------------- * Fri Jun 20 18:00:00 2008 Mamoru Tasaka - 1.6.0.1-2.date20080619 - Revert XCompositeRedirectSubwindows() part in cairo-dock-X-utilities.c cdparanoia-10.0-2.fc10 ---------------------- * Thu Jun 19 18:00:00 2008 Adam Jackson 10.0-2 - cdparanoia 10. dnssec-tools-1.4-1.fc10 ----------------------- * Tue May 27 18:00:00 2008 Wes Hardaker - 1.4.rc1-1 - Update to upstream 1.4 evolution-2.23.4-2.fc10 ----------------------- * Thu Jun 19 18:00:00 2008 Matthew Barnes - 2.23.4-2.fc10 - Don't ship the unfinished "Custom Header" plugin. fio-1.21-1.fc10 --------------- * Thu Jun 19 18:00:00 2008 Eric Sandeen 1.21-1 - New upstream version - Build verbosely and with RPM cflags freeciv-2.1.5-1.fc10 -------------------- * Thu Jun 19 18:00:00 2008 Brian Pepple - 2.1.5-1 - Update to 2.1.5. gcin-1.4.1-1.fc10 ----------------- * Fri Jun 20 18:00:00 2008 Chung-Yen Chang - 1.4.1-1 - update to 1.4.1 ghc-6.8.3-3.fc10 ---------------- * Wed Jun 18 18:00:00 2008 Bryan O'Sullivan - 6.8.3-3 - Add symlinks from _libdir, where ghc looks, to _libexecdir - Patch libraries/gen_contents_index to use haddock-0.9 * Wed Jun 18 18:00:00 2008 Bryan O'Sullivan - 6.8.3-2 - Remove unnecessary dependency on alex * Wed Jun 18 18:00:00 2008 Bryan O'Sullivan - 6.8.3-1 - Upgrade to 6.8.3 - Drop the ghc682-style naming scheme, obsolete those packages - Manually strip binaries * Tue Apr 8 18:00:00 2008 Jens Petersen - 6.8.2-10 - another rebuild attempt * Thu Feb 14 17:00:00 2008 Jens Petersen - 6.8.2-9 - remove unrecognized --docdir and --htmldir from configure - drop old buildrequires on libX11-devel and libXt-devel - rebuild with gcc43 * Sun Jan 6 17:00:00 2008 Bryan O'Sullivan - 6.8.2-7 - More attempts to fix docdir * Sun Jan 6 17:00:00 2008 Bryan O'Sullivan - 6.8.2-6 - Fix docdir git-1.5.6-1.fc10 ---------------- * Thu Jun 19 18:00:00 2008 James Bowes 1.5.6-1 - git-1.5.6 * Tue Jun 3 18:00:00 2008 Stepan Kasal 1.5.5.3-2 - use tar.bz2 instead of tar.gz gnokii-0.6.26-2.fc10 -------------------- * Thu Jun 19 18:00:00 2008 - Bastien Nocera - 0.6.26-2 - Rebuild with libical support gnome-packagekit-0.2.3-4.20080618.fc10 -------------------------------------- * Wed Jun 18 18:00:00 2008 Richard Hughes - 0.2.3-4.20080618 - Pull in a new snapshot from the unstable branch. - Fixes a problem when installing with the DBUS session interface gstreamer-plugins-base-0.10.20-1.fc10 ------------------------------------- * Wed Jun 18 18:00:00 2008 - Bastien Nocera - 0.10.20-1 - Update to 0.10.20 gstreamer-plugins-good-0.10.8-7.fc10 ------------------------------------ * Thu Jun 19 18:00:00 2008 Adam Jackson 0.10.8-7 - gst-plugins-good-0.10.8-speex-nego.patch: Backport speex channel and rate negotiation from 0.10.9. (#451391) gtk2-2.13.3-2.fc10 ------------------ * Thu Jun 19 18:00:00 2008 Soren Sandmann - 2.13.3-2 - Require glib 2.17.1 (for g_dgettext) gtkwave-3.1.11-1.fc10 --------------------- * Thu Jun 19 18:00:00 2008 Paul Howarth 3.1.11-1 - update to 3.1.11 hunspell-1.2.4.2-1.fc10 ----------------------- * Wed Jun 18 18:00:00 2008 Caolan McNamara - 1.2.4.2-1 - latest version initscripts-8.77-1 ------------------ * Thu Jun 19 18:00:00 2008 Bill Nottingham - 8.77-1 - NMDispatcher/05-netfs: fix check for default route (#445509) - service: don't set $LANG, rely on it to inherit from system locales (#422141) - init.d/functions: fix resolve_dm_raid() for older dmraid configs - Don't unmount sysfs in halt. (#446292) - rc.sysinit: don't try to startup crypto if we can't find the device - rc.sysinit: don't echo crypto stuff unless we're actually *doing* something - ifup: don't try to rename devices - udev rules are the way to go - rc.sysinit: fix typo, and don't restorecon on swap, etc. partitions (#448886) - set MALLOC_CHECK_ & MALLOC_PERTURB_ if configured () - console_init: support SYSFONTACM correctly, and support UNIMAP (#448704, ) - don't export GRAPHICAL - plymouth is for all modes. also, don't start rhgb - fix clock rules to properly handle old-style RTC devices (#447019) - translation updates: ko, or, pl kdebase-runtime-4.0.83-1.fc10 ----------------------------- kdebase-workspace-4.0.83-1.fc10 ------------------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdelibs-4.0.83-1.fc10 --------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdepim-4.0.83-1.fc10 -------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdepimlibs-4.0.83-1.fc10 ------------------------ * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) libjpeg-6b-42.fc10 ------------------ * Thu Jun 19 18:00:00 2008 Tom Lane - 6b-42 - Work around autoconf 2.62 breakage Resolves: #449471 Related: #449245 nasm-2.03.01-1.fc10 ------------------- * Thu Jun 19 18:00:00 2008 Petr Machata - 2.03.01-1 - rebase to a new stable upstream version 2.03.01 nmh-1.3-1.fc10 -------------- * Thu Jun 19 18:00:00 2008 Josh Bressers 0:1.3-1 - Update nmh to 1.3 ocfs2-tools-1.3.9-8.20080221git.fc10 ------------------------------------ * Thu Jun 19 18:00:00 2008 Fabio M. Di Nitto - 1.3.9-8.20080221git - Make alpha tag optional - Use package names rather than files for Requires - Clean up changelog in spec file - Respect fedora build default CFLAGS python-eyed3-0.6.16-1.fc10 -------------------------- * Thu Jun 19 18:00:00 2008 Brian Pepple - 0.6.16-1 - Update to 0.6.16. scim-tables-0.5.8-2.fc10 ------------------------ * Thu Jun 19 18:00:00 2008 Caius Chance - 0.5.8-2.fc10 - Resolves: rhbz#438662 (Reverted Zhu Yin tables to previous version.) - Rearrange Ukrainian IME as individual group. - Reapply patch of bz#217639. - Refined previous jk_tables patch. - Arranged patch order. * Mon Mar 31 18:00:00 2008 Caius Chance - 0.5.8.1.fc9 - Update sources to 0.5.8. - Applied certain patches in 0.5.7. - Grouped Translit (Russian) and Ukrainian Translit IME to subpackages. subtitleeditor-0.21.2-1.fc10 ---------------------------- * Thu Jun 19 18:00:00 2008 Martin Sourada - 0.21.2-1 - New upstream release texlive-2007-33.fc10 -------------------- * Thu Jun 19 18:00:00 2008 Jindrich Novy - 2007-33 - platex belongs to texlive-east-asian otherwise it is a dangling symlink in texlive-latex texlive-texmf-2007-22.fc10 -------------------------- * Thu Jun 19 18:00:00 2008 Jindrich Novy - 2007-22 - rebuild to have higher NVR than F9 xorg-x11-server-1.4.99.902-2.20080612.fc10 ------------------------------------------ * Thu Jun 19 18:00:00 2008 Adam Tkac 1.4.99.902-2.20080612 - workaround broken AC_C_BIGENDIAN macro (#449944) xpdf-3.02-7.fc10 ---------------- * Thu Jun 19 18:00:00 2008 Tom "spot" Callaway 1:3.02-7 - add missing Requires: xorg-x11-fonts-ISO8859-1-75dpi yakuake-2.9.3-1.fc10 -------------------- * Fri Jun 20 18:00:00 2008 Johan Cwiklinski - 2.9.3-1 - 2.9.3 - kdebase is required Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 37 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libisofs.so.5 brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.x86_64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libisofs.so.5 brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.ppc64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From buc at odusz.so-cdu.ru Fri Jun 20 12:10:48 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 20 Jun 2008 16:10:48 +0400 Subject: What changelog to preserve at untrivial merging? In-Reply-To: <1218b5bc0806191731t4c7fb720l39e5569df3af7b83@mail.gmail.com> References: <485A7F86.2090502@odu.neva.ru> <1218b5bc0806191731t4c7fb720l39e5569df3af7b83@mail.gmail.com> Message-ID: <485B9E48.4020508@odu.neva.ru> Callum Lerwick wrote: > On Thu, Jun 19, 2008 at 10:47 AM, Dmitry Butskoy > wrote: > > Both packages have their own history. What changelog preserve in > the new mailx in rawhide -- the old entries from mailx-8.x, the > new entries from nail-12.3, or something else? > > > I would consider it a package rename, nail -> mailx, thus the nail > changelog should be preserved. > > Would it have been more appropriate to just have nail obsolete mailx? Nope... > What is the actual upstream name? ...because the actual upstream name is "mailx". (It was "nail" initially, then it was renamed, since the original mailx-8.x development is stopped long time ago...) Hence new "mailx-12.3" upgrades the previous one "mailx-8.x" and obsoletes "nail" (providing /usr/bin/nail symlink for backward compatibility). ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From mcepl at redhat.com Fri Jun 20 12:40:10 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 20 Jun 2008 14:40:10 +0200 Subject: Upcoming kernel build References: <1213725419.13481.25.camel@localhost.localdomain> Message-ID: On 2008-06-17, 17:56 GMT, Jesse Keating wrote: > In order to have a working kernel, but not make gcc go > backwards by untagging it while the gcc folks are working out > a fix, I've created a special buildroot to put the old gcc back > into service so that we can build the kernel and move beyond > the ext3 issues. This will be a short lived buildroot, only > used by the kernel, so that we have something working for the > next few days (somewhat critical given FUDCon). Yey, kernel compiler is back!!! :-) (I remember those days when on Debian lists we had to explain to all former Red Hat users, that no, you don't need special compiler just for kernel ;-)). Mat?j From jkeating at redhat.com Fri Jun 20 12:56:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jun 2008 08:56:35 -0400 Subject: Upcoming kernel build In-Reply-To: References: <1213725419.13481.25.camel@localhost.localdomain> Message-ID: <1213966595.27059.2.camel@localhost.localdomain> On Fri, 2008-06-20 at 14:40 +0200, Matej Cepl wrote: > On 2008-06-17, 17:56 GMT, Jesse Keating wrote: > > In order to have a working kernel, but not make gcc go > > backwards by untagging it while the gcc folks are working out > > a fix, I've created a special buildroot to put the old gcc back > > into service so that we can build the kernel and move beyond > > the ext3 issues. This will be a short lived buildroot, only > > used by the kernel, so that we have something working for the > > next few days (somewhat critical given FUDCon). > > Yey, kernel compiler is back!!! :-) > > (I remember those days when on Debian lists we had to explain to > all former Red Hat users, that no, you don't need special > compiler just for kernel ;-)). > > Mat?j Hhaha. Well due to FUDCon fun, I had forgotten to actually tag the build we did on the side, so the newly built kernel won't actually show up until tomorrow. Whoops. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tmraz at redhat.com Fri Jun 20 13:12:00 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 20 Jun 2008 15:12:00 +0200 Subject: gnutls upgrade in rawhide to 2.4.0 and license change Message-ID: <1213967520.25242.8.camel@vespa.frost.loc> I plan to do gnutls library update in rawhide to version 2.4.0 soon. Unfortunately the ABI of this version is different from 2.0.4 as is currently in rawhide. That means that all the libraries and applications which depend on it will have to be rebuilt. The new version also changes license on the libgnutls-extra and libgnutls-openssl libraries and on the utilities which are part of this package from GPLv2+ to GPLv3+. The main libgnutls library is unaffected by this licence change as it stays at LGPLv2.1+. It seems that the only packages currently in rawhide which depend on these two extra libraries are mcabber and gkrellm which have compatible license with GPLv3 so there should be no problem with that. The packages which will have to be rebuilt due to the ABI change are here: aiccu-2007.01.15-3.fc9.src.rpm aria2-0.12.0-4.fc9.src.rpm bitlbee-1.2-1.fc9.src.rpm buoh-0.8.2-4.fc9.src.rpm climm-0.6.2-1.fc9.src.rpm ctrlproxy-3.0.5-2.fc9.src.rpm cups-1.3.7-9.fc10.src.rpm drivel-2.1.1-0.5.20071130svn.fc9.src.rpm ekg2-0.2-0.1.rc1.fc10.src.rpm filezilla-3.0.11-1.fc10.src.rpm gkrellm-2.3.1-3.fc9.src.rpm gnutls-2.0.4-3.fc10.src.rpm gobby-0.4.5-3.fc9.src.rpm gtk-gnutella-0.96.5-1.fc9.src.rpm gtk-vnc-0.3.6-1.fc10.src.rpm gurlchecker-0.10.1-8.fc9.src.rpm hardinfo-0.4.2.3-5.fc9.src.rpm heartbeat-2.1.3-1.fc9.src.rpm iksemel-1.3-4.fc9.src.rpm jd-2.0.0-0.6.svn2129_trunk.fc10.src.rpm kazehakase-0.5.4-4.fc9.src.rpm kvm-70-1.fc10.src.rpm libepc-0.3.5-1.fc10.src.rpm libggz-0.0.14.1-1.fc9.src.rpm libprelude-0.9.17.1-1.fc10.src.rpm libpreludedb-0.9.14.1-2.fc9.src.rpm libsoup22-2.2.105-2.fc9.src.rpm libsoup-2.23.1-3.fc10.src.rpm libtranslate-0.99-14.fc9.src.rpm libvirt-0.4.3-1.fc10.src.rpm liferea-1.4.15-5.fc9.src.rpm loudmouth-1.4.0-1.fc10.src.rpm mcabber-0.9.6-1.fc9.src.rpm msmtp-1.4.13-4.fc9.src.rpm mutt-1.5.18-2.fc10.src.rpm neon-0.28.2-3.src.rpm net6-1.3.5-3.fc9.src.rpm ntfsprogs-2.0.0-7.fc10.src.rpm obby-0.4.4-3.fc9.src.rpm prelude-lml-0.9.12.2-1.fc10.src.rpm prelude-manager-0.9.12.1-1.fc10.src.rpm qemu-0.9.1-9.fc10.src.rpm rsyslog-3.19.7-2.fc10.src.rpm snort-2.8.1-3.fc10.src.rpm sobby-0.4.4-2.fc9.src.rpm vinagre-2.23.3.1-1.fc10.src.rpm virt-viewer-0.0.3-1.fc9.src.rpm weechat-0.2.6-3.fc9.src.rpm wireshark-1.0.0-2.fc9.src.rpm xen-3.2.0-12.fc9.src.rpm xenwatch-0.5.2-3.fc9.src.rpm xmlsec1-1.2.9-10.1.src.rpm First all the library packages must be rebuilt because the dependent applications will not build due to the buildroot inconsistency. I'll rebuild all the packages where it is allowed by ACLs, if you have a package on the list above and do not want me to rebuild it even though the ACLs allow it please send me an e-mail. If you have any comments/objections to the version update, please respond soon before I'll start the rebuilds - most probably on Monday if there will be no objections. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From moe at blagblagblag.org Fri Jun 20 14:23:25 2008 From: moe at blagblagblag.org (jeff) Date: Fri, 20 Jun 2008 11:23:25 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485B24D3.2030106@gmail.com> References: <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> <485AC889.5040409@blagblagblag.org> <20080619214816.GI9581@localhost.localdomain> <485B0CE7.4030904@blagblagblag.org> <485B24D3.2030106@gmail.com> Message-ID: <485BBD5D.8040304@blagblagblag.org> Les Mikesell wrote: > jeff wrote: >> Anders Karlsson wrote: >>> * jeff [20080619 23:00]: >>> [snip] >>> >>>> Well, Red Hat added it to the Linux kernel before the "Derived from >>>> Proprietary Sources" line was added. How do you know Red Hat doesn't >>>> have or never had the source to it? I don't think they have it, but >>>> I've never seen them say they didn't. >>> >>> Can you provide the commit ID showing that it was Red Hat that >>> committed it to the upstream Linux kernel source tree? I'm actually >>> curious to have a look at that commit. >> >> Somewhere else in this thread, jeff wrote: >> > The "GPLing" of the driver (MODULE_LICENSE("GPL")) and the >> inclusion of >> > a chunk of non-free code occurred in commit [1] >> > 2d8a9d3fd19147c808aa39ddc69a743d1c90f199. >> > >> > The commit shows David S. Miller (davem at redhat.com) and Jeff Garzik >> > (jgarzik at mandrakesoft.com) as authors. >> > >> > [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git >> >> -Jeff >> > > Per the debian discussion on this topic at > http://wiki.debian.org/KernelFirmwareLicensing this was fixed in this > commit: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 > > (i.e. the GPL indication removed). But that is simply wrong. Did you go to your own URL? It doesn't remove *a single line*. It just added (in 2005): + * Derived from proprietary unpublished source code, + * Copyright (C) 2000-2003 Broadcom Corporation. + * + * Permission is hereby granted for the distribution of this firmware + * data in hexadecimal or equivalent format, provided this copyright + * notice is accompanying it. -Jeff From dominik at greysector.net Fri Jun 20 14:30:00 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 20 Jun 2008 16:30:00 +0200 Subject: gnutls upgrade in rawhide to 2.4.0 and license change In-Reply-To: <1213967520.25242.8.camel@vespa.frost.loc> References: <1213967520.25242.8.camel@vespa.frost.loc> Message-ID: <20080620143000.GB21873@mokona.greysector.net> On Friday, 20 June 2008 at 15:12, Tomas Mraz wrote: > I plan to do gnutls library update in rawhide to version 2.4.0 soon. > Unfortunately the ABI of this version is different from 2.0.4 as is > currently in rawhide. That means that all the libraries and applications > which depend on it will have to be rebuilt. [...] > The packages which will have to be rebuilt due to the ABI change are > here: [...] > ekg2-0.2-0.1.rc1.fc10.src.rpm ekg2 doesn't build currently due to gtk2 breakage, please don't touch it. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From lesmikesell at gmail.com Fri Jun 20 14:59:06 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 20 Jun 2008 09:59:06 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <485BBD5D.8040304@blagblagblag.org> References: <1213744509.26255.1127.camel@pmac.infradead.org> <485908AF.5050402@gmail.com> <1213796150.26255.1236.camel@pmac.infradead.org> <48591B19.6080108@gmail.com> <4859264B.1050206@gmail.com> <48592E84.4020209@blagblagblag.org> <20080618201338.GA9581@localhost.localdomain> <485A9C75.3090204@blagblagblag.org> <200806192029.m5JKTdEZ009759@laptop13.inf.utfsm.cl> <485AC889.5040409@blagblagblag.org> <20080619214816.GI9581@localhost.localdomain> <485B0CE7.4030904@blagblagblag.org> <485B24D3.2030106@gmail.com> <485BBD5D.8040304@blagblagblag.org> Message-ID: <485BC5BA.2040006@gmail.com> jeff wrote: > >>>>> Well, Red Hat added it to the Linux kernel before the "Derived from >>>>> Proprietary Sources" line was added. How do you know Red Hat >>>>> doesn't have or never had the source to it? I don't think they have >>>>> it, but I've never seen them say they didn't. >>>> >>>> Can you provide the commit ID showing that it was Red Hat that >>>> committed it to the upstream Linux kernel source tree? I'm actually >>>> curious to have a look at that commit. >>> >>> Somewhere else in this thread, jeff wrote: >>> > The "GPLing" of the driver (MODULE_LICENSE("GPL")) and the >>> inclusion of >>> > a chunk of non-free code occurred in commit [1] >>> > 2d8a9d3fd19147c808aa39ddc69a743d1c90f199. >>> > >>> > The commit shows David S. Miller (davem at redhat.com) and Jeff Garzik >>> > (jgarzik at mandrakesoft.com) as authors. >>> > >>> > [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git >>> >>> -Jeff >>> >> >> Per the debian discussion on this topic at >> http://wiki.debian.org/KernelFirmwareLicensing this was fixed in this >> commit: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be;hp=9beb1d587f690d5b2f9087f8f10c0ff9f6b66886 >> >> (i.e. the GPL indication removed). > > But that is simply wrong. Did you go to your own URL? It doesn't remove > *a single line*. It just added (in 2005): > > + * Derived from proprietary unpublished source code, > + * Copyright (C) 2000-2003 Broadcom Corporation. > + * > + * Permission is hereby granted for the distribution of this firmware > + * data in hexadecimal or equivalent format, provided this copyright > + * notice is accompanying it. > I guess I didn't look that closely. Maybe the GPL line was removed earlier and this put in (back?) the permission to distribute. I just pasted the link from the debian discussion where they quoted the earlier one that said it was GPL and then said this commit solved their problem with it. See the tg3 section of the 1st link I posted. -- Les Mikesell lesmikesell at gmail.com From katzj at redhat.com Fri Jun 20 14:10:30 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 20 Jun 2008 10:10:30 -0400 Subject: RPM compression format In-Reply-To: References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> <20080620064739.GA7083@localhost.localdomain> Message-ID: <1213971030.12272.10.camel@aglarond.local> On Fri, 2008-06-20 at 08:47 +0100, Nigel Metheringham wrote: > On 20 Jun 2008, at 07:47, Jindrich Novy wrote: > > The exact timing for the new rpm release is not clear yet, but there > > would be a need of mass rebuild to fully take advantage of the new > > compression. > > I guess we also need to stage things appropriately so that those > updating to Fedora x (where x is the LZMA supported distro) by using > on-line update (yeah I know its not supported as such but its always > worked well in the past), are able to get the initial upgrade > requirements onto their box (which I guess would be rpm, yum & fedora- > release) without being stymied by an rpm for those packages being > compressed with LZMA when their own rpm cannot cope with it... This is why upgrades via anaconda[1] are the recommended method. The anaconda environment then has the newer bits and things can Just Work (tm) without requiring weird jumping through hoops Jeremy [1] With or without preupgrade From katzj at redhat.com Fri Jun 20 14:11:08 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 20 Jun 2008 10:11:08 -0400 Subject: RPM compression format In-Reply-To: References: <3e4ec4600806191051id299c1dy3128d46e451ad40@mail.gmail.com> <20080620064739.GA7083@localhost.localdomain> Message-ID: <1213971068.12272.11.camel@aglarond.local> On Fri, 2008-06-20 at 13:03 +0200, KH KH wrote: > I think that's already done, on transaction, rpm (yum and co.) always > search for updated version of themselves first. No, this doesn't happen. And it gets you into a bit of a pickle because what happens when you need the new python which needs the new glibc, etc. ... Jeremy From brent at brentnorris.net Fri Jun 20 16:49:54 2008 From: brent at brentnorris.net (Brent Norris) Date: Fri, 20 Jun 2008 11:49:54 -0500 Subject: Latest Zoneminder Message-ID: <485BDFB2.3010105@brentnorris.net> I have read some of the tickets in bugzilla about it, but things seem to have stalled. What is the status of getting the latest zoneminder into Fedora? At one time I read that there were some pieces that were missing, but I think the last bugzilla entry that I read said that they were submitted for review. Brent From tibbs at math.uh.edu Fri Jun 20 16:59:33 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Jun 2008 11:59:33 -0500 Subject: Latest Zoneminder In-Reply-To: <485BDFB2.3010105@brentnorris.net> References: <485BDFB2.3010105@brentnorris.net> Message-ID: >>>>> "BN" == Brent Norris writes: BN> I have read some of the tickets in bugzilla about it, but things BN> seem to have stalled. What is the status of getting the latest BN> zoneminder into Fedora? I believe the significant prerequisite is in Fedora now, at least in rawhide; I'm not sure that we'll want to push the new zoneminder into the release branches. That's basically up to Martin. Remaining issues are the two javascript packages needed by the new ZM release; these are basically awaiting the completion of the javascript guidelines but I may go ahead and do things in an interim fashion. If you want to help testing, make sure you're CC'd on https://bugzilla.redhat.com/show_bug.cgi?id=429910 - J< From hedayat at grad.com Fri Jun 20 17:11:40 2008 From: hedayat at grad.com (Hedayat Vatnakhah) Date: Fri, 20 Jun 2008 21:41:40 +0430 Subject: rpmlint warnings In-Reply-To: <1213920437.28011.TMDA@tmda.severn.wwwdotorg.org> References: <485AEFD6.7030701@grad.com> <1213920437.28011.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <485BE4CC.6050202@grad.com> Hi, Yes it does. /*Stephen Warren */ wrote on 06/20/2008 04:37:17 AM: > On Thu, June 19, 2008 5:46 pm, Hedayat Vatnakhah wrote: > >> Hi all, >> >> I've a question about an rpmlint warning message: when I run rpmlint >> against my package >> ... >> It'll print a set of dangling-relative-symlink errors like this: >> >> rcssserver3d-devel.i386: W: dangling-relative-symlink >> /usr/lib/rcssserver3d/librcssnet3D.so librcssnet3D.so.0.0.0 >> > > Does the -devel package require the main package, and by exact version > number? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.masch at gmail.com Fri Jun 20 18:37:56 2008 From: the.masch at gmail.com (Mario Chacon) Date: Fri, 20 Jun 2008 15:37:56 -0300 Subject: Update for Gnome-do 0.5 Message-ID: <93d66b780806201137h78d6293aja9e057fdc7178194@mail.gmail.com> Hi! Somebody know if you plan to compile gnome-do version 0.5 ?... Thanks.. From jroth at linux.vnet.ibm.com Fri Jun 20 18:55:19 2008 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Fri, 20 Jun 2008 20:55:19 +0200 Subject: Cross toolchain support for SPUs on Cell / ppc64 Message-ID: <485BFD17.9090503@linux.vnet.ibm.com> A lot of people using the PS3 and / or Cell based systems suffer from missing toolchain support for building SPU applications just after they installed Fedora. They have to download the necessary packages from various places and have to do the package management by their own. I think that the time is right to support SPUs right out of the box after installing the latest Fedora release. Therefore we'd need to have the following packages in Fedora. spu-binutils spu-gcc spu-newlib spu-gdb Before we start opening Review Requests in Bugzilla we want to start the discussion what the best approach for supporting cross compiling toolchains like the SPU toolchain in Fedora is. As far as I know there is only one example for cross compiler support in Fedora which is Atmels AVR. Our suggestion would be to build spu-binutils from the same source as the system gcc for ppc is build. Here we'd have to change the ppc binutils package and add --enable-target=spu . A separate spu-binutils package including the spu assembly is needed anyhow. It would also be good to be able to build the spu-gcc from the same sources as the system gcc is build. It would be even better if the spu-gcc is build from the same .spec file. Of course this needs a lot of configuration and adjustments. For spu-newlib we'd have to create a separate package as we'd have for spu-gdb. Thanks for any comment, suggestion and help. -- Jochen From amdunn at gmail.com Fri Jun 20 19:36:26 2008 From: amdunn at gmail.com (Alan Dunn) Date: Fri, 20 Jun 2008 15:36:26 -0400 Subject: Another reviewer for Coq package? Current one currently away Message-ID: I'm looking for another reviewer for my Coq package - the one currently assigned (Richard W. M. Jones) is away for a few weeks and won't be able to look at it further until he returns. I've fixed the issues cited by him since he looked at the package, as documented on the bugzilla page: https://bugzilla.redhat.com/show_bug.cgi?id=450323 I still also need a sponsor, as this is my first Fedora package. For those interested - the description: Coq is a formal proof management system. It allows for the development of theorems through first order logic that are mechanically checked by the machine. Sets of definitions and theorems can be saved as compiled modules and loaded into the system. Coq is based off of OCaml. - Alan From pertusus at free.fr Fri Jun 20 21:34:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Jun 2008 23:34:24 +0200 Subject: rpmlint warnings In-Reply-To: <485BE4CC.6050202@grad.com> References: <485AEFD6.7030701@grad.com> <1213920437.28011.TMDA@tmda.severn.wwwdotorg.org> <485BE4CC.6050202@grad.com> Message-ID: <20080620213424.GA2614@free.fr> On Fri, Jun 20, 2008 at 09:41:40PM +0430, Hedayat Vatnakhah wrote: > Hi, > Yes it does. > You can ignore the warning then. If you run rpmlint against the installed rpm it shouldn't complain. -- Pat From lists at ebourne.me.uk Fri Jun 20 23:44:34 2008 From: lists at ebourne.me.uk (Martin Ebourne) Date: Fri, 20 Jun 2008 23:44:34 +0000 (UTC) Subject: Latest Zoneminder References: <485BDFB2.3010105@brentnorris.net> Message-ID: On Fri, 20 Jun 2008 11:59:33 -0500, Jason L Tibbitts III wrote: >>>>>> "BN" == Brent Norris writes: > > BN> I have read some of the tickets in bugzilla about it, but things BN> > seem to have stalled. What is the status of getting the latest BN> > zoneminder into Fedora? > > I believe the significant prerequisite is in Fedora now, at least in > rawhide; I'm not sure that we'll want to push the new zoneminder into > the release branches. That's basically up to Martin. I was hoping we might get the upgrade as an early F9 update but we've passed that one. I would still like to see the upgrade in F9, although if we end up closer to F10 before it's complete maybe it would be better to hold off. > Remaining issues are the two javascript packages needed by the new ZM > release; these are basically awaiting the completion of the javascript > guidelines but I may go ahead and do things in an interim fashion. It's probably reasonable to come up with a solution for now even if it needs to be revised when the guidelines are complete. Cheers, Martin. From davej at redhat.com Fri Jun 20 22:29:21 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 20 Jun 2008 18:29:21 -0400 Subject: make clog slowdown in devel. Message-ID: <20080620222921.GA6099@redhat.com> I noticed something odd.. (18:25:35:davej at gelk:F-9)$ time make clog make: `clog' is up to date. 0.22user 0.11system 0:00.33elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+52803minor)pagefaults 0swaps (18:25:40:davej at gelk:F-9)$ cd ../devel/ (18:25:43:davej at gelk:devel)$ time make clog make: `clog' is up to date. 0.25user 0.15system 0:02.82elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+76947minor)pagefaults 0swaps The times are consistent across multiple runs. Same command in devel takes a lot longer. The spec file differences are irrelevant. (tested by copying the specfile from f9 to devel) The clog target is just a simple sed & tee, so I'm confused as to why it takes longer. Dave -- http://www.codemonkey.org.uk From katzj at redhat.com Sat Jun 21 02:07:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 20 Jun 2008 22:07:33 -0400 Subject: make clog slowdown in devel. In-Reply-To: <20080620222921.GA6099@redhat.com> References: <20080620222921.GA6099@redhat.com> Message-ID: <1214014053.12272.14.camel@aglarond.local> On Fri, 2008-06-20 at 18:29 -0400, Dave Jones wrote: > I noticed something odd.. [snip] > The times are consistent across multiple runs. Same command in devel takes > a lot longer. The spec file differences are irrelevant. > (tested by copying the specfile from f9 to devel) > > The clog target is just a simple sed & tee, so I'm confused as to why > it takes longer. I suspect it's due to the fact that we don't have a branch file and so do more checking for figuring out what branch you're on (which is used to determine the value of %dist among other things) Jeremy From davej at redhat.com Sat Jun 21 02:25:18 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 20 Jun 2008 22:25:18 -0400 Subject: make clog slowdown in devel. In-Reply-To: <1214014053.12272.14.camel@aglarond.local> References: <20080620222921.GA6099@redhat.com> <1214014053.12272.14.camel@aglarond.local> Message-ID: <20080621022518.GA20834@redhat.com> On Fri, Jun 20, 2008 at 10:07:33PM -0400, Jeremy Katz wrote: > On Fri, 2008-06-20 at 18:29 -0400, Dave Jones wrote: > > I noticed something odd.. > [snip] > > The times are consistent across multiple runs. Same command in devel takes > > a lot longer. The spec file differences are irrelevant. > > (tested by copying the specfile from f9 to devel) > > > > The clog target is just a simple sed & tee, so I'm confused as to why > > it takes longer. > > I suspect it's due to the fact that we don't have a branch file and so > do more checking for figuring out what branch you're on (which is used > to determine the value of %dist among other things) I tried faking one. Didn't change anything.. $ echo F-10 > branch $ time make clog make: `clog' is up to date. 0.24user 0.15system 0:02.82elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+74933minor)pagefaults 0swaps Dave -- http://www.codemonkey.org.uk From rc040203 at freenet.de Sat Jun 21 04:21:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Jun 2008 06:21:53 +0200 Subject: Cross toolchain support for SPUs on Cell / ppc64 In-Reply-To: <485BFD17.9090503@linux.vnet.ibm.com> References: <485BFD17.9090503@linux.vnet.ibm.com> Message-ID: <1214022113.3615.36.camel@beck.corsepiu.local> On Fri, 2008-06-20 at 20:55 +0200, Jochen Roth wrote: > Before we start opening Review Requests in Bugzilla we want to start the > discussion what the best approach for supporting cross compiling > toolchains like the SPU toolchain in Fedora is. As far as I know there > is only one example for cross compiler support in Fedora which is Atmels > AVR. > > Our suggestion would be to build spu-binutils from the same source as > the system gcc for ppc is build. Theoretically, this would be one possibility, however, practice tells this doesn't work, because there always will be situations when you will want to patch/apply hacks to your cross-binutils, or when target-specific bugs force your cross-binutils to use a different version of binutils than of the native binutils. > Here we'd have to change the ppc > binutils package and add --enable-target=spu . A separate spu-binutils > package including the spu assembly is needed anyhow. The latter is what I have learned to be the only viable approach. > It would also be good to be able to build the spu-gcc from the same > sources as the system gcc is build. IMO, this doesn't work for the same rationales as above. > It would be even better if the > spu-gcc is build from the same .spec file. Of course this needs a lot of > configuration and adjustments. Yes, building cross-toolchain packages is tedious. > For spu-newlib we'd have to create a separate package as we'd have for > spu-gdb. This is one option, but it raises problems with bootstrapping GCC. The alternative is building newlib+gcc one-tree-style (building newlib and gcc at the same time). It's what I do for my cross-toolchains. Ralf From lordmorgul at gmail.com Sat Jun 21 07:05:27 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 21 Jun 2008 00:05:27 -0700 Subject: help understanding architecture of audio In-Reply-To: <48583BE3.6070405@as.arizona.edu> References: <48583BE3.6070405@as.arizona.edu> Message-ID: <485CA837.6040007@gmail.com> don fisher wrote: > I am quite familiar with connecting arbitrarily complex audio systems. I > have been trying to understand how the sections of the linux audio plug > together. > > For sources I have a microphone, audio and video CDs, and MP3s. For > output I have an audio jack, a bluetooth transmitter. > > Is there a mux (or preamp equivalent) that allows one to select and > input and output path? Perhaps also set the gain, balance, base, treble > and loudness. Pulseaudio has interface controls to handle nearly anything you want to do with a stream. You need to find and install all the pulse tools like paman, pavumeter, pavucontrol, and padevchooser. > Is there a document that describes haw to turn on, and then access the > various input and and output channels. As mentioned in other email, docs on gstreamer, alsa, or pulseaudio are where you want to look really. There are other sound subsystems but these are where the real forward movement is in linux audio. I'm no expert either, but generally applications implement calls to the gstreamer libraries, the alsa sound subsystem is either used above that (i.e. pulseaudio is not being used and alsa configuration is all there is), or pulseaudio is used in combination with alsa with PA being the top-level interface/system. F9+ use pulseaudio running as a user daemon, interfacing with alsa controlling the hardware devices, with applications streaming sound in through gstreamer or direct alsa channels. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From thomas.moschny at gmail.com Sat Jun 21 07:23:38 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Sat, 21 Jun 2008 09:23:38 +0200 Subject: make clog slowdown in devel. In-Reply-To: <20080621022518.GA20834@redhat.com> References: <20080620222921.GA6099@redhat.com> <1214014053.12272.14.camel@aglarond.local> <20080621022518.GA20834@redhat.com> Message-ID: 2008/6/21 Dave Jones : > I tried faking one. Didn't change anything.. See the top of Makefile.common. If the current directory is named "devel", a cvs rlog command is issued to determine whether BRANCH should be set to "F-10" or "devel". I don't quite grok the logic yet, but that's the reason for the delay. - Thomas From ville.skytta at iki.fi Sat Jun 21 07:34:16 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 21 Jun 2008 10:34:16 +0300 Subject: make clog slowdown in devel. In-Reply-To: <20080621022518.GA20834@redhat.com> References: <20080620222921.GA6099@redhat.com> <1214014053.12272.14.camel@aglarond.local> <20080621022518.GA20834@redhat.com> Message-ID: <200806211034.16674.ville.skytta@iki.fi> On Saturday 21 June 2008, Dave Jones wrote: > On Fri, Jun 20, 2008 at 10:07:33PM -0400, Jeremy Katz wrote: > > On Fri, 2008-06-20 at 18:29 -0400, Dave Jones wrote: > > > I noticed something odd.. > > > > [snip] > > > > > The times are consistent across multiple runs. Same command in devel > > > takes a lot longer. The spec file differences are irrelevant. > > > (tested by copying the specfile from f9 to devel) > > > > > > The clog target is just a simple sed & tee, so I'm confused as to why > > > it takes longer. > > > > I suspect it's due to the fact that we don't have a branch file and so > > do more checking for figuring out what branch you're on (which is used > > to determine the value of %dist among other things) > > I tried faking one. Didn't change anything.. > > $ echo F-10 > branch [...] Makefile.common doesn't seem to be looking at the "branch" file at all to figure out the branch, instead it does a "pwd | awk -F '/' '{ print $NF }'". And as Jeremy noted, if the branch is "devel", a subsequent "cvs rlog" is done before anything else which I'm pretty sure is the slowdown culprit. I wonder if it would be feasible to modify Makefile.commmon to do that only when needed so frequently run targets that don't need the branch/dist info wouldn't be affected. Or just disable the rlog thingy during times when no early branching for the next release is being done (I suppose that's what it is all about). From ville.skytta at iki.fi Sat Jun 21 08:06:08 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 21 Jun 2008 11:06:08 +0300 Subject: rpmlint warnings In-Reply-To: <20080620213424.GA2614@free.fr> References: <485AEFD6.7030701@grad.com> <485BE4CC.6050202@grad.com> <20080620213424.GA2614@free.fr> Message-ID: <200806211106.08623.ville.skytta@iki.fi> On Saturday 21 June 2008, Patrice Dumas wrote: > On Fri, Jun 20, 2008 at 09:41:40PM +0430, Hedayat Vatnakhah wrote: > > Hi, > > Yes it does. > > You can ignore the warning then. If you run rpmlint against the > installed rpm it shouldn't complain. Yep, this is a rpmlint bug. It has code in place to skip all dangling symlink checks for *.so (no matter what the package dependencies are), but that code currently matches only *.so placed directly in */lib and */lib64 dirs. Improved upstream: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1434 From dwashington at gmx.net Sat Jun 21 09:51:47 2008 From: dwashington at gmx.net (Denis Washington) Date: Sat, 21 Jun 2008 11:51:47 +0200 Subject: LSB Package API Message-ID: <1214041907.5778.39.camel@dwashington> Hi, Some time ago, it was discussed on an LSB face-to-face meeting that an API should be developed that allows ISVs to install sotware packages which integrate into the package manager - the "Berlin Packaging API". While the idea seemed to be well received, there didn't seem much progress since then, except for a wiki page with a rundimentary proposal [1]. Considering that third-party software installation is an undeniably important weak spot of the Linux infrastructure, I found this was a shame. To reignite the the initiative, I decided to design and develop a prototype implementation of the Berlin API, most creatively named the "LSB Package API". It is designed as a simple D-Bus interface accompanied with an XML-based package description format. A detailed description and the source code can be found on this page: http://www.linuxfoundation.org/en/LSB_Package_API The implementation currently supports integration into RPM and dpkg; due to its modular nature, support for more package managers could be added later on. I hope this implementation will act as a starting point for resurrecting the Berlin API process. Let us overcome the "Third-party software installation on Linux sucks" problem and strive to a brave new world of easily distributable Linux software! ;) Best regards, Denis Washington [1] http://www.linuxfoundation.org/en/Berlin_Packaging_API From rawhide at fedoraproject.org Sat Jun 21 10:43:12 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 21 Jun 2008 10:43:12 +0000 (UTC) Subject: rawhide report: 20080621 changes Message-ID: <20080621104313.07FD2209D3C@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080620/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080621/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package kdeplasmoids Additional plasmoids for KDE New package swarp Tool that resamples and co-adds together FITS images New package xxdiff Graphical file and directories comparator and merge tool Updated Packages: WebKit-1.0.0-0.13.svn34655.fc10 ------------------------------- * Thu Jun 12 18:00:00 2008 Peter Gordon 1.0.0-0.13.svn34655 - Update to new upstream snapshot (SVN 34655) - Add some build-time conditionals for non-default features: debug, html5video, libsoup, pango, svg. akonadi-0.82.0-1.fc10 --------------------- * Wed Jun 18 18:00:00 2008 Rex Dieter 0.82.0-1 - akonadi-0.82.0 anaconda-11.4.1.7-1 ------------------- * Fri Jun 20 18:00:00 2008 Chris Lumens - 11.4.1.7-1 - Remove ancient block of code to upgrade Netscape Communicator. (clumens) - Move enableNetwork into the interface. Bring network up for scp. (clumens) - If we can't mount for some reason, don't traceback (#452159). (clumens) - Fix the upgrade button traceback (#374891). (clumens) bigboard-0.5.38-2.fc10 ---------------------- * Thu Jun 19 18:00:00 2008 Owen Taylor - 0.5.38-2 - Update to 0.5.38 (improvements for people search) * Wed Jun 18 18:00:00 2008 Owen Taylor - 0.5.37-1 - Update to 0.5.37 (fixes problem with libgmail not being installed) * Mon Jun 16 18:00:00 2008 Owen Taylor - 0.5.35-2 - Fix file list for files that are no longer there * Mon Jun 16 18:00:00 2008 Owen Taylor - 0.5.35-1 - Update to 0.5.35 cairo-dock-1.6.0.2-0.1.svn1120_trunk.fc10 ----------------------------------------- * Sat Jun 21 18:00:00 2008 Mamoru Tasaka - svn 1020 (prepare for 1.6.0.2) climm-0.6.2-3.fc10 ------------------ * Fri Jun 20 18:00:00 2008 Jan ONDREJ (SAL) - 0.6.2-3 - Add patch to prevent "typing too fast" messages. cylindrix-1.0-5.fc10 -------------------- * Fri Jun 20 18:00:00 2008 Jon Ciesla - 1.0-5 - Set terminal to false in .desktop, BZ 452155. dirac-0.10.0-1.fc10 ------------------- * Sat Jun 21 18:00:00 2008 kwizart < kwizart at gmail.com > - 0.10.0-1 - Update to 0.10.0 e2fsprogs-1.41-0.WIP.0617.1.fc10 -------------------------------- * Fri Jun 20 18:00:00 2008 Eric Sandeen 1.41-0.WIP.0617.1 - Fix blkid -g segfault when clearing entries (#452333) echo-icon-theme-0.3.89.0-0.2.gitd5668098.fc10 --------------------------------------------- * Fri Jun 20 18:00:00 2008 Martin Sourada - 0.3.90.0-0.2.gitd5668098 - New git snapshot gdb-6.8-12.fc10 --------------- * Fri Jun 20 18:00:00 2008 Jan Kratochvil - 6.8-12 - Remove the gdb/gdbtui binaries duplicity. gnome-applet-timer-2.0.1-2.fc10 ------------------------------- * Fri Jun 20 18:00:00 2008 Christoph Wickert - 2.0.2-1 - Disable broken check macro (#449717) temporarily to fix #449485 gnome-icon-theme-2.23.2-2.fc10 ------------------------------ * Fri Jun 20 18:00:00 2008 Matthias Clasen - 2.23.2-2 - Re-add the symlinks for gtk stock icons, remove some other symlinks gtkmozembedmm-1.4.2.cvs20060817-20.fc9 -------------------------------------- * Fri Jun 20 18:00:00 2008 Martin Stransky - 1.4.2.cvs20060817-20 - rebuild against new gecko-libs 1.9 (xulrunner) * Sat Apr 12 18:00:00 2008 Ha??kel Gu??mar - 1.4.2.cvs20060817-19 - remove now useless sed one-liner. - fixed gtkmozembedmm-1.4.2.cvs20060817-xulrunner.patch - added gtkmozembedmm-1.4.2.cvs20060817-m4.patch * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.4.2.cvs20060817-18 - Autorebuild for GCC 4.3 hippo-canvas-0.2.34-1.fc10 -------------------------- * Thu Jun 19 18:00:00 2008 Owen Taylor - 0.2.34-1 - Update to 0.2.34 (Fixes crash when destroying HippoCanvasWidget) * Tue Jun 17 18:00:00 2008 Owen Taylor - 0.2.33-1 - Update to 0.2.33 (Fixes problem with python bindings missing get_font() method) * Mon Jun 16 18:00:00 2008 Owen Taylor - 0.2.32-1 - Update to 0.2.32 initscripts-8.78-1 ------------------ * Fri Jun 20 18:00:00 2008 Bill Nottingham - 8.78-1 - fix mounting of /dev/pts kdeaccessibility-4.0.83-1.fc10 ------------------------------ * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdeadmin-4.0.83-1.fc10 ---------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdeartwork-4.0.83-1.fc10 ------------------------ * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdebase-4.0.83-1.fc10 --------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdebindings-4.0.83-2.fc10 ------------------------- * Fri Jun 20 18:00:00 2008 Kevin Kofler 4.0.83-2 - reenable smoke again (keep ruby off for now) - drop explicit ENABLE_SMOKEKDEVPLATFORM=OFF (now off by default) - add BR kdegraphics-devel for the Smoke Okular bindings - fix file list * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdeedu-4.0.83-1.fc10 -------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdegames-4.0.83-1.fc10 ---------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdegraphics-4.0.83-1.fc10 ------------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) * Sun Jun 15 18:00:00 2008 Rex Dieter 4.0.82-1 - 4.0.82 kdemultimedia-4.0.83-1.fc10 --------------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdenetwork-4.0.83-1.fc10 ------------------------ * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdetoys-4.0.83-1.fc10 --------------------- * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kernel-2.6.26-0.74.rc6.git4.fc10 -------------------------------- * Tue Jun 17 18:00:00 2008 Dave Jones - 2.6.26-rc6-git4 libgphoto2-2.4.1-5.fc10 ----------------------- * Fri Jun 20 18:00:00 2008 Kevin Kofler 2.4.1-5 - fix pkgcfg patch to match actual .pc file names (fixes kdegraphics build) libopensync-plugin-evolution2-0.36-1.fc10 ----------------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade - fix upgrade path libopensync-plugin-file-0.36-1.fc10 ----------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-gnokii-0.36-1.fc10 ------------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-google-calendar-0.36-1.fc10 ---------------------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade - fix FTBFS (#433995, #449497) * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.35-3 - Autorebuild for GCC 4.3 libopensync-plugin-gpe-0.36-1.fc10 ---------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade - fix upgrade path libopensync-plugin-moto-0.36-1.fc10 ----------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-opie-0.36-1.fc10 ----------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-palm-0.36-1.fc10 ----------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-python-0.36-1.fc10 ------------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libopensync-plugin-vformat-0.36-1.fc10 -------------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libwfut-0.2.0-3.fc10 -------------------- * Fri Jun 20 18:00:00 2008 Alexey Torkhov 0.2.0-3 - Fixing deps. logwatch-7.3.6-24.fc10 ---------------------- * Fri Jun 20 18:00:00 2008 Ivana Varekova 7.3.6-24 - Resolves: #452044 handle 2.6.25+ audit messages - add init script logs parsing mod_geoip-1.2.4-2.fc10 ---------------------- * Fri Jun 20 18:00:00 2008 Michael Fleming 1.2.4-2 - New upstream update - Minor spec tweaks * Sun Apr 13 18:00:00 2008 Michael Fleming 1.2.2-1 - New upstream update msynctool-0.36-1.fc10 --------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade mugshot-1.2.1-1.fc10 -------------------- * Wed Jun 18 18:00:00 2008 Owen Taylor - 1.2.1-1 - Update to 1.2.1 (Fixes Firefox min version #451918) * Mon Jun 16 18:00:00 2008 Owen Taylor - 1.2.0-1 - Update to 1.2.0 nip2-7.14.4-1.fc10 ------------------ * Sat Jun 21 18:00:00 2008 Adam Goode - 7.14.4-1 - New release online-desktop-0.2.29-4.fc10 ---------------------------- * Thu Jun 19 18:00:00 2008 Owen Taylor - 0.2.29-4 - Tiny wording tweak * Thu Jun 19 18:00:00 2008 Owen Taylor - 0.2.29-3 - Add Getting_Started.html * Mon Jun 16 18:00:00 2008 Owen Taylor - 0.2.29-2 - Add missing BuildRequires on pidgin-devel * Mon Jun 16 18:00:00 2008 Owen Taylor - 0.2.29-1 - Update to 0.2.29 openvrml-0.17.6-1.fc10 ---------------------- * Fri Jun 20 18:00:00 2008 Braden McDaniel - 0.17.6-1 - Updated to 0.17.6. - Build with -fvisibility=hidden -fvisibility-inlines-hidden phonon-4.2-0.2.beta2.fc10 ------------------------- * Fri Jun 20 18:00:00 2008 Rex Dieter 4.2-0.2.beta2 - phonon 4.2beta2 (aka 4.1.83) php-5.2.6-2.fc9 --------------- * Thu May 8 18:00:00 2008 Joe Orton 5.2.6-2 - update to 5.2.6 postgresql-8.3.3-2.fc10 ----------------------- * Fri Jun 20 18:00:00 2008 Tom Lane 8.3.3-2 - Install Pgtcl in /usr/lib/tcl$TCL_VERSION, not directly in /usr/lib. Needed because tcl 8.5 no longer puts /usr/lib into its package search path. NOTE: do not back-port this change into branches using pre-8.5 tcl, because /usr/lib/tcl8.4 had been a symlink to /usr/share/tcl8.4, and /usr/share is exactly where we must not put Pgtcl. Resolves: #228263 python-lxml-2.0.7-1.fc10 ------------------------ * Fri Jun 20 18:00:00 2008 Jeffrey C. Ollie - 2.0.7-1 - Update to 2.0.7 - Update download URL quota-3.16-2.fc10 ----------------- * Fri Jun 20 18:00:00 2008 Ondrej Vasik 3.16-2 - upstream fix of some typos, string formats + 4TB+ fix for repquota - some additional stripping removal - change default mode of binaries from 555 to 755 (strip error messages in build log) rubygem-krb5-auth-0.7-1.fc10 ---------------------------- * Fri Jun 20 18:00:00 2008 Chris Lalancette 0.7-1 - Convert from hand-coded makes to a proper Rakefile - Update to 0.7 sblim-wbemcli-1.5.1-7.fc10 -------------------------- * Fri Jun 20 18:00:00 2008 Tom "spot" Callaway 1.5.1-7 - fix gcc43 compile failure * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.5.1-6 - Autorebuild for GCC 4.3 seq24-0.8.7-12.fc10 ------------------- * Fri Jun 20 18:00:00 2008 Tom "spot" Callaway 0.8.7-12 - Fix license tag - Fix compile against libsigc++ 2.2 * Mon Mar 3 17:00:00 2008 Anthony Green 0.8.7-11 - Update gcc 4.3 patch. * Thu Feb 28 17:00:00 2008 Anthony Green 0.8.7-10 - Update for gcc 4.3. sugar-presence-service-0.81.2-1.fc10 ------------------------------------ * Fri Jun 20 18:00:00 2008 Morgan Collett - 0.81.2-1 - Update to 0.81.2 vips-7.14.4-1.fc10 ------------------ * Fri Jun 20 18:00:00 2008 Adam Goode - 7.14.4-1 - New release vsftpd-2.0.6-5.fc10 ------------------- * Fri Jun 20 18:00:00 2008 Dennis Gilmore - 2.0.6-5 - add sparc arches to -fPIE list xemacs-packages-extra-20070427-2.fc9 ------------------------------------ * Wed Jun 18 18:00:00 2008 Ville Skytt?? - 20070427-2 - Apply upstream security fix for CVE-2008-2142 (#446069). xmlto-0.0.21-1.fc10 ------------------- * Fri Jun 20 18:00:00 2008 Ondrej Vasik - 0.0.21-1 - new version 0.0.21 Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 60 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libisofs.so.5 brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 maniadrive-1.2-8.fc9.i386 requires libphp5-5.2.5.so maniadrive-track-editor-1.2-8.fc9.i386 requires libphp5-5.2.5.so muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 raydium-1.2-8.fc9.i386 requires libphp5-5.2.5.so scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.x86_64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) maniadrive-1.2-8.fc9.x86_64 requires libphp5-5.2.5.so()(64bit) maniadrive-track-editor-1.2-8.fc9.x86_64 requires libphp5-5.2.5.so()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 raydium-1.2-8.fc9.i386 requires libphp5-5.2.5.so raydium-1.2-8.fc9.x86_64 requires libphp5-5.2.5.so()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libisofs.so.5 brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) maniadrive-1.2-8.fc9.ppc requires libphp5-5.2.5.so maniadrive-track-editor-1.2-8.fc9.ppc requires libphp5-5.2.5.so muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 raydium-1.2-8.fc9.ppc requires libphp5-5.2.5.so raydium-1.2-8.fc9.ppc64 requires libphp5-5.2.5.so()(64bit) scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.ppc64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot maniadrive-1.2-8.fc9.ppc64 requires libphp5-5.2.5.so()(64bit) maniadrive-track-editor-1.2-8.fc9.ppc64 requires libphp5-5.2.5.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot raydium-1.2-8.fc9.ppc64 requires libphp5-5.2.5.so()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From jdieter at gmail.com Sat Jun 21 10:59:58 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 21 Jun 2008 13:59:58 +0300 Subject: Broken requirements in F9 Message-ID: <1214045998.4966.15.camel@jdlaptop> Just a heads up that I came across this set of broken requirements for updates with the new version of php that just came out in Fedora 9 updates: [root at jdlaptop Desktop]# yum update --> Finished Dependency Resolution maniadrive-1.2-8.fc9.i386 from installed has depsolving problems --> Missing Dependency: libphp5-5.2.5.so is needed by package maniadrive-1.2-8.fc9.i386 (installed) raydium-1.2-8.fc9.i386 from installed has depsolving problems --> Missing Dependency: libphp5-5.2.5.so is needed by package raydium-1.2-8.fc9.i386 (installed) Error: Missing Dependency: libphp5-5.2.5.so is needed by package raydium-1.2-8.fc9.i386 (installed) Error: Missing Dependency: libphp5-5.2.5.so is needed by package maniadrive-1.2-8.fc9.i386 (installed) This is from the presto test repository that was just synced up with mirrors.eu.kernel.org. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sat Jun 21 11:18:57 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 21 Jun 2008 13:18:57 +0200 Subject: Broken requirements in F9 In-Reply-To: <1214045998.4966.15.camel@jdlaptop> References: <1214045998.4966.15.camel@jdlaptop> Message-ID: <485CE3A1.1040806@hhs.nl> Jonathan Dieter wrote: > Just a heads up that I came across this set of broken requirements for > updates with the new version of php that just came out in Fedora 9 > updates: > [root at jdlaptop Desktop]# yum update > > --> Finished Dependency Resolution > maniadrive-1.2-8.fc9.i386 from installed has depsolving problems > --> Missing Dependency: libphp5-5.2.5.so is needed by package > maniadrive-1.2-8.fc9.i386 (installed) > raydium-1.2-8.fc9.i386 from installed has depsolving problems > --> Missing Dependency: libphp5-5.2.5.so is needed by package > raydium-1.2-8.fc9.i386 (installed) > Error: Missing Dependency: libphp5-5.2.5.so is needed by package > raydium-1.2-8.fc9.i386 (installed) > Error: Missing Dependency: libphp5-5.2.5.so is needed by package > maniadrive-1.2-8.fc9.i386 (installed) > Already reported in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=452327 And I'm on it (should be just a rebuild). Regards, Hans From loupgaroublond at gmail.com Sat Jun 21 11:20:45 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 21 Jun 2008 13:20:45 +0200 Subject: LSB Package API In-Reply-To: <1214041907.5778.39.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> Message-ID: <7f692fec0806210420o4a19aecal3b09329cf183f3d4@mail.gmail.com> On Sat, Jun 21, 2008 at 11:51 AM, Denis Washington wrote: > Hi, > > Some time ago, it was discussed on an LSB face-to-face meeting that an > API should be developed that allows ISVs to install sotware packages > which integrate into the package manager - the "Berlin Packaging API". > While the idea seemed to be well received, there didn't seem much > progress since then, except for a wiki page with a rundimentary proposal > [1]. Considering that third-party software installation is an undeniably > important weak spot of the Linux infrastructure, I found this was a > shame. > > To reignite the the initiative, I decided to design and develop a > prototype implementation of the Berlin API, most creatively named the > "LSB Package API". It is designed as a simple D-Bus interface > accompanied with an XML-based package description format. A detailed > description and the source code can be found on this page: > > http://www.linuxfoundation.org/en/LSB_Package_API > > The implementation currently supports integration into RPM and dpkg; due > to its modular nature, support for more package managers could be added > later on. > > I hope this implementation will act as a starting point for resurrecting > the Berlin API process. Let us overcome the "Third-party software > installation on Linux sucks" problem and strive to a brave new world of > easily distributable Linux software! ;) > > Best regards, > Denis Washington > > [1] http://www.linuxfoundation.org/en/Berlin_Packaging_API How is this different than PackageKit? PackageKit seems to cover the use case of presenting a comprehensive API and userspace tools to manage packages consistently across distros. What can the Berlin API do that PackageKit doesn't do, and doesn't make sense for PackageKit to do? -Yaakov From dwashington at gmx.net Sat Jun 21 11:40:44 2008 From: dwashington at gmx.net (Denis Washington) Date: Sat, 21 Jun 2008 13:40:44 +0200 Subject: LSB Package API In-Reply-To: <7f692fec0806210420o4a19aecal3b09329cf183f3d4@mail.gmail.com> References: <1214041907.5778.39.camel@dwashington> <7f692fec0806210420o4a19aecal3b09329cf183f3d4@mail.gmail.com> Message-ID: <1214048444.5778.60.camel@dwashington> On Sat, 2008-06-21 at 13:20 +0200, Yaakov Nemoy wrote: > How is this different than PackageKit? PackageKit seems to cover the > use case of presenting a comprehensive API and userspace tools to > manage packages consistently across distros. What can the Berlin API > do that PackageKit doesn't do, and doesn't make sense for PackageKit > to do? > > -Yaakov While the use cases of PackageKit are related to the Berlin API, they are pretty different. PackageKit is focused on providing a frontend for managing repository-based package systems, like apt and and yum. It is mainly thought to abstract installation and upgrades from package repositories, like when an application likes to install a package with a particular name from the distro's repos. However, it does not address the problem of software distribution itself - the repositories and package files are still specific to the packagaing system. The Berlin API, on the other side, does exlclusively deal with providing a package-manager-neutral software distribution method. So the Berlin API is not a replacement for PackageKit, but a complement. In fact, as the software installed with the Berlin API is added to the package system's database, it can be managed (e.g. uninstalled) with PackageKit afterwards - a dream team! ;) Regards, Denis Washington From kagesenshi.87 at gmail.com Sat Jun 21 12:16:00 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Sat, 21 Jun 2008 20:16:00 +0800 Subject: Firewall and user services that needs open ports Message-ID: I needed to print through a network printer a few days ago. But it doesn't just work. Seems like the firewall need to be stopped and cups-config-daemon need to be started (not sure bout the latter, coz i simply start all cups related services). This raises a question, as Fedora turns on firewall by default, what's the plan for certain user services that requires firewall to be turned off (cups, gnome file sharing) ?? Something like PolicyKit but for firewall??. Ubuntu took the easy way of simply disabling firewall, and I doubt Fedora will follow that path. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From nicolas.mailhot at laposte.net Sat Jun 21 12:57:57 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 Jun 2008 14:57:57 +0200 Subject: LSB Package API In-Reply-To: <7f692fec0806210420o4a19aecal3b09329cf183f3d4@mail.gmail.com> References: <1214041907.5778.39.camel@dwashington> <7f692fec0806210420o4a19aecal3b09329cf183f3d4@mail.gmail.com> Message-ID: <1214053077.3691.4.camel@rousalka.okg> Le samedi 21 juin 2008 ? 13:20 +0200, Yaakov Nemoy a ?crit : > How is this different than PackageKit? It would make possible for ISVs to create packages in a non-native packaging format, so they don't have to care about the format each distro uses, or about understanding each distro dependency checks, or generally speaking wasting time and money on integration and QA. Of course that's supposing you can actually do good packaging in non-native formats and the distros won't be left to collect the pieces afterwards. -- 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 dank at kegel.com Sat Jun 21 13:59:50 2008 From: dank at kegel.com (Dan Kegel) Date: Sat, 21 Jun 2008 06:59:50 -0700 Subject: [packaging] LSB Package API In-Reply-To: <1214037152.5778.32.camel@dwashington> References: <1214037152.5778.32.camel@dwashington> Message-ID: On Sat, Jun 21, 2008 at 1:32 AM, Denis Washington wrote: > Some time ago, it was discussed on an LSB face-to-face meeting that an > API should be developed that allows ISVs to install sotware packages > which integrate into the package manager - the "Berlin Packaging API". > While the idea seemed to be well received, there didn't seem much > progress since then I dislike that route intensely. Why, I'm not sure. Perhaps because it encourages ISVs to manage package updates themselves, perhaps because it smacks of the complexity of Microsoft's MSI. I'm more interested in the single-click install idea Suse's working on, since it's much less of an end run around normal Linux packaging practices. And I have a summer intern to throw at the problem, so perhaps I'll make some headway on it. Can we move followups to packaging at lists.linux-foundation.org rather than cc'ing all those lists? - Dan From dwashington at gmx.net Sat Jun 21 14:18:31 2008 From: dwashington at gmx.net (Denis Washington) Date: Sat, 21 Jun 2008 16:18:31 +0200 Subject: [packaging] LSB Package API In-Reply-To: References: <1214037152.5778.32.camel@dwashington> Message-ID: <1214057911.5778.73.camel@dwashington> On Sat, 2008-06-21 at 06:59 -0700, Dan Kegel wrote: > On Sat, Jun 21, 2008 at 1:32 AM, Denis Washington wrote: > > Some time ago, it was discussed on an LSB face-to-face meeting that an > > API should be developed that allows ISVs to install sotware packages > > which integrate into the package manager - the "Berlin Packaging API". > > While the idea seemed to be well received, there didn't seem much > > progress since then > > I dislike that route intensely. Why, I'm not sure. Perhaps > because it encourages ISVs to manage package updates themselves, > perhaps because it smacks of the complexity of Microsoft's MSI. > > I'm more interested in the single-click install idea Suse's > working on, since it's much less of an end run around > normal Linux packaging practices. And I have a summer intern > to throw at the problem, so perhaps I'll make some headway on > it. The problem I currently see with single-click install is that it still relies on a single package format (.rpm), so there would have to be several packages of the same application again. Another particular problem I see is security: RPM runs as root, so post-install routines will do so too. That's why I tried to do an architecture that works without root privileges (in many cases at least). But maybe there are are already plans how to address this? I must admit I'm not all that well-informed about SuSE's one-click install. > Can we move followups to packaging at lists.linux-foundation.org rather > than cc'ing all those lists? OK. I wanted to get as many parties as possible on board, but now let's say: whoever likes to follow this discussion is encouraged to to join packaging at lists.linux-foundation.org [1]. Follow-ups should only be sent there. Regards, Denis [1] https://lists.linux-foundation.org/mailman/listinfo/packaging From jroth at linux.vnet.ibm.com Sat Jun 21 14:21:40 2008 From: jroth at linux.vnet.ibm.com (Jochen Roth) Date: Sat, 21 Jun 2008 16:21:40 +0200 Subject: Cross toolchain support for SPUs on Cell / ppc64 In-Reply-To: <1214022113.3615.36.camel@beck.corsepiu.local> References: <485BFD17.9090503@linux.vnet.ibm.com> <1214022113.3615.36.camel@beck.corsepiu.local> Message-ID: <485D0E74.3080907@linux.vnet.ibm.com> Ralf Corsepius wrote: >> Our suggestion would be to build spu-binutils from the same source as >> the system gcc for ppc is build. > Theoretically, this would be one possibility, however, practice tells > this doesn't work, because there always will be situations when you will > want to patch/apply hacks to your cross-binutils, or when > target-specific bugs force your cross-binutils to use a different > version of binutils than of the native binutils. Yes, we need a separate spu-binutils package for the assembly anyway. And then we can build the spu-binutils from the same source tree as the systems binutils package. And of course add some patches for target specific bugs if needed. I think this is also the way avr-binutils does. The systems binutils package has to be compiled with at least the option --enable-target=spu or even better with --enable-target=all What is the right directory where SPU include files should go? I just looked into avr-libc and they put everything in /usr/avr/ .. So would it be correct to put spu related files in /usr/spu/ and subdirectories? >> For spu-newlib we'd have to create a separate package as we'd have for >> spu-gdb. > This is one option, but it raises problems with bootstrapping GCC. > > The alternative is building newlib+gcc one-tree-style (building newlib > and gcc at the same time). It's what I do for my cross-toolchains. Yes, right, that is another thing we have to care about. Btw, is there any Fedora cross-toolchain guide I should be aware of? Thanks! -- Jochen From kanarip at kanarip.com Sat Jun 21 19:34:37 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 21 Jun 2008 15:34:37 -0400 Subject: Firewall and user services that needs open ports In-Reply-To: References: Message-ID: <485D57CD.5010802@kanarip.com> Izhar Firdaus wrote: > I needed to print through a network printer a few days ago. But it > doesn't just work. Seems like the firewall need to be stopped and > cups-config-daemon need to be started (not sure bout the latter, coz i > simply start all cups related services). > > This raises a question, as Fedora turns on firewall by default, what's > the plan for certain user services that requires firewall to be turned > off (cups, gnome file sharing) ?? Something like PolicyKit but for > firewall??. Ubuntu took the easy way of simply disabling firewall, and > I doubt Fedora will follow that path. > This has been a discussion on some list some time ago... If memory serves me well it was not becoming the default. I think the only move forward to make is to; 1) invent a system that will do this kind of thing 2) do the work and test-case / show-case the system 3) make it available to users that would otherwise just shut down the firewall entirely -Jeroen From caillon at redhat.com Sat Jun 21 19:56:20 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 21 Jun 2008 15:56:20 -0400 Subject: xulrunner and silent breakage of downstream apps In-Reply-To: <5256d0b0806200412i67263f0en8a911cf0eec3caf3@mail.gmail.com> References: <485B536F.7050503@gmail.com> <5256d0b0806200412i67263f0en8a911cf0eec3caf3@mail.gmail.com> Message-ID: <485D5CE4.7070602@redhat.com> Peter Robinson wrote: > On Fri, Jun 20, 2008 at 7:51 AM, Michel Salim wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> The recent push of xulrunner-1.9 and Firefox 3 broke Miro and devhelp >> (https://admin.fedoraproject.org/updates/F9/pending/devhelp-0.19.1-2.fc9) >> again. >> >> Is there a way to declare these kinds of dependencies that we are not >> using right now? Should Miro and devhelp specifically require xulrunner >> = %{version}-%{release} -- or perhaps a more administrative solution; >> block a non-security release of xulrunner for at least one day and >> automatically notify the maintainers of its dependents? > > xulrunner was suppose to stop this from happening with a stable api. XULRunner provides both a stable and unstable API. Things aren't going to magically be fixed until the applications actually start *using* the stable API. From hedayat at grad.com Sat Jun 21 22:09:59 2008 From: hedayat at grad.com (Hedayat Vatnakhah) Date: Sun, 22 Jun 2008 02:39:59 +0430 Subject: rpmlint warnings In-Reply-To: <200806211106.08623.ville.skytta@iki.fi> References: <485AEFD6.7030701@grad.com> <485BE4CC.6050202@grad.com> <20080620213424.GA2614@free.fr> <200806211106.08623.ville.skytta@iki.fi> Message-ID: <485D7C37.6070106@grad.com> Thank you all. So, my package is fine :) and I should fill a bug report for rpmlint. Good luck, Hedayat /*?*/ wrote on 06/21/2008 12:36:08 PM: > On Saturday 21 June 2008, Patrice Dumas wrote: > >> On Fri, Jun 20, 2008 at 09:41:40PM +0430, Hedayat Vatnakhah wrote: >> >>> Hi, >>> Yes it does. >>> >> You can ignore the warning then. If you run rpmlint against the >> installed rpm it shouldn't complain. >> > > Yep, this is a rpmlint bug. It has code in place to skip all dangling symlink > checks for *.so (no matter what the package dependencies are), but that code > currently matches only *.so placed directly in */lib and */lib64 dirs. > > Improved upstream: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1434 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From casimiro.barreto at gmail.com Sun Jun 22 06:41:04 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sun, 22 Jun 2008 03:41:04 -0300 Subject: Off Topic: where I can see how I translate old gdm conf files to new ones? Message-ID: <485DF400.2030102@gmail.com> Hello, After upgrading to Fedora Rel 9 I've had trouble to drop the -nolisten in the Xserver (old defaults.conf is not working anymore) and I need to set the command=/usr/bin/X ... Gdm was shipped without proper documentation (no man pages, nothing for the missing gdmsetup and other programs... Best regards and sorry for the inconvenience... Casimiro Barreto -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sun Jun 22 10:22:12 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 22 Jun 2008 10:22:12 +0000 (UTC) Subject: rawhide report: 20080622 changes Message-ID: <20080622102212.6106D209D21@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080621/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080622/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package mediawiki-SpecialInterwiki An extension to provide an interwiki management system New package mfiler3 Two pane file manager under UNIX console Updated Packages: apachetop-0.12.6-5.fc10 ----------------------- * Sat Jun 21 18:00:00 2008 Robert Scheck 0.12.6-5 - Fixed a buffer overflow by wrong MAXPATHLEN define (#446199) cairo-dock-1.6.0.2-1.date20080621.fc10 -------------------------------------- dhcp-4.0.0-16.fc10 ------------------ * Sat Jun 21 18:00:00 2008 David Cantrell - 12:4.0.0-16 - Remove instaces of \032 in domain search option (#450042) - Make 'service dhcpd configtest' display text indicating the status dovecot-1.1.0-1.fc10 -------------------- * Sat Jun 21 18:00:00 2008 Dan Horak - 1:1.1.0-1 - update to upstream version 1.1.0 - update sieve plugin to 1.1.5 - remove unnecessary patches - enable ldap and gssapi plugins - change ownership of dovecot.conf (Resolves: #452088) elinks-0.11.4-1.fc10 -------------------- * Sat Jun 21 18:00:00 2008 Ondrej Vasik 0.11.4-1 - new stable upstream release gnome-applet-music-2.4.0-1.fc10 ------------------------------- * Wed Jun 18 18:00:00 2008 Peter Gordon - 2.4.0-1 - Update to new upstream release (2.4.0), which adds Banshee 1.0 support, and an updated Czech (cs) translation. horde-3.2.1-1.fc10 ------------------ * Sun Jun 22 18:00:00 2008 Nigel Jones - 3.2.1-1 - New Upstream (3.2.1) - Security Updates mainly * Wed May 28 18:00:00 2008 Nigel Jones - 3.2-1 - New Upstream (3.2) & Spec file cleanups imp-4.2-1.fc10 -------------- * Wed May 28 18:00:00 2008 Nigel Jones - 4.2-1 - New Upstream (4.2) & Spec file cleanups ingo-1.2-1.fc10 --------------- * Wed May 28 18:00:00 2008 Nigel Jones - 1.2-1 - New Upstream (1.2) & Spec file cleanups kdebindings-4.0.83-4.fc10 ------------------------- * Sat Jun 21 18:00:00 2008 Kevin Kofler 4.0.83-4 - fix PyKDE4-devel to require PyKDE4 rather than itself * Sat Jun 21 18:00:00 2008 Kevin Kofler 4.0.83-3 - reenable Ruby again - add missing Epoch for minimum kdegraphics-devel version requirement - fix CMake target name conflict between Ruby and Python bindings - fix file list for Ruby kdesdk-4.0.83-2.fc10 -------------------- * Sat Jun 21 18:00:00 2008 Kevin Kofler 4.0.83-2 - drop upstreamed rh#433399 patch * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdeutils-4.0.83-2.fc10 ---------------------- * Sat Jun 21 18:00:00 2008 Kevin Kofler 4.0.83-2 - add explicit dep on rhpl to work around missing dep in system-config-printer * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kile-2.0.1-2.fc10 ----------------- * Sun Jun 22 18:00:00 2008 Kevin Kofler 2.0.1-2 - also change QuickPreview to use xdg-open (#445934 reloaded) kismet-0.0.2008.05.R1-2.fc10 ---------------------------- * Sat Jun 21 18:00:00 2008 Enrico Scholz - 0.0.2008.05.R1-2 - applied forgotten patch - honor $NO_TMPWATCH instead of $NO_LOGROTATE in the tmpwatch script (#427262) * Sat Jun 21 18:00:00 2008 Enrico Scholz - 0.0.2008.05.R1-1 - updated to 2008-05-R1 - removed some patches and added new ones libextractor-0.5.20b-1.fc10 --------------------------- * Sat Jun 21 18:00:00 2008 Enrico Scholz - 0.5.20b-1 - updated to 0.5.20b (SECURITY); fixes CVE-2008-1693 (xpdf embedded font vulnerability) - build with -Wl,-as-needed - fixed rpath issues libpar2-0.2-6.fc10 ------------------ * Sat Jun 21 18:00:00 2008 Adel Gadllah 0.2-6 - Add missing requires to devel package (RH #452363) maniadrive-1.2-9.fc10 --------------------- * Sat Jun 21 18:00:00 2008 Hans de Goede 1.2-9 - Rebuild for new php version milter-greylist-4.1.1-1.fc10 ---------------------------- * Sat Jun 21 18:00:00 2008 Enrico Scholz - 4.1.1-1 - updated to 4.1.1 perl-Config-General-2.40-1.fc10 ------------------------------- * Sat Jun 21 18:00:00 2008 Ville Skytt?? - 2.40-1 - 2.40. plymouth-0.4.0-1.fc10 --------------------- * Sun Jun 22 18:00:00 2008 Ray Strode - 0.4.0-1 - Update to version 0.4.0 - Only run if rhgb is on kernel command line - Make text plugin more animated python-setuptools-0.6c8-1.fc10 ------------------------------ * Sat Jun 21 18:00:00 2008 Konstantin Ryabitsev - 0.6c8-1 - Update to 0.6c8 - Accept small tweaks from Gareth Armstrong swarp-2.17.1-2.fc10 ------------------- * Sat Jun 21 18:00:00 2008 Sergio Pascual 2.17.1-2 - Spec cleanup turba-2.2.1-1.fc10 ------------------ * Sun Jun 22 18:00:00 2008 Nigel Jones - 2.2.1-1 - New Upstream (2.2.1) - Mainly security related changes * Wed May 28 18:00:00 2008 Nigel Jones - 2.2-1 - New Upstream (2.2) & Spec file cleanups xmlrpc-c-1.14.8-1.fc10 ---------------------- * Sat Jun 21 18:00:00 2008 Enrico Scholz - 1.14.8-1 - updated to 1.14.8 Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 24 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libisofs.so.5 brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.x86_64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libisofs.so.5 brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.ppc64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From a.badger at gmail.com Sun Jun 22 10:42:38 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Jun 2008 06:42:38 -0400 Subject: Toshio is vacationing Message-ID: <485E2C9E.9050101@gmail.com> Hi all, I'll be vacationing from tomorrow to the 1st of July (be back in California July 2nd.) My packages should all have open acls so feel free to fix and I've added myself to https://fedoraproject.org/wiki/Vacation There's some changes in the packagedb that are very nice but I don't want to push them while I'm on vacation as I've noticed some slowness on certain queries. :-( If someone else wants to do so, I'm totally fine with it as long as you have the old packages available to rollback in case we start getting timeouts. python-fedora-devel has been updated to a new version. But there's a few very strange things happening in the new jsonfas interface. I've clued lmacken in on that so if he has time to work on it we could end up pushing the new stuff to some test servers. Otherwise it will probably wait until after I get back in July. I'll stop by on IRC once in a while but I'm going to make a conscious effort not to check my email ;-) See you all in July! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Sun Jun 22 11:07:04 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jun 2008 14:07:04 +0300 Subject: rpmlint warnings In-Reply-To: <485D7C37.6070106@grad.com> References: <485AEFD6.7030701@grad.com> <200806211106.08623.ville.skytta@iki.fi> <485D7C37.6070106@grad.com> Message-ID: <200806221407.05349.ville.skytta@iki.fi> On Sunday 22 June 2008, Hedayat Vatnakhah wrote: > Thank you all. So, my package is fine :) and I should fill a bug report > for rpmlint. No need to do that because as I said, it's already fixed upstream and will be in the next release: > > Improved upstream: > > http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1434 From hughsient at gmail.com Sun Jun 22 12:45:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 22 Jun 2008 13:45:36 +0100 Subject: [packaging] LSB Package API In-Reply-To: <1214057911.5778.73.camel@dwashington> References: <1214037152.5778.32.camel@dwashington> <1214057911.5778.73.camel@dwashington> Message-ID: <1214138736.3377.3.camel@hughsie-work> On Sat, 2008-06-21 at 16:18 +0200, Denis Washington wrote: > The problem I currently see with single-click install is that it still > relies on a single package format (.rpm), so there would have to be > several packages of the same application again. Another particular > problem I see is security: RPM runs as root, so post-install routines > will do so too. That's why I tried to do an architecture that works > without root privileges (in many cases at least). But maybe there are > are already plans how to address this? I must admit I'm not all that > well-informed about SuSE's one-click install. We've discussed this in detail on the PackageKit mailing list. > > Can we move followups to packaging at lists.linux-foundation.org rather > > than cc'ing all those lists? > > OK. I wanted to get as many parties as possible on board, but now > let's say: whoever likes to follow this discussion is encouraged to to > join packaging at lists.linux-foundation.org [1]. Follow-ups should only > be sent there. Sure, you probably want to see the FAQ and mailing lists archives for PackageKit too. There's a real reason PackageKit doesn't support OCI, and another reason it supports catalog instead. Richard. From hughsient at gmail.com Sun Jun 22 13:15:18 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 22 Jun 2008 14:15:18 +0100 Subject: LSB Package API In-Reply-To: <1214041907.5778.39.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> Message-ID: <1214140518.3377.31.camel@hughsie-work> On Sat, 2008-06-21 at 11:51 +0200, Denis Washington wrote: > Some time ago, it was discussed on an LSB face-to-face meeting that an > API should be developed that allows ISVs to install sotware packages > which integrate into the package manager - the "Berlin Packaging API". > While the idea seemed to be well received, there didn't seem much > progress since then, except for a wiki page with a rundimentary proposal > [1]. Considering that third-party software installation is an undeniably > important weak spot of the Linux infrastructure, I found this was a > shame. ?Sure, it's been tried before a few times before and fallen on it's face each time. There's a reason that PackageKit uses the distro supplied packages, rather than trying to spin it's own thing. > To reignite the the initiative, I decided to design and develop a > prototype implementation of the Berlin API, most creatively named the > "LSB Package API". It is designed as a simple D-Bus interface > accompanied with an XML-based package description format. A detailed > description and the source code can be found on this page: > > http://www.linuxfoundation.org/en/LSB_Package_API Sounds quite like PackageKit, which has been developed for the last year or so with buy-in from most of the big distros. PackageKit doesn't try to replace the entire stack, only make some sort of abstraction for GUI tools where such an abstraction makes sense. Being blunt, no distro is going to support a LSB package API. To me, a distro is basically: community+trust+infrastructure If you take away the trust (letting other people create and sign packages), the infrastructure (letting other people host packages and manage security errata) and the community (basically reduced to PR) you've got nothing left. The cost of a distro rolling it's own packages is trivial considering the advantages of the vendor trust model, with a single infrastructure and support. > The implementation currently supports integration into RPM and dpkg; due > to its modular nature, support for more package managers could be added > later on. Looks like you've not considered localisation, multi-lib, multiple versions of packages, or any of the problems solved with solutions like NEVRAs. I would suggest to read the rpm(+yum), dpkg and conary sources before you even start to propose APIs. > I hope this implementation will act as a starting point for resurrecting > the Berlin API process. Let us overcome the "Third-party software > installation on Linux sucks" problem and strive to a brave new world of > easily distributable Linux software! ;) I think you are looking for a solution to a problem that doesn't exist. For the corner cases of where this does apply (proprietary software) this is not enough of a use case to justify all the work required. ?From somebody that's spent the best part of a year researching the packaging formats and distribution of metadata, I don't see such a LSB package API as a viable project. Richard Hughes (PackageKit maintainer) From skvidal at fedoraproject.org Sun Jun 22 15:41:35 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 22 Jun 2008 11:41:35 -0400 Subject: Seth is Vacationing In-Reply-To: <485E2C9E.9050101@gmail.com> References: <485E2C9E.9050101@gmail.com> Message-ID: <1214149295.8545.4.camel@rosebud> On Sun, 2008-06-22 at 06:42 -0400, Toshio Kuratomi wrote: > Hi all, me too. But I'll be back on June 30th. I should have network access where I am but I intend to not use it :) There are a number of folks who have my cell if it is an emergency but I doubt it will be :) -sv From ricky at fedoraproject.org Sun Jun 22 16:42:24 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 22 Jun 2008 12:42:24 -0400 Subject: Ricky will be Vacationing In-Reply-To: <1214149295.8545.4.camel@rosebud> References: <485E2C9E.9050101@gmail.com> <1214149295.8545.4.camel@rosebud> Message-ID: <20080622164224.GG3910@Max> On 2008-06-22 11:41:35 AM, seth vidal wrote: > me too. But I'll be back on June 30th. I should have network access > where I am but I intend to not use it :) I guess now's a good time to mention that I'll be gone from 2008-06-28 until 2008-07-05 (with no internet access). Have fun, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From michel.sylvan at gmail.com Sun Jun 22 17:13:06 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 22 Jun 2008 13:13:06 -0400 Subject: %configure assuming in-source-tree builds Message-ID: <485E8822.1020000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Some upstream developers recommend that their software (thinking of LLVM and PLT Scheme, but there must be others) *not* be configured and built at the top-level source directory (typically recommending using build/, object/ or some such). When this is needed, currently the Fedora packager has to revert to calling the configure script directly, foregoing the %configure macro, and copying as much of the configure settings by hand. Would it be a desirable feature to, say, be able to declare %define configure_relative_path .. and then have %configure use the value of that instead of './' when calling the actual configure script? Thanks, - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkheiA4ACgkQWt0J3fd+7ZDb1QCeLjtxpBimjo0YS20SIHqorgJF WFcAoIkX+dkp+8EbwZ5RzFyr7sLxHCbq =zuT3 -----END PGP SIGNATURE----- From bpepple at fedoraproject.org Sun Jun 22 17:13:26 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 22 Jun 2008 13:13:26 -0400 Subject: Brian is Vacationing In-Reply-To: <1214149295.8545.4.camel@rosebud> References: <485E2C9E.9050101@gmail.com> <1214149295.8545.4.camel@rosebud> Message-ID: <1214154806.2540.2.camel@truman> On Sun, 2008-06-22 at 11:41 -0400, seth vidal wrote: > On Sun, 2008-06-22 at 06:42 -0400, Toshio Kuratomi wrote: > > Hi all, > > me too. But I'll be back on June 30th. I should have network access > where I am but I intend to not use it :) Guess I'll add my me too, also. I'll be back on July 2nd, but I should have internet access for most of my time in Sacramento so I'll be periodically checking my e-mail. 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: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Sun Jun 22 17:42:19 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 22 Jun 2008 19:42:19 +0200 Subject: %configure assuming in-source-tree builds In-Reply-To: <485E8822.1020000@gmail.com> References: <485E8822.1020000@gmail.com> Message-ID: <20080622194219.dc50e1bf.mschwendt@gmail.com> On Sun, 22 Jun 2008 13:13:06 -0400, Michel Salim wrote: > Hi all, > > Some upstream developers recommend that their software (thinking of LLVM > and PLT Scheme, but there must be others) *not* be configured and built > at the top-level source directory (typically recommending using build/, > object/ or some such). > > When this is needed, currently the Fedora packager has to revert to > calling the configure script directly, foregoing the %configure macro, > and copying as much of the configure settings by hand. Would it be a > desirable feature to, say, be able to declare > > %define configure_relative_path .. > > and then have %configure use the value of that instead of './' when > calling the actual configure script? Try this in your spec (substitute SOMEPATH appropriately): %global configure %(rpm --eval %%configure|sed -e 's!./configure!SOMEPATH/configure!') -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.22 1.27 1.17 From aoliva at redhat.com Sun Jun 22 17:44:52 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 22 Jun 2008 14:44:52 -0300 Subject: Fedora Freedom and linux-libre In-Reply-To: <485B553E.3040209@gmail.com> (Les Mikesell's message of "Fri\, 20 Jun 2008 01\:59\:10 -0500") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.c! om> <200806191725.m5JHOxf4022576@laptop13.inf.utfsm.cl> <485AA5A7.7010900@gmail.com> <485B553E.3040209@gmail.com> Message-ID: On Jun 20, 2008, Les Mikesell wrote: > You specifically have the right, in the US, at least, to make > changes that are "an essential step in the utilization of the > computer program". Indeed, there are such things as fair use and exceptions to copyright. We've already covered this. > Which turns out to include adding improvements you need. > http://www.techlawjournal.com/topstories/2005/20051107.asp That's quite interesting. It's a far cry from the Free Software Definition's freedom #1, but no doubt this is another positive step from US courts. > And the court noted that no damage was done to the copyright holder by > someone else modifying their own copy of a work. ... because the copy was only for internal use. Quite unrelated with the original points of this debate, that's all about distribution. But no doubt it's a good thing. This is a reasoning that finds support in the original rationale for copyrights, but the fact that they have to resort to contortions such as thinking of "damage" shows how far behind the original rationale was left :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From dwashington at gmx.net Sun Jun 22 18:02:50 2008 From: dwashington at gmx.net (Denis Washington) Date: Sun, 22 Jun 2008 20:02:50 +0200 Subject: LSB Package API In-Reply-To: <1214140518.3377.31.camel@hughsie-work> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> Message-ID: <1214157770.5783.25.camel@dwashington> On Sun, 2008-06-22 at 14:15 +0100, Richard Hughes wrote: > On Sat, 2008-06-21 at 11:51 +0200, Denis Washington wrote: > > Some time ago, it was discussed on an LSB face-to-face meeting that an > > API should be developed that allows ISVs to install sotware packages > > which integrate into the package manager - the "Berlin Packaging API". > > While the idea seemed to be well received, there didn't seem much > > progress since then, except for a wiki page with a rundimentary proposal > > [1]. Considering that third-party software installation is an undeniably > > important weak spot of the Linux infrastructure, I found this was a > > shame. > > ?Sure, it's been tried before a few times before and fallen on it's face > each time. There's a reason that PackageKit uses the distro supplied > packages, rather than trying to spin it's own thing. We shouldn't resignate just because nothing came out of the previous attempts. Also, the LSB Package API is designed to require as little adjustments as possible to installers - it's just to calls and a single file, after all. > > To reignite the the initiative, I decided to design and develop a > > prototype implementation of the Berlin API, most creatively named the > > "LSB Package API". It is designed as a simple D-Bus interface > > accompanied with an XML-based package description format. A detailed > > description and the source code can be found on this page: > > > > http://www.linuxfoundation.org/en/LSB_Package_API > > Sounds quite like PackageKit, which has been developed for the last year > or so with buy-in from most of the big distros. PackageKit doesn't try > to replace the entire stack, only make some sort of abstraction for GUI > tools where such an abstraction makes sense. > As already mentioned before in this thread, the focus of PackageKit and the LSB Package API are quite different, so there is no big reason for them to not exist side-by-side. > Being blunt, no distro is going to support a LSB package API. To me, a > distro is basically: > > community+trust+infrastructure > > If you take away the trust (letting other people create and sign > packages), the infrastructure (letting other people host packages and > manage security errata) and the community (basically reduced to PR) > you've got nothing left. > > The cost of a distro rolling it's own packages is trivial considering > the advantages of the vendor trust model, with a single infrastructure > and support. The distro model is nice (and arguably better than the LSB Package API) if the packages you like to have are in the repos in sufficiently new versions. But if you need to go past that (bleeding edge versions, not widely spread apps), things get more difficult currently. Especially propietary applications just cannot be distributed by the distros directly. > > The implementation currently supports integration into RPM and dpkg; due > > to its modular nature, support for more package managers could be added > > later on. > > Looks like you've not considered localisation, multi-lib, multiple > versions of packages, or any of the problems solved with solutions like > NEVRAs. I would suggest to read the rpm(+yum), dpkg and conary sources > before you even start to propose APIs. Naturally some things are not considered yet. That's why I called the spec and implementation I released a "starting point", not the completely finished thing ready for production. There are quite a few points that will have to be thought through and added, but I don't think it's impossible to do so on top of the current basic design. > > I hope this implementation will act as a starting point for resurrecting > > the Berlin API process. Let us overcome the "Third-party software > > installation on Linux sucks" problem and strive to a brave new world of > > easily distributable Linux software! ;) > > I think you are looking for a solution to a problem that doesn't exist. > For the corner cases of where this does apply (proprietary software) > this is not enough of a use case to justify all the work required. I don't think this is a corner case at all. For one thing, propietary applications might just don't play a role _because_ there is no really good distribution method for them - the typical chicken-and-egg problem. (I'm not saying this is the only reason, but an important one.) We're just not giving them an easy method of cross-distro integration. I think providing this is important. Second, this way of distribution will help open-source projects as well. It would make it really easy for them to distribute bleeding-edge versions of there apps that integrate well into the packaging system without having to package for each and every package manager. It will also help those projects which are not widely used enough to be in distro repos, as they can more easily release binary distributions without having to depend on getting packaged by the distros. I really believe this decentralism would be very nice to have, especially in something as naturally decentralized as the open source community. Regards, Denis From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 22 18:26:04 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 23 Jun 2008 03:26:04 +0900 Subject: %configure assuming in-source-tree builds In-Reply-To: <485E8822.1020000@gmail.com> References: <485E8822.1020000@gmail.com> Message-ID: <485E993C.2010503@ioa.s.u-tokyo.ac.jp> Michel Salim wrote, at 06/23/2008 02:13 AM +9:00: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > Some upstream developers recommend that their software (thinking of LLVM > and PLT Scheme, but there must be others) *not* be configured and built > at the top-level source directory (typically recommending using build/, > object/ or some such). > > When this is needed, currently the Fedora packager has to revert to > calling the configure script directly, foregoing the %configure macro, > and copying as much of the configure settings by hand. Would it be a > desirable feature to, say, be able to declare > > %define configure_relative_path .. > > and then have %configure use the value of that instead of './' when > calling the actual configure script? > > Thanks, xscreensaver uses: %build archdir=`./config.guess` mkdir $archdir cd $archdir ..... ln -s ../configure . %configure $CONFIG_OPTS rm -f configure make %{?_smp_mflags} Regards, Mamoru From lordmorgul at gmail.com Sun Jun 22 19:06:44 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 22 Jun 2008 12:06:44 -0700 Subject: Firewall and user services that needs open ports In-Reply-To: References: Message-ID: <485EA2C4.3070802@gmail.com> Izhar Firdaus wrote: > I needed to print through a network printer a few days ago. But it > doesn't just work. Seems like the firewall need to be stopped and > cups-config-daemon need to be started (not sure bout the latter, coz i > simply start all cups related services). > > This raises a question, as Fedora turns on firewall by default, what's > the plan for certain user services that requires firewall to be turned > off (cups, gnome file sharing) ?? Something like PolicyKit but for > firewall??. Ubuntu took the easy way of simply disabling firewall, and > I doubt Fedora will follow that path. There is no service which requires a firewall to be turned off... that does not exist. What they require is configuration to function with the firewall on. Improvement of the firewall configuration tool would certainly be a good step forward, and perhaps more automated configuration via upnp, but turning it off is definitely the wrong move... no matter what service you're trying to get through it. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From mmcgrath at redhat.com Sun Jun 22 19:30:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 22 Jun 2008 14:30:41 -0500 (CDT) Subject: Mike is not Vacationing In-Reply-To: <1214154806.2540.2.camel@truman> References: <485E2C9E.9050101@gmail.com> <1214149295.8545.4.camel@rosebud> <1214154806.2540.2.camel@truman> Message-ID: :) From lemenkov at gmail.com Sun Jun 22 19:35:09 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 22 Jun 2008 23:35:09 +0400 Subject: Mike is not Vacationing In-Reply-To: References: <485E2C9E.9050101@gmail.com> <1214149295.8545.4.camel@rosebud> <1214154806.2540.2.camel@truman> Message-ID: Me too! Let's burn the house while all parents are out! :) 2008/6/22 Mike McGrath : > :) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- With best regards! From jspaleta at gmail.com Sun Jun 22 19:41:17 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 22 Jun 2008 11:41:17 -0800 Subject: LSB Package API In-Reply-To: <1214157770.5783.25.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> Message-ID: <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> On Sun, Jun 22, 2008 at 10:02 AM, Denis Washington wrote: > I don't think this is a corner case at all. For one thing, propietary > applications might just don't play a role _because_ there is no really > good distribution method for them - the typical chicken-and-egg problem. I do not want to make proprietary applications easy to install. My involvement in Fedora is predicated on the idea that everything I do as part of my involvement with this project makes it easier for people to stop using proprietary applications. I would strongly suggest that you don't stand up proprietary applications as your primary argument or use case for the technology. If you want this considered seriously by this community. Stand up a usage case which benefits open source software and wok through that usage case. > Second, this way of distribution will help open-source projects as well. > It would make it really easy for them to distribute bleeding-edge > versions of there apps that integrate well into the packaging system > without having to package for each and every package manager. If its that bleeding edge, should it tie in to the packaging system, potentially causing problems for the distribution dependency resolution? Or should it be more like autopackage built as a secondary system? Aren't you just re-inventing a new implementation for the problem that autopackage has been attempting to solve for years now? In fact I think you should go back and look at autopackage and make a compare and contrast between the APIs. I know why I don't like autopackage. it would be useful to know if I'm going to dislike your API for the same reasons. -jef From dank at kegel.com Sun Jun 22 20:34:31 2008 From: dank at kegel.com (Dan Kegel) Date: Sun, 22 Jun 2008 13:34:31 -0700 Subject: [packaging] LSB Package API In-Reply-To: <1214157770.5783.25.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> Message-ID: On Sun, Jun 22, 2008 at 11:02 AM, Denis Washington wrote: > I don't think this is a corner case at all. For one thing, propietary > applications might just don't play a role _because_ there is no really > good distribution method for them - the typical chicken-and-egg problem. > (I'm not saying this is the only reason, but an important one.) We're > just not giving them an easy method of cross-distro integration. I think > providing this is important. Sure, and that's why I support the LSB. Has everybody else given up on it? - Dan From cra at WPI.EDU Sun Jun 22 20:53:10 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 22 Jun 2008 16:53:10 -0400 Subject: Firewall and user services that needs open ports In-Reply-To: <485EA2C4.3070802@gmail.com> References: <485EA2C4.3070802@gmail.com> Message-ID: <20080622205310.GA1065@angus.ind.WPI.EDU> On Sun, Jun 22, 2008 at 12:06:44PM -0700, Andrew Farris wrote: > Izhar Firdaus wrote: > There is no service which requires a firewall to be turned off... that does > not exist. What they require is configuration to function with the > firewall on. Improvement of the firewall configuration tool would certainly > be a good step forward, and perhaps more automated configuration via upnp, > but turning it off is definitely the wrong move... no matter what service > you're trying to get through it. Why do we need a firewall when you can easily prevent services from being accessed...just stop the service! Don't bind to the port, and it won't be possible to connect to it. From hughsient at gmail.com Sun Jun 22 21:00:23 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 22 Jun 2008 22:00:23 +0100 Subject: LSB Package API In-Reply-To: <1214157770.5783.25.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> Message-ID: <1214168423.3377.51.camel@hughsie-work> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote: > The distro model is nice (and arguably better than the LSB Package API) > if the packages you like to have are in the repos in sufficiently new > versions. But if you need to go past that (bleeding edge versions, not > widely spread apps), things get more difficult currently. Especially > propietary applications just cannot be distributed by the distros > directly. Right. These packages are compiled against system versions of libraries. Do we choose the F9 or rawhide version of xulrunner to link against? There's substantial API and ABI changes between distro versions for the majority of shared libraries. > I don't think this is a corner case at all. For one thing, propietary > applications might just don't play a role _because_ there is no really > good distribution method for them - the typical chicken-and-egg problem. Incorrect. Most closed-source applications I have to use are installed with an installer binary or script, which just smatters files on the hard drive in /opt. There's just no need to register these with the native system package manager as there are no updates repositories nor dependency tracking required. > Second, this way of distribution will help open-source projects as well. > It would make it really easy for them to distribute bleeding-edge > versions of there apps that integrate well into the packaging system > without having to package for each and every package manager. Who supports these bleeding edge packages? Where do the users get security updates from? What if the library it's compiled against also changes to a bleeding edge version too? This is not a standard use case, unless you want a system like gentoo where you compile from source. > It will > also help those projects which are not widely used enough to be in > distro repos, as they can more easily release binary distributions > without having to depend on getting packaged by the distros. Bad argument - see the PackageKit archives for details why this is a really, really, bad idea. > I really > believe this decentralism would be very nice to have, especially in > something as naturally decentralized as the open source community. Err, open source communities are not decentralised. They are _more_ centralised than closed source software. I currently use one vendor for my new software, my updates and also all the metadata and translations. I use the same vendor for talking to users on forums and developers on mailing lists and use the same channel for pastebin and collaborative editing. My vendor is Fedora. Calling an open source community decentralised is a very naive statement in my honest opinion. Richard. From hughsient at gmail.com Sun Jun 22 21:08:28 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 22 Jun 2008 22:08:28 +0100 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> Message-ID: <1214168908.3377.58.camel@hughsie-work> On Thu, 2008-06-19 at 13:26 -0300, Alexandre Oliva wrote: > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} > FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Yup. > Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Maybe you could spend more time on compiler design and optimisation than evangelism? This is really wearing a bit thin with hundreds of emails with the same tune to this mailing list. A few more posts about "Fedora Freedom" and I'm unsubscribing from this mailing list as it's more noise than signal. This mailing list is for DEVELOPMENT - not about subtle nuances of licensing. Please create your own mailing list and ask people to subscribe there instead of bombarding all of us _developers_ with this garbage. Thanks, Richard. From pbrobinson at gmail.com Sun Jun 22 21:12:44 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 22 Jun 2008 22:12:44 +0100 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214168908.3377.58.camel@hughsie-work> References: <1212917892.32207.488.camel@pmac.infradead.org> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: <5256d0b0806221412t3535194bq4474696346df89bf@mail.gmail.com> >> Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ >> Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} >> FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > > Yup. > >> Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} > > Maybe you could spend more time on compiler design and optimisation than > evangelism? This is really wearing a bit thin with hundreds of emails > with the same tune to this mailing list. > > A few more posts about "Fedora Freedom" and I'm unsubscribing from this > mailing list as it's more noise than signal. > > This mailing list is for DEVELOPMENT - not about subtle nuances of > licensing. Please create your own mailing list and ask people to > subscribe there instead of bombarding all of us _developers_ with this > garbage. Sounds like a perfect candidate for a SIG! From drago01 at gmail.com Sun Jun 22 21:27:34 2008 From: drago01 at gmail.com (drago01) Date: Sun, 22 Jun 2008 23:27:34 +0200 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214168908.3377.58.camel@hughsie-work> References: <1212917892.32207.488.camel@pmac.infradead.org> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: On Sun, Jun 22, 2008 at 11:08 PM, Richard Hughes wrote: > On Thu, 2008-06-19 at 13:26 -0300, Alexandre Oliva wrote: >> Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ >> Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} >> FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > > Yup. > >> Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} > > Maybe you could spend more time on compiler design and optimisation than > evangelism? This is really wearing a bit thin with hundreds of emails > with the same tune to this mailing list. > > A few more posts about "Fedora Freedom" and I'm unsubscribing from this > mailing list as it's more noise than signal. > > This mailing list is for DEVELOPMENT - not about subtle nuances of > licensing. Please create your own mailing list and ask people to > subscribe there instead of bombarding all of us _developers_ with this > garbage. > > Thanks, > > Richard. Thanks, finally someone said (wrote) it! From michel.sylvan at gmail.com Sun Jun 22 21:43:49 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 22 Jun 2008 17:43:49 -0400 Subject: %configure assuming in-source-tree builds In-Reply-To: <485E8822.1020000@gmail.com> References: <485E8822.1020000@gmail.com> Message-ID: <485EC795.8020507@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michel Salim wrote: > Hi all, > > Some upstream developers recommend that their software (thinking of LLVM > and PLT Scheme, but there must be others) *not* be configured and built > at the top-level source directory (typically recommending using build/, > object/ or some such). > > When this is needed, currently the Fedora packager has to revert to > calling the configure script directly, foregoing the %configure macro, > and copying as much of the configure settings by hand. Would it be a > desirable feature to, say, be able to declare > Thanks to Michael and Mamoru -- should these be listed in our packaging guidelines? - -- Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhex5UACgkQWt0J3fd+7ZAQAgCeMIJcla7PVON/3jx4i25ILcOM ebMAoJB+rstX/gFaiNe5+EKEfTOzLfdY =l/bp -----END PGP SIGNATURE----- From pinto.elia at gmail.com Sun Jun 22 22:08:43 2008 From: pinto.elia at gmail.com (devzero2000) Date: Mon, 23 Jun 2008 00:08:43 +0200 Subject: LSB Package API In-Reply-To: References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <1214168423.3377.51.camel@hughsie-work> Message-ID: > On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes > wrote: > >> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote: >> > The distro model is nice (and arguably better than the LSB Package API) >> > if the packages you like to have are in the repos in sufficiently new >> > versions. But if you need to go past that (bleeding edge versions, not >> > widely spread apps), things get more difficult currently. Especially >> > propietary applications just cannot be distributed by the distros >> > directly. >> >> Right. These packages are compiled against system versions of libraries. >> Do we choose the F9 or rawhide version of xulrunner to link against? >> There's substantial API and ABI changes between distro versions for the >> majority of shared libraries. >> >> > I don't think this is a corner case at all. For one thing, propietary >> > applications might just don't play a role _because_ there is no really >> > good distribution method for them - the typical chicken-and-egg problem. >> >> Incorrect. Most closed-source applications I have to use are installed >> with an installer binary or script, which just smatters files on the >> hard drive in /opt. There's just no need to register these with the >> native system package manager as there are no updates repositories nor >> dependency tracking required.> > > > You you like an opinion on this, well, that it is mine. For example, look > ad Oracle Client 11g > application : it. as released with a tarball or so, have on it: > > - a full stack of perl > - a full stack of shared library : glibc in primisis. > > So what have to do un poor packager manager with this ? Disable the deps > and hope the best. Other, as MQ client, are released with RPM : with deps > disabled anyway. But not all > are equal : for example websphere. Sure it is tricky to package it but > almost don't force me to disable the deps: I DON'T WANT DISABLE THE DEPS. > > IMHO, YMMV as usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Sun Jun 22 23:11:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Jun 2008 01:11:38 +0200 Subject: %configure assuming in-source-tree builds In-Reply-To: <485EC795.8020507@gmail.com> References: <485E8822.1020000@gmail.com> <485EC795.8020507@gmail.com> Message-ID: <20080622231137.GA2618@free.fr> On Sun, Jun 22, 2008 at 05:43:49PM -0400, Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks to Michael and Mamoru -- should these be listed in our packaging > guidelines? I don't think so, but you can go ahead and add it to https://fedoraproject.org/wiki/PackagingTricks -- Pat From kagesenshi.87 at gmail.com Mon Jun 23 01:56:50 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Mon, 23 Jun 2008 09:56:50 +0800 Subject: Firewall and user services that needs open ports In-Reply-To: <20080622205310.GA1065@angus.ind.WPI.EDU> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> Message-ID: On Mon, Jun 23, 2008 at 3:06 AM, Andrew Farris wrote: > > There is no service which requires a firewall to be turned off... that does > not exist. What they require is configuration to function with the firewall > on. Improvement of the firewall configuration tool would certainly be a good > step forward, and perhaps more automated configuration via upnp, but turning > it off is definitely the wrong move... no matter what service you're trying > to get through it. > err, well, yeah, - firewall turned off or port opened - .. I know I can use netstat -nap to find what ports that i need to open, but JoeRandom can't do that .. I didn't suggest turning off the firewall, I really believe Fedora would never do that .. My question was, are there any plans for handling such purpose .. because so far, the only approach that i've seen is to disable the firewall - which is rather an ugly move .. On Mon, Jun 23, 2008 at 4:53 AM, Chuck Anderson wrote: > Why do we need a firewall when you can easily prevent services from > being accessed...just stop the service! Don't bind to the port, and > it won't be possible to connect to it. > because JoeRandom don't know what daemon to turn on, and what daemon to turn off.. he will turn on whatever daemon the found/install .. and because binding port > 1024 doesnt need root, who knows what (malicious) software might be utilizing those high ports .. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From tcallawa at redhat.com Mon Jun 23 03:16:06 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 22 Jun 2008 23:16:06 -0400 Subject: Where Legal Queries Go (Was: Re: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre) In-Reply-To: <1214168908.3377.58.camel@hughsie-work> References: <1212917892.32207.488.camel@pmac.infradead.org> <1213045893.2534.85.camel@shinybook.infradead.org> <20080609213359.GA11775@devserv.devel.redhat.com> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: <1214190966.3172.22.camel@localhost.localdomain> On Sun, 2008-06-22 at 22:08 +0100, Richard Hughes wrote: > Please create your own mailing list and ask people to > subscribe there instead of bombarding all of us _developers_ with this > garbage. Not that I want to encourage this endless armchair lawyering, but there is a fedora-legal-list at redhat.com for public questions about legal or licensing matters in Fedora. If you'd rather email something in private, either email fedora-legal at redhat.com or just email me directly at tcallawa at redhat.com, and I'll put it in the queue to investigate. Please be aware that I may not be able to fully reply or comment on public emails (and even some private emails). Thanks, ~spot (IANAL, I just triage the issues) From seg at haxxed.com Mon Jun 23 06:37:05 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 23 Jun 2008 01:37:05 -0500 Subject: Firewall and user services that needs open ports In-Reply-To: <20080622205310.GA1065@angus.ind.WPI.EDU> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> Message-ID: <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> On Sun, Jun 22, 2008 at 3:53 PM, Chuck Anderson wrote: > On Sun, Jun 22, 2008 at 12:06:44PM -0700, Andrew Farris wrote: > > Izhar Firdaus wrote: > > There is no service which requires a firewall to be turned off... that > does > > not exist. What they require is configuration to function with the > > firewall on. Improvement of the firewall configuration tool would > certainly > > be a good step forward, and perhaps more automated configuration via > upnp, > > but turning it off is definitely the wrong move... no matter what service > > you're trying to get through it. > > Why do we need a firewall when you can easily prevent services from > being accessed...just stop the service! Don't bind to the port, and > it won't be possible to connect to it. Yes, the correct thing to do for local security is use something like selinux to prevent things from binding to interfaces/ports they shouldn't be binding to in the first place. Using iptables for this is a completely unsustainable hack. iptables firewalling is for machines that route packets to other machines. Unfortunately for some reason network devices are exempt from the "everything is a file" architecture thus don't recieve the benefit of the pre-existing filesystem access control architecture. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Jun 23 07:58:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Jun 2008 09:58:52 +0200 (CEST) Subject: Firewall and user services that needs open ports In-Reply-To: <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> Message-ID: <14783.192.54.193.59.1214207932.squirrel@rousalka.dyndns.org> Le Lun 23 juin 2008 08:37, Callum Lerwick a ?crit : > Yes, the correct thing to do for local security is use something like > selinux to prevent things from binding to interfaces/ports they > shouldn't be > binding to in the first place. Using iptables for this is a completely > unsustainable hack. iptables firewalling is for machines that route > packets to other machines. Iptables is actually wonderfully simple and transparent to normal users, unlike apps that do black magic using a system bus one can't inspect, a registry system full of rotten undocumented keys, and massive use of bandaids (PA startup I'm thinking about you). You'll take iptables out of my system the day I can easily check the spaguetti pile userspace is those days is not misbehaving. And no current selinux is not an "easy to inspect" system. -- Nicolas Mailhot From rawhide at fedoraproject.org Mon Jun 23 10:09:53 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 23 Jun 2008 10:09:53 +0000 (UTC) Subject: rawhide report: 20080623 changes Message-ID: <20080623100954.238FF209D25@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080622/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080623/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package R-DBI Database interface module for R New package kronolith The Horde calendar application New package mysqltuner MySQL high performance tuning script New package php-pear-Auth-RADIUS Wrapper Classes for the RADIUS PECL Updated Packages: darcs-2.0.0-1.fc10 ------------------ * Mon Jun 23 18:00:00 2008 Jens Petersen - 2.0.0-1.fc10 - update to 2.0.0 - no longer require darcs-ghc-6_8-compat.patch and darcs-error_xml-missing.patch - move utf-8 conversion to prep - disable check for now - manual is now doc and shell completion config lives in tools - install bash completion dovecot-1.1.1-1.fc10 -------------------- * Sun Jun 22 18:00:00 2008 Dan Horak - 1:1.1.1-1 - update to upstream version 1.1.1 ejabberd-2.0.1-4.fc10 --------------------- * Sun Jun 22 18:00:00 2008 Peter Lemenkov 2.0.1-4 - Last minute fix (issue with shortnames/fqdn) * Sun Jun 22 18:00:00 2008 Peter Lemenkov 2.0.1-3 -Fixed BZ# 439583, 452326, 451554 fwbackups-1.43.2-0.4.rc2.fc10 ----------------------------- * Sun Jun 22 18:00:00 2008 Stewart Adam 1.43.2-0.4.rc2 - Add patch to fix _import() functions gnash-0.8.3-1.fc10 ------------------ * Sun Jun 22 18:00:00 2008 Patrice Dumas 0.8.3-1 - update to 0.8.3 * Wed Apr 9 18:00:00 2008 Patrice Dumas 0.8.2-3 - ship libklashpart (#441601) gnome-python2-extras-2.19.1-16.fc9 ---------------------------------- * Fri Jun 20 18:00:00 2008 Martin Stransky - 2.19.1-16.fc9 - Rebuild against new gecko-libs 1.9 (xulrunner) gnome-web-photo-0.3-12.fc9 -------------------------- * Fri Jun 20 18:00:00 2008 Martin Stransky - 0.3-12 - Rebuild against new xulrunner jd-2.0.0-0.6.svn2145_trunk.fc10 ------------------------------- * Mon Jun 23 18:00:00 2008 Mamoru Tasaka - svn 2145 kernel-2.6.26-0.81.rc7.fc10 --------------------------- * Fri Jun 20 18:00:00 2008 Dave Jones - Reduce the NFS mount code stack usage. * Fri Jun 20 18:00:00 2008 Dave Jones - 2.6.26-rc7 * Thu Jun 19 18:00:00 2008 Dave Jones - 2.6.26-rc6-git6 * Wed Jun 18 18:00:00 2008 Eric Paris - Better selinux support for ecryptfs overlays (BZ 450867) * Wed Jun 18 18:00:00 2008 Dave Jones - 2.6.26-rc6-git5 libselinux-2.0.65-1.fc10 ------------------------ * Sun Jun 22 18:00:00 2008 Dan Walsh - 2.0.65-1 - Update to Upstream * Fix selinux_file_context_verify() and selinux_lsetfilecon_default() to call matchpathcon_init_prefix if not already initialized. * Add -q qualifier for -V option of matchpathcon and change it to indicate whether verification succeeded or failed via exit status. * Fri May 16 18:00:00 2008 Dan Walsh - 2.0.64-3 - libselinux no longer neets to telnet -u in post install libsepol-2.0.31-1.fc10 ---------------------- * Sun Jun 22 18:00:00 2008 Dan Walsh 2.0.31-1 - Upgrade to latest from NSA * Fix mls_semantic_level_expand() to handle a user require w/o MLS information from Stephen Smalley. libsoup-2.23.1-4.fc10 --------------------- * Sun Jun 22 18:00:00 2008 Matthew Barnes - 2.23.1-4 - Remove unnecessary pkgconfig build requirement. openvrml-0.17.6-2.fc10 ---------------------- * Sun Jun 22 18:00:00 2008 Braden McDaniel - 0.17.6-2 - Make symbols for libglade callbacks in openvrml-player visible. perl-Catalyst-Devel-1.07-1.fc10 ------------------------------- * Sun Jun 22 18:00:00 2008 Chris Weyl 1.07-1 - update to 1.07 - require perl-Catalyst-Runtime-scripts; catalyst.pl lives in there now. * Wed May 28 18:00:00 2008 Chris Weyl 1.06-1 - update to 1.06 (runtime to 5.7014) - drop br on Catalyst::Manual; add br on parent perl-Catalyst-Manual-5.7012-1.fc10 ---------------------------------- * Sun Jun 22 18:00:00 2008 Chris Weyl 5.7012-1 - update to 7.012... - ...and add an epoch. sigh. * Sun Jun 22 18:00:00 2008 Chris Weyl 5.701003-1 - update to 5.701003 - un-exclude Catalyst::Manual pod as it's been moved over from Catalyst::Runtime to this dist - License tag update: GPL -> GPL+ perl-Catalyst-Runtime-5.7014-2.fc10 ----------------------------------- * Sat May 31 18:00:00 2008 Chris Weyl 5.7014-2 - pull catalyst.pl back from perl-Catalyst-Devel, put into subpackage: too much of a headache to keep this bit of -Runtime in -Devel - pull in tests - deal with perl-Catalyst-Manual issues * Sat May 31 18:00:00 2008 Chris Weyl 5.7014-1 - update to 5.7014 pinot-0.86-1.fc10 ----------------- * Sun Jun 22 18:00:00 2008 Adel Gadllah 0.86-1 - Update to 0.86 pm-utils-1.1.2.3-1.fc10 ----------------------- * Sun Jun 22 18:00:00 2008 Richard Hughes - 1.1.2.3-1 - Update to 1.1.2.3 * Fri Jun 20 18:00:00 2008 Till Maas - 1.1.2.2-2 - %pre and %post scriptlets should not be needed anymore, old config files should be already moved in every supported release and the selinux context for the logfile should be restored by rpm - remove pcitulils BR, it was needed for vbetool, which is in a separate package now - substitute %{__rm} macros for uniform macro usage policycoreutils-2.0.49-7.fc10 ----------------------------- * Mon Jun 16 18:00:00 2008 Dan Walsh 2.0.49-7 - Fix sepolgen-ifgen processing pulseaudio-0.9.11-0.5.svn20080622.fc10 -------------------------------------- * Sun Jun 22 18:00:00 2008 Lennart Poettering 0.9.11-0.5.svn20080622 - New GIT snapshot python-inotify-0.8.0-3.r.fc10 ----------------------------- * Sun Jun 22 18:00:00 2008 Terje Rosten - 0.8.0-3.r - rebuild * Tue Jun 17 18:00:00 2008 Terje Rosten - 0.8.0-2.r - 0.8.0r - add wrapper in /usr/bin python-turbojson-1.2-1.fc10 --------------------------- * Sun Jun 22 18:00:00 2008 Luke Macken 1.2-1 - Latest upstream release, intended to be used with the upcoming TurboGears 1.1 version. - Remove python-turbojson-SAfix-r3749.patch roxterm-1.12.2-1.fc10 --------------------- * Sun Jun 22 18:00:00 2008 Sebastian Vahl - 1.12.1-2 - new upstream version: 1.12.2 - move menu entry to category "System" selinux-policy-3.4.2-5.fc10 --------------------------- * Sun Jun 22 18:00:00 2008 Dan Walsh 3.4.2-5 - Fix prelude file context tcpreplay-3.3.2-1.fc10 ---------------------- * Mon Jun 23 18:00:00 2008 Bojan Smojver - 3.3.2-1 - bump up to 3.3.2 trac-0.10.5-1.fc10 ------------------ * Sun Jun 22 18:00:00 2008 Jeffrey C. Ollie - 0.10.5-1 - Update to 0.10.5 xorg-x11-drv-radeonhd-1.2.1-3.2.20080622git.fc10 ------------------------------------------------ * Sun Jun 22 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.2.20080622git - Proposed fix for bugs #451349 and #452050 (commit a67a65eb) - New snapshot (upstream commit 1eff3e783bf6cab33dad837ec0c4edc07d967f7c): - 1eff3e78: CONNTEST: Added new PCI Ids. - 372c5905: ATOMBios: Fix bogus log message. - a67a65eb: MC: Add sanity check for IGP FB location. - c38112c8: VRAM Fix clamping to aperture. - 2bfccf62: Add more verbose debugging information. - 74cb0fc6: Free data structures on close screen to avoid memory leak. - 47ba86d6: Add a bit of info to the README to help FreeBSD users who are having trouble building the driver. Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 27 Broken deps for i386 ---------------------------------------------------------- brasero-0.7.1-4.fc10.i386 requires libisofs.so.5 brasero-0.7.1-4.fc10.i386 requires libburn.so.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.x86_64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.x86_64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc requires libisofs.so.5 brasero-0.7.1-4.fc10.ppc requires libburn.so.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- brasero-0.7.1-4.fc10.ppc64 requires libburn.so.0()(64bit) brasero-0.7.1-4.fc10.ppc64 requires libisofs.so.5()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From choeger at cs.tu-berlin.de Mon Jun 23 10:21:26 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 23 Jun 2008 12:21:26 +0200 Subject: Need help with openvpn behavior Message-ID: <1214216486.32346.9.camel@choeger6> Hi, currently I cannot fix #446335 because of some strange openvpn settings: NetworkManager-openvpn starts openvpn with --up nm-openvpn-service-helper That is basically to allow NetworkManager to update the IPv4 configuration. The problem occurs when the helper trys to figure out what the remote machine is by evaluating environment vars set by openvpn. In some configurations "trusted_ip" holds that info, in some its just "remote_1" and -even worse- I just had a test where that remote ip is not stored in _any_ variable in a simple tun/psk connection. ?This also makes NetworkManager-openvpn-0.7.0-13.svn3632.fc9.i386 a regression for some users currently as I switched usage of "trusted_ip" to "remote_1" I would patch that to make "remote_1" a fallback if "trusted_ip" is not set but that does not So does anyone know how to get openvpn to _always_ set a var which holds the remote ip and which it is? thank you for any advice christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From naheemzaffar at gmail.com Mon Jun 23 11:10:44 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 23 Jun 2008 12:10:44 +0100 Subject: totem* 2.23.2 in stable updates Message-ID: <3adc77210806230410l52b6848dgb4647e3921539f4e@mail.gmail.com> Just checking the current lot of updates to Fedora 9 and totem* 2.23.2 came to my attention. Looking in packagekiot, the previously installed is also 2.23.2. I though the stable gnome components should be at 2.22.x at the moment, so i am wondering wether this is an accident or on purpose. (if on purpose, I trust the maintainers to have valid reasons. I will not second guess them.) From bnocera at redhat.com Mon Jun 23 11:17:18 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 23 Jun 2008 12:17:18 +0100 Subject: totem* 2.23.2 in stable updates In-Reply-To: <3adc77210806230410l52b6848dgb4647e3921539f4e@mail.gmail.com> References: <3adc77210806230410l52b6848dgb4647e3921539f4e@mail.gmail.com> Message-ID: <1214219838.3133.8.camel@cookie.hadess.net> On Mon, 2008-06-23 at 12:10 +0100, Naheem Zaffar wrote: > Just checking the current lot of updates to Fedora 9 and totem* 2.23.2 > came to my attention. Looking in packagekiot, the previously installed > is also 2.23.2. > > I though the stable gnome components should be at 2.22.x at the > moment, so i am wondering wether this is an accident or on purpose. > (if on purpose, I trust the maintainers to have valid reasons. I will > not second guess them.) It's on purpose, and I'm both upstream and the package maintainer, so I guess you can trust me there :) From naheemzaffar at gmail.com Mon Jun 23 11:20:33 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 23 Jun 2008 12:20:33 +0100 Subject: totem* 2.23.2 in stable updates In-Reply-To: <1214219838.3133.8.camel@cookie.hadess.net> References: <3adc77210806230410l52b6848dgb4647e3921539f4e@mail.gmail.com> <1214219838.3133.8.camel@cookie.hadess.net> Message-ID: <3adc77210806230420g4efdc2dei182ef13afe81c4a0@mail.gmail.com> Thanks for the quick reply. :) From harald at redhat.com Mon Jun 23 12:07:00 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 23 Jun 2008 14:07:00 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> Message-ID: <485F91E4.6040406@redhat.com> Jeff Spaleta wrote: > On Fri, May 23, 2008 at 12:16 PM, Harald Hoyer wrote: >> too obvious :) replaced the old one with the free version and renamed it to >> .ogg :) >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.ogg > > > Now! do it all again..starting with a blank gimp application but this > time record the process with instanbul and create a screencast so we > can include it as one of our first videos for a Fedora content channel > meant for miro. > > Think of it as an initiation or hazing ritual required of all incoming > Board members. > > -jef > ok, made two ogg videos with istanbul. Now I want to join them and add a separate audio track. pitivi crashes on "render" and does not have any useful functionality... which video editor should I use? From walters at verbum.org Mon Jun 23 14:17:02 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 23 Jun 2008 10:17:02 -0400 Subject: Firewall and user services that needs open ports In-Reply-To: <14783.192.54.193.59.1214207932.squirrel@rousalka.dyndns.org> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> <14783.192.54.193.59.1214207932.squirrel@rousalka.dyndns.org> Message-ID: On Mon, Jun 23, 2008 at 3:58 AM, Nicolas Mailhot < nicolas.mailhot at laposte.net> wrote: > > Le Lun 23 juin 2008 08:37, Callum Lerwick a ?crit : > > > Yes, the correct thing to do for local security is use something like > > selinux to prevent things from binding to interfaces/ports they > > shouldn't be > > binding to in the first place. Using iptables for this is a completely > > unsustainable hack. iptables firewalling is for machines that route > > packets to other machines. > > Iptables is actually wonderfully simple and transparent to normal > users, unlike apps that do black magic using a system bus one can't > inspect, dbus-monitor --system d-feet > > You'll take iptables out of my system the day I can easily check the > spaguetti pile userspace is those days is not misbehaving. netstat -ln -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjones at redhat.com Mon Jun 23 14:39:49 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 23 Jun 2008 10:39:49 -0400 Subject: %configure assuming in-source-tree builds In-Reply-To: <485EC795.8020507@gmail.com> References: <485E8822.1020000@gmail.com> <485EC795.8020507@gmail.com> Message-ID: <485FB5B5.803@redhat.com> Michel Salim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michel Salim wrote: >> Hi all, >> >> Some upstream developers recommend that their software (thinking of LLVM >> and PLT Scheme, but there must be others) *not* be configured and built >> at the top-level source directory (typically recommending using build/, >> object/ or some such). >> >> When this is needed, currently the Fedora packager has to revert to >> calling the configure script directly, foregoing the %configure macro, >> and copying as much of the configure settings by hand. Would it be a >> desirable feature to, say, be able to declare >> > Thanks to Michael and Mamoru -- should these be listed in our packaging > guidelines? I'd really rather see something like your initial suggestion. -- Peter From pjones at redhat.com Mon Jun 23 14:45:25 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 23 Jun 2008 10:45:25 -0400 Subject: rpmreaper In-Reply-To: References: <20080603154111.GA24155@localhost> <1212510885.3774.23.camel@cutter> <20080603164847.GA26868@localhost> <1212512425.3273.8.camel@ignacio.lan> <4845A242.4050306@poolshark.org> <1212523375.3774.35.camel@cutter> <3e4ec4600806031318i73c022e8s8c9cf05640cd1754@mail.gmail.com> <1212524860.3774.42.camel@cutter> <3e4ec4600806031422r5aecade3w7a21201bd23901ef@mail.gmail.com> <604aa7910806031822m7105c23am85684a795c8afb44@mail.gmail.com> Message-ID: <485FB705.6090302@redhat.com> Rudolf Kastl wrote: > rpm -qi mkinitrd > > *hint* *hint* > > you might notice the missing url line :) Fixed in 6.0.54-1.fc10 . -- Peter From lesmikesell at gmail.com Mon Jun 23 15:15:04 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 23 Jun 2008 10:15:04 -0500 Subject: Firewall and user services that needs open ports In-Reply-To: <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> Message-ID: <485FBDF8.8080506@gmail.com> Callum Lerwick wrote: > > > Why do we need a firewall when you can easily prevent services from > being accessed...just stop the service! Don't bind to the port, and > it won't be possible to connect to it. > > > Yes, the correct thing to do for local security is use something like > selinux to prevent things from binding to interfaces/ports they > shouldn't be binding to in the first place. But what you usually want to control are the ranges of source/destination addresses that are permitted. > Using iptables for this is a > completely unsustainable hack. iptables firewalling is for machines that > route packets to other machines. Unsustainable? But it is what you need to do, not kill functionality completely. > Unfortunately for some reason network devices are exempt from the > "everything is a file" architecture thus don't recieve the benefit of > the pre-existing filesystem access control architecture. Yes, this seems like a bizarre design decision in Linux but realistically, everything needs network access to be useful at all these days and what you need to control is where on the network something can/can't connect. -- Les Mikesell lesmikesell at gmail.com From dwashington at gmx.net Mon Jun 23 15:23:59 2008 From: dwashington at gmx.net (Denis Washington) Date: Mon, 23 Jun 2008 17:23:59 +0200 Subject: LSB Package API In-Reply-To: References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <1214168423.3377.51.camel@hughsie-work> Message-ID: <1214234639.5784.12.camel@dwashington> On Mon, 2008-06-23 at 00:08 +0200, devzero2000 wrote: > > > > On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes > wrote: > On Sun, 2008-06-22 at 20:02 +0200, Denis Washington > wrote: > > The distro model is nice (and arguably better than > the LSB Package API) > > if the packages you like to have are in the repos in > sufficiently new > > versions. But if you need to go past that (bleeding > edge versions, not > > widely spread apps), things get more difficult > currently. Especially > > propietary applications just cannot be distributed > by the distros > > directly. > > > Right. These packages are compiled against system > versions of libraries. > Do we choose the F9 or rawhide version of xulrunner to > link against? > There's substantial API and ABI changes between distro > versions for the > majority of shared libraries. > > > I don't think this is a corner case at all. For one > thing, propietary > > applications might just don't play a role _because_ > there is no really > > good distribution method for them - the typical > chicken-and-egg problem. > > > Incorrect. Most closed-source applications I have to > use are installed > with an installer binary or script, which just > smatters files on the > hard drive in /opt. There's just no need to register > these with the > native system package manager as there are no updates > repositories nor > dependency tracking required.> Well, if there is no update tracking, there is naturally no gain in having the application registered with the package (well, perhaps except the user being able to uninstall the application with their package manager and ISVs not having to provide an explicit uninstaller). But a way of tracking updates _is_ planned, even if it isn't in the spec right now. This is especially crucial because LSB applications may not depend on anything else but the LSB itself, that is, they need to care a lot of libraries around. Without update integration, this would certainly suck. But it should be possible in a "final" LSB Package API by all means. > You you like an opinion on this, well, that it is mine. For > example, look ad Oracle Client 11g > application : it. as released with a tarball or so, have on > it: > > - a full stack of perl > - a full stack of shared library : glibc in primisis. Wow, that's taking it to the extreme. Both glibc and perl are in the LSB afaik. > So what have to do un poor packager manager with this ? > Disable the deps and hope the best. Other, as MQ client, are > released with RPM : with deps disabled anyway. But not all > are equal : for example websphere. Sure it is tricky to > package it but almost don't force me to disable the deps: I > DON'T WANT DISABLE THE DEPS. Well, the problem with arbitrary dependencies is that you can't guarantee that every distro has them, or has them in the correct version. But as the many important libraries are in the LSB and thus are used system-wide, the problem of having to package the remaing ones with the application is not that big IMHO, especially if there is integration in the packaging system's update tracking. > IMHO, YMMV as usual Sure, same for my reply naturally. Regards, Denis From yersinia.spiros at gmail.com Mon Jun 23 15:48:02 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Mon, 23 Jun 2008 17:48:02 +0200 Subject: Firewall and user services that needs open ports In-Reply-To: <485FBDF8.8080506@gmail.com> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <1218b5bc0806222337pd7271feqea35d40fe214184a@mail.gmail.com> <485FBDF8.8080506@gmail.com> Message-ID: The MLS Selinux policy go beyond a "everything a file" acl and offer much more protection, at the expense di some complexity http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/#more-19 Also james morris had post some useful docu on the subject in his blog. Regards On Mon, Jun 23, 2008 at 5:15 PM, Les Mikesell wrote: > Callum Lerwick wrote: > >> >> >> Why do we need a firewall when you can easily prevent services from >> being accessed...just stop the service! Don't bind to the port, and >> it won't be possible to connect to it. >> >> >> Yes, the correct thing to do for local security is use something like >> selinux to prevent things from binding to interfaces/ports they shouldn't be >> binding to in the first place. >> > > But what you usually want to control are the ranges of source/destination > addresses that are permitted. > > Using iptables for this is a completely unsustainable hack. iptables >> firewalling is for machines that route packets to other machines. >> > > Unsustainable? But it is what you need to do, not kill functionality > completely. > > Unfortunately for some reason network devices are exempt from the >> "everything is a file" architecture thus don't recieve the benefit of the >> pre-existing filesystem access control architecture. >> > > Yes, this seems like a bizarre design decision in Linux but realistically, > everything needs network access to be useful at all these days and what you > need to control is where on the network something can/can't connect. > > -- > Les Mikesell > lesmikesell at gmail.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 jkeating at redhat.com Mon Jun 23 15:49:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jun 2008 11:49:34 -0400 Subject: debuginfo for subpackages Message-ID: <1214236174.4405.18.camel@localhost.localdomain> I'm currently adding support for pungi to gather debuginfo packages based on the other packages it gathered. However I see things like the kernel where there are subpackages that have their own debuginfo. Having to search for these will greatly increase the amount of time it takes pungi to discover all the appropriate debuginfo packages it should have. Is there any other package anybody is aware of other than the kernel that has subpackage specific debuginfo? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Mon Jun 23 16:17:25 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 23 Jun 2008 11:17:25 -0500 Subject: Firewall and user services that needs open ports In-Reply-To: <20080622205310.GA1065@angus.ind.WPI.EDU> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> Message-ID: <20080623161725.GB3960@wolff.to> On Sun, Jun 22, 2008 at 16:53:10 -0400, Chuck Anderson wrote: > > Why do we need a firewall when you can easily prevent services from > being accessed...just stop the service! Don't bind to the port, and > it won't be possible to connect to it. Because there are network services that you only want accessible locally. From cra at WPI.EDU Mon Jun 23 16:58:58 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 23 Jun 2008 12:58:58 -0400 Subject: Firewall and user services that needs open ports In-Reply-To: <20080623161725.GB3960@wolff.to> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <20080623161725.GB3960@wolff.to> Message-ID: <20080623165858.GI10754@angus.ind.WPI.EDU> On Mon, Jun 23, 2008 at 11:17:25AM -0500, Bruno Wolff III wrote: > On Sun, Jun 22, 2008 at 16:53:10 -0400, > Chuck Anderson wrote: > > > > Why do we need a firewall when you can easily prevent services from > > being accessed...just stop the service! Don't bind to the port, and > > it won't be possible to connect to it. > > Because there are network services that you only want accessible locally. Right, but the default firewall rules don't do that. By default maybe the firewall should be off. From cra at WPI.EDU Mon Jun 23 16:59:46 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 23 Jun 2008 12:59:46 -0400 Subject: debuginfo for subpackages In-Reply-To: <1214236174.4405.18.camel@localhost.localdomain> References: <1214236174.4405.18.camel@localhost.localdomain> Message-ID: <20080623165946.GJ10754@angus.ind.WPI.EDU> On Mon, Jun 23, 2008 at 11:49:34AM -0400, Jesse Keating wrote: > I'm currently adding support for pungi to gather debuginfo packages > based on the other packages it gathered. However I see things like the > kernel where there are subpackages that have their own debuginfo. > Having to search for these will greatly increase the amount of time it > takes pungi to discover all the appropriate debuginfo packages it should > have. Is there any other package anybody is aware of other than the > kernel that has subpackage specific debuginfo? glibc From walters at verbum.org Mon Jun 23 17:22:38 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 23 Jun 2008 13:22:38 -0400 Subject: apport/breakpad and fedora Message-ID: Hey, There was some good discussion at FUDCon about apport and friends. I'd really like to see us have a sane story on this by F10 - currently Bugzilla has a lot of unannotated backtraces and it's a big waste of developer/triager time. So the goal is that when a program crashes, we get a full annotated backtrace to the eyes of the developer. There's some discussion on the current Fedora wiki page: https://fedoraproject.org/wiki/Releases/FeatureApport Here's my executive summary: Apport: Based on kernel core dump piping, can handle any program crash. Submits data to launchpad which has tracing server which uses debuginfo to create full stack trace. Fedora would need to make custom server on top of the lowlevel tools. Breakpad: Used by Firefox and various Google applications. Based on a shared library linked into processes which catches SIGSEGV and submits a report via HTTP. Format: http://code.google.com/p/google-breakpad/wiki/ProcessorDesign One nice thing is that Mozilla has a lot of investment in a free software scalable processing server called "Socorro": http://code.google.com/p/socorro GNOME is using breakpad/socorro and has a server up: http://blogs.gnome.org/ovitters/2007/10/06/crash-gnome-org/ They were prototyping it using Fedora, and I believe bug-buddy which is linked into all GTK+ programs uses breakpad and sends to crash.gnome.org by default. Some data points from the discussion: * Apparently Apport submits an entire core dump which is (IMO) a non-starter for Fedora; there are things like passwords in memory that we just can't send by default. * Mozilla is unhappy that we're turning off their breakpad integration on Fedora, which means they don't have visibility into crashes on freedesktop.org/Linux systems. * Possibly replace breakpad library linking by using utrace+system service (right?) * Create debuginfo DAV server and pull debuginfo data dynamically (what are the download requirements? does this replace gdb's "debuginfo-install" display?) My 2? - Link in breakpad, create http://crash.fedoraproject.org running Socorro. Investigate either submitting reports to Mozilla as well for Firefox or create a system where our Socorro pushes reports to theirs. Longer term investigate utrace system service instead of having apps link to breakpad (this gets us non-desktop system crashes without having to universally LD_PRELOAD or whatever). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lordmorgul at gmail.com Mon Jun 23 17:48:11 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 23 Jun 2008 10:48:11 -0700 Subject: Firewall and user services that needs open ports In-Reply-To: <20080623165858.GI10754@angus.ind.WPI.EDU> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <20080623161725.GB3960@wolff.to> <20080623165858.GI10754@angus.ind.WPI.EDU> Message-ID: <485FE1DB.9040306@gmail.com> Chuck Anderson wrote: > On Mon, Jun 23, 2008 at 11:17:25AM -0500, Bruno Wolff III wrote: >> On Sun, Jun 22, 2008 at 16:53:10 -0400, >> Chuck Anderson wrote: >>> Why do we need a firewall when you can easily prevent services from >>> being accessed...just stop the service! Don't bind to the port, and >>> it won't be possible to connect to it. >> Because there are network services that you only want accessible locally. > > Right, but the default firewall rules don't do that. By default maybe > the firewall should be off. Or maybe the default firewall rules shouldn't be wide open, but should be local instead... with the understanding that most people who do not know how to effectively change their firewall ruleset are going to be working in a small home network. I wouldn't argue the default firewall rules are perfect, but turning it off doesn't help anything at all. You say its just as good to turn the services off... but its not. The firewall is a layer of protection in place if the service is started unintentionally, or if a breach takes place and an open port is hijacked for unintended purposes. Yes SELinux handles that, but with the popularity of turning that off after install (still lots of people seem to do that) the firewall is still a useful protection. And the firewall also gives you traffic control and stateful packet inspection which is valuable in itself; any running service should have SPI protecting it whether its supposed to be open to the world or just local. Just preventing ports from getting bound is not the same. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From halfline at gmail.com Mon Jun 23 17:51:31 2008 From: halfline at gmail.com (Ray Strode) Date: Mon, 23 Jun 2008 13:51:31 -0400 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <45abe7d80806231051v4f257a32xc8b821208c3c39fd@mail.gmail.com> Hi again, > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. > > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down). The link is here, fwiw: https://fedoraproject.org/wiki/Releases/FeatureBetterStartup >The replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. > > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. So after a bit of hacking on 2, we've come to the conclusion that 1 isn't really necessary. It looks really good to just keep 2 up until gdm would normally start. We don't need to start it earlier in the boot process. A lot of the bits are in rawhide now, but the graphical bits won't be really testable until the drm modesetting drivers get added back to rawhide. --Ray From abo at kth.se Mon Jun 23 18:01:31 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Jun 2008 20:01:31 +0200 Subject: Firewall and user services that needs open ports In-Reply-To: <20080623165858.GI10754@angus.ind.WPI.EDU> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <20080623161725.GB3960@wolff.to> <20080623165858.GI10754@angus.ind.WPI.EDU> Message-ID: <1214244092.12372.53.camel@tempo.alexander.bostrom.net> m?n 2008-06-23 klockan 12:58 -0400 skrev Chuck Anderson: > Right, but the default firewall rules don't do that. The default filrewall doesn't filter anything on the loopback interface, does it? Or you mean traffic on an external interface but using a source IP address of the host? > By default maybe the firewall should be off. Well, a firewall should only be an added protection. If you want a caching nameserver locally then make sure it only binds to the loopback interface even if you have a firewall. Same thing with sendmail. It only listens locally by default, even though there's a firewall. That's how it should be. Anything else is way too risky. A quick service iptables stop shouldn't leave you wide open, just without a safety net. It's probably good to have a firewall, but regular users needs a good tool to manage it. The question is, what range of options does it need and how much of the configuration can be automated? Some thoughts: Not everyone would want the /proc/sys/net/ipv4/ip_local_port_range open for UDP/TCP/SCTP, but it should be an option, perhaps the default. Options for specific service-related ports such as ssh or VNC. (Btw, VNC, security and usability is unfortunately a topic for a whole thread.) Profiles for "server", "desktop" and so on. Manage both iptables and ip6tables together. Open ports automatically based on running services? Then what's the point? Perhaps a built-in view of listening sockets? With sane defaults, users installing a desktop machine shouldn't have to care about the firewall. And on server machines the sane defaults should mean you have fairly good protection and only need to open up things for services you start. But yes, the above can be done with SELinux as well. Maybe that will could actually provide a better user experience since you'd get error messages when binding sockets instead of mostly silently dropped packets. /abo From abo at kth.se Mon Jun 23 18:07:16 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Jun 2008 20:07:16 +0200 Subject: LSB Package API In-Reply-To: <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> Message-ID: <1214244436.12372.63.camel@tempo.alexander.bostrom.net> s?n 2008-06-22 klockan 11:41 -0800 skrev Jeff Spaleta: > Stand up a usage case which benefits open source > software and wok through that usage case. Then how about this use case: To simplify the uninstallation of installed proprietary packages. I guess a way to do that would be to add support for uninstalling autopackage packages using the PackageKit interfaces. /abo From abo at kth.se Mon Jun 23 18:10:40 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Jun 2008 20:10:40 +0200 Subject: LSB Package API In-Reply-To: <1214244436.12372.63.camel@tempo.alexander.bostrom.net> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> <1214244436.12372.63.camel@tempo.alexander.bostrom.net> Message-ID: <1214244640.12372.66.camel@tempo.alexander.bostrom.net> m?n 2008-06-23 klockan 20:07 +0200 skrev Alexander Bostr?m: > Then how about this use case: > > To simplify the uninstallation of installed proprietary packages. That's not a use case but never mind. /abo From Jochen at herr-schmitt.de Mon Jun 23 18:23:30 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 23 Jun 2008 20:23:30 +0200 Subject: Package kyum retired. Message-ID: <485FEA22.6010908@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, unfortunately, the upstream author has no time to maintain the kyum package. So I have to retired this package in the Fedora collection. If anyone wnat to resurrecting this package, they have to overtake the upstream project from sourceforge.net Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhf6iIACgkQT2AHK6txfgxmTwCfRH2hmboW6tz8TVICUDZVpSeA PrkAnjSKbZguEiXqw1gMcDkWwWsatGWF =8SLS -----END PGP SIGNATURE----- From jspaleta at gmail.com Mon Jun 23 18:42:53 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 Jun 2008 10:42:53 -0800 Subject: LSB Package API In-Reply-To: <1214244436.12372.63.camel@tempo.alexander.bostrom.net> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> <1214244436.12372.63.camel@tempo.alexander.bostrom.net> Message-ID: <604aa7910806231142w7e5d9259ucae58ff10d39be2b@mail.gmail.com> On Mon, Jun 23, 2008 at 10:07 AM, Alexander Bostr?m wrote: > Then how about this use case: > > To simplify the uninstallation of installed proprietary packages. I think you missed my point entirely about not standing up proprietary packages as the primary reason. Hopefully the original poster got my point. > I guess a way to do that would be to add support for uninstalling > autopackage packages using the PackageKit interfaces. I'm still waiting for someone to give me a comparison between the LSB/Berlin API concept and what autopackage currently does. Is there really a need for the LSB/Berlin API? Does it really do more than what the autopackage roadmap encompasses? Just from a motivations point of view, it seems to me that autopackage is meant to solve exactly the same problem as the LSB/Berlin API. And if that is the case, and its only implementation details that are different, then I think its probably appropriate for the LSB/Berlin API supporters to do a compare/constrast against the more mature autopackage concept so we can get a better understanding of the detailed differences. Sadly, such a comparison would need to use very small words, if I am to be part of the target audience. -jef"My comments should not be construed as support for autopackage."spaleta From the.masch at gmail.com Mon Jun 23 18:56:38 2008 From: the.masch at gmail.com (Mario Chacon) Date: Mon, 23 Jun 2008 15:56:38 -0300 Subject: Update for Gnome-do 0.5 Message-ID: <93d66b780806231156s732c5253y7d97cb4e68d09037@mail.gmail.com> Hi! How Can i help to update the gnome-do to ?version ?0.5? Thanks.. From seg at haxxed.com Mon Jun 23 18:56:57 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 23 Jun 2008 13:56:57 -0500 Subject: Firewall and user services that needs open ports In-Reply-To: <1214244092.12372.53.camel@tempo.alexander.bostrom.net> References: <485EA2C4.3070802@gmail.com> <20080622205310.GA1065@angus.ind.WPI.EDU> <20080623161725.GB3960@wolff.to> <20080623165858.GI10754@angus.ind.WPI.EDU> <1214244092.12372.53.camel@tempo.alexander.bostrom.net> Message-ID: <1218b5bc0806231156o52fd8082s60458e2edc604d9d@mail.gmail.com> On Mon, Jun 23, 2008 at 1:01 PM, Alexander Bostr?m wrote: > But yes, the above can be done with SELinux as well. Maybe that will > could actually provide a better user experience since you'd get error > messages when binding sockets instead of mostly silently dropped > packets. Exactly my point. Rejecting the bind() call allows the app to present an understandable error, within the context of the application. With an interactive app it could provide a pretty GUI error dialog right then and there. The API we need is there already. We're just not using it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abo at kth.se Mon Jun 23 19:10:00 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Jun 2008 21:10:00 +0200 Subject: LSB Package API In-Reply-To: <604aa7910806231142w7e5d9259ucae58ff10d39be2b@mail.gmail.com> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> <1214244436.12372.63.camel@tempo.alexander.bostrom.net> <604aa7910806231142w7e5d9259ucae58ff10d39be2b@mail.gmail.com> Message-ID: <1214248200.12372.117.camel@tempo.alexander.bostrom.net> m?n 2008-06-23 klockan 10:42 -0800 skrev Jeff Spaleta: > On Mon, Jun 23, 2008 at 10:07 AM, Alexander Bostr?m wrote: > > Then how about this use case: > > > > To simplify the uninstallation of installed proprietary packages. > > I think you missed my point entirely about not standing up proprietary > packages as the primary reason. Hopefully the original poster got my > point. Of course I got the point! But to help get rid of proprietary software, how could that be wrong? Answer: By helping those who installed it in the first place. It's not wrong, it's just not something I expect anyone around here will care much about. But the LSB devs might. /abo From wwoods at redhat.com Mon Jun 23 20:12:15 2008 From: wwoods at redhat.com (Will Woods) Date: Mon, 23 Jun 2008 16:12:15 -0400 Subject: apport/breakpad and fedora In-Reply-To: References: Message-ID: <1214251935.29455.79.camel@metroid.rdu.redhat.com> On Mon, 2008-06-23 at 13:22 -0400, Colin Walters wrote: > Breakpad: Used by Firefox and various Google applications. Based on a > shared library linked into processes which catches SIGSEGV and submits > a report via HTTP. > Format: http://code.google.com/p/google-breakpad/wiki/ProcessorDesign > One nice thing is that Mozilla has a lot of investment in a free > software scalable processing server called "Socorro": > http://code.google.com/p/socorro > > GNOME is using breakpad/socorro and has a server up: > http://blogs.gnome.org/ovitters/2007/10/06/crash-gnome-org/ > They were prototyping it using Fedora, and I believe bug-buddy which > is linked into all GTK+ programs uses breakpad and sends to > crash.gnome.org by default. > > * Possibly replace breakpad library linking by using utrace+system > service (right?) If I remember right, the reason for this part of the discussion was: 1) Linking everything on the system to breakpad is a bit nasty. 2) Apport doesn't need to be linked in, but it runs *after* the process gets dumped by the kernel. At which point it's slightly different from when it actually crashed. pjones' idea was to have a system service that would receive notification of segfaults and use utrace to stop the process and generate a (breakpad-style report). > * Create debuginfo DAV server and pull debuginfo data dynamically > (what are the download requirements? does this replace gdb's > "debuginfo-install" display?) It would make the 'debuginfo-install' message go away, because (if DAV + FUSE does the right thing) you'll have all the debuginfo you need, in the right place - mounted as a FUSE filesystem. It requires some trickery with the web server to keep from *actually* unpacking all the debuginfo packages in existence (something like ~5T of data?) but Peter was working on a proof-of-concept at FUDCon. > My 2? - Link in breakpad, create http://crash.fedoraproject.org > running Socorro. Link it into what? Everything, via LD_PRELOAD? Or just GNOME stuff? I thought bug-buddy already used breakpad? Oh, and don't forget that we need the debuginfo server (which I think Peter has been calling "littlebottom" to make these reports useful. > Investigate either submitting reports to Mozilla as well for Firefox > or create a system where our Socorro pushes reports to theirs. The latter seems like the Right Thing, but it depends on the previous actions. I wonder how caillon would feel about getting Firefox doing reports to Mozilla in the meantime. > Longer term investigate utrace system service instead of having apps > link to breakpad (this gets us non-desktop system crashes without > having to universally LD_PRELOAD or whatever). Yeah, I don't think we need to solve this until we've got the proof-of-concept stack: a couple of choice apps sending Breakpad reports (with debuginfo fetched from littlebottom) to our own Socorro instance. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From pablo.martin-gomez at laposte.net Mon Jun 23 20:21:05 2008 From: pablo.martin-gomez at laposte.net (Martin-Gomez Pablo) Date: Mon, 23 Jun 2008 22:21:05 +0200 Subject: Update for Gnome-do 0.5 In-Reply-To: <93d66b780806231156s732c5253y7d97cb4e68d09037@mail.gmail.com> References: <93d66b780806231156s732c5253y7d97cb4e68d09037@mail.gmail.com> Message-ID: <20080623222105.7cfbeb6c@laposte.net> Le Mon, 23 Jun 2008 15:56:38 -0300, "Mario Chacon" a ?crit : > > Hi! > > How Can i help to update the gnome-do to ?version ?0.5? > > > Thanks.. > Hi, Maybe by reading this bug : https://bugzilla.redhat.com/show_bug.cgi?id=451492 Regards From the.masch at gmail.com Mon Jun 23 20:31:56 2008 From: the.masch at gmail.com (Mario Chacon) Date: Mon, 23 Jun 2008 17:31:56 -0300 Subject: Update for Gnome-do 0.5 In-Reply-To: <20080623222105.7cfbeb6c@laposte.net> References: <93d66b780806231156s732c5253y7d97cb4e68d09037@mail.gmail.com> <20080623222105.7cfbeb6c@laposte.net> Message-ID: <93d66b780806231331g6bfd5ccbha285d034256b1799@mail.gmail.com> i will try that way. Thanks.. On Mon, Jun 23, 2008 at 5:21 PM, Martin-Gomez Pablo wrote: > Le Mon, 23 Jun 2008 15:56:38 -0300, > "Mario Chacon" a ?crit : > >> >> Hi! >> >> How Can i help to update the gnome-do to ?version ?0.5? >> >> >> Thanks.. >> > Hi, > > Maybe by reading this bug : > https://bugzilla.redhat.com/show_bug.cgi?id=451492 > > Regards > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kevin at scrye.com Mon Jun 23 21:41:46 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 15:41:46 -0600 Subject: Fedora Support channels Improvement ideas Message-ID: <20080623154146.6753ae91@ohm.scrye.com> Greetings. First of all, I am not sure this is the best place to discuss this, but I figured I would start here. If someone can think of a better venue I am happy to move discussion there. (Also, see the end of this mail where I suggest a brainstorming session on IRC). This weekend at Paul's State of Fedora talk at the end of the sessions on Saturday, he mentioned several areas where Fedora really could improve. One of these areas was the help that people get on the #fedora irc channel. I've been hanging out in that channel for the last year and a half, and I agree we could do a lot better than we have been, so I jotted some ideas down while waiting for my 5 hour delayed flight leaving boston. Lets look at where we are now first. End users can seek peer provided support from: - #fedora on irc.freenode.net - #fedora-XX (for lang specific support) on irc.freenode.net - The web based Fedora forum at http://fedoraforum.org - The fedora-list email list at: http://www.redhat.com/mailman/listinfo/fedora-list/ Currently as far as I know, all these efforts are managed by interested folks in each area, largely without any guidance from the Fedora Project itself. I'm going to focus now on the #fedora channel, because I know it. Perhaps some interested folks who are involved in the forum and/or the fedora-list can chime in here and talk about them? On the IRC channel I think there are a number of issues that we should address, here's just a few I came up with in a few minutes: - It's impossible for a user seeking help to know who they should listen to. Anyone can provide incorrect or bad advice, but it should be easier for them to identify that someone is representing Fedora and/or has helped lots of others and knows what they are talking about. - Sometimes no ops are around, so abusive or disruptive people aren't kicked out soon enough. - Sometimes no helpers are around, so questions just go unanswered. - Sometimes users are abused by folks that seem to be helping them. Always taking their questions very literally, pointing them to unhelpful sites, leading them on with a bunch of statements that don't help to get the users question figured out or problem solved. - Support is uneven. It would be good if there were clear guidelines what things were off topic and/or not supported. Most folks will tell users that Fedora versions without updates anymore (anything before f8 currently) aren't supported, but some people still try and assist them. - Sometimes users are upset with the way they have been treated, and they have no recourse to improve things or find out what they did wrong. Some possible solutions I think would be worth considering: - Form a 'Fedora Support' SIG to gather all the support channels under one org and start up some communication channels between them. Perhaps call it "Fedora HelpDesk" or "Fedora Helpers" or something to prevent people from confusing it with paid support. One possible problem with this is the legal aspect: Can folks who are in a SIG ofically representing Fedora talk about things like the livna repo or point people to those sources. (Many many many folks coming to #fedora for help ask about those). - Some way of showing who has been helpful on the IRC channel would be great. Perhaps some kind of karma system where users could add karma to people who are assisting and remove from those who are not, then a periodic report to the channel about the active users and their standing, or a pointer to a website with current stats. Perhaps freenode cloaks for the folks in the SIG/group. - Some guidelines people could look at for the channel. What is specifically supported. What is not. A list of items that will get you removed from the channel. A way to address a complaint to the SIG that will get mediated and checked. Specific HOWTO's or docs that should be used to help users. - Scheduled Shifts for SIG members, listed somewhere people could look. Ideally we could get enough people to always have someone available to help. If not, we could clearly show that it was "after hours" and come back when helpers are around. - Scheduled Shifts for OP's. Ideally we would always have an active OP around who could take care of abusive or disruptive people, based on the guidelines. - Training for helpers and/or open to the Fedora community. Get a rotating group of people to do a class on irc once a week on some topic or SIG. Regular meetings of the SIG could help show other support channels what questions are "hot" and the best answers to them. - A bot might be useful to implement some of these things, allowing users to check karma, get pointers to guidelines or resources, etc. Thats just a few ideas to get things going. I propose that any interested parties meet on #fedora-meeting later this week and brainstorm ideas. Anyone interested in attending, please send me an email what times you are available on thursday or friday of this week and we see what we can come up with. Hopefully the idea isn't all bad. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From walters at verbum.org Mon Jun 23 21:57:10 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 23 Jun 2008 17:57:10 -0400 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623154146.6753ae91@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: 2008/6/23 Kevin Fenzi : > > This weekend at Paul's State of Fedora talk at the end of the sessions > on Saturday, he mentioned several areas where Fedora really could > improve. One of these areas was the help that people get on the #fedora > irc channel. I think IRC is kind of fundamentally doomed because of the culture. If we want to emphasize a support medium, the forum is much nicer: http://forums.fedoraforum.org/forumdisplay.php?f=7 It has decent search (and unlike Bugzilla your forum thread won't vanish from search because it's too old or got fixed, grrr) The live aspect of IRC is nice though; Mozilla has been doing some work on live chat support which looks potentially useful: http://support.mozilla.com/en-US/kb/Live+Chat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Mon Jun 23 22:05:31 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 24 Jun 2008 00:05:31 +0200 Subject: Fedora Support channels Improvement ideas In-Reply-To: References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: <20080623220531.GA15528@mokona.greysector.net> On Monday, 23 June 2008 at 23:57, Colin Walters wrote: > 2008/6/23 Kevin Fenzi : > > > > > This weekend at Paul's State of Fedora talk at the end of the sessions > > on Saturday, he mentioned several areas where Fedora really could > > improve. One of these areas was the help that people get on the #fedora > > irc channel. > > > I think IRC is kind of fundamentally doomed because of the culture. It's possible to keep small channels (<50 people) nice and civil, but with more people, it's not really viable unless you have an op watching at all times. > If we want to emphasize a support medium, the forum is much nicer: > > http://forums.fedoraforum.org/forumdisplay.php?f=7 > > It has decent search (and unlike Bugzilla your forum thread won't vanish > from search because it's too old or got fixed, grrr) I, for one, detest the forums (any forums) for their terrible user interface. Mailing lists or usenet newsgroups are much more convenient to use. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From kevin at scrye.com Mon Jun 23 22:09:22 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 16:09:22 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: <20080623160922.7dd2678c@ohm.scrye.com> On Mon, 23 Jun 2008 17:57:10 -0400 walters at verbum.org ("Colin Walters") wrote: > 2008/6/23 Kevin Fenzi : > > > > > This weekend at Paul's State of Fedora talk at the end of the > > sessions on Saturday, he mentioned several areas where Fedora > > really could improve. One of these areas was the help that people > > get on the #fedora irc channel. > > > I think IRC is kind of fundamentally doomed because of the culture. Well, I agree there are issues to be overcome, but I think it's worth us trying to provide all the support channels we can, eventually even (if enough people are insane enough to want to): call in support (fedora talk rocks!) :) > If we want to emphasize a support medium, the forum is much nicer: > > http://forums.fedoraforum.org/forumdisplay.php?f=7 > > It has decent search (and unlike Bugzilla your forum thread won't > vanish from search because it's too old or got fixed, grrr) Sure, I think forums work great for some people... I would love to see the forum people talking to the irc people talking to the mailing list people and each providing the support they like to provide. I have no real idea who runs the forum... are we likely to get them seeing this thread? > The live aspect of IRC is nice though; Mozilla has been doing some > work on live chat support which looks potentially useful: > http://support.mozilla.com/en-US/kb/Live+Chat Yeah, that would be potentially very nice to use... We could point that at the #fedora channel if we can get it setup better. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sandeen at redhat.com Mon Jun 23 22:11:27 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 23 Jun 2008 17:11:27 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623220531.GA15528@mokona.greysector.net> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> Message-ID: <48601F8F.4090909@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 June 2008 at 23:57, Colin Walters wrote: >> 2008/6/23 Kevin Fenzi : >> >>> This weekend at Paul's State of Fedora talk at the end of the sessions >>> on Saturday, he mentioned several areas where Fedora really could >>> improve. One of these areas was the help that people get on the #fedora >>> irc channel. >> >> I think IRC is kind of fundamentally doomed because of the culture. > > It's possible to keep small channels (<50 people) nice and civil, but > with more people, it's not really viable unless you have an op watching > at all times. What if there were #fedora-filesystems, #fedora-gnome, #fedora-sound, $fedora-$WHATEVER to focus the discussions & keep things a bit more manageable? Or is that just many more tabs for the fedora-keepers to lurk in... >> If we want to emphasize a support medium, the forum is much nicer: >> >> http://forums.fedoraforum.org/forumdisplay.php?f=7 >> >> It has decent search (and unlike Bugzilla your forum thread won't vanish >> from search because it's too old or got fixed, grrr) > > I, for one, detest the forums (any forums) for their terrible user > interface. Mailing lists or usenet newsgroups are much more convenient > to use. Amen. :) -Eric From smooge at gmail.com Mon Jun 23 22:12:17 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 23 Jun 2008 16:12:17 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623220531.GA15528@mokona.greysector.net> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> Message-ID: <80d7e4090806231512o4df29be6gefe8ee2a3f64a4f@mail.gmail.com> On Mon, Jun 23, 2008 at 4:05 PM, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 23 June 2008 at 23:57, Colin Walters wrote: >> 2008/6/23 Kevin Fenzi : >> >> > >> > This weekend at Paul's State of Fedora talk at the end of the sessions >> > on Saturday, he mentioned several areas where Fedora really could >> > improve. One of these areas was the help that people get on the #fedora >> > irc channel. >> >> >> I think IRC is kind of fundamentally doomed because of the culture. > > It's possible to keep small channels (<50 people) nice and civil, but > with more people, it's not really viable unless you have an op watching > at all times. > >> If we want to emphasize a support medium, the forum is much nicer: >> >> http://forums.fedoraforum.org/forumdisplay.php?f=7 >> >> It has decent search (and unlike Bugzilla your forum thread won't vanish >> from search because it's too old or got fixed, grrr) > > I, for one, detest the forums (any forums) for their terrible user > interface. Mailing lists or usenet newsgroups are much more convenient > to use. > I have to agree... having tried to do Red Hat support through Forums before.. it was pretty broken ( a long rant has been deleted due to not wanting to put on another eyepatch). The interface in forums does not seem to be any more different from 1999/2000 to now. If anything, you want something that combines mail and forums.. I need to look at the mailman patches for that. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Mon Jun 23 22:14:45 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 23 Jun 2008 16:14:45 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623160922.7dd2678c@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623160922.7dd2678c@ohm.scrye.com> Message-ID: <80d7e4090806231514s41c64748q9ea1419e54f6a983@mail.gmail.com> 2008/6/23 Kevin Fenzi : > On Mon, 23 Jun 2008 17:57:10 -0400 > walters at verbum.org ("Colin Walters") wrote: > >> 2008/6/23 Kevin Fenzi : >> >> > >> > This weekend at Paul's State of Fedora talk at the end of the >> > sessions on Saturday, he mentioned several areas where Fedora >> > really could improve. One of these areas was the help that people >> > get on the #fedora irc channel. >> >> >> I think IRC is kind of fundamentally doomed because of the culture. > > Well, I agree there are issues to be overcome, but I think it's worth > us trying to provide all the support channels we can, eventually even > (if enough people are insane enough to want to): call in support > (fedora talk rocks!) :) > >> If we want to emphasize a support medium, the forum is much nicer: >> >> http://forums.fedoraforum.org/forumdisplay.php?f=7 >> >> It has decent search (and unlike Bugzilla your forum thread won't >> vanish from search because it's too old or got fixed, grrr) > > Sure, I think forums work great for some people... I would love to see Yeah I have seen some people able to wrap their midns around it.. me I just can't focus on the forums and my email and my IRC sessions. > the forum people talking to the irc people talking to the mailing list > people and each providing the support they like to provide. > I have no real idea who runs the forum... are we likely to get them > seeing this thread? > >> The live aspect of IRC is nice though; Mozilla has been doing some >> work on live chat support which looks potentially useful: >> http://support.mozilla.com/en-US/kb/Live+Chat > > Yeah, that would be potentially very nice to use... > We could point that at the #fedora channel if we can get it setup > better. > The big issue with IRC is that when you are in crisis mode, you want to focus on one 'thread' at a time.. and IRC ends up getting lolcat threads with 'kernel corrupted ext3 node' in horrible ways. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pemboa at gmail.com Mon Jun 23 22:15:01 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 23 Jun 2008 17:15:01 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <48601F8F.4090909@redhat.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> Message-ID: <16de708d0806231515o2cde32d2s5d37b91ae47a8dd@mail.gmail.com> On Mon, Jun 23, 2008 at 5:11 PM, Eric Sandeen wrote: > Dominik 'Rathann' Mierzejewski wrote: >> On Monday, 23 June 2008 at 23:57, Colin Walters wrote: >>> 2008/6/23 Kevin Fenzi : >>> >>>> This weekend at Paul's State of Fedora talk at the end of the sessions >>>> on Saturday, he mentioned several areas where Fedora really could >>>> improve. One of these areas was the help that people get on the #fedora >>>> irc channel. >>> >>> I think IRC is kind of fundamentally doomed because of the culture. >> >> It's possible to keep small channels (<50 people) nice and civil, but >> with more people, it's not really viable unless you have an op watching >> at all times. > > What if there were #fedora-filesystems, #fedora-gnome, #fedora-sound, > $fedora-$WHATEVER to focus the discussions & keep things a bit more > manageable? Or is that just many more tabs for the fedora-keepers to > lurk in... That seems the most feasible solution to me. Java applets to connect to an appropriate channel from the fedora website would also be useful (to ease the barrier to entry) -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Mon Jun 23 22:20:15 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 Jun 2008 14:20:15 -0800 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623154146.6753ae91@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: <604aa7910806231520y3c9d823fi6dbb47a0cf203e0c@mail.gmail.com> 2008/6/23 Kevin Fenzi : > - Form a 'Fedora Support' SIG to gather all the support channels under > one org and start up some communication channels between them. > Perhaps call it "Fedora HelpDesk" or "Fedora Helpers" or something to > prevent people from confusing it with paid support. This has been kicked around for a while now. The idea needs a leader to organize the space. Form the SIG and see who shows up willing to put in effort. > - Some way of showing who has been helpful on the IRC channel would be > great. Perhaps some kind of karma system where users could add karma to > people who are assisting and remove from those who are not, then a > periodic report to the channel about the active users and their > standing, or a pointer to a website with current stats. Perhaps > freenode cloaks for the folks in the SIG/group. I have a hard time envisioning how evaluate the quality of help without introducing significant personal bias. Its beyond me, but that shouldn't stop you from finding a way to do it. I would certainly appreciate having a metric by which to trend. > > - Some guidelines people could look at for the channel. What is > specifically supported. What is not. A list of items that will get you > removed from the channel. A way to address a complaint to the SIG that > will get mediated and checked. Specific HOWTO's or docs that should be > used to help users. I think this would be priority #1 for a SIG in this area. In fact I think I'm in agreement with the rest of what you said, in the order you said it as a priority list... its been said before. We need to either attempt it or we stop talking about it and move on. If you want to re-use #fedora and other existing channels you'll need to make an effort to get the ops on those channels in on the SIG work to draft the guidelines. The more of the existing ops you can have in the guideline formulation, and the more who affirm their personal commitment to the final guidelines the less of a fight we'll have when it comes time to do the re-org. -jef"If I've been voted out of office, I'll definitely be participating heavily in the SIG discussions."spaleta From sonar_guy at c-ccom.com Mon Jun 23 22:35:07 2008 From: sonar_guy at c-ccom.com (Scott Glaser) Date: Mon, 23 Jun 2008 18:35:07 -0400 Subject: Fedora Support channels Improvement ideas In-Reply-To: <16de708d0806231515o2cde32d2s5d37b91ae47a8dd@mail.gmail.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <16de708d0806231515o2cde32d2s5d37b91ae47a8dd@mail.gmail.com> Message-ID: <1214260507.7924.10.camel@localhost.localdomain> On Mon, 2008-06-23 at 17:15 -0500, Arthur Pemberton wrote: > That seems the most feasible solution to me. Java applets to connect > to an appropriate channel from the fedora website would also be useful > (to ease the barrier to entry) As one of the current OP's #fedora, I think that starting with a basic #fedora channel guideline would be the best way to start. Then the users would know what is tolerated and what is not, it would also cover guidelines for the OP's as far as code of conduct and what is grounds for a ban/kick including time frames for each. When I became and OP 2 years ago it was here you go your an OP now. This was done due to the lack of OPs at the time. Several of us were thrown into this position this way. Not a good way to start in the channel. It would have been nice to have a reference at that time. I am also one of the "Helpers" in the channel, I help many people to the best of my ability. I do know quite a bit as I have been running *nix since 1998 but I still have many things to learn. So I agree with the proposed training sessions. I am also one of the founders of Fedora Unity and the reason we set it up was to document many of the items that could not be covered in the Installation Guide due to legalities. I think we have done a pretty good job but it would be nice if we could do better. I am all for the the changes and believe it needs to start with guidelines first, all the other things could be implemented at a later time but the guidelines are needed NOW!! The guidelines would instantly improve the quality of the channel in short time. V/R Scott Glaser Fedora Unity From walters at verbum.org Mon Jun 23 23:08:17 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 23 Jun 2008 19:08:17 -0400 Subject: apport/breakpad and fedora In-Reply-To: <1214251935.29455.79.camel@metroid.rdu.redhat.com> References: <1214251935.29455.79.camel@metroid.rdu.redhat.com> Message-ID: 2008/6/23 Will Woods : > > > > If I remember right, the reason for this part of the discussion was: > > 1) Linking everything on the system to breakpad is a bit nasty. > 2) Apport doesn't need to be linked in, but it runs *after* the process > gets dumped by the kernel. At which point it's slightly different from > when it actually crashed. Yeah, sounds right. pjones' idea was to have a system service that would receive > notification of segfaults and use utrace to stop the process and > generate a (breakpad-style report). > He was thinking of hooking it into kerneloops, right? (Hm, I didn't seem to have that installed on my F9 system which was upgraded from F8...I guess this is a generic problem with new comps packages and upgrades; need to solve that) Though isn't there a race between when we get the kernel notification and when the service stops it and inspects? Not my area of expertise really, just thinking out loud. > It would make the 'debuginfo-install' message go away, because (if DAV + > FUSE does the right thing) you'll have all the debuginfo you need, in > the right place - mounted as a FUSE filesystem. Ah, ok. > > My 2? - Link in breakpad, create http://crash.fedoraproject.org > > running Socorro. > > Link it into what? Everything, via LD_PRELOAD? Or just GNOME stuff? I > thought bug-buddy already used breakpad? I'm personally most interested in the desktop apps because, well we desktop developers are masochists and code complex user-facing code in C/C++, and not surprisingly they crash =) So right now...hm, actually this is weird, I can't get any Fedora-compiled program to spawn bug-buddy at all right now. I get it for some local custom code, but not for anything in /usr/bin. I see libgnomebreakpad is linked into the process. I'm out of time for this issue for today, I'll investigate a bit more later. > > The latter seems like the Right Thing, but it depends on the previous > actions. I wonder how caillon would feel about getting Firefox doing > reports to Mozilla in the meantime. Yeah, we should probably disable GTK+'s bug-buddy breakpad module for Firefox for now. > Longer term investigate utrace system service instead of having apps > > link to breakpad (this gets us non-desktop system crashes without > > having to universally LD_PRELOAD or whatever). > > Yeah, I don't think we need to solve this until we've got the > proof-of-concept stack: a couple of choice apps sending Breakpad reports > (with debuginfo fetched from littlebottom) to our own Socorro instance. > Ok cool. Should we create a feature proposal wiki page for this, or repurpose the old Apport one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Tue Jun 24 01:55:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 23 Jun 2008 21:55:34 -0400 Subject: Fedora Support channels Improvement ideas In-Reply-To: <48601F8F.4090909@redhat.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> Message-ID: <1214272534.3172.63.camel@localhost.localdomain> On Mon, 2008-06-23 at 17:11 -0500, Eric Sandeen wrote: > What if there were #fedora-filesystems, #fedora-gnome, #fedora-sound, > $fedora-$WHATEVER to focus the discussions & keep things a bit more > manageable? Or is that just many more tabs for the fedora-keepers to > lurk in... One thing to keep in mind is that freenode has a max number of channels permitted. Not sure what it is offhand, but I do know that I occasionally hit it as is, and tiering things out will simply make that more prevalent. As the "super-op" for all things Fedora/Red Hat IRC, I agree with pretty much everything Kevin has said. I've been planning to write an IRC "code of conduct" for some time, but I've not yet gotten that far down my todo list. A few things we should consider: 1. Office hours. People who sign up to be "official" helpers during a regular shift can get +v, making them easily identifiable to people looking for help. We can document this in the topic (or in a FAQ URL). 2. Auditing. It might not be a bad idea to put a very simple logging bot in #fedora which just logs the channel text. This would also help us track abuse in a more reliable way than how it is now ("This guy is being abusive.") I think OP shifts are also great ideas, I'd be willing to take a few. We may need to take a look at who the ops are currently. Folks who haven't been active or helpful may need to be replaced. WRT bots, we just need to keep the noise level from any bots to a bare minimum. Perhaps tie it into a user list so that helpers and chanops can have it speak in channel, and all other queries go to the user in privmsg. I won't be around for the meeting on Thursday, because I'm on vacation (not that you can tell from my emails), but I'm interested in participating. ~spot From sonar_guy at c-ccom.com Tue Jun 24 02:40:34 2008 From: sonar_guy at c-ccom.com (Scott Glaser) Date: Mon, 23 Jun 2008 22:40:34 -0400 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214272534.3172.63.camel@localhost.localdomain> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> Message-ID: <1214275234.21467.7.camel@localhost.localdomain> On Mon, 2008-06-23 at 21:55 -0400, Tom "spot" Callaway wrote: > As the "super-op" for all things Fedora/Red Hat IRC, I agree with pretty > much everything Kevin has said. I've been planning to write an IRC "code > of conduct" for some time, but I've not yet gotten that far down my todo > list. I would be more than willing to assist in working on the "code of conduct" with you. It has one thing that I would have liked to see from day one. > > A few things we should consider: > > 1. Office hours. People who sign up to be "official" helpers during a > regular shift can get +v, making them easily identifiable to people > looking for help. We can document this in the topic (or in a FAQ URL). I am willing to take shifts as both "Official Helper" and/or OP as needed. I am in #fedora almost every night between 6pm and 11pm EST, so it would not be much of an issue. > > 2. Auditing. It might not be a bad idea to put a very simple logging bot > in #fedora which just logs the channel text. This would also help us > track abuse in a more reliable way than how it is now ("This guy is > being abusive.") I think auditing would be great, as most of us who help and/or participate currently as ops already do logging just so we see what the hot-topics are, and to identify potential trouble makers in the channel. Also most of the current ops communicate regularly which helps. > We may need to take a look at who the ops are currently. Folks who > haven't been active or helpful may need to be replaced. There are a few of those such as corwyn who is no longer involved in fedora or fedora-unity/ > WRT bots, we just need to keep the noise level from any bots to a bare > minimum. Perhaps tie it into a user list so that helpers and chanops can > have it speak in channel, and all other queries go to the user in > privmsg. I see this as important as once people determine there is a bot in the channel tend to play with the bot to see what it can do. V/R Scott Glaser From jwilliam at xmission.com Tue Jun 24 04:33:16 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Mon, 23 Jun 2008 22:33:16 -0600 Subject: Help building rpm, works with f8 fails in f9 Message-ID: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> I could use some help trying to figure out why a package builds just fine on Fedora 8 but fails on Fedora 9 Fedora 8 build output looks like: make[1]: Leaving directory `/usr/src/redhat/BUILD/crrcsim-0.9.9' + desktop-file-install --vendor= --dir=/usr/share/applications --add-category X-Red-Hat-Extra /usr/src/redhat/SOURCES/CRRCsim.desktop + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/crrcsim-0.9.9 extracting debug info from ./crrcsim 2702 blocks Fedora 9 looks like: make[1]: Leaving directory `/usr/src/redhat/BUILD/crrcsim-0.9.9' + desktop-file-install --vendor= --dir=/usr/share/applications --add-category X- Red-Hat-Extra /usr/src/redhat/SOURCES/CRRCsim.desktop + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/crrcsim-0.9.9 find: invalid predicate `' error: Bad exit status from /var/tmp/rpm-tmp.13280 (%install) SPEC file looks like: # cat crrcsim.spec Summary: A Model-Airplane Flight Simulation Program Name: crrcsim Version: 0.9.9 Release: 1.fc8 License: GPL Group: Amusements/Games URL: http://crrcsim.sourceforge.net/ Source0: %{name}-%{version}.tar.gz Source1: CRRCsim.desktop Requires: plib Requires: portaudio Requires: SDL BuildPrereq: SDL-devel BuildPrereq: portaudio-devel BuildPrereq: freeglut-devel BuildPrereq: plib-devel BuildPrereq: libXi-devel BuildPrereq: libXt-devel BuildPrereq: libXmu-devel BuildRequires: desktop-file-utils %description Crrcsim is a model-airplane flight simulation program. Using it, you can learn how to fly model aircraft, test new aircraft designs, and improve your skills by practicing on your computer. It rules! The flight model is very realistic. The flight model parameters are calculated based on a 3D representation of the aircraft. Stalls are properly modelled as well. Model control is possible with your own rc transmitter, or any input device such as joystick, mouse, keyboard ... %prep %setup -q %build ./configure make %install rm -rf %{buildroot} #make DESTDIR=%{buildroot} install make install desktop-file-install --vendor="" \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ --add-category X-Red-Hat-Extra \ ${RPM_SOURCE_DIR}/CRRCsim.desktop %clean rm -rf %{buildroot} %files %defattr(-,root,root) /usr/local/share/games/crrcsim /usr/local/bin/crrcsim /usr/share/applications/CRRCsim.desktop I am not sure if this is the best place to post this message, if there is a better list, please let me know. Thanks is advance for any help! Jerry Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Tue Jun 24 04:35:23 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 22:35:23 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214272534.3172.63.camel@localhost.localdomain> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> Message-ID: <20080623223523.03421999@ohm.scrye.com> On Mon, 23 Jun 2008 21:55:34 -0400 tcallawa at redhat.com ("Tom \"spot\" Callaway") wrote: > On Mon, 2008-06-23 at 17:11 -0500, Eric Sandeen wrote: > > What if there were #fedora-filesystems, #fedora-gnome, > > #fedora-sound, $fedora-$WHATEVER to focus the discussions & keep > > things a bit more manageable? Or is that just many more tabs for > > the fedora-keepers to lurk in... > > One thing to keep in mind is that freenode has a max number of > channels permitted. Not sure what it is offhand, but I do know that I > occasionally hit it as is, and tiering things out will simply make > that more prevalent. Agreed. Also, expecting users to find some subchannel is impossible. Many folks are new to Linux and Fedora and even have a hard time articulating their questions. Many have multiple questions on various subjects. There are surely some cases where people are reffered to other channels, ie, if they have a selinux question that no one in #fedora can figure out, they are sent to #selinux, if they are running rawhide and have a complex question, they can go ask in #fedora-devel, etc. > As the "super-op" for all things Fedora/Red Hat IRC, I agree with > pretty much everything Kevin has said. I've been planning to write an > IRC "code of conduct" for some time, but I've not yet gotten that far > down my todo list. Yeah. We can help things along and get something drafted that you can review. ;) > A few things we should consider: > > 1. Office hours. People who sign up to be "official" helpers during a > regular shift can get +v, making them easily identifiable to people > looking for help. We can document this in the topic (or in a FAQ URL). Ah ha. We will have to see if +v shows up enough for people, but thats a great idea. > 2. Auditing. It might not be a bad idea to put a very simple logging > bot in #fedora which just logs the channel text. This would also help > us track abuse in a more reliable way than how it is now ("This guy is > being abusive.") Agreed. I think that would be great. > I think OP shifts are also great ideas, I'd be willing to take a few. Excellent. > We may need to take a look at who the ops are currently. Folks who > haven't been active or helpful may need to be replaced. Yeah, we will want to go over the list. > WRT bots, we just need to keep the noise level from any bots to a bare > minimum. Perhaps tie it into a user list so that helpers and chanops > can have it speak in channel, and all other queries go to the user in > privmsg. Agreed. I think that would be fine. There are some cases where going to the channel might be good, like saying when shifts change and who the new helpers are, etc. > I won't be around for the meeting on Thursday, because I'm on vacation > (not that you can tell from my emails), but I'm interested in > participating. Excellent. We can try and hold a meeting/brainstorming session this week and see about ideas moving forward. Hopefully we are going to meet more and get more ideas moving forward. > ~spot kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at scrye.com Tue Jun 24 04:38:34 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 22:38:34 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <604aa7910806231520y3c9d823fi6dbb47a0cf203e0c@mail.gmail.com> References: <20080623154146.6753ae91@ohm.scrye.com> <604aa7910806231520y3c9d823fi6dbb47a0cf203e0c@mail.gmail.com> Message-ID: <20080623223834.64c6f607@ohm.scrye.com> On Mon, 23 Jun 2008 14:20:15 -0800 jspaleta at gmail.com ("Jeff Spaleta") wrote: > 2008/6/23 Kevin Fenzi : > > - Form a 'Fedora Support' SIG to gather all the support channels > > under one org and start up some communication channels between them. > > Perhaps call it "Fedora HelpDesk" or "Fedora Helpers" or something > > to prevent people from confusing it with paid support. > > This has been kicked around for a while now. The idea needs a leader > to organize the space. Form the SIG and see who shows up willing to > put in effort. Yeah, I am willing to lead such an effort. It's past due and I am happy to make it happen. > > - Some way of showing who has been helpful on the IRC channel would > > be great. Perhaps some kind of karma system where users could add > > karma to people who are assisting and remove from those who are > > not, then a periodic report to the channel about the active users > > and their standing, or a pointer to a website with current stats. > > Perhaps freenode cloaks for the folks in the SIG/group. > > I have a hard time envisioning how evaluate the quality of help > without introducing significant personal bias. Its beyond me, but > that shouldn't stop you from finding a way to do it. I would certainly > appreciate having a metric by which to trend. Well, if we used some kind of karma then people who at least pleased users would be rated up. That might mean they answered questions well, or in a good enough manner that users were happy they were at least being addressed. > > - Some guidelines people could look at for the channel. What is > > specifically supported. What is not. A list of items that will get > > you removed from the channel. A way to address a complaint to the > > SIG that will get mediated and checked. Specific HOWTO's or docs > > that should be used to help users. > > I think this would be priority #1 for a SIG in this area. In fact I > think I'm in agreement with the rest of what you said, in the order > you said it as a priority list... its been said before. We need to > either attempt it or we stop talking about it and move on. I am going to attempt it. Any help welcome. > If you want to re-use #fedora and other existing channels you'll need > to make an effort to get the ops on those channels in on the SIG work > to draft the guidelines. The more of the existing ops you can have in > the guideline formulation, and the more who affirm their personal > commitment to the final guidelines the less of a fight we'll have when > it comes time to do the re-org. Agreed 100% > -jef"If I've been voted out of office, I'll definitely be > participating heavily in the SIG discussions."spaleta :) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at scrye.com Tue Jun 24 04:40:58 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 22:40:58 -0600 Subject: Fedora Support channels Improvement ideas Message-ID: <20080623224058.439dfdb3@ohm.scrye.com> > On Mon, 2008-06-23 at 17:15 -0500, Arthur Pemberton wrote: > > That seems the most feasible solution to me. Java applets to connect > > to an appropriate channel from the fedora website would also be > > useful (to ease the barrier to entry) > > As one of the current OP's #fedora, I think that starting with a basic > #fedora channel guideline would be the best way to start. Then the > users would know what is tolerated and what is not, it would also > cover guidelines for the OP's as far as code of conduct and what is > grounds for a ban/kick including time frames for each. Agreed. Perhaps we can draft something rough this week and polish it over the next few. > When I became and OP 2 years ago it was here you go your an OP now. > This was done due to the lack of OPs at the time. Several of us were > thrown into this position this way. Not a good way to start in the > channel. It would have been nice to have a reference at that time. > > I am also one of the "Helpers" in the channel, I help many people to > the best of my ability. I do know quite a bit as I have been running > *nix since 1998 but I still have many things to learn. So I agree > with the proposed training sessions. > > I am also one of the founders of Fedora Unity and the reason we set it > up was to document many of the items that could not be covered in the > Installation Guide due to legalities. I think we have done a pretty > good job but it would be nice if we could do better. > > I am all for the the changes and believe it needs to start with > guidelines first, all the other things could be implemented at a later > time but the guidelines are needed NOW!! The guidelines would > instantly improve the quality of the channel in short time. Agreed again. It seems that's the priority for the SIG. > V/R > > Scott Glaser > Fedora Unity kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at scrye.com Tue Jun 24 04:43:30 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 22:43:30 -0600 Subject: Fedora Support channels Improvement ideas Message-ID: <20080623224330.01946927@ohm.scrye.com> > On Mon, 2008-06-23 at 21:55 -0400, Tom "spot" Callaway wrote: > > > As the "super-op" for all things Fedora/Red Hat IRC, I agree with > > pretty much everything Kevin has said. I've been planning to write > > an IRC "code of conduct" for some time, but I've not yet gotten > > that far down my todo list. > > I would be more than willing to assist in working on the "code of > conduct" with you. It has one thing that I would have liked to see > from day one. I think we could work on such at a meeting and then run it by spot for correction/checkover. > > A few things we should consider: > > > > 1. Office hours. People who sign up to be "official" helpers during > > a regular shift can get +v, making them easily identifiable to > > people looking for help. We can document this in the topic (or in a > > FAQ URL). > > I am willing to take shifts as both "Official Helper" and/or OP as > needed. I am in #fedora almost every night between 6pm and 11pm EST, > so it would not be much of an issue. Yeah, me too. Hopefully we get enough people to pull things off. > > 2. Auditing. It might not be a bad idea to put a very simple > > logging bot in #fedora which just logs the channel text. This would > > also help us track abuse in a more reliable way than how it is now > > ("This guy is being abusive.") > > I think auditing would be great, as most of us who help and/or > participate currently as ops already do logging just so we see what > the hot-topics are, and to identify potential trouble makers in the > channel. Also most of the current ops communicate regularly which > helps. Yeah, also good. > > We may need to take a look at who the ops are currently. Folks who > > haven't been active or helpful may need to be replaced. > > There are a few of those such as corwyn who is no longer involved in > fedora or fedora-unity/ Yeah, the list will need updating. > > WRT bots, we just need to keep the noise level from any bots to a > > bare minimum. Perhaps tie it into a user list so that helpers and > > chanops can have it speak in channel, and all other queries go to > > the user in privmsg. > > I see this as important as once people determine there is a bot in the > channel tend to play with the bot to see what it can do. Agreed. It shouldn't normally answer users on channel at least. > V/R > > Scott Glaser kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pemboa at gmail.com Tue Jun 24 04:44:32 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 23 Jun 2008 23:44:32 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623223523.03421999@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> <20080623223523.03421999@ohm.scrye.com> Message-ID: <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> 2008/6/23 Kevin Fenzi : [ snip ] > Agreed. Also, expecting users to find some subchannel is impossible. I don't see how someone can find #fedora, but not #fedora-kde. How do you see that? We could put up a page directing people. > Many folks are new to Linux and Fedora and even have a hard time > articulating their questions. Many have multiple questions on various > subjects. such a person would go to the "general" list > There are surely some cases where people are reffered to other > channels, ie, if they have a selinux question that no one in #fedora > can figure out, they are sent to #selinux, if they are running rawhide > and have a complex question, they can go ask in #fedora-devel, etc. quite true, more would be better IMHO [ snip ] -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From kevin at scrye.com Tue Jun 24 04:49:13 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 23 Jun 2008 22:49:13 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> <20080623223523.03421999@ohm.scrye.com> <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> Message-ID: <20080623224913.6377a551@ohm.scrye.com> On Mon, 23 Jun 2008 23:44:32 -0500 pemboa at gmail.com ("Arthur Pemberton") wrote: > 2008/6/23 Kevin Fenzi : > [ snip ] > > > Agreed. Also, expecting users to find some subchannel is impossible. > > I don't see how someone can find #fedora, but not #fedora-kde. How do > you see that? > We could put up a page directing people. New users often don't know where their problem is. If my system locks up when I login to the desktop, would I look for #fedora-kernel? Or #fedora-gnome? Do I even know I am running gnome? I think spreading our resources this way is a bad idea. > > > Many folks are new to Linux and Fedora and even have a hard time > > articulating their questions. Many have multiple questions on > > various subjects. > > such a person would go to the "general" list ok. Many people don't realize they have many questions until the first is answered and leads to another however. > > There are surely some cases where people are reffered to other > > channels, ie, if they have a selinux question that no one in #fedora > > can figure out, they are sent to #selinux, if they are running > > rawhide and have a complex question, they can go ask in > > #fedora-devel, etc. > > quite true, more would be better IMHO > > [ snip ] I agree, but only where such channels have a community of users and other purpose. I think trying to start such for purely support reasons is spreading our limited resources too thin. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pemboa at gmail.com Tue Jun 24 04:54:46 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 23 Jun 2008 23:54:46 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623224913.6377a551@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> <20080623223523.03421999@ohm.scrye.com> <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> <20080623224913.6377a551@ohm.scrye.com> Message-ID: <16de708d0806232154o1eae84c4i5ce0a7729d007ff2@mail.gmail.com> 2008/6/23 Kevin Fenzi : > On Mon, 23 Jun 2008 23:44:32 -0500 > pemboa at gmail.com ("Arthur Pemberton") wrote: > >> 2008/6/23 Kevin Fenzi : >> [ snip ] >> >> > Agreed. Also, expecting users to find some subchannel is impossible. >> >> I don't see how someone can find #fedora, but not #fedora-kde. How do >> you see that? >> We could put up a page directing people. > > New users often don't know where their problem is. If my system locks > up when I login to the desktop, would I look for #fedora-kernel? Or > #fedora-gnome? Do I even know I am running gnome? I would think that they could go to #fedora and be directed appropriately > I think spreading our resources this way is a bad idea. How is this spreading our resources? One person can have multiple IRC tabs open, no? >> > Many folks are new to Linux and Fedora and even have a hard time >> > articulating their questions. Many have multiple questions on >> > various subjects. >> >> such a person would go to the "general" list > > ok. Many people don't realize they have many questions until the first > is answered and leads to another however. Fair enough, not sure if you're agreeing or rebutting however. >> > There are surely some cases where people are reffered to other >> > channels, ie, if they have a selinux question that no one in #fedora >> > can figure out, they are sent to #selinux, if they are running >> > rawhide and have a complex question, they can go ask in >> > #fedora-devel, etc. >> >> quite true, more would be better IMHO >> >> [ snip ] > > I agree, but only where such channels have a community of users and > other purpose. I think trying to start such for purely support reasons > is spreading our limited resources too thin. I don't really see how having multiple resources equals spreading resources. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sundaram at fedoraproject.org Tue Jun 24 05:15:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 24 Jun 2008 10:45:23 +0530 Subject: Fedora Support channels Improvement ideas In-Reply-To: <16de708d0806232154o1eae84c4i5ce0a7729d007ff2@mail.gmail.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> <20080623223523.03421999@ohm.scrye.com> <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> <20080623224913.6377a551@ohm.scrye.com> <16de708d0806232154o1eae84c4i5ce0a7729d007ff2@mail.gmail.com> Message-ID: <486082EB.6020403@fedoraproject.org> Arthur Pemberton wrote: > 2008/6/23 Kevin Fenzi : > > I would think that they could go to #fedora and be directed appropriately > >> I think spreading our resources this way is a bad idea. > > How is this spreading our resources? One person can have multiple IRC > tabs open, no? Freenode has a limit per project however and opening more tabs makes it hard to follow the conversations unless it is specifically directed at you. This isn't specific to IRC channels. More mailing lists have similar problems too. Rahul From rawhide at fedoraproject.org Tue Jun 24 09:36:01 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 24 Jun 2008 09:36:01 +0000 (UTC) Subject: rawhide report: 20080624 changes Message-ID: <20080624093601.4F94A209D3D@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080623/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080624/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package garmin-sync Download data from Garmin fitness computers New package ocsinventory Open Computer and Software Inventory Next Generation New package perl-Crypt-CAST5_PP CAST5 block cipher in pure Perl New package perl-Mail-DKIM Sign and verify Internet mail with DKIM/DomainKey signatures New package pyusb Python bindings for libusb Updated Packages: anaconda-11.4.1.8-1 ------------------- * Mon Jun 23 18:00:00 2008 Jeremy Katz - 11.4.1.8-1 - Remove from being installed too (katzj) - Remove anaconda-runtime as a separate subpackage (katzj) - Remove the stuff we're not calling. (pjones) - Remove this since we don't use it anymore (katzj) - Don't continue on using the base installclass if we can't find one (katzj) - Get rid of wlite and unicode-lite; these were necessary to support (pjones) - Remove pkgorder and splittree; these should be in pungi (katzj) - Add the .treeinfo file into the exception report. (clumens) - Fix a typo (#452140). (clumens) brasero-0.7.90-1.fc10 --------------------- * Wed Jun 11 18:00:00 2008 Denis Leroy - 0.7.90-1 - Update to unstable 0.7.90 - Added patch to validate desktop file - BRs updated compiz-0.7.6-7.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Adel Gadllah - 0.7.6-7 - Speed up gconf schema installation compiz-fusion-0.7.6-4.fc10 -------------------------- * Mon Jun 23 18:00:00 2008 Adel Gadllah 0.7.6-4 - Speed up gconf schema installation compiz-fusion-extras-0.7.6-4.fc10 --------------------------------- * Mon Jun 23 18:00:00 2008 Adel Gadllah 0.7.6-4 - Speed up gconf schema installation control-center-2.23.4-3.fc10 ---------------------------- * Mon Jun 23 18:00:00 2008 Ray Strode - 2.23.4-3 - Install bg capplet .policy file * Fri Jun 20 18:00:00 2008 Matthias Clasen - 2.23.4-2 - Use standard icon names for capplets where available dump-0.4b41-8.fc10 ------------------ * Mon Jun 23 18:00:00 2008 Adam Tkac 0.4b41-8 - removed compat static -> non-static symlinks (#452425) echo-icon-theme-0.3.89.0-0.3.git5d18d86.fc10 -------------------------------------------- * Mon Jun 23 18:00:00 2008 Martin Sourada - 0.3.90.0-0.3.git5d18d86 - New git snapshot ext3grep-0.7.0-1.fc10 --------------------- * Mon Jun 23 18:00:00 2008 Milos Jakubicek - 0.7.0-1 - Upstream version 0.7.0 filesystem-2.4.17-1.fc10 ------------------------ * Mon Jun 23 18:00:00 2008 Phil Knirsch - 2.4.17-1 - Added URL for lang-exception source (#225752) geoqo-0.97-2.fc10 ----------------- * Mon Jun 23 18:00:00 2008 Wes Hardaker - 0.97-2 - Fix bug #452481: require DBD::sqlite2 * Fri May 16 18:00:00 2008 Wes Hardaker - 0.97-1 - update to upstream that contains multiple bug fixes ghostscript-8.62-4.fc10 ----------------------- * Mon Jun 23 18:00:00 2008 Tim Waugh 8.62-4 - Applied patch to work around bug #229174. - Applied patch from upstream to fix box_fill_path for shfill (bug #452348). gnomesword-2.3.4-2.fc10 ----------------------- * Mon Jun 23 18:00:00 2008 Deji Akingunola - 2.3.4-2 - Remove --enable-gtkthml configure option, to enable gecko support hplip-2.8.6-1.fc10 ------------------ * Mon Jun 23 18:00:00 2008 Tim Waugh 2.8.6-1 - 2.8.6. No longer need libm patch. jabbim-0.4.1-1.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Michal Schmidt - 0.4.1-1 - Upstream bugfix release 0.4.1. Fixes: - archive now actually displays messages - search dialog and privacy editor can be closed - Added scalable icon. jpilot-1.6.0-1.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Ivana Varekova - 1.6.0-1 - update to 1.6.0 kernel-2.6.26-0.85.rc7.git1.fc10 -------------------------------- * Mon Jun 23 18:00:00 2008 Dave Jones - Change ACPI button driver to non-modular. * Mon Jun 23 18:00:00 2008 Dave Jones - Build LIBATA & the SCSI bits non-modular. * Mon Jun 23 18:00:00 2008 Dave Jones - Add debug variants of the RCU linked list routines. * Sun Jun 22 18:00:00 2008 Dave Jones - 2.6.26-rc7-git1 libraw1394-2.0.0-0.2.20080430_git.fc10 -------------------------------------- * Mon Jun 23 18:00:00 2008 Jarod Wilson - 2.0.0-0.2.20080430_git - Restore ieee1394 raw1394_read_cycle_timer, add firewire variant lirc-0.8.3-4.fc10 ----------------- * Mon Jun 23 18:00:00 2008 Jarod Wilson - 0.8.3-4 - Drop resume switch patch, no longer required - Add support for config option style used by gnome-lirc-properties (#442341) mfiler3-1.0.2-1.fc10 -------------------- * Mon Jun 23 18:00:00 2008 Mamoru Tasaka - 1.0.2-1 - 1.0.2 - -Werror-implicit-function-declaration is added in the source tarball moodle-1.9.1-2.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Jon Ciesla - 1.9.1-2 - Add php Requires, BZ 452341. openais-0.84-1.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Steven Dake - 0.84-1 - New upstream release 0.84 with stability enhancements in protocols. oprofile-0.9.3-18.fc10 ---------------------- * Mon Jun 23 18:00:00 2008 Will Cohen - 0.9.3-18 - Fix default location for vmlinux. rhbz #451539 pam_mount-0.41-2.fc10 --------------------- * Mon Jun 23 18:00:00 2008 Till Maas - 0.41-2 - Add patch to fix handling in config file, reference: Red Hat Bugzilla #448485 comment 9 http://sourceforge.net/tracker/index.php?func=detail&aid=1974442&group_id=41452&atid=430593 comment from 2008-06-19 10:29 perl-Catalyst-Runtime-5.7014-3.fc10 ----------------------------------- * Mon Jun 23 18:00:00 2008 Chris Weyl 5.7014-3 - Quiet STDERR somewhat on build perl-XML-LibXML-1.66-1.fc10 --------------------------- * Mon Jun 23 18:00:00 2008 Marcela Maslanova - 1:1.66-1 - upgrade to 1.66 phpMyAdmin-2.11.7-1.fc10 ------------------------ * Mon Jun 23 18:00:00 2008 Robert Scheck 2.11.7-1 - Upstream released 2.11.7 (#452497) plymouth-0.4.0-2.fc10 --------------------- policycoreutils-2.0.49-8.fc10 ----------------------------- * Mon Jun 23 18:00:00 2008 Dan Walsh 2.0.49-8 - Fix sepolgen/audit2allow handling of roles qt-4.4.0-11.fc10 ---------------- * Mon Jun 23 18:00:00 2008 Rex Dieter 4.4.0-11 - fix dbus conditional (#452487) radvd-1.1-4.fc10 ---------------- * Mon Jun 23 18:00:00 2008 Jiri Skala - 1.1-4 - radvd.init LSB compliant rpcbind-0.1.5-1.fc10 -------------------- * Mon Jun 23 18:00:00 2008 Steve Dickson 0.1.5-1 - Updated to latest upstream release 0.1.5 ruby-1.8.6.230-1.fc10 --------------------- * Tue Jun 24 18:00:00 2008 Akira TAGOH - 1.8.6.230-1 - New upstream release. - Security fixes. (#452295) - CVE-2008-1891: WEBrick CGI source disclosure. - CVE-2008-2662: Integer overflow in rb_str_buf_append(). - CVE-2008-2663: Integer overflow in rb_ary_store(). - CVE-2008-2664: Unsafe use of alloca in rb_str_format(). - CVE-2008-2725: Integer overflow in rb_ary_splice(). - CVE-2008-2726: Integer overflow in rb_ary_splice(). - ruby-1.8.6.111-CVE-2007-5162.patch: removed. - Build ruby-mode package for all archtectures. scim-bridge-0.4.15-6.fc10 ------------------------- * Mon Apr 21 18:00:00 2008 Caius Chance - 0.4.15-6.fc10 - Resolves: rhbz#199389 (Add global hotkey list in help window.) scim-tables-0.5.8-3.fc10 ------------------------ * Mon Jun 23 18:00:00 2008 Jens Petersen - 0.5.8-3.fc10 - update the license field to GPL2+ - use canonical source url for sourceforge - fix conditioning of patches selinux-policy-3.4.2-6.fc10 --------------------------- * Mon Jun 23 18:00:00 2008 Dan Walsh 3.4.2-6 - Apply unconfined_execmem_exec_t to haskell programs setup-2.6.16-1.fc10 ------------------- * Tue Jun 17 18:00:00 2008 Phil Knirsch 2.6.16-1 - Dropped user news from default /etc/passwd (#437462) texlive-2007-34.fc10 -------------------- * Mon Jun 23 18:00:00 2008 Jindrich Novy - 2007-34 - do not directly depend on restorecon and run it only if selinux is enabled texlive-texmf-2007-23.fc10 -------------------------- * Mon Jun 23 18:00:00 2008 Jindrich Novy - 2007-23 - do not directly depend on restorecon and run it only if selinux is enabled ultimatestunts-0.7.5-1.fc10 --------------------------- * Mon Jun 23 18:00:00 2008 Dan Horak 0.7.5-1 - update to upstream version 0751 - use locale data from system directory words-3.0-13.fc10 ----------------- * Mon Jun 23 18:00:00 2008 Karel Zak - 3.0-13 - fix #428582 - linux.words contains misspelled word "flourescent" - fix #440146 - misspelled word in /usr/share/dict/words (architecure) wordwarvi-0.16-1.fc10 --------------------- * Mon Jun 23 18:00:00 2008 Hans de Goede 0.16-1 - New upstream release 0.16 Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 42 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) From aph at redhat.com Tue Jun 24 09:48:54 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jun 2008 10:48:54 +0100 Subject: Fedora Support channels Improvement ideas In-Reply-To: <48601F8F.4090909@redhat.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> Message-ID: <4860C306.8010806@redhat.com> Eric Sandeen wrote: > Dominik 'Rathann' Mierzejewski wrote: >> On Monday, 23 June 2008 at 23:57, Colin Walters wrote: >>> 2008/6/23 Kevin Fenzi : >>> >>>> This weekend at Paul's State of Fedora talk at the end of the sessions >>>> on Saturday, he mentioned several areas where Fedora really could >>>> improve. One of these areas was the help that people get on the #fedora >>>> irc channel. >>> I think IRC is kind of fundamentally doomed because of the culture. >> It's possible to keep small channels (<50 people) nice and civil, but >> with more people, it's not really viable unless you have an op watching >> at all times. > > What if there were #fedora-filesystems, #fedora-gnome, #fedora-sound, > $fedora-$WHATEVER to focus the discussions & keep things a bit more > manageable? Or is that just many more tabs for the fedora-keepers to > lurk in... I work on the #fedora-java channel. It's not perfect but ot does work. Web forums are no substitute for immediate communication. Andrew. From nicolas.mailhot at laposte.net Tue Jun 24 10:28:51 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 24 Jun 2008 12:28:51 +0200 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4860C306.8010806@redhat.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <4860C306.8010806@redhat.com> Message-ID: <1214303331.3739.2.camel@rousalka.okg> Le mardi 24 juin 2008 ? 10:48 +0100, Andrew Haley a ?crit : > I work on the #fedora-java channel. It's not perfect but ot does work. > Web forums are no substitute for immediate communication It would be nice, BTW, if there was a java entry there http://fedoraproject.org/wiki/Category:Language-specific_SIGs There are certainly enough people working on Java in Fedora, and enough java-related material in the wiki, to justify a proper SIG. -- 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 mcepl at redhat.com Tue Jun 24 10:40:44 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 24 Jun 2008 12:40:44 +0200 Subject: Fedora Support channels Improvement ideas References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: On 2008-06-23, 21:57 GMT, Colin Walters wrote: > I think IRC is kind of fundamentally doomed because of the > culture. > > If we want to emphasize a support medium, the forum is much nicer: Well, there are two things I have against formus (and it may be just my feelings problem): -- they don't scale well -- when subscribed to as many fora as I am to NGs or email lists, I would went crazy fast, and they are not immediate. I am a big fan of Jabber, which has advantage of being cool (don't laugh, familiarity of users with IM is an advantage IMHO), has a ton of additional functionality (and more could be added), and in terms of your problem, it deemphasizes culture of cranky geeks with RTFM always on hand. Mat?j From mcepl at redhat.com Tue Jun 24 10:50:25 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 24 Jun 2008 12:50:25 +0200 Subject: Fedora Support channels Improvement ideas References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> <1214272534.3172.63.camel@localhost.localdomain> <20080623223523.03421999@ohm.scrye.com> <16de708d0806232144u69b78cd7r14038c2098467132@mail.gmail.com> <20080623224913.6377a551@ohm.scrye.com> Message-ID: On 2008-06-24, 04:49 GMT, Kevin Fenzi wrote: > New users often don't know where their problem is. If my system > locks up when I login to the desktop, would I look for > #fedora-kernel? Or #fedora-gnome? Do I even know I am running > gnome? +1000 There has to be #fedora even if its main purpose would be to directo people to #fedora-* (but it shouldn't be the only purpose, IMHO). Mat?j From hughsient at gmail.com Tue Jun 24 11:03:02 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 24 Jun 2008 12:03:02 +0100 Subject: LSB Package API In-Reply-To: <1214157770.5783.25.camel@dwashington> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> Message-ID: <1214305382.3444.28.camel@hughsie-work> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote: > We shouldn't resignate just because nothing came out of the previous > attempts. Also, the LSB Package API is designed to require as little > adjustments as possible to installers - it's just to calls and a single > file, after all. Uses a DBUS service: check Uses pluggable backends: check Use PolicyKit: check Use an XML parser: check System activation: check Define own linked list implementation: check > As already mentioned before in this thread, the focus of PackageKit and the > LSB Package API are quite different, so there is no big reason for them to > not exist side-by-side. Err, http://www.linuxfoundation.org/en/LSB_Package_API suggests otherwise. You've got calls to PolicyKit, a system activated daemon, pluggable backends - you might as well call the project LSBPackageKit. You don't appear to have any defined scope for the project and it seems to be just be technology-bingo at the moment. > I don't think this is a corner case at all. For one thing, propietary > applications might just don't play a role _because_ there is no really > good distribution method for them - the typical chicken-and-egg problem. > (I'm not saying this is the only reason, but an important one.) We're > just not giving them an easy method of cross-distro integration. I think > providing this is important. Have you talked to customers? I have. Lots of them. Customers don't want DBUS services or PolicyKit, they want one of two things: 1. A tested (supported) binary package for something like RHEL and SLED. 2. An installer that uses something like /bin/sh for the other distros. If you want them to use a library to install stuff, you better make it static (else they have to depend on really new versions of distros) and also make it very lightweight, libc type stuff. Most of this closed source stuff has to install on distros 5 years old, and continue to work on distros 2 years in the future. > Second, this way of distribution will help open-source projects as well. > It would make it really easy for them to distribute bleeding-edge > versions of there apps that integrate well into the packaging system > without having to package for each and every package manager. Talk to the distro maintainers. They really don't want random projects replacing supported packages. Packages are not normally just the upstream tarball with a spec file - normally the packager includes spec files to make the package compile, or integrate well with the distro. Then there's the world of pain that comes from security errata. I really think you should talk to distro maintainers as well as closed source vendors before coming up with any more API. Richard. From tcallawa at redhat.com Tue Jun 24 13:13:48 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Jun 2008 09:13:48 -0400 Subject: Help building rpm, works with f8 fails in f9 In-Reply-To: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> References: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> Message-ID: <1214313228.3119.6.camel@localhost.localdomain> On Mon, 2008-06-23 at 22:33 -0600, Jerry Williams wrote: > I could use some help trying to figure out why a package builds just > fine on Fedora 8 but fails on Fedora 9 Jerry, The only way that package would build is if you were building it as root. Honestly, there are a lot of things in that spec that aren't quite right, so I'm not sure what specifically is causing the failure. I recently gave a presentation at the Red Hat Summit on making good RPM packages, and I think it may be helpful to you. You can find the presentation (and a handout with fully documented example spec files) here: http://spot.fedorapeople.org/Summit2008/ In addition, I've reworked your spec file (and desktop file) into something that works (and would probably pass review for inclusion into Fedora). I would highly recommend that you compare it to your original spec file. If you have any questions about the new spec file, please feel free to drop me an email (or reply here). New SRPM: http://spot.fedorapeople.org/crrcsim/crrcsim-0.9.9-2.fc10.src.rpm New SPEC: http://spot.fedorapeople.org/crrcsim/crrcsim.spec New Desktop File: http://spot.fedorapeople.org/crrcsim/CRRCsim.desktop Note: This game/simulator doesn't actually run on my rawhide system, it does a wonderful job of corrupting the X session with rainbow color noise and locking up my laptop, but I don't think that is a fault of the packaging, probably a Mesa/Intel/Xorg/Rawhide bug. ~spot From jbwillia at math.vt.edu Tue Jun 24 13:25:10 2008 From: jbwillia at math.vt.edu (ben) Date: Tue, 24 Jun 2008 09:25:10 -0400 Subject: Fedora Support channels Improvement ideas Message-ID: <4860F5B6.5030803@math.vt.edu> As one of the OPs for the #fedora channel, i feel all theses ideas are great but I think what we should do first is the following: 1) policy or rules created and posted somewhere linked in the channel topic and or on the Chanserv message entering the channel. 2) enough active ops to enforce said policy or rules. (replace people on the ops list who are no longer around or inactive) these 2 things quickly will give us time to work towards the other issues. Southern_Gentlem -- Ben Williams Window-Linux Specialist Mathematics Department-Virginia Tech 561E McBryde Hall 540 231-2739 From bruno at wolff.to Tue Jun 24 13:54:04 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 24 Jun 2008 08:54:04 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <48601F8F.4090909@redhat.com> References: <20080623154146.6753ae91@ohm.scrye.com> <20080623220531.GA15528@mokona.greysector.net> <48601F8F.4090909@redhat.com> Message-ID: <20080624135404.GA30751@wolff.to> On Mon, Jun 23, 2008 at 17:11:27 -0500, Eric Sandeen wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > > I, for one, detest the forums (any forums) for their terrible user > > interface. Mailing lists or usenet newsgroups are much more convenient > > to use. > > Amen. :) But all three are very similar in data flow and really differ in the interface. With some cleverness it should be possible to have all three share a central repository with three different interfaces that each can be used to access all of the data. From dwashington at gmx.net Tue Jun 24 14:05:05 2008 From: dwashington at gmx.net (Denis Washington) Date: Tue, 24 Jun 2008 16:05:05 +0200 Subject: LSB Package API In-Reply-To: <1214305382.3444.28.camel@hughsie-work> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <1214305382.3444.28.camel@hughsie-work> Message-ID: <1214316306.5779.20.camel@dwashington> On Tue, 2008-06-24 at 12:03 +0100, Richard Hughes wrote: > On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote: > > We shouldn't resignate just because nothing came out of the previous > > attempts. Also, the LSB Package API is designed to require as little > > adjustments as possible to installers - it's just to calls and a single > > file, after all. > > Uses a DBUS service: check > Uses pluggable backends: check > Use PolicyKit: check > Use an XML parser: check > System activation: check > Define own linked list implementation: check I don't know where you a heading. The D-Bus service, pluggable backends, the XML parser, and system activation are all things that installers don't have to deal with. They just use the few functions from liblsb_package. > > As already mentioned before in this thread, the focus of PackageKit and the > > LSB Package API are quite different, so there is no big reason for them to > > not exist side-by-side. > > Err, http://www.linuxfoundation.org/en/LSB_Package_API suggests > otherwise. > > You've got calls to PolicyKit, a system activated daemon, pluggable > backends - you might as well call the project LSBPackageKit. You don't > appear to have any defined scope for the project and it seems to be just > be technology-bingo at the moment. Just because it does use the same technologies, that doesn't mean the APIs' scope is the same. You should know enough about your project to realize that the LSB Package API is focused on entirely different needs (providing an interface for third-party app installers) than PackageKit (provide an API for the packaging system, based on distro repositories). > > I don't think this is a corner case at all. For one thing, propietary > > applications might just don't play a role _because_ there is no really > > good distribution method for them - the typical chicken-and-egg problem. > > (I'm not saying this is the only reason, but an important one.) We're > > just not giving them an easy method of cross-distro integration. I think > > providing this is important. > > Have you talked to customers? I have. Lots of them. Customers don't want > DBUS services or PolicyKit, they want one of two things: > > 1. A tested (supported) binary package for something like RHEL and SLED. > 2. An installer that uses something like /bin/sh for the other distros. Again, ISVs don't have to deal with D-BUS etc. Those are _implementation details_. They can just use a simple C API which could also be easily wrapped into simple command-line tools. > If you want them to use a library to install stuff, you better make it > static (else they have to depend on really new versions of distros) and > also make it very lightweight, libc type stuff. Most of this closed > source stuff has to install on distros 5 years old, and continue to work > on distros 2 years in the future. The LSB Package API would only be in newer versions of the LSB, so support of legacy distros is not that high on the list. (On any older distro, no one could rely on the API even being there.) > > Second, this way of distribution will help open-source projects as well. > > It would make it really easy for them to distribute bleeding-edge > > versions of there apps that integrate well into the packaging system > > without having to package for each and every package manager. > > Talk to the distro maintainers. They really don't want random projects > replacing supported packages. Packages are not normally just the > upstream tarball with a spec file - normally the packager includes spec > files to make the package compile, or integrate well with the distro. > Then there's the world of pain that comes from security errata. No packages are going to be replaced. LSB applications are required to install to /opt, so nothing is overridden. Even the package naming won't clash (it's "lsb--" in the implemented RPM and DPKG backends). > I really think you should talk to distro maintainers as well as closed > source vendors before coming up with any more API. A number of ISVs have already been talked to; see the comments from Jeff Licquia. Regards, Denis From voltaire at idirect.com Tue Jun 24 14:07:50 2008 From: voltaire at idirect.com (voltaire at idirect.com) Date: Tue, 24 Jun 2008 10:07:50 -0400 Subject: unsubscibe In-Reply-To: <1214316306.5779.20.camel@dwashington> References: <1214041907.5778.39.camel@dwashington><1214140518.3377.31.camel@hughsie-work><1214157770.5783.25.camel@dwashington><1214305382.3444.28.camel@hughsie-work> <1214316306.5779.20.camel@dwashington> Message-ID: <023301c8d603$b002ab30$141e0a0a@romboughlabs.local> unsubscibe -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Denis Washington Sent: Tuesday, June 24, 2008 10:05 AM To: rpm-lsb at rpm5.org Cc: Development discussions related to Fedora; packaging at lists.linux-foundation.org; opensuse-project at opensuse.org; lf_desktop at lists.linux-foundation.org; ubuntu-devel-discuss at lists.ubuntu.com; rpm-maint at lists.rpm.org; debian-dpkg at lists.debian.org Subject: Re: LSB Package API On Tue, 2008-06-24 at 12:03 +0100, Richard Hughes wrote: > On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote: > > We shouldn't resignate just because nothing came out of the previous > > attempts. Also, the LSB Package API is designed to require as little > > adjustments as possible to installers - it's just to calls and a single > > file, after all. > > Uses a DBUS service: check > Uses pluggable backends: check > Use PolicyKit: check > Use an XML parser: check > System activation: check > Define own linked list implementation: check I don't know where you a heading. The D-Bus service, pluggable backends, the XML parser, and system activation are all things that installers don't have to deal with. They just use the few functions from liblsb_package. > > As already mentioned before in this thread, the focus of PackageKit and the > > LSB Package API are quite different, so there is no big reason for them to > > not exist side-by-side. > > Err, http://www.linuxfoundation.org/en/LSB_Package_API suggests > otherwise. > > You've got calls to PolicyKit, a system activated daemon, pluggable > backends - you might as well call the project LSBPackageKit. You don't > appear to have any defined scope for the project and it seems to be just > be technology-bingo at the moment. Just because it does use the same technologies, that doesn't mean the APIs' scope is the same. You should know enough about your project to realize that the LSB Package API is focused on entirely different needs (providing an interface for third-party app installers) than PackageKit (provide an API for the packaging system, based on distro repositories). > > I don't think this is a corner case at all. For one thing, propietary > > applications might just don't play a role _because_ there is no really > > good distribution method for them - the typical chicken-and-egg problem. > > (I'm not saying this is the only reason, but an important one.) We're > > just not giving them an easy method of cross-distro integration. I think > > providing this is important. > > Have you talked to customers? I have. Lots of them. Customers don't want > DBUS services or PolicyKit, they want one of two things: > > 1. A tested (supported) binary package for something like RHEL and SLED. > 2. An installer that uses something like /bin/sh for the other distros. Again, ISVs don't have to deal with D-BUS etc. Those are _implementation details_. They can just use a simple C API which could also be easily wrapped into simple command-line tools. > If you want them to use a library to install stuff, you better make it > static (else they have to depend on really new versions of distros) and > also make it very lightweight, libc type stuff. Most of this closed > source stuff has to install on distros 5 years old, and continue to work > on distros 2 years in the future. The LSB Package API would only be in newer versions of the LSB, so support of legacy distros is not that high on the list. (On any older distro, no one could rely on the API even being there.) > > Second, this way of distribution will help open-source projects as well. > > It would make it really easy for them to distribute bleeding-edge > > versions of there apps that integrate well into the packaging system > > without having to package for each and every package manager. > > Talk to the distro maintainers. They really don't want random projects > replacing supported packages. Packages are not normally just the > upstream tarball with a spec file - normally the packager includes spec > files to make the package compile, or integrate well with the distro. > Then there's the world of pain that comes from security errata. No packages are going to be replaced. LSB applications are required to install to /opt, so nothing is overridden. Even the package naming won't clash (it's "lsb--" in the implemented RPM and DPKG backends). > I really think you should talk to distro maintainers as well as closed > source vendors before coming up with any more API. A number of ISVs have already been talked to; see the comments from Jeff Licquia. Regards, Denis -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From bruno at wolff.to Tue Jun 24 14:18:13 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 24 Jun 2008 09:18:13 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623223834.64c6f607@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> <604aa7910806231520y3c9d823fi6dbb47a0cf203e0c@mail.gmail.com> <20080623223834.64c6f607@ohm.scrye.com> Message-ID: <20080624141813.GB30751@wolff.to> On Mon, Jun 23, 2008 at 22:38:34 -0600, Kevin Fenzi wrote: > > Well, if we used some kind of karma then people who at least pleased > users would be rated up. That might mean they answered questions well, > or in a good enough manner that users were happy they were at least > being addressed. This would work to weed out well meaning people who just don't know what they are talking about. It might not be very effective in preventing delibrate abuse. It wouldn't be too hard to create lots of accounts and get them all highly rated and then start abusing people. I wouldn't have thought that would be a problem, until I read your description of the current state of irc support. Now I am not so sure. From ed at eh3.com Tue Jun 24 14:36:29 2008 From: ed at eh3.com (Ed Hill) Date: Tue, 24 Jun 2008 10:36:29 -0400 Subject: Help building rpm, works with f8 fails in f9 In-Reply-To: <1214313228.3119.6.camel@localhost.localdomain> References: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> <1214313228.3119.6.camel@localhost.localdomain> Message-ID: <20080624103629.00e0565a@localhost.localdomain> On Tue, 24 Jun 2008 09:13:48 -0400 "Tom \"spot\" Callaway" wrote: > On Mon, 2008-06-23 at 22:33 -0600, Jerry Williams wrote: > > I could use some help trying to figure out why a package builds just > > fine on Fedora 8 but fails on Fedora 9 > > > I recently gave a presentation at the Red Hat Summit on making good > RPM packages, and I think it may be helpful to you. You can find the > presentation (and a handout with fully documented example spec files) > here: > http://spot.fedorapeople.org/Summit2008/ Hi Tom, Thank you for posting the above presentation on-line! Just out of curiosity, is there any particular license associated with it? May I have your permission to re-use part or all of it? If so, I'll be careful to *prominently* cite you as the original author, provide your URL, etc. People have asked me to give quick "intro to RPM and Fedora/RHEL" talks and your slides are *much* nicer (more thorough, entertaining, etc.) than anything I've thrown together. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d12og at yahoo.com Tue Jun 24 15:05:26 2008 From: d12og at yahoo.com (Corey Campbell) Date: Tue, 24 Jun 2008 08:05:26 -0700 (PDT) Subject: unsubscibe In-Reply-To: <023301c8d603$b002ab30$141e0a0a@romboughlabs.local> Message-ID: <247517.31272.qm@web38905.mail.mud.yahoo.com> unsubscribe --- voltaire at idirect.com wrote: > unsubscibe > > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com] On > Behalf Of Denis Washington > Sent: Tuesday, June 24, 2008 10:05 AM > To: rpm-lsb at rpm5.org > Cc: Development discussions related to Fedora; > packaging at lists.linux-foundation.org; > opensuse-project at opensuse.org; > lf_desktop at lists.linux-foundation.org; > ubuntu-devel-discuss at lists.ubuntu.com; > rpm-maint at lists.rpm.org; > debian-dpkg at lists.debian.org > Subject: Re: LSB Package API > > On Tue, 2008-06-24 at 12:03 +0100, Richard Hughes > wrote: > > On Sun, 2008-06-22 at 20:02 +0200, Denis > Washington wrote: > > > We shouldn't resignate just because nothing came > out of the previous > > > attempts. Also, the LSB Package API is designed > to require as little > > > adjustments as possible to installers - it's > just to calls and a single > > > file, after all. > > > > Uses a DBUS service: check > > Uses pluggable backends: check > > Use PolicyKit: check > > Use an XML parser: check > > System activation: check > > Define own linked list implementation: check > > I don't know where you a heading. The D-Bus service, > pluggable backends, > the XML parser, and system activation are all things > that installers > don't have to deal with. They just use the few > functions from > liblsb_package. > > > > As already mentioned before in this thread, the > focus of PackageKit and > the > > > LSB Package API are quite different, so there is > no big reason for them > to > > > not exist side-by-side. > > > > Err, > http://www.linuxfoundation.org/en/LSB_Package_API > suggests > > otherwise. > > > > You've got calls to PolicyKit, a system activated > daemon, pluggable > > backends - you might as well call the project > LSBPackageKit. You don't > > appear to have any defined scope for the project > and it seems to be just > > be technology-bingo at the moment. > > Just because it does use the same technologies, that > doesn't mean the > APIs' scope is the same. You should know enough > about your project to > realize that the LSB Package API is focused on > entirely different needs > (providing an interface for third-party app > installers) than PackageKit > (provide an API for the packaging system, based on > distro repositories). > > > > I don't think this is a corner case at all. For > one thing, propietary > > > applications might just don't play a role > _because_ there is no really > > > good distribution method for them - the typical > chicken-and-egg problem. > > > (I'm not saying this is the only reason, but an > important one.) We're > > > just not giving them an easy method of > cross-distro integration. I think > > > providing this is important. > > > > Have you talked to customers? I have. Lots of > them. Customers don't want > > DBUS services or PolicyKit, they want one of two > things: > > > > 1. A tested (supported) binary package for > something like RHEL and SLED. > > 2. An installer that uses something like /bin/sh > for the other distros. > > Again, ISVs don't have to deal with D-BUS etc. Those > are _implementation > details_. They can just use a simple C API which > could also be easily > wrapped into simple command-line tools. > > > If you want them to use a library to install > stuff, you better make it > > static (else they have to depend on really new > versions of distros) and > > also make it very lightweight, libc type stuff. > Most of this closed > > source stuff has to install on distros 5 years > old, and continue to work > > on distros 2 years in the future. > > The LSB Package API would only be in newer versions > of the LSB, so > support of legacy distros is not that high on the > list. (On any older > distro, no one could rely on the API even being > there.) > > > > Second, this way of distribution will help > open-source projects as well. > > > It would make it really easy for them to > distribute bleeding-edge > > > versions of there apps that integrate well into > the packaging system > > > without having to package for each and every > package manager. > > > > Talk to the distro maintainers. They really don't > want random projects > > replacing supported packages. Packages are not > normally just the > > upstream tarball with a spec file - normally the > packager includes spec > > files to make the package compile, or integrate > well with the distro. > > Then there's the world of pain that comes from > security errata. > > No packages are going to be replaced. LSB > applications are required to > install to /opt, so nothing is overridden. Even the > package naming won't > clash (it's "lsb--" in the > implemented RPM and > DPKG backends). > > > I really think you should talk to distro > maintainers as well as closed > > source vendors before coming up with any more API. > > A number of ISVs have already been talked to; see > the comments from Jeff > Licquia. > > Regards, > Denis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pjones at redhat.com Tue Jun 24 15:20:53 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 24 Jun 2008 11:20:53 -0400 Subject: apport/breakpad and fedora In-Reply-To: References: <1214251935.29455.79.camel@metroid.rdu.redhat.com> Message-ID: <486110D5.4050606@redhat.com> Colin Walters wrote: > 2008/6/23 Will Woods : >> If I remember right, the reason for this part of the discussion was: >> >> 1) Linking everything on the system to breakpad is a bit nasty. >> 2) Apport doesn't need to be linked in, but it runs *after* the process >> gets dumped by the kernel. At which point it's slightly different from >> when it actually crashed. > > > Yeah, sounds right. > > pjones' idea was to have a system service that would receive >> notification of segfaults and use utrace to stop the process and >> generate a (breakpad-style report). >> > > He was thinking of hooking it into kerneloops, right? This was really just my "easiest first-pass way to implement it"; I expect we can replace this part with something better if we need to, and it may or may not be necessary. > Though isn't there a race between when we get the kernel notification and > when the service stops it and inspects? Not my area of expertise really, > just thinking out loud. If we're /not/ changing any kernel APIs, we'd want to do several things, conditional on the feature being enabled. A mostly inclusive list follows: 1) make /var/cache/cores/ a tmpfs mount 2) set kernel.core_pattern to something like "/var/cache/cores/core.%p" 3) do something along the lines of setfacl to limit access 4) "ulimit -c $SOMETHING_NONZERO" for everything. If we were to change kernel APIs, my initial thought is a utrace plugin that suspends the task instead of delivering the segfault, and gives us a notification on a file descriptor we're ppoll()ing on. Then we'd go examine the process's memory and collect a trace. This also has the advantage that it means no shared writable space and no spinning up the disk to write the core out. Also, on the whole it requires fewer different parts of the system to be set up right. >> It would make the 'debuginfo-install' message go away, because (if DAV + >> FUSE does the right thing) you'll have all the debuginfo you need, in >> the right place - mounted as a FUSE filesystem. > > Ah, ok. FWIW, the debuginfo server I'm working on is at http://git.fedorahosted.org/git/?p=littlebottom.git;a=summary . It's still very much in its infancy, and I can use all the help I can get. I'll gladly add you to the group if you want to help out ;) >>> My 2? - Link in breakpad, create http://crash.fedoraproject.org >>> running Socorro. >> Link it into what? Everything, via LD_PRELOAD? Or just GNOME stuff? I >> thought bug-buddy already used breakpad? IMNSHO, LD_PRELOAD is just a plain bad idea here (and nearly everywhere else). There are also plenty of places where we want tracebacks, but the upstream maintainers won't like the patches, and we don't want to be carrying patches. Not to mention patching everything is a herculean task. I really if we're going to succeed, we've got to plan on /not/ changing most executables. > I'm personally most interested in the desktop apps because, well we desktop > developers are masochists and code complex user-facing code in C/C++, and > not surprisingly they crash =) The same is true of the rest of the system; I think our solution needs to work for everything (well, everything compiled, though the reporting/statistics infrastructure need not be even that specific.) > So right now...hm, actually this is weird, I can't get any Fedora-compiled > program to spawn bug-buddy at all right now. I get it for some local custom > code, but not for anything in /usr/bin. I see libgnomebreakpad is linked > into the process. Another point against the "link in a magic library" approach. If the crashing executable has to do the work to spawn the reporting tool, it'll *never* be reliable. >> Longer term investigate utrace system service instead of having apps >>> link to breakpad (this gets us non-desktop system crashes without >>> having to universally LD_PRELOAD or whatever). >> Yeah, I don't think we need to solve this until we've got the >> proof-of-concept stack: a couple of choice apps sending Breakpad reports >> (with debuginfo fetched from littlebottom) to our own Socorro instance. I think we're all in agreement here. -- Peter From jmtaylor90 at gmail.com Tue Jun 24 15:21:38 2008 From: jmtaylor90 at gmail.com (Jason) Date: Tue, 24 Jun 2008 11:21:38 -0400 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4860F5B6.5030803@math.vt.edu> References: <4860F5B6.5030803@math.vt.edu> Message-ID: <1214320898.6379.9.camel@bruiser.localdomain> On Tue, 2008-06-24 at 09:25 -0400, ben wrote: > As one of the OPs for the #fedora channel, i feel all theses ideas are > great but I think what we should do first is the following: > > 1) policy or rules created and posted somewhere linked in the channel > topic and or on the Chanserv message entering the channel. > > 2) enough active ops to enforce said policy or rules. (replace people > on the ops list who are no longer around or inactive) > > > these 2 things quickly will give us time to work towards the other issues. > > > > Southern_Gentlem > > -- > Ben Williams > Window-Linux Specialist > Mathematics Department-Virginia Tech > 561E McBryde Hall > 540 231-2739 After reading through the thread and being in general agreement, I am also wondering if any of the other distro's have any sort of formal free support structure that we could glean from? (Planning on checking around later today) I also would like to volunteer and help get stuff up and running. -Jason (jmtaylor) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jjj123jjj at hushmail.com Tue Jun 24 16:05:39 2008 From: jjj123jjj at hushmail.com (Joshua C.) Date: Tue, 24 Jun 2008 18:05:39 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <20080624160541.99C7C118040@mailserver5.hushmail.com> Hello guys, I had a serios problems with my bios and at the end it was the dsdt table that was broken. this gave me alot of kernel panics untill i figured it out. Now I have to recompile the kernel every time a new one goes out in order to put in my custom dsdt table and enable it. this takes about 30 min and I cannot use any of the devel kernels. There is, however, a kernel patch at gaugusch.at/kernel.shtml which enables the kernel to load a custom dsdt table from the initrd. and this is alot faster than the previous method with the kernel recompilation. Will it be possible for this patch to go in the mainstream fedora kernel? Some other distros are using it and I don't see any reason why fedora shouldn't use it either. I know this kind of tainting the kernel is "dangerous" but it is the only way for user (like me) with broken bios/dsdt table to run their kernels. And because lots of bioses are tested only on windows there are no other way than inserting a custom dsdt for linux. Any sugestions or downsides of this method that can prove the exclusion of this patch from the mainstream fedora kernel? Cheers, Joshua -- Internet Security Software - Click here. http://tagline.hushmail.com/fc/Ioyw6h4dJxHDn2puyZ3Jrv4LFpXqrJ3oKIWGfQomgsD4N9EJi3jVn1/ From caillon at redhat.com Tue Jun 24 17:08:26 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 24 Jun 2008 13:08:26 -0400 Subject: apport/breakpad and fedora In-Reply-To: <1214251935.29455.79.camel@metroid.rdu.redhat.com> References: <1214251935.29455.79.camel@metroid.rdu.redhat.com> Message-ID: <48612A0A.4090606@redhat.com> Will Woods wrote: > The latter seems like the Right Thing, but it depends on the previous > actions. I wonder how caillon would feel about getting Firefox doing > reports to Mozilla in the meantime. Our binaries aren't the exact same as Mozilla's for various reasons: compiler flags, using system libs instead of in-tree, local patches we may have, etc. Thus our symbols don't match up 1 to 1 with what their symbol server expects. Additionally, we have symbols for architectures they don't. We can likely get them our symbol data, but it needs to be done for every build we push through the build system. If someone makes this automatic, yeah sure I have no problem with it at that point. From dominik at greysector.net Tue Jun 24 17:20:46 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 24 Jun 2008 19:20:46 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624160541.99C7C118040@mailserver5.hushmail.com> References: <20080624160541.99C7C118040@mailserver5.hushmail.com> Message-ID: <20080624172045.GA20481@mokona.greysector.net> Hi, On Tuesday, 24 June 2008 at 18:05, Joshua C. wrote: > I had a serios problems with my bios and at the end it was the dsdt > table that was broken. this gave me alot of kernel panics untill i > figured it out. Now I have to recompile the kernel every time a new > one goes out in order to put in my custom dsdt table and enable it. > this takes about 30 min and I cannot use any of the devel kernels. > > There is, however, a kernel patch at gaugusch.at/kernel.shtml which > enables the kernel to load a custom dsdt table from the initrd. and > this is alot faster than the previous method with the kernel > recompilation. > > Will it be possible for this patch to go in the mainstream fedora > kernel? This has already been discussed and the answer was no: https://bugzilla.redhat.com/show_bug.cgi?id=110511 https://bugzilla.redhat.com/show_bug.cgi?id=140215 https://bugzilla.redhat.com/show_bug.cgi?id=169014 Actually these bug reports should be marked as duplicates. > Some other distros are using it and I don't see any reason why > fedora shouldn't use it either. I know this kind of tainting the > kernel is "dangerous" but it is the only way for user (like me) > with broken bios/dsdt table to run their kernels. And because lots > of bioses are tested only on windows there are no other way than > inserting a custom dsdt for linux. > > Any sugestions or downsides of this method that can prove the > exclusion of this patch from the mainstream fedora kernel? Quoting Dave Jones (https://bugzilla.redhat.com/show_bug.cgi?id=169014#c2): | I've already explained this several times already. | The only way this is going into the fedora kernel is via upstream. | If users start manipulating their DSDTs, and getting panics etc, they file bugs | here, and would 'neglect' to say how they hacked their dsdt's | It's a support nightmare waiting to happen. So there you go. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dwashington at gmx.net Tue Jun 24 17:57:50 2008 From: dwashington at gmx.net (Denis Washington) Date: Tue, 24 Jun 2008 19:57:50 +0200 Subject: LSB Package API In-Reply-To: <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> References: <1214041907.5778.39.camel@dwashington> <1214140518.3377.31.camel@hughsie-work> <1214157770.5783.25.camel@dwashington> <604aa7910806221241v335a9ac3wb3f4d9958fda3364@mail.gmail.com> Message-ID: <1214330270.19927.26.camel@dwashington> On Sun, 2008-06-22 at 11:41 -0800, Jeff Spaleta wrote: > On Sun, Jun 22, 2008 at 10:02 AM, Denis Washington wrote: > > I don't think this is a corner case at all. For one thing, propietary > > applications might just don't play a role _because_ there is no really > > good distribution method for them - the typical chicken-and-egg problem. > > I do not want to make proprietary applications easy to install. My > involvement in Fedora is predicated on the idea that everything I do > as part of my involvement with this project makes it easier for people > to stop using proprietary applications. I would strongly suggest that > you don't stand up proprietary applications as your primary argument > or use case for the technology. If you want this considered seriously > by this community. Stand up a usage case which benefits open source > software and wok through that usage case. Bleeding-edge versions of open-source projects. It would likely benefit project maintainers to provide installers for new versions of their software so that users can easily install and use them, even if the stable version of their distro does not provide the newer version. Especially trying some beta or release candidate (which no stable distro will ship) would be made a lot easier. This could in turn increase the number of people testing a pre-release version of their favorite open-source applications and, thus, expose more bugs that can be fixed before the final release. And everybody's happy. Another usage case is the distribution of very young and small open-source applications. Those often suffer from not being in any major distro's repositories yet. If they could provide an installer which installs the application in all major distros and even integrates it nicely into the packaging system, more people will be likely to give the new application a try than when there are just packages for certain distros or even nothing more than a source distribution. So I see strong benefits here too. Anyway, I don't think that we should not make lifes difficult for propietary application vendors just because some don't like them. I respect your dedication to a pure free software system, but I don't think we should force this opinion of all users of Linux. Having an easy way to install propietary applications does not mean that anybody has to install such software. It should be easy to those who want (or need) to do so - and that's a goal of the LSB Package API. > > Second, this way of distribution will help open-source projects as well. > > It would make it really easy for them to distribute bleeding-edge > > versions of there apps that integrate well into the packaging system > > without having to package for each and every package manager. > > If its that bleeding edge, should it tie in to the packaging system, > potentially causing problems for the distribution dependency > resolution? There will not be any dependency problems. An LSB-compliant application is required to bundle all libraries which are not guaranteed to be provided by the LSB, so it won't interfere with the base system here. Additionally, as much as possible is installed to /opt, so that no conflicts with distro packages arise. > Or should it be more like autopackage built as a secondary system? > Aren't you just re-inventing a new implementation for the problem that > autopackage has been attempting to solve for years now? In fact I > think you should go back and look at autopackage and make a compare > and contrast between the APIs. I know why I don't like autopackage. > it would be useful to know if I'm going to dislike your API for the > same reasons. I must admit that I haven't looked much at autopackage yet. I will have to evaluate it thoroughly in the next days to make a good comparison. But it is important to note that the LSB Package API is _not_ a secondary package manager; it always uses the distro's packaging system. Regards, Denis From tcallawa at redhat.com Tue Jun 24 16:21:33 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Jun 2008 12:21:33 -0400 Subject: Help building rpm, works with f8 fails in f9 In-Reply-To: <20080624103629.00e0565a@localhost.localdomain> References: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> <1214313228.3119.6.camel@localhost.localdomain> <20080624103629.00e0565a@localhost.localdomain> Message-ID: <1214324493.3119.15.camel@localhost.localdomain> On Tue, 2008-06-24 at 10:36 -0400, Ed Hill wrote: > On Tue, 24 Jun 2008 09:13:48 -0400 "Tom \"spot\" Callaway" wrote: > > > On Mon, 2008-06-23 at 22:33 -0600, Jerry Williams wrote: > > > I could use some help trying to figure out why a package builds just > > > fine on Fedora 8 but fails on Fedora 9 > > > > > > I recently gave a presentation at the Red Hat Summit on making good > > RPM packages, and I think it may be helpful to you. You can find the > > presentation (and a handout with fully documented example spec files) > > here: > > http://spot.fedorapeople.org/Summit2008/ > > > Hi Tom, > > Thank you for posting the above presentation on-line! > > Just out of curiosity, is there any particular license associated with > it? May I have your permission to re-use part or all of it? If so, > I'll be careful to *prominently* cite you as the original author, > provide your URL, etc. You'd think I'd have thought of this already. :) You (and anyone) are welcome to use the presentation under the terms of the Creative Commons Attribution-Share Alike 3.0 license: http://creativecommons.org/licenses/by-sa/3.0/ ~spot From pemboa at gmail.com Tue Jun 24 19:28:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 24 Jun 2008 14:28:21 -0500 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214320898.6379.9.camel@bruiser.localdomain> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> Message-ID: <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> 2008/6/24 Jason : [ snip ] > After reading through the thread and being in general agreement, I am > also wondering if any of the other distro's have any sort of formal free > support structure that we could glean from? (Planning on checking around > later today) I also would like to volunteer and help get stuff up and > running. My only observation, as a non distro hopper, is that the Ubuntu forums get very high Google search scoring. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From davej at redhat.com Tue Jun 24 20:15:51 2008 From: davej at redhat.com (Dave Jones) Date: Tue, 24 Jun 2008 16:15:51 -0400 Subject: 32bit PowerPC questions. Message-ID: <20080624201551.GA11499@redhat.com> PPC32 kernel builds take _forever_ in the build system. They're slowing things down to such extent that I'm usually still waiting for them several hours after the other architectures have finished building. One way to make them slightly faster is to not build as many modules. Looking through the config files, there's some obvious silly stuff in there (I really really hope no-one found a way to put an IWL4965 in a PPC32 box). The likelyhood of someone needing infiniband drivers on such a box is also somewhat slim. In culling out the obvious options though, there's a bunch where I'm not quite sure, largely due to a) my ignorance when it comes to PPC, and b) I have no idea what hardware platforms users are actually running Fedora PPC32 on. (And smolt is useless here, because PPC boxes don't have DMI[*]). So, if you use 32bit PowerPC, drop me a mail describing what kind of platform it is. ("powermac G4" for eg). Also useful would be lspci output, and the answer to "does it have ISA slots?". Thanks, Dave [*] It'd be a neat hack if we could extract this from openfirmware though.. -- http://www.codemonkey.org.uk From jjj123jjj at hushmail.com Tue Jun 24 20:24:43 2008 From: jjj123jjj at hushmail.com (Joshua C.) Date: Tue, 24 Jun 2008 22:24:43 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <20080624202444.3D4F211803C@mailserver5.hushmail.com> I read these comments but they are from year 2004 and 2005. And the propoced patch was in some of the 2.6.25-rc versions. This is not an extra functionallity but the only option (for some of us) to run linux on our laptops. The ACPI code is quite difficult to play with, so I don't see any "nightmare waiting to happen" here. If at the end there are so many bug reports connected with DSDT, then just drop the patch again. I don't see that much bug reports on opensuse, ubuntu and mandriva complaining about a kernel panic based on broken dsdt. Maybe Dave Jones should reconsider his opinion about it. Or at least try to explain to the notebook producers that they should test their bios to work with linux, too. Fedora is supposed to be "on the bleeding edge". so i really don't see any reasons against (at least trying to) inserting this patch in some RCs. Lets see what'll happen. it is always possible to revert the patch. -- Click to get a free auto insurance quotes from top companies. http://tagline.hushmail.com/fc/Ioyw6h4d8EIXAvwILUXMaz5GGa1ZtyyaAXI851HuaA9ykDdFoQLNoH/ From jspaleta at gmail.com Tue Jun 24 20:31:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 Jun 2008 12:31:50 -0800 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624202444.3D4F211803C@mailserver5.hushmail.com> References: <20080624202444.3D4F211803C@mailserver5.hushmail.com> Message-ID: <604aa7910806241331q38828173n7adcbe459d0b5701@mail.gmail.com> On Tue, Jun 24, 2008 at 12:24 PM, Joshua C. wrote: > Fedora is supposed to be "on the bleeding edge". so i really don't > see any reasons against (at least trying to) inserting this patch > in some RCs. Lets see what'll happen. it is always possible to > revert the patch. You missed a very important point. Its not just bleeding edge... but sustainable bleed-edge. We work closely with upstream. And in the case of this specific kernel patch. Doesn't everyone benefit by getting that patch into the mainline kernel? -jef From poelstra at redhat.com Tue Jun 24 20:42:26 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 24 Jun 2008 13:42:26 -0700 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: <48615C32.8050500@redhat.com> Dave Jones said the following on 06/24/2008 01:15 PM Pacific Time: > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > it is. ("powermac G4" for eg). Also useful would be lspci output, and > the answer to "does it have ISA slots?". > > Thanks, > > Dave > > [*] It'd be a neat hack if we could extract this from openfirmware though.. > # lspci 0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth AGP 0000:00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth PCI 0001:10:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) 0001:11:07.0 Class ff00: Apple Computer Inc. KeyLargo Mac I/O (rev 02) 0001:11:08.0 USB Controller: Apple Computer Inc. KeyLargo USB 0001:11:09.0 USB Controller: Apple Computer Inc. KeyLargo USB 0001:11:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller 0002:21:0b.0 Host bridge: Apple Computer Inc. UniNorth Internal PCI 0002:21:0f.0 Ethernet controller: Apple Computer Inc. UniNorth GMAC (Sun GEM) (rev 01) It's a "screamer" too ;-) # cat /proc/cpuinfo processor : 0 cpu : 7400, altivec supported temperature : 20 C (uncalibrated) clock : 400.000000MHz revision : 2.9 (pvr 000c 0209) bogomips : 49.66 timebase : 24908583 platform : PowerMac machine : PowerMac3,1 motherboard : PowerMac3,1 MacRISC Power Macintosh detected as : 65 (PowerMac G4 AGP Graphics) pmac flags : 00000004 L2 cache : 1024K unified pmac-generation : NewWorld From dcbw at redhat.com Tue Jun 24 21:35:09 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 24 Jun 2008 17:35:09 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: <1214343309.11980.6.camel@localhost.localdomain> On Tue, 2008-06-24 at 16:15 -0400, Dave Jones wrote: > PPC32 kernel builds take _forever_ in the build system. They're slowing things > down to such extent that I'm usually still waiting for them several hours > after the other architectures have finished building. > > One way to make them slightly faster is to not build as many modules. > Looking through the config files, there's some obvious silly stuff in there > (I really really hope no-one found a way to put an IWL4965 in a PPC32 box). Only the G5 (ie, 64-bit) was released with PCI-E slots. Unless somebody is using PCI-E on a PPC32 board that's not a Mac, or is installing 32-bit Fedora on a 64-bit G5 box, there's absolutely no way that PPC32 could coexist with the 3945 or 4965. You'd also have to get a PCI-E-to-ExpressCard or PCI-E-to-MiniCard carrier. No PowerBooks ever had internal PCI-E minicard slots. No PowerBooks ever had ExpressCard slots. Dan > The likelyhood of someone needing infiniband drivers on such a box is also > somewhat slim. In culling out the obvious options though, there's a bunch > where I'm not quite sure, largely due to a) my ignorance when it comes to PPC, > and b) I have no idea what hardware platforms users are actually running Fedora > PPC32 on. (And smolt is useless here, because PPC boxes don't have DMI[*]). > > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > it is. ("powermac G4" for eg). Also useful would be lspci output, and > the answer to "does it have ISA slots?". > > Thanks, > > Dave > > [*] It'd be a neat hack if we could extract this from openfirmware though.. > > -- > http://www.codemonkey.org.uk > From arjan at infradead.org Tue Jun 24 21:40:24 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 24 Jun 2008 14:40:24 -0700 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <604aa7910806241331q38828173n7adcbe459d0b5701@mail.gmail.com> References: <20080624202444.3D4F211803C@mailserver5.hushmail.com> <604aa7910806241331q38828173n7adcbe459d0b5701@mail.gmail.com> Message-ID: <20080624144024.093f5201@infradead.org> On Tue, 24 Jun 2008 12:31:50 -0800 "Jeff Spaleta" wrote: > On Tue, Jun 24, 2008 at 12:24 PM, Joshua C. > wrote: > > Fedora is supposed to be "on the bleeding edge". so i really don't > > see any reasons against (at least trying to) inserting this patch > > in some RCs. Lets see what'll happen. it is always possible to > > revert the patch. > > > You missed a very important point. Its not just bleeding edge... but > sustainable bleed-edge. > We work closely with upstream. And in the case of this specific kernel > patch. Doesn't everyone benefit by getting that patch into the > mainline kernel? > said upstream patch was merged by Linus for a short while and then reverted for quality reasons.... so that would be a strong indication of "maybe not a good idea" -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jkeating at redhat.com Tue Jun 24 21:44:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jun 2008 17:44:15 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214343309.11980.6.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <1214343309.11980.6.camel@localhost.localdomain> Message-ID: <1214343855.11688.8.camel@localhost.localdomain> On Tue, 2008-06-24 at 17:35 -0400, Dan Williams wrote: > or is installing > 32-bit Fedora on a 64-bit G5 box As far as I know, that's not possible. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Tue Jun 24 21:57:46 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 24 Jun 2008 22:57:46 +0100 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > it is. ("powermac G4" for eg). Also useful would be lspci output, and > the answer to "does it have ISA slots?". I didn't think any Apple PPC machines ever had ISA as actual slots. Whether other PPC machines from IBM or others did I'm not sure, or whether PPC has the embedded ISA stuff like some of the newer Intel stuff for things like the i2c bus. Can we just disable a lot and get it reported on the list or bugs. What options do the yellow dog guys enable in their 32 bit kernels? Peter From jspaleta at gmail.com Tue Jun 24 22:03:10 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 Jun 2008 14:03:10 -0800 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624144024.093f5201@infradead.org> References: <20080624202444.3D4F211803C@mailserver5.hushmail.com> <604aa7910806241331q38828173n7adcbe459d0b5701@mail.gmail.com> <20080624144024.093f5201@infradead.org> Message-ID: <604aa7910806241503t48b7f12oc8f5375231204f8b@mail.gmail.com> On Tue, Jun 24, 2008 at 1:40 PM, Arjan van de Ven wrote: > said upstream patch was merged by Linus for a short while and then > reverted for quality reasons.... so that would be a strong indication > of "maybe not a good idea" Even better... everyone benefits by not being exposed to a poor quality patch. The question, which I can't personally answer, becomes what is it going to take to clean this patch up so it can be upstreamed. -jef From sandeen at redhat.com Tue Jun 24 22:05:43 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 24 Jun 2008 17:05:43 -0500 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <604aa7910806241503t48b7f12oc8f5375231204f8b@mail.gmail.com> References: <20080624202444.3D4F211803C@mailserver5.hushmail.com> <604aa7910806241331q38828173n7adcbe459d0b5701@mail.gmail.com> <20080624144024.093f5201@infradead.org> <604aa7910806241503t48b7f12oc8f5375231204f8b@mail.gmail.com> Message-ID: <48616FB7.1030806@redhat.com> Jeff Spaleta wrote: > On Tue, Jun 24, 2008 at 1:40 PM, Arjan van de Ven wrote: >> said upstream patch was merged by Linus for a short while and then >> reverted for quality reasons.... so that would be a strong indication >> of "maybe not a good idea" > > Even better... everyone benefits by not being exposed to a poor quality patch. > > The question, which I can't personally answer, becomes what is it > going to take to clean this patch up so it can be upstreamed. It looks like it's already underway, at least as far as the author is concerned. From http://gaugusch.at/kernel.shtml : Update as of 2008-03-15: Several maintainers in the Linux kernel have started to reconsider their position on the feature. The patch as even made a brief appearance in some development versions of the kernel 2.6.25 (it has been reverted because deemed too likely to bring bugs, but a new approach, patch v0.9, is already available for next development cycle). -Eric From lightsolphoenix at gmail.com Tue Jun 24 22:13:54 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Tue, 24 Jun 2008 18:13:54 -0400 Subject: rhgb no more In-Reply-To: <45abe7d80806231051v4f257a32xc8b821208c3c39fd@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <45abe7d80806231051v4f257a32xc8b821208c3c39fd@mail.gmail.com> Message-ID: <200806241813.54747.lightsolphoenix@gmail.com> On June 23, 2008 1:51:31 pm Ray Strode wrote: > >The replacement for rhgb will be a mixture of two things: > > > > 1) Starting gdm as early as possible and fitting it to give boot > > progress before asking for login. This is somewhat in line with the > > early-login prototype feature some of you may remember from several > > fedora releases ago. > > > > 2) Hiding boot messages before gdm unless escape key is pressed. For > > graphics hardware that has drm modesetting, we'll be able to show some > > sort of pretty graphics, and for everyone else we'll show a very > > simple text mode progress. What about other display managers, like KDM or Entrance or XDM? From alan at redhat.com Tue Jun 24 22:18:46 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 24 Jun 2008 18:18:46 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: <20080624221846.GA2268@devserv.devel.redhat.com> On Tue, Jun 24, 2008 at 04:15:51PM -0400, Dave Jones wrote: > it is. ("powermac G4" for eg). Also useful would be lspci output, and > the answer to "does it have ISA slots?". Careful: our 'ISA' in the kernel also coverse the various LPC busses that replaced it. You can get burned if you just check for slots rather than onboard 'ISA' devices. From jjj123jjj at hushmail.com Tue Jun 24 23:18:56 2008 From: jjj123jjj at hushmail.com (Joshua C.) Date: Wed, 25 Jun 2008 01:18:56 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <20080624231858.05C632003E@mailserver7.hushmail.com> Eric Sandeen wrote: >It looks like it's already underway, at least as far as the author is >concerned. From http://gaugusch.at/kernel.shtml : > >Update as of 2008-03-15: Several maintainers in the Linux kernel have >started to reconsider their position on the feature. The patch as even >made a brief appearance in some development versions of the kernel >2.6.25 (it has been reverted because deemed too likely to bring bugs, >but a new approach, patch v0.9, is already available for next >development cycle). > >-Eric > ok guys, then it is up to whether the patch is "clean" enough to go in the mainstream kernel. I think the decision about a custom dsdt table in the kernel has been taken long time ago. and the answer is the option that enables the kernel to load a custom table. what the patch does is that it pospones the loading of the table until the initram is loaded. so the custom dsdt can be read from it. If someone thinks the patch isn't good enough, then he should suggest his own patch. but for now this is the only one available. Either in the kernel or in the initram, in both cases we can load our custom dsdt table. the only difference is that the kernel recompilation takes about 30 mins (compared to the 2mins for the repacking of the initram). I really don't see any objections to simplifying this process. Please, prove me wrong, but I'm just trying to make it easier to run linux on my machine. And the patch simlifies this process. PS: There is one more option: Email the acpi-dev-team my custom dsdt so that they can include it in the mainline kernel :). Since this is the "missing" code that breaks my machine, it should be send as a patch for inclussion. And this is the only way to make my hardware work. So maybe I should email the kernel-acpi-dev-team :). As you can see, this is a lot "dirtier" than the above solution. Any other ideas how to make my hardware work? :) Joshua -- Shop & save on the supplements you want. Click now! http://tagline.hushmail.com/fc/Ioyw6h4fK5SEhRB76ZjQFrf3fIDbozD9Jz2WUnmOvXQBcaKi9IoiwL/ From naheemzaffar at gmail.com Tue Jun 24 23:38:38 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 25 Jun 2008 00:38:38 +0100 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624231858.05C632003E@mailserver7.hushmail.com> References: <20080624231858.05C632003E@mailserver7.hushmail.com> Message-ID: <3adc77210806241638x54f30ed4pd1c4e07786892878@mail.gmail.com> If it fixes the problem for good instead of just working around it, I doubt many would see that as a dirtier solution. From vonbrand at inf.utfsm.cl Wed Jun 25 00:21:47 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 24 Jun 2008 20:21:47 -0400 Subject: rawhide report: 20080624 changes In-Reply-To: <20080624093601.4F94A209D3D@releng1.fedora.phx.redhat.com> References: <20080624093601.4F94A209D3D@releng1.fedora.phx.redhat.com> Message-ID: <200806250021.m5P0Llj1006244@laptop13.inf.utfsm.cl> Rawhide wrote: [...] > kernel-2.6.26-0.85.rc7.git1.fc10 Crashes on boot on x86_64 and i686 (both dual-core) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From jwboyer at gmail.com Wed Jun 25 01:10:32 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 24 Jun 2008 21:10:32 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214343855.11688.8.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <1214343309.11980.6.camel@localhost.localdomain> <1214343855.11688.8.camel@localhost.localdomain> Message-ID: <1214356232.14225.71.camel@weaponx> On Tue, 2008-06-24 at 17:44 -0400, Jesse Keating wrote: > On Tue, 2008-06-24 at 17:35 -0400, Dan Williams wrote: > > or is installing > > 32-bit Fedora on a 64-bit G5 box > > As far as I know, that's not possible. Not anymore anyway. josh From jwboyer at gmail.com Wed Jun 25 01:11:41 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 24 Jun 2008 21:11:41 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214343309.11980.6.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <1214343309.11980.6.camel@localhost.localdomain> Message-ID: <1214356301.14225.74.camel@weaponx> On Tue, 2008-06-24 at 17:35 -0400, Dan Williams wrote: > > Only the G5 (ie, 64-bit) was released with PCI-E slots. Unless somebody > is using PCI-E on a PPC32 board that's not a Mac, or is installing I have some dubious plans for that. But they are irrelevant here, as it would require a different flavor of kernel that we build today anyway. josh From jwboyer at gmail.com Wed Jun 25 01:14:57 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 24 Jun 2008 21:14:57 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: <1214356497.14225.77.camel@weaponx> On Tue, 2008-06-24 at 16:15 -0400, Dave Jones wrote: > PPC32 kernel builds take _forever_ in the build system. They're slowing things > down to such extent that I'm usually still waiting for them several hours > after the other architectures have finished building. Has anyone looked at _why_ they are so slow? Do you have timing information for a particular kernel flavor? If I'm remembering correctly, local kernel builds on my G5 were quite faster than what is in koji. Finding out why might be a good start. josh From aoliva at redhat.com Wed Jun 25 01:21:53 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Tue, 24 Jun 2008 22:21:53 -0300 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214168908.3377.58.camel@hughsie-work> (Richard Hughes's message of "Sun\, 22 Jun 2008 22\:08\:28 +0100") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: On Jun 22, 2008, Richard Hughes wrote: > Maybe you could spend more time on compiler design and optimisation than > evangelism? This is really wearing a bit thin with hundreds of emails > with the same tune to this mailing list. If you'd read them, you'd know this was already discussed, and it was pointed out by other developers that the discussion was relevant. You'd also know that we've covered several different topics, starting with one that is hardly off-topic, sticking to some that definitely are, while a few others were indeed better suited for legal, and others for which there's no better-suited list. Now, since you have clearly not read the messages you're complaining about, why are you even annoyed by them? Was it too hard to just delete them? Do you find the topic particularly disturbing or welcome, or is it just so annoying to delete this particular thread with a few messages a day from among the other hundreds of messages that read this list daily? Since this is the list where policies are debated, meetings are called, etc, framing the discussion as unwelcome would almost make it sound like software freedom is not welcome in Fedora. I realize it's (unfortunately) not consensus, but I'd hardly believe it's not something a lot of Fedora developers care about. Besides, it's kind of silly to wait for the end of the thread to only then complain about it. Odds are it would result in prologing a dying discussion, which is precisely what you didn't want. And then, "shut up or I'll leave" is quite tempting. If you don't want to participate, just don't. There's no point in going "gimme what I want or I won't play with you any more"; it sounds as terrifying as similar threats from my four year old, even though I'm sure you didn't quite mean it that way. Heh. Take care, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From francis.earl at gmail.com Wed Jun 25 02:14:34 2008 From: francis.earl at gmail.com (Francis Earl) Date: Tue, 24 Jun 2008 19:14:34 -0700 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: <1214360074.7375.18.camel@trinity.home.net> > Since this is the list where policies are debated, meetings are > called, etc, framing the discussion as unwelcome would almost make it > sound like software freedom is not welcome in Fedora. I realize it's > (unfortunately) not consensus, but I'd hardly believe it's not > something a lot of Fedora developers care about. Actually, I believe the consensus is that Fedora should continue its ethics and not cave because it'll get more users. If a user can't figure out how to add Livna to their repo, or makes poor choices when purchasing hardware, that's not Fedora's problem. Fedora is about advancing the best software FOSS has to offer, how many users it has benefits no one! I think the #1 thing people using or contributing to Fedora care about are these ideals, although those same ideals say you can use that software however you wish. Red Hat doesn't go out of its way to make it difficult to get codecs or drivers etc though, it just doesn't go out of its way to provide them. Basically, those complaining constantly are just too lazy to figure out how to do what they want, so why should people have to see post and post on the lists about it? It is Ubuntu's place to cave on anything that will get them more users. Are they extremely popular for doing so? Sure, but what are they really accomplishing for the FOSS community? They are attracting a whole new breed of user that doesn't care, and they are gradually making Linux less fun. I think debates about legal issues, and Fedora's ethics are pointless and should be moderated in some way. Fedora should never have to cater to any proprietary software vendor just because users that don't educate themselves on the reasoning are complaining. It's tedious to see so many debates about policies when they'll amount to nothing. I think Fedora would lose more users than it gains by even considering such things anyway! The morals and beliefs of Fedora are what brings a lot of users to Fedora, it is what makes people passionate about Fedora, and they are what set Fedora apart. I for one paid $200 more for my hardware just to ensure that my hardware is well supported on Fedora, I should write that off as wasted money because the vocal minority won't shut up about technical decisions they don't understand? It is particularly pointless because there ARE distro's who's sole purpose is to cater to them. They should stick to those distros and leave Fedora to those passionate about its beliefs. From arjan at infradead.org Wed Jun 25 02:38:03 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 24 Jun 2008 19:38:03 -0700 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624231858.05C632003E@mailserver7.hushmail.com> References: <20080624231858.05C632003E@mailserver7.hushmail.com> Message-ID: <20080624193803.6a9b3785@infradead.org> On Wed, 25 Jun 2008 01:18:56 +0200 "Joshua C." wrote: > > PS: There is one more option: > Email the acpi-dev-team my custom dsdt so that they can include it > in the mainline kernel :). Since this is the "missing" code that > breaks my machine, it should be send as a patch for inclussion. And > this is the only way to make my hardware work. So maybe I should > email the kernel-acpi-dev-team :). As you can see, this is a lot > "dirtier" than the above solution. Any other ideas how to make my > hardware work? :) as someone who works for Intel near the ACPI dev team (yes one cube away)... lets put it this way: If Windows works with the BIOS, and Linux does not, that is a bug that needs fixing in Linux. The ACPI team takes this and other bugs VERY seriously; especially if the impact is severe functional impairment and Windows does work. I would strongly suggest you file a bug in bugzilla.kernel.org attaching your dsdt.... -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From sandeen at redhat.com Wed Jun 25 02:42:24 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 24 Jun 2008 21:42:24 -0500 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624231858.05C632003E@mailserver7.hushmail.com> References: <20080624231858.05C632003E@mailserver7.hushmail.com> Message-ID: <4861B090.8000608@redhat.com> Joshua C. wrote: > ok guys, > > then it is up to whether the patch is "clean" enough to go in the > mainstream kernel. Yes, that is basically it. > I think the decision about a custom dsdt table in the kernel has > been taken long time ago. and the answer is the option that enables > the kernel to load a custom table. what the patch does is that it > pospones the loading of the table until the initram is loaded. so > the custom dsdt can be read from it. > > If someone thinks the patch isn't good enough, then he should > suggest his own patch. but for now this is the only one available. > Either in the kernel or in the initram, in both cases we can load > our custom dsdt table. the only difference is that the kernel > recompilation takes about 30 mins (compared to the 2mins for the > repacking of the initram). I really don't see any objections to > simplifying this process. > > Please, prove me wrong, but I'm just trying to make it easier to > run linux on my machine. And the patch simlifies this process. There's really nothing to prove. Fedora isn't in the business of maintaining patches not in upstream for long periods of time; it hurts Fedora because of the maintenance load, and it hurts the kernel in general because the problem isn't being fixed at the source. So if there's something you need, find a way to help it get upstream. Probably the best thing you could do would be to email the patch author, test the patch he plans to submit next time, and when he does, chime in with the fact that it works well for you. If people have concerns about ways it might break, see if you can break it in those ways, etc. I do understand that the functionality provided by the patch makes your life easier, but these things have to be done in maintainable ways. It looks like there's a decent chance the patch will be upstream soon, then we can all be happy. :) -Eric From halfline at gmail.com Wed Jun 25 02:57:11 2008 From: halfline at gmail.com (Ray Strode) Date: Tue, 24 Jun 2008 22:57:11 -0400 Subject: rhgb no more In-Reply-To: <200806241813.54747.lightsolphoenix@gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <45abe7d80806231051v4f257a32xc8b821208c3c39fd@mail.gmail.com> <200806241813.54747.lightsolphoenix@gmail.com> Message-ID: <45abe7d80806241957s555edfbr310b7cf3eaec8886@mail.gmail.com> Hi, > What about other display managers, like KDM or Entrance or XDM? I answered that in the mail you replied to (but not the part you quoted) :-) Originally, we were going to start GDM early, but have gotten good results without that, so we aren't going to do it for now. We are going to have to do some integration work with GDM to ensure a smooth transition between plymouth and GDM, but if that integration work is lacking in other display managers it should just result in flicker, not a fatal problem. --Ray From michael at laptop.org Wed Jun 25 03:16:32 2008 From: michael at laptop.org (Michael Stone) Date: Tue, 24 Jun 2008 23:16:32 -0400 Subject: OLPC Packaging Wishlist Message-ID: <20080625031628.GA27081@teach.media.mit.edu> Dear OLPC & Fedora folk: In response to conversation at Fudcon, I've thrown up OLPC's packaging wishlist at https://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist OLPC folks: please check to make sure that your work is listed. Also, please assist Fedora volunteers in any way you can, for example, by working with them to provide any missing information that is necessary for packaging. Fedora folks: please let us know where you need more information! Also, don't be shy about joining #olpc-devel on irc.oftc.net and asking if it looks like we're doing something dumb. Michael From tmraz at redhat.com Wed Jun 25 07:36:14 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 25 Jun 2008 09:36:14 +0200 Subject: gnutls upgrade in rawhide to 2.4.0 and license change In-Reply-To: <1213967520.25242.8.camel@vespa.frost.loc> References: <1213967520.25242.8.camel@vespa.frost.loc> Message-ID: <1214379374.5983.45.camel@vespa.frost.loc> On Fri, 2008-06-20 at 15:12 +0200, Tomas Mraz wrote: > I plan to do gnutls library update in rawhide to version 2.4.0 soon. > Unfortunately the ABI of this version is different from 2.0.4 as is > currently in rawhide. That means that all the libraries and applications > which depend on it will have to be rebuilt. Unfortunately libsoup22 does not rebuild cleanly with the new gnutls package. The ssl test is crashing. I'm still investigating the problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From adrian.joian at fedoraproject.ro Wed Jun 25 07:45:22 2008 From: adrian.joian at fedoraproject.ro (Adrian Joian) Date: Wed, 25 Jun 2008 10:45:22 +0300 Subject: Fedora 9 kernel configuration Message-ID: <4861F792.1000008@fedoraproject.ro> Hello, My name is Adrian Joian and I'm a fedora ambassador [1] for the Romanian community. This is my first time that I'm addressing the devel list so please be patient with me. I plan to write an article that will speak about Fedora 9 on laptops on our local site [2]. My question is why the 2.6.25.6-55.fc9.i686 kernel is not compiled whit the following options, as they have big impact on laptop "cpu sleep" : CONFIG_HPET_TIMER CONFIG_NO_HZ CONFIG_USB_SUSPEND Are this values replaced by new ones, if yes what are the new options, and forgive my lack of knowledge? Do the above values cause some problems, if yes where can I find the bug reports, again and forgive my lack of knowledge ? Thank you very much for your time. [1] - https://fedoraproject.org/wiki/AdrianJoian [2] - http://www.fedoraproject.ro/ Best regards, Adrian JOIAN From loupgaroublond at gmail.com Wed Jun 25 08:03:38 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 25 Jun 2008 10:03:38 +0200 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: <7f692fec0806250103h10f65a1i89cc540409de69b7@mail.gmail.com> Alexandre, On Wed, Jun 25, 2008 at 3:21 AM, Alexandre Oliva wrote: > On Jun 22, 2008, Richard Hughes wrote: > >> Maybe you could spend more time on compiler design and optimisation than >> evangelism? This is really wearing a bit thin with hundreds of emails >> with the same tune to this mailing list. > > If you'd read them, you'd know this was already discussed, and it was > pointed out by other developers that the discussion was relevant. > You'd also know that we've covered several different topics, starting > with one that is hardly off-topic, sticking to some that definitely > are, while a few others were indeed better suited for legal, and > others for which there's no better-suited list. Could you please make this thread die, immediately if not sooner? Yes, you are correct that these discussions are relevant to the future of Free Software, Open Source, Fedora, and any other label you want to attach to the conversation. However, this presents a few large problems. First, Richard Hughes is right. This mailing list is intended for technical discussions *only*. I'm sure many people on this list are more than willing to participate in such conversations, and even find it valuable to do so, but this is the wrong place for it. Period. Second, there are a number of other mailing lists better suited for this discussion. Why are you leaving those people out of the conversation? Third, this mailing list is highly flammable. Bringing up the issue *again* about how freedom is important just encourages more posts on the same topic. People here have had enough of the topic on this list already. Continuing to defend your decision to post to the wrong mailing list is only going to drive our developers away from this mailing list. So please do us a favour. Either move this conversation to another mailing list, or just drop it and let it die. If you want to comment on this message, please discuss it with me off list, or if you really honestly feel this conversation needs to be in public (and I really don't,) there is the fedora-advisory-board mailing list. I'm sure they could 'advise' us both what the correct usage of a development oriented mailing list is. -Yaakov From fedora at camperquake.de Wed Jun 25 08:16:49 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 25 Jun 2008 10:16:49 +0200 Subject: rawhide report: 20080624 changes In-Reply-To: <200806250021.m5P0Llj1006244@laptop13.inf.utfsm.cl> References: <20080624093601.4F94A209D3D@releng1.fedora.phx.redhat.com> <200806250021.m5P0Llj1006244@laptop13.inf.utfsm.cl> Message-ID: <20080625101649.0725ec5b@addix-jd-wxp.int.addix.net> Hi. On Tue, 24 Jun 2008 20:21:47 -0400, Horst H. von Brand wrote: > > kernel-2.6.26-0.85.rc7.git1.fc10 > > Crashes on boot on x86_64 and i686 (both dual-core) Are current kernels still built with GCC 4.3.1, or has that been removed from the build roots? From jjj123jjj at hushmail.com Wed Jun 25 08:28:17 2008 From: jjj123jjj at hushmail.com (Joshua C.) Date: Wed, 25 Jun 2008 10:28:17 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <20080625082821.061D515803E@mailserver6.hushmail.com> On Wed, 25 Jun 2008 04:38:03 +0200 Arjan van de Ven wrote: > >as someone who works for Intel near the ACPI dev team (yes one >cube >away)... lets put it this way: >If Windows works with the BIOS, and Linux does not, that is a bug >that >needs fixing in Linux. The ACPI team takes this and other bugs >VERY >seriously; especially if the impact is severe functional >impairment and >Windows does work. I would strongly suggest you file a bug in >bugzilla.kernel.org attaching your dsdt.... > Thank you for the advice. I filed a bugreport at bugzilla.kernel.org and this is how we got the bad dsdt table (vista and xp never expirienced this problem). the report is here: http://bugzilla.kernel.org/show_bug.cgi?id=10237 As you can see all works well now. But I have to manually insert the dsdt in the kernel and recompile it for every kernel. :( I think the acpi-dev-team did a great job finding and repairing this bug but there is nothing else they could do. Inclusion of my dsdt in the mainstream kernel is a bad idea because: 1. in the future the table could be repaired but i don't believe this. 2. en extra code will be needed to chack for the machine version and the bios and apply the patch only on my machine type. :( 3. the kernel shouldn't be a place to put working dsdt tables Now I'm waiting for another solution to save the 30 min (+ config time) for recompilation. -- Enter for Your Chance to WIN* The TotalBeauty.com Summer Spa Sweepstakes! http://tagline.hushmail.com/fc/JKFkuIjyZ57oJlsSjM42VuVf5IcP2M677NnHCXBFw04CPdXtDuuMV9/ From hughsient at gmail.com Wed Jun 25 08:31:46 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 25 Jun 2008 09:31:46 +0100 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> Message-ID: <1214382706.3224.12.camel@hughsie-work> On Tue, 2008-06-24 at 22:21 -0300, Alexandre Oliva wrote: > And then, "shut up or I'll leave" is quite tempting. If you don't > want to participate, just don't. You are posting this from your @redhat.com email address. As a fellow Red Hatter, I want you to stop posting from your corporate email, and instead use something else (maybe ?oliva at gnu.org might be best).? Doing so makes the community think this is the view of Red Hat, when ?quite clearly it's not. If you are indeed writing these emails in work time, then maybe you and your manager need to evaluate your priorities better. Sorry to sound harsh, but I _am_ part of Red Hat and you are making _me_ look bad. Richard (rhughes_at_redhat_dot_com) From jjj123jjj at hushmail.com Wed Jun 25 08:41:29 2008 From: jjj123jjj at hushmail.com (Joshua C.) Date: Wed, 25 Jun 2008 10:41:29 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <20080625084130.F2955D032F@mailserver10.hushmail.com> On Wed, 25 Jun 2008 04:42:24 +0200 Eric Sandeen wrote: >Joshua C. wrote: > >> ok guys, >> >> then it is up to whether the patch is "clean" enough to go in >the >> mainstream kernel. > >Yes, that is basically it. > >> I think the decision about a custom dsdt table in the kernel has > >> been taken long time ago. and the answer is the option that >enables >> the kernel to load a custom table. what the patch does is that >it >> pospones the loading of the table until the initram is loaded. >so >> the custom dsdt can be read from it. >> >> If someone thinks the patch isn't good enough, then he should >> suggest his own patch. but for now this is the only one >available. >> Either in the kernel or in the initram, in both cases we can >load >> our custom dsdt table. the only difference is that the kernel >> recompilation takes about 30 mins (compared to the 2mins for the > >> repacking of the initram). I really don't see any objections to >> simplifying this process. >> >> Please, prove me wrong, but I'm just trying to make it easier to > >> run linux on my machine. And the patch simlifies this process. > >There's really nothing to prove. Fedora isn't in the business of >maintaining patches not in upstream for long periods of time; it >hurts >Fedora because of the maintenance load, and it hurts the kernel in >general because the problem isn't being fixed at the source. > >So if there's something you need, find a way to help it get >upstream. > >Probably the best thing you could do would be to email the patch >author, >test the patch he plans to submit next time, and when he does, >chime in >with the fact that it works well for you. If people have concerns >about >ways it might break, see if you can break it in those ways, etc. > >I do understand that the functionality provided by the patch makes >your >life easier, but these things have to be done in maintainable >ways. It >looks like there's a decent chance the patch will be upstream >soon, then >we can all be happy. :) > >-Eric > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list I tried it (v.0.9) and it worked for me without any issues. -- Smart Girls Secret Weapon Read Unbiased Beauty Product Reviews, Get Helpful Tips, Tricks and Sam http://tagline.hushmail.com/fc/JKFkuIjyaUNYxOtRufju68yr6F5O4Rtu6kypgcoGTywfjNAEWRCqiv/ From rawhide at fedoraproject.org Wed Jun 25 09:18:11 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 25 Jun 2008 09:18:11 +0000 (UTC) Subject: rawhide report: 20080625 changes Message-ID: <20080625091811.9E1D8209D23@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080624/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080625/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package R-lmtest Testing Linear Regression Models for R New package libibcm Userspace InfiniBand Connection Manager New package liblicense Content License Library New package perl-Algorithm-Permute Handy and fast permutation with object oriented interface New package perl-Authen-Captcha Perl extension for creating captchas New package perl-Business-CreditCard Validate/generate credit card checksums/names New package perl-String-Random Perl module to generate random strings based on a pattern New package perl-TAP-Harness-Archive Create an archive of TAP test results New package perl-Test-Mock-LWP Easy mocking of LWP packages New package speech-dispatcher To provide a high-level device independent layer for speech synthesis Updated Packages: QuantLib-0.9.0-5.fc10 --------------------- aiccu-2007.01.15-4.fc10 ----------------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz 2007.01.15-4 - rebuild with new gnutls aria2-0.12.0-5.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz - 0.12.0-5 - rebuild with new gnutls autoconf-2.62-3.fc10 -------------------- * Tue Jun 24 18:00:00 2008 Karsten Hopp 2.62-3 - add fix for same line comments #449245 (Ralf Wildenhues) climm-0.6.2-4.fc10 ------------------ * Tue Jun 24 18:00:00 2008 Tomas Mraz - 0.6.2-4 - rebuild with new gnutls cluster-2.99.05-1.fc10 ---------------------- * Tue Jun 24 18:00:00 2008 Fabio M. Di Nitto - 2.99.05-1 - New upstream release - Update licence tags again after upstream relicensing to kill OSL 2.1. - Add 2 commodity packages (gfs-utils and gnbd-utils). They both require external kernel modules but at least userland will stay automatically in sync for our users. - BR openais 0.84 for new logsys symbols (and requires for runtime). - Update build section to enable gfs-utils and gnbd-utils. compiz-fusion-0.7.6-5.fc10 -------------------------- * Tue Jun 24 18:00:00 2008 Adel Gadllah 0.7.6-5 - Fix up scriptlets (RH #452674) compiz-fusion-extras-0.7.6-5.fc10 --------------------------------- * Tue Jun 24 18:00:00 2008 Adel Gadllah 0.7.6-5 - Fix up scriptlets (RH #452677) cups-1.3.7-10.fc10 ------------------ * Tue Jun 24 18:00:00 2008 Tim Waugh 1:1.3.7-10 - Rebuilt for new gnutls. deluge-0.5.9.3-1.fc10 --------------------- * Tue Jun 24 18:00:00 2008 Peter Gordon - 0.5.9.3-1 - Update to new upstream release (0.5.9.3) dvgrab-3.1-3.fc10 ----------------- * Tue Jun 24 18:00:00 2008 Jarod Wilson - 3.1-3 - Fix segfault when we get bogus timecodes (#370931) ed-0.9-1.fc10 ------------- * Tue Jun 24 18:00:00 2008 Karsten Hopp 0.9-1 - version 0.9 * Sun Mar 23 18:00:00 2008 Tom "spot" Callaway - 0.8-3 - fix license tag epiphany-extensions-2.22.1-2.fc9 -------------------------------- * Sun Jun 22 18:00:00 2008 Martin Stransky - 2.22.1-2 - Rebuild against newer gecko fedora-release-9.90.1-1 ----------------------- * Wed Jun 11 18:00:00 2008 Jesse Keating - 9.90-2 - Package up the ia64 key as the first secondary arch - Mark config files correctly - Stop using download.fedora.redhat.com and use download.fedoraproject.org instead filesystem-2.4.18-1.fc10 ------------------------ * Tue Jun 24 18:00:00 2008 Phil Knirsch - 2.4.18-1 - Added comment with raw format lang-exception URL gcc-4.3.1-3 ----------- * Tue Jun 24 18:00:00 2008 Jakub Jelinek 4.3.1-3 - update from gcc-4_3-branch - PRs c++/35317, c++/35320, documentation/30739, fortran/34908, fortran/36276, fortran/36538, java/36247, middle-end/36584, rtl-optimization/35604, target/36336, target/36424, tree-optimization/36493, tree-optimization/36498, tree-optimization/36504, tree-optimization/36519 - don't mark hard registers as reg pointers (#451068, target/36533) - allow more compute_antic iterations (#450889, tree-optimization/36508) - fix #pragma omp task copyfn registration with cgraph (c++/36523) gnome-themes-extras-2.22.0-2.fc9 -------------------------------- * Sat Jun 21 18:00:00 2008 Marc Wiriadisastra - 2.22.0-2 - Fixed changelog - Added patch to fix bz#449428 which fixes the Darklooks theme gnutls-2.4.0-1.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz 2.4.0-1 - upgrade to latest upstream gvfs-0.99.1-3.fc10 ------------------ * Tue Jun 24 18:00:00 2008 Tomas Bzatek - 0.99.1-3 - gvfsd-trash: Skip autofs mounts jabbim-0.4.1-3.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Michal Schmidt - 0.4.1-3 - Add upstream patch to prevent initial message loss if sender's mood is empty. jd-2.0.0-0.6.svn2145_trunk.fc10.1 --------------------------------- * Tue Jun 24 18:00:00 2008 Mamoru Tasaka - F-10: rebuild against new gnutls - F-10: kill subversion tagging until dependency is solved. kdebase-4.0.83-2.fc10 --------------------- * Tue Jun 24 18:00:00 2008 Luk???? Tinkl - 4.0.83-2 - #426108: Add more directories to konqueror's default plugin search path list kdepim-4.0.83-2.fc10 -------------------- * Tue Jun 24 18:00:00 2008 Than Ngo 4.0.83-2 - respun kdepimlibs-4.0.83-2.fc10 ------------------------ * Tue Jun 24 18:00:00 2008 Than Ngo 4.0.83-2 - respun kernel-2.6.26-0.90.rc7.git2.fc10 -------------------------------- * Tue Jun 24 18:00:00 2008 John W. Linville - Upstream wireless updates from 2008-06-14 (http://marc.info/?l=linux-netdev&m=121346686508160&w=2) * Tue Jun 24 18:00:00 2008 John W. Linville - Restore wireless patches disabled during recent updates * Tue Jun 24 18:00:00 2008 Dave Jones - Disable the RCU linked list debug routines for now. * Tue Jun 24 18:00:00 2008 Dave Jones - Disable a bunch of modules in the ppc32 kernel. * Tue Jun 24 18:00:00 2008 Dave Jones - 2.6.26-rc7-git2 libkdcraw-0.1.4-2.fc10 ---------------------- * Tue Jun 24 18:00:00 2008 Rex Dieter 0.1.4-2 - fix conflicts with kdegraphics (f9+, #452392) libkipi-0.1.6-2.fc10 -------------------- * Tue Jun 24 18:00:00 2008 Rex Dieter 0.1.6-2 - fix conflicts with kdegraphics (f9+, #452392) libsoup-2.23.1-5.fc10 --------------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz - 2.23.1-5 - rebuild with new gnutls netpbm-10.35.46-1.fc10 ---------------------- * Tue Jun 24 18:00:00 2008 Jindrich Novy 10.35.46-1 - update to 10.35.46 - fixes pbmtext, pamtotga, pamtouil and pnmtopclxl nss-3.12.0.3-3.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Kai Engert - 3.12.0.3-3 - nss package should own /etc/prelink.conf.d folder, rhbz#452062 - use upstream patch to fix test suite abort perl-5.10.0-28.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Marcela Maslanova 4:5.10.0-28 - CVE-2008-2827 perl: insecure use of chmod in rmtree * Wed Jun 11 18:00:00 2008 Marcela Maslanova 4:5.10.0-27 - 447371 wrong access permission rt49003 perl-File-Find-Rule-Perl-1.04-2.fc10 ------------------------------------ * Tue Jun 24 18:00:00 2008 Ralf Cors??pius - 1.04-2 - Unconditionally BR: perl(Test::CPAN::Meta). perl-SOAP-Lite-0.710.07-1.fc10 ------------------------------ * Tue Jun 24 18:00:00 2008 Mike McGrath - 0.710.07-1 - Upstream released new version pungi-2.0.1-1.fc10 ------------------ * Tue Jun 24 18:00:00 2008 Jesse Keating - 2.0.1-1 - Take on splittree and pkgorder from anaconda. pvm-3.4.5-11.fc10 ----------------- * Tue Jun 24 18:00:00 2008 Doug Ledford - 3.4.5-11 - spec file cleanups - add arch patch that fixes upgrade issues caused by arch definition change in a minor point release * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 0.9.5-1 - Update to 0.9.5. - Remove license patch which is now corrected upstream. readahead-1.4.4-1.fc10 ---------------------- * Tue Jun 24 18:00:00 2008 Karel Zak 1:1.4.4-1 - upgrade to 1.4.4 selinux-policy-3.4.2-7.fc10 --------------------------- * Tue Jun 24 18:00:00 2008 Dan Walsh 3.4.2-7 - Allow confined users to use postgres - Allow system_mail_t to exec other mail clients - Label mogrel_rails as an apache server system-config-language-1.3.1-1.fc10 ----------------------------------- * Tue Jun 24 18:00:00 2008 Pravin Satpute - 1.3.1-1 - upstream release 1.3.1 tiquit-2.5.1-1.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Jon Ciesla - 2.5.1-1 - New upstream, BZ 452747. vdr-skinsoppalusikka-1.6.1-1.fc10 --------------------------------- * Wed Jun 25 18:00:00 2008 - Ville-Pekka Vainio 1.6.1-1 - 1.6.1 including translation updates and a bugfix Summary: Added Packages: 10 Removed Packages: 0 Modified Packages: 41 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ctrlproxy-3.0.5-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) ctrlproxy-3.0.5-2.fc9.i386 requires libgnutls.so.13 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 filezilla-3.0.11-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) filezilla-3.0.11-1.fc10.i386 requires libgnutls.so.13 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.i386 requires ghc682 gkrellm-2.3.1-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) gkrellm-2.3.1-3.fc9.i386 requires libgnutls-openssl.so.13 gkrellm-2.3.1-3.fc9.i386 requires libgnutls.so.13 gobby-0.4.5-3.fc9.i386 requires libgnutls.so.13 gtk-gnutella-0.96.5-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) gtk-gnutella-0.96.5-1.fc9.i386 requires libgnutls.so.13 gtk-vnc-0.3.6-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) gtk-vnc-0.3.6-1.fc10.i386 requires libgnutls.so.13 gurlchecker-0.10.1-8.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) gurlchecker-0.10.1-8.fc9.i386 requires libgnutls.so.13 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 heartbeat-2.1.3-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) heartbeat-2.1.3-1.fc9.i386 requires libgnutls.so.13 heartbeat-gui-2.1.3-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) heartbeat-gui-2.1.3-1.fc9.i386 requires libgnutls.so.13 iksemel-1.3-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) iksemel-1.3-4.fc9.i386 requires libgnutls.so.13 iksemel-utils-1.3-4.fc9.i386 requires libgnutls.so.13 kazehakase-0.5.4-4.fc9.i386 requires libgnutls.so.13 kazehakase-base-0.5.4-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) kazehakase-base-0.5.4-4.fc9.i386 requires libgnutls.so.13 kazehakase-ruby-0.5.4-4.fc9.i386 requires libgnutls.so.13 kvm-70-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) kvm-70-1.fc10.i386 requires libgnutls.so.13 libepc-0.3.5-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libepc-0.3.5-1.fc10.i386 requires libgnutls.so.13 libggz-0.0.14.1-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libggz-0.0.14.1-1.fc9.i386 requires libgnutls.so.13 libprelude-0.9.17.1-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libprelude-0.9.17.1-1.fc10.i386 requires libgnutls.so.13 libprelude-python-0.9.17.1-1.fc10.i386 requires libgnutls.so.13 libpreludedb-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libpreludedb-mysql-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libpreludedb-pgsql-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libpreludedb-python-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libpreludedb-sqlite-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtranslate-0.99-14.fc9.i386 requires libgnutls.so.13 libvirt-0.4.3-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libvirt-0.4.3-1.fc10.i386 requires libgnutls.so.13 liferea-1.4.15-5.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-5.fc9.i386 requires libgnutls.so.13 loudmouth-1.4.0-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) loudmouth-1.4.0-1.fc10.i386 requires libgnutls.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13 msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 5:mutt-1.5.18-2.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) 5:mutt-1.5.18-2.fc10.i386 requires libgnutls.so.13 neon-0.28.2-3.i386 requires libgnutls.so.13(GNUTLS_1_3) neon-0.28.2-3.i386 requires libgnutls.so.13 net6-1.3.5-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) net6-1.3.5-3.fc9.i386 requires libgnutls.so.13 ntfsprogs-2.0.0-7.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ntfsprogs-2.0.0-7.fc10.i386 requires libgnutls.so.13 obby-0.4.4-3.fc9.i386 requires libgnutls.so.13 perl-Algorithm-Permute-0.12-1.fc8.i386 requires perl(:MODULE_COMPAT_5.8.8) prelude-lml-0.9.12.2-1.fc10.i386 requires libgnutls.so.13 prelude-manager-0.9.12.1-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) prelude-manager-0.9.12.1-1.fc10.i386 requires libgnutls.so.13 prelude-manager-db-plugin-0.9.12.1-1.fc10.i386 requires libgnutls.so.13 qemu-0.9.1-9.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) qemu-0.9.1-9.fc10.i386 requires libgnutls.so.13 rsyslog-gnutls-3.19.7-2.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) rsyslog-gnutls-3.19.7-2.fc10.i386 requires libgnutls.so.13 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config snort-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-bloat-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-mysql-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-mysql+flexresp-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-plain+flexresp-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-postgresql-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-postgresql+flexresp-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-snmp-2.8.1-3.fc10.i386 requires libgnutls.so.13 snort-snmp+flexresp-2.8.1-3.fc10.i386 requires libgnutls.so.13 sobby-0.4.4-2.fc9.i386 requires libgnutls.so.13 stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 vinagre-2.23.3.1-1.fc10.i386 requires libgnutls.so.13 virt-viewer-0.0.3-1.fc9.i386 requires libgnutls.so.13 weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-gnome-1.0.0-2.fc9.i386 requires libgnutls.so.13 xen-runtime-3.2.0-12.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) xen-runtime-3.2.0-12.fc9.i386 requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ctrlproxy-3.0.5-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ctrlproxy-3.0.5-2.fc9.x86_64 requires libgnutls.so.13()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) filezilla-3.0.11-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) filezilla-3.0.11-1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.x86_64 requires ghc682 gkrellm-2.3.1-3.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gkrellm-2.3.1-3.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit) gkrellm-2.3.1-3.fc9.x86_64 requires libgnutls.so.13()(64bit) gobby-0.4.5-3.fc9.x86_64 requires libgnutls.so.13()(64bit) gtk-gnutella-0.96.5-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gtk-gnutella-0.96.5-1.fc9.x86_64 requires libgnutls.so.13()(64bit) gtk-vnc-0.3.6-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) gtk-vnc-0.3.6-1.fc10.i386 requires libgnutls.so.13 gtk-vnc-0.3.6-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gtk-vnc-0.3.6-1.fc10.x86_64 requires libgnutls.so.13()(64bit) gurlchecker-0.10.1-8.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gurlchecker-0.10.1-8.fc9.x86_64 requires libgnutls.so.13()(64bit) hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) heartbeat-2.1.3-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) heartbeat-2.1.3-1.fc9.i386 requires libgnutls.so.13 heartbeat-2.1.3-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) heartbeat-2.1.3-1.fc9.x86_64 requires libgnutls.so.13()(64bit) heartbeat-gui-2.1.3-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) heartbeat-gui-2.1.3-1.fc9.x86_64 requires libgnutls.so.13()(64bit) iksemel-1.3-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) iksemel-1.3-4.fc9.i386 requires libgnutls.so.13 iksemel-1.3-4.fc9.x86_64 requires libgnutls.so.13()(64bit) iksemel-1.3-4.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) iksemel-utils-1.3-4.fc9.x86_64 requires libgnutls.so.13()(64bit) kazehakase-0.5.4-4.fc9.x86_64 requires libgnutls.so.13()(64bit) kazehakase-base-0.5.4-4.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) kazehakase-base-0.5.4-4.fc9.x86_64 requires libgnutls.so.13()(64bit) kazehakase-ruby-0.5.4-4.fc9.x86_64 requires libgnutls.so.13()(64bit) kvm-70-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) kvm-70-1.fc10.x86_64 requires libgnutls.so.13()(64bit) libepc-0.3.5-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libepc-0.3.5-1.fc10.i386 requires libgnutls.so.13 libepc-0.3.5-1.fc10.x86_64 requires libgnutls.so.13()(64bit) libepc-0.3.5-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libggz-0.0.14.1-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libggz-0.0.14.1-1.fc9.i386 requires libgnutls.so.13 libggz-0.0.14.1-1.fc9.x86_64 requires libgnutls.so.13()(64bit) libggz-0.0.14.1-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libprelude-0.9.17.1-1.fc10.i386 requires libgnutls.so.13 libprelude-0.9.17.1-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) libprelude-python-0.9.17.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) libpreludedb-0.9.14.1-2.fc9.i386 requires libgnutls.so.13 libpreludedb-0.9.14.1-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libpreludedb-mysql-0.9.14.1-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libpreludedb-pgsql-0.9.14.1-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libpreludedb-python-0.9.14.1-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libpreludedb-sqlite-0.9.14.1-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) libtranslate-0.99-14.fc9.i386 requires libgnutls.so.13 libtranslate-0.99-14.fc9.x86_64 requires libgnutls.so.13()(64bit) libvirt-0.4.3-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) libvirt-0.4.3-1.fc10.i386 requires libgnutls.so.13 libvirt-0.4.3-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libvirt-0.4.3-1.fc10.x86_64 requires libgnutls.so.13()(64bit) liferea-1.4.15-5.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-5.fc9.x86_64 requires libgnutls.so.13()(64bit) loudmouth-1.4.0-1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) loudmouth-1.4.0-1.fc10.i386 requires libgnutls.so.13 loudmouth-1.4.0-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) loudmouth-1.4.0-1.fc10.x86_64 requires libgnutls.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 5:mutt-1.5.18-2.fc10.x86_64 requires libgnutls.so.13()(64bit) 5:mutt-1.5.18-2.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) neon-0.28.2-3.i386 requires libgnutls.so.13(GNUTLS_1_3) neon-0.28.2-3.i386 requires libgnutls.so.13 neon-0.28.2-3.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) neon-0.28.2-3.x86_64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) net6-1.3.5-3.fc9.i386 requires libgnutls.so.13 net6-1.3.5-3.fc9.x86_64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ntfsprogs-2.0.0-7.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ntfsprogs-2.0.0-7.fc10.i386 requires libgnutls.so.13 ntfsprogs-2.0.0-7.fc10.x86_64 requires libgnutls.so.13()(64bit) ntfsprogs-2.0.0-7.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) obby-0.4.4-3.fc9.i386 requires libgnutls.so.13 obby-0.4.4-3.fc9.x86_64 requires libgnutls.so.13()(64bit) perl-Algorithm-Permute-0.12-1.fc8.x86_64 requires perl(:MODULE_COMPAT_5.8.8) prelude-lml-0.9.12.2-1.fc10.x86_64 requires libgnutls.so.13()(64bit) prelude-manager-0.9.12.1-1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) prelude-manager-0.9.12.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) prelude-manager-db-plugin-0.9.12.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) qemu-0.9.1-9.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) qemu-0.9.1-9.fc10.x86_64 requires libgnutls.so.13()(64bit) rsyslog-gnutls-3.19.7-2.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) rsyslog-gnutls-3.19.7-2.fc10.x86_64 requires libgnutls.so.13()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config snort-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-bloat-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-mysql-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-mysql+flexresp-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-plain+flexresp-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-postgresql-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-postgresql+flexresp-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-snmp-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) snort-snmp+flexresp-2.8.1-3.fc10.x86_64 requires libgnutls.so.13()(64bit) sobby-0.4.4-2.fc9.x86_64 requires libgnutls.so.13()(64bit) stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) vinagre-2.23.3.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) virt-viewer-0.0.3-1.fc9.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) xen-runtime-3.2.0-12.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xen-runtime-3.2.0-12.fc9.x86_64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.x86_64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ctrlproxy-3.0.5-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) ctrlproxy-3.0.5-2.fc9.ppc requires libgnutls.so.13 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 filezilla-3.0.11-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) filezilla-3.0.11-1.fc10.ppc requires libgnutls.so.13 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc-haddock-2.0.0.0-2.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 ghc682-haddock-2.0.0.0-2.fc9.ppc requires ghc682 gkrellm-2.3.1-3.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) gkrellm-2.3.1-3.fc9.ppc requires libgnutls-openssl.so.13 gkrellm-2.3.1-3.fc9.ppc requires libgnutls.so.13 gobby-0.4.5-3.fc9.ppc requires libgnutls.so.13 gtk-gnutella-0.96.5-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) gtk-gnutella-0.96.5-1.fc9.ppc requires libgnutls.so.13 gtk-vnc-0.3.6-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) gtk-vnc-0.3.6-1.fc10.ppc requires libgnutls.so.13 gtk-vnc-0.3.6-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gtk-vnc-0.3.6-1.fc10.ppc64 requires libgnutls.so.13()(64bit) gurlchecker-0.10.1-8.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) gurlchecker-0.10.1-8.fc9.ppc requires libgnutls.so.13 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 heartbeat-2.1.3-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) heartbeat-2.1.3-1.fc9.ppc requires libgnutls.so.13 heartbeat-2.1.3-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) heartbeat-2.1.3-1.fc9.ppc64 requires libgnutls.so.13()(64bit) heartbeat-gui-2.1.3-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) heartbeat-gui-2.1.3-1.fc9.ppc requires libgnutls.so.13 iksemel-1.3-4.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) iksemel-1.3-4.fc9.ppc requires libgnutls.so.13 iksemel-1.3-4.fc9.ppc64 requires libgnutls.so.13()(64bit) iksemel-1.3-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) iksemel-utils-1.3-4.fc9.ppc requires libgnutls.so.13 kazehakase-0.5.4-4.fc9.ppc requires libgnutls.so.13 kazehakase-base-0.5.4-4.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) kazehakase-base-0.5.4-4.fc9.ppc requires libgnutls.so.13 kazehakase-ruby-0.5.4-4.fc9.ppc requires libgnutls.so.13 libepc-0.3.5-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) libepc-0.3.5-1.fc10.ppc requires libgnutls.so.13 libepc-0.3.5-1.fc10.ppc64 requires libgnutls.so.13()(64bit) libepc-0.3.5-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libggz-0.0.14.1-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libggz-0.0.14.1-1.fc9.ppc requires libgnutls.so.13 libggz-0.0.14.1-1.fc9.ppc64 requires libgnutls.so.13()(64bit) libggz-0.0.14.1-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) libprelude-0.9.17.1-1.fc10.ppc requires libgnutls.so.13 libprelude-0.9.17.1-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) libprelude-python-0.9.17.1-1.fc10.ppc requires libgnutls.so.13 libpreludedb-0.9.14.1-2.fc9.ppc requires libgnutls.so.13 libpreludedb-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-mysql-0.9.14.1-2.fc9.ppc requires libgnutls.so.13 libpreludedb-pgsql-0.9.14.1-2.fc9.ppc requires libgnutls.so.13 libpreludedb-python-0.9.14.1-2.fc9.ppc requires libgnutls.so.13 libpreludedb-sqlite-0.9.14.1-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtranslate-0.99-14.fc9.ppc requires libgnutls.so.13 libtranslate-0.99-14.fc9.ppc64 requires libgnutls.so.13()(64bit) libvirt-0.4.3-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) libvirt-0.4.3-1.fc10.ppc requires libgnutls.so.13 libvirt-0.4.3-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libvirt-0.4.3-1.fc10.ppc64 requires libgnutls.so.13()(64bit) liferea-1.4.15-5.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-5.fc9.ppc requires libgnutls.so.13 loudmouth-1.4.0-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) loudmouth-1.4.0-1.fc10.ppc requires libgnutls.so.13 loudmouth-1.4.0-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) loudmouth-1.4.0-1.fc10.ppc64 requires libgnutls.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13 msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 5:mutt-1.5.18-2.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) 5:mutt-1.5.18-2.fc10.ppc requires libgnutls.so.13 neon-0.28.2-3.ppc requires libgnutls.so.13(GNUTLS_1_3) neon-0.28.2-3.ppc requires libgnutls.so.13 neon-0.28.2-3.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) neon-0.28.2-3.ppc64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) net6-1.3.5-3.fc9.ppc requires libgnutls.so.13 net6-1.3.5-3.fc9.ppc64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) obby-0.4.4-3.fc9.ppc requires libgnutls.so.13 obby-0.4.4-3.fc9.ppc64 requires libgnutls.so.13()(64bit) perl-Algorithm-Permute-0.12-1.fc8.ppc requires perl(:MODULE_COMPAT_5.8.8) prelude-lml-0.9.12.2-1.fc10.ppc requires libgnutls.so.13 prelude-manager-0.9.12.1-1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) prelude-manager-0.9.12.1-1.fc10.ppc requires libgnutls.so.13 prelude-manager-db-plugin-0.9.12.1-1.fc10.ppc requires libgnutls.so.13 qemu-0.9.1-9.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) qemu-0.9.1-9.fc10.ppc requires libgnutls.so.13 rsyslog-gnutls-3.19.7-2.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) rsyslog-gnutls-3.19.7-2.fc10.ppc requires libgnutls.so.13 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config snort-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-bloat-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-mysql-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-mysql+flexresp-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-plain+flexresp-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-postgresql-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-postgresql+flexresp-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-snmp-2.8.1-3.fc10.ppc requires libgnutls.so.13 snort-snmp+flexresp-2.8.1-3.fc10.ppc requires libgnutls.so.13 sobby-0.4.4-2.fc9.ppc requires libgnutls.so.13 stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 vinagre-2.23.3.1-1.fc10.ppc requires libgnutls.so.13 virt-viewer-0.0.3-1.fc9.ppc requires libgnutls.so.13 weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ctrlproxy-3.0.5-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ctrlproxy-3.0.5-2.fc9.ppc64 requires libgnutls.so.13()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 filezilla-3.0.11-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) filezilla-3.0.11-1.fc10.ppc64 requires libgnutls.so.13()(64bit) gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) gkrellm-2.3.1-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gkrellm-2.3.1-3.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit) gkrellm-2.3.1-3.fc9.ppc64 requires libgnutls.so.13()(64bit) gobby-0.4.5-3.fc9.ppc64 requires libgnutls.so.13()(64bit) gtk-gnutella-0.96.5-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gtk-gnutella-0.96.5-1.fc9.ppc64 requires libgnutls.so.13()(64bit) gtk-vnc-0.3.6-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gtk-vnc-0.3.6-1.fc10.ppc64 requires libgnutls.so.13()(64bit) gurlchecker-0.10.1-8.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) gurlchecker-0.10.1-8.fc9.ppc64 requires libgnutls.so.13()(64bit) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) heartbeat-2.1.3-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) heartbeat-2.1.3-1.fc9.ppc64 requires libgnutls.so.13()(64bit) heartbeat-gui-2.1.3-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) heartbeat-gui-2.1.3-1.fc9.ppc64 requires libgnutls.so.13()(64bit) iksemel-1.3-4.fc9.ppc64 requires libgnutls.so.13()(64bit) iksemel-1.3-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) iksemel-utils-1.3-4.fc9.ppc64 requires libgnutls.so.13()(64bit) kazehakase-0.5.4-4.fc9.ppc64 requires libgnutls.so.13()(64bit) kazehakase-base-0.5.4-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) kazehakase-base-0.5.4-4.fc9.ppc64 requires libgnutls.so.13()(64bit) kazehakase-ruby-0.5.4-4.fc9.ppc64 requires libgnutls.so.13()(64bit) libepc-0.3.5-1.fc10.ppc64 requires libgnutls.so.13()(64bit) libepc-0.3.5-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libggz-0.0.14.1-1.fc9.ppc64 requires libgnutls.so.13()(64bit) libggz-0.0.14.1-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libprelude-0.9.17.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) libprelude-python-0.9.17.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-mysql-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-pgsql-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-python-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libpreludedb-sqlite-0.9.14.1-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) libtranslate-0.99-14.fc9.ppc64 requires libgnutls.so.13()(64bit) libvirt-0.4.3-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libvirt-0.4.3-1.fc10.ppc64 requires libgnutls.so.13()(64bit) liferea-1.4.15-5.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-5.fc9.ppc64 requires libgnutls.so.13()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot loudmouth-1.4.0-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) loudmouth-1.4.0-1.fc10.ppc64 requires libgnutls.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13()(64bit) 5:mutt-1.5.18-2.fc10.ppc64 requires libgnutls.so.13()(64bit) 5:mutt-1.5.18-2.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) neon-0.28.2-3.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) neon-0.28.2-3.ppc64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.ppc64 requires libgnutls.so.13()(64bit) net6-1.3.5-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) obby-0.4.4-3.fc9.ppc64 requires libgnutls.so.13()(64bit) perl-Algorithm-Permute-0.12-1.fc8.ppc64 requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot prelude-lml-0.9.12.2-1.fc10.ppc64 requires libgnutls.so.13()(64bit) prelude-manager-0.9.12.1-1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) prelude-manager-0.9.12.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) prelude-manager-db-plugin-0.9.12.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) rsyslog-gnutls-3.19.7-2.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) rsyslog-gnutls-3.19.7-2.fc10.ppc64 requires libgnutls.so.13()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config snort-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-bloat-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-mysql-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-mysql+flexresp-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-plain+flexresp-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-postgresql-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-postgresql+flexresp-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-snmp-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) snort-snmp+flexresp-2.8.1-3.fc10.ppc64 requires libgnutls.so.13()(64bit) sobby-0.4.4-2.fc9.ppc64 requires libgnutls.so.13()(64bit) stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) vinagre-2.23.3.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) virt-viewer-0.0.3-1.fc9.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.ppc64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From mmaslano at redhat.com Wed Jun 25 10:17:27 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Wed, 25 Jun 2008 12:17:27 +0200 Subject: man-pages-de Message-ID: <48621B37.6010905@redhat.com> Would be some native German speaker interested in maintaining man-pages-de? The upstream is dead and they are no open bugs on them, I've just prefer native speakers for manuals. Thanks, -- Marcela Ma?l??ov? BaseOS team Brno From alan at redhat.com Wed Jun 25 10:58:48 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 25 Jun 2008 06:58:48 -0400 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080624231858.05C632003E@mailserver7.hushmail.com> References: <20080624231858.05C632003E@mailserver7.hushmail.com> Message-ID: <20080625105848.GA10108@devserv.devel.redhat.com> > Email the acpi-dev-team my custom dsdt so that they can include it > in the mainline kernel :). Since this is the "missing" code that > breaks my machine, it should be send as a patch for inclussion. And You do not have the rights or the permissions from the manufacturer to distribute or generally make available copies of the DSDT (whether counted as firmware or not) beyond limited 'fair use' rights in some part of the world. That is one big problem with this patch - Red Hat couldn't ship the modified DSDTs without permission of each vendor or more likely whichever company they paid to do the work. From jwboyer at gmail.com Wed Jun 25 11:04:40 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 25 Jun 2008 07:04:40 -0400 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214382706.3224.12.camel@hughsie-work> References: <1212917892.32207.488.camel@pmac.infradead.org> <1213090193.32207.722.camel@pmac.infradead.org> <20080610093658.GA13339@devserv.devel.redhat.com> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> <1214382706.3224.12.camel@hughsie-work> Message-ID: <1214391880.14225.85.camel@weaponx> On Wed, 2008-06-25 at 09:31 +0100, Richard Hughes wrote: > On Tue, 2008-06-24 at 22:21 -0300, Alexandre Oliva wrote: > > And then, "shut up or I'll leave" is quite tempting. If you don't > > want to participate, just don't. > > You are posting this from your @redhat.com email address. As a fellow > Red Hatter, I want you to stop posting from your corporate email, and > instead use something else (maybe ?oliva at gnu.org might be best).? Doing > so makes the community think this is the view of Red Hat, when ?quite > clearly it's not. I think you need to give the community more credit. People are generally aware that email is a personal thing and companies don't make position statements through individual developers using a work email address. Particularly when so many other @redhat.com addresses have objected. josh From che666 at gmail.com Wed Jun 25 11:19:20 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 25 Jun 2008 13:19:20 +0200 Subject: man-pages-de In-Reply-To: <48621B37.6010905@redhat.com> References: <48621B37.6010905@redhat.com> Message-ID: maintain the package or become upstream, fork it whatever... ? kind regards, Rudolf Kastl 2008/6/25 Marcela Maslanova : > Would be some native German speaker interested in maintaining man-pages-de? > The upstream is dead and they are no open bugs on them, I've just prefer > native speakers for manuals. > Thanks, > > -- > Marcela Ma?l??ov? > BaseOS team Brno > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dcbw at redhat.com Wed Jun 25 11:58:56 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 25 Jun 2008 07:58:56 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> References: <20080624201551.GA11499@redhat.com> <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> Message-ID: <1214395136.25155.15.camel@localhost.localdomain> On Tue, 2008-06-24 at 22:57 +0100, Peter Robinson wrote: > > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > > it is. ("powermac G4" for eg). Also useful would be lspci output, and > > the answer to "does it have ISA slots?". > > I didn't think any Apple PPC machines ever had ISA as actual slots. > Whether other PPC machines from IBM or others did I'm not sure, or > whether PPC has the embedded ISA stuff like some of the newer Intel > stuff for things like the i2c bus. Yes, some pSeries had ISA busses long, long ago. But even more recent (post 2000 even?) pSeries machines like some of the 43p series have an internal ISA bus that drives stuff like the floppy and sound controllers. Dan > Can we just disable a lot and get it reported on the list or bugs. > What options do the yellow dog guys enable in their 32 bit kernels? > > Peter > From cra at WPI.EDU Wed Jun 25 12:11:54 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 25 Jun 2008 08:11:54 -0400 Subject: Fedora 9 kernel configuration In-Reply-To: <4861F792.1000008@fedoraproject.ro> References: <4861F792.1000008@fedoraproject.ro> Message-ID: <20080625121154.GB20486@angus.ind.WPI.EDU> On Wed, Jun 25, 2008 at 10:45:22AM +0300, Adrian Joian wrote: > I plan to write an article that will speak about Fedora 9 on laptops on > our local site [2]. My question is why the 2.6.25.6-55.fc9.i686 kernel is > not compiled whit the following options, as they have big impact on laptop > "cpu sleep" : CONFIG_HPET_TIMER CONFIG_NO_HZ CONFIG_USB_SUSPEND I think you are mistaken: grep -E 'CONFIG_HPET_TIMER|CONFIG_NO_HZ|CONFIG_USB_SUSPEND' /boot/config-2.6.25.6-55.fc9.i686 CONFIG_NO_HZ=y CONFIG_HPET_TIMER=y CONFIG_USB_SUSPEND=y From jwboyer at gmail.com Wed Jun 25 12:14:32 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 25 Jun 2008 08:14:32 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214395136.25155.15.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> <1214395136.25155.15.camel@localhost.localdomain> Message-ID: <1214396072.14225.87.camel@weaponx> On Wed, 2008-06-25 at 07:58 -0400, Dan Williams wrote: > On Tue, 2008-06-24 at 22:57 +0100, Peter Robinson wrote: > > > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > > > it is. ("powermac G4" for eg). Also useful would be lspci output, and > > > the answer to "does it have ISA slots?". > > > > I didn't think any Apple PPC machines ever had ISA as actual slots. > > Whether other PPC machines from IBM or others did I'm not sure, or > > whether PPC has the embedded ISA stuff like some of the newer Intel > > stuff for things like the i2c bus. > > Yes, some pSeries had ISA busses long, long ago. But even more recent > (post 2000 even?) pSeries machines like some of the 43p series have an > internal ISA bus that drives stuff like the floppy and sound > controllers. We last had working support for 43p-150 machines in FC6. Something in the kernel has broken it since, and despite good attempts to fix it we still don't have a working kernel there. josh From lemenkov at gmail.com Wed Jun 25 12:28:02 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 25 Jun 2008 16:28:02 +0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080624201551.GA11499@redhat.com> References: <20080624201551.GA11499@redhat.com> Message-ID: 2008/6/25 Dave Jones : > So, if you use 32bit PowerPC, drop me a mail describing what kind of platform > it is. ("powermac G4" for eg). Also useful would be lspci output, and > the answer to "does it have ISA slots?". Mac Mini G4: 0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 0001:10:17.0 Class ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O 0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI 0002:20:0d.0 Class ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100 0002:20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81) 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80) processor : 0 cpu : 7447A, altivec supported clock : 1416.666661MHz revision : 0.2 (pvr 8003 0102) bogomips : 82.94 timebase : 41620997 platform : PowerMac machine : PowerMac10,1 motherboard : PowerMac10,1 MacRISC3 Power Macintosh detected as : 287 (Mac mini) pmac flags : 00000010 L2 cache : 512K unified pmac-generation : NewWorld No ISA slots. We should populate smolt to provide such information automatically (if it still can't do it). -- With best regards! From joshuacov at googlemail.com Wed Jun 25 12:27:34 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 25 Jun 2008 14:27:34 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time Message-ID: <5f6f8c5f0806250527md333561s81bd5e8b3d624fe6@mail.gmail.com> On Wed, 25 Jun 2008 12:58:48 +0200 Alan Cox wrote: >> Email the acpi-dev-team my custom dsdt so that they can include >it >> in the mainline kernel :). Since this is the "missing" code that > >> breaks my machine, it should be send as a patch for inclussion. >And > >You do not have the rights or the permissions from the >manufacturer to >distribute or generally make available copies of the DSDT (whether >counted >as firmware or not) beyond limited 'fair use' rights in some part >of the >world. > >That is one big problem with this patch - Red Hat couldn't ship >the modified >DSDTs without permission of each vendor or more likely whichever >company >they paid to do the work. This with my dsdt in the maistream kernel (as missing code) was just a joke. I think the kernel shouldn't collect fixes for broken dsdt tables but just provide a way to insert a custom one at boot time. I think it is poor judgemnt to incorporate anyones dsdt (or other system specific code like bioses) in the mainstream kernel. Just in case if this could have happended: at boot the kernel should look throught a register with broken dsdt tables and apply the "correct" one. and with new bios - should we incorporate our new dsdt? Should the kernel check (on the millions of pcs it runs on) for my/anyones dsdt? This is insane! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Wed Jun 25 12:50:54 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 25 Jun 2008 14:50:54 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <5f6f8c5f0806250527md333561s81bd5e8b3d624fe6@mail.gmail.com> References: <5f6f8c5f0806250527md333561s81bd5e8b3d624fe6@mail.gmail.com> Message-ID: <20080625125054.GA28479@mokona.greysector.net> On Wednesday, 25 June 2008 at 14:27, Joshua C. wrote: [...] > This with my dsdt in the maistream kernel (as missing code) was > just a joke. I think the kernel shouldn't collect fixes for broken > dsdt tables but just provide a way to insert a custom one at boot > time. I think it is poor judgemnt to incorporate anyones dsdt (or > other system specific code like bioses) in the mainstream kernel. > > Just in case if this could have happended: at boot the kernel > should look throught a register with broken dsdt tables and apply > the "correct" one. and with new bios - should we incorporate our > new dsdt? Should the kernel check (on the millions of pcs it runs > on) for my/anyones dsdt? This is insane! Nobody is suggesting anything of the sort. The fix (or probably a workaround) should be done in the kernel acpi code, because if Windows works, then so should Linux. We don't want users to mess with their DSDT tables, however broken they may be. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at gmail.com Wed Jun 25 13:05:54 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 25 Jun 2008 09:05:54 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214356497.14225.77.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> Message-ID: <1214399154.14225.111.camel@weaponx> On Tue, 2008-06-24 at 21:14 -0400, Josh Boyer wrote: > On Tue, 2008-06-24 at 16:15 -0400, Dave Jones wrote: > > PPC32 kernel builds take _forever_ in the build system. They're slowing things > > down to such extent that I'm usually still waiting for them several hours > > after the other architectures have finished building. > > Has anyone looked at _why_ they are so slow? Do you have timing > information for a particular kernel flavor? > > If I'm remembering correctly, local kernel builds on my G5 were quite > faster than what is in koji. Finding out why might be a good start. Ok, so I did a cvs checkout of the devel kernel last night and timed a simple 'make ppc'. That built both the UP and SMP ppc kernels, with all the associated -devel and -debuginfo packages. This was done on a dual-cpu G5 with 1.5 GiB of DRAM running F9. Gnome, Evolution, X-Chat, and Rhythmbox were running, but it was otherwise unused. The results: real 117m16.886s user 133m27.480s sys 20m47.314s How does that compare with koji builds? josh From adrian.joian at fedoraproject.ro Wed Jun 25 14:04:04 2008 From: adrian.joian at fedoraproject.ro (adrian.joian at fedoraproject.ro) Date: Wed, 25 Jun 2008 07:04:04 -0700 (PDT) Subject: Fedora 9 kernel configuration In-Reply-To: <20080625121154.GB20486@angus.ind.WPI.EDU> References: <4861F792.1000008@fedoraproject.ro> <20080625121154.GB20486@angus.ind.WPI.EDU> Message-ID: <53117.208.97.187.133.1214402644.squirrel@mail.fedoraproject.ro> But powertop is reporting that they are not available. > On Wed, Jun 25, 2008 at 10:45:22AM +0300, Adrian Joian wrote: >> I plan to write an article that will speak about Fedora 9 on laptops >> on >> our local site [2]. My question is why the 2.6.25.6-55.fc9.i686 kernel >> is >> not compiled whit the following options, as they have big impact on >> laptop >> "cpu sleep" : CONFIG_HPET_TIMER CONFIG_NO_HZ CONFIG_USB_SUSPEND > > I think you are mistaken: > > grep -E 'CONFIG_HPET_TIMER|CONFIG_NO_HZ|CONFIG_USB_SUSPEND' > /boot/config-2.6.25.6-55.fc9.i686 > CONFIG_NO_HZ=y > CONFIG_HPET_TIMER=y > CONFIG_USB_SUSPEND=y > From adrian.joian at fedoraproject.ro Wed Jun 25 14:34:56 2008 From: adrian.joian at fedoraproject.ro (Adrian Joian) Date: Wed, 25 Jun 2008 17:34:56 +0300 Subject: Fedora 9 kernel configuration Message-ID: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> An HTML attachment was scrubbed... URL: From buc at odusz.so-cdu.ru Wed Jun 25 15:24:20 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 25 Jun 2008 19:24:20 +0400 Subject: Ugly broken paths in F7 to F8 upgrade Message-ID: <48626324.3010605@odu.neva.ru> I am upgrading now from Fedora 7 to Fedora 8, and have discovered that some packages in Fedora 8 is "earlier" than in my current Fedora 7. First of all, please, do not offer me the idea to upgrade to the latest Fedora 9 . I live in some production environment, and for some stability reasons prefer to switch to Fedora 8 (for the next half-year until it EOF'ed). The packages which affect me are: Fedora 7 Fedora 8 ctapi-cyberjack-3.0.5-1.fc7 ctapi-cyberjack-3.0.4-1.fc8.i386.rpm ctapi-cyberjack-pcsc-3.0.5-1.fc7 ctapi-cyberjack-pcsc-3.0.4-1.fc8.i386.rpm dbus-python-0.82.3-1.fc7 dbus-python-0.82.0-2.fc8.i386.rpm knetworkmanager-0.2.2-3.fc7 knetworkmanager-0.2-0.7.fc8.i386.rpm libxcb-1.1-1.fc7 libxcb-1.0-4.fc8.i386.rpm libxcb-devel-1.1-1.fc7 libxcb-devel-1.0-4.fc8.i386.rpm microcode_ctl-1.17-1.39.fc7 microcode_ctl-1.17-1.38.fc8.i386.rpm nss-3.12.0.3-0.8.1.fc8 nss-3.11.7-10.fc8.i386.rpm proftpd-1.3.1-2.fc7 proftpd-1.3.1-1.fc8.i386.rpm proftpd-ldap-1.3.1-2.fc7 proftpd-ldap-1.3.1-1.fc8.i386.rpm proftpd-mysql-1.3.1-2.fc7 proftpd-mysql-1.3.1-1.fc8.i386.rpm proftpd-postgresql-1.3.1-2.fc7 proftpd-postgresql-1.3.1-1.fc8.i386.rpm rpmlint-0.83-1.fc7 rpmlint-0.82-2.fc8.noarch.rpm rsync-2.6.9-6.fc7 rsync-2.6.9-5.fc8.i386.rpm Perhaps there are much more in the repos (which I don't use). What the current status of such issues? Is it a correct state? IOW, can I leave things as is (ie. continue to use the correspond F7 packages) or should install F8 versions manually? (Note, that I don't use anaconda, since prefer just "yum upgrade" + some little manual interventions). Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From dwmw2 at infradead.org Wed Jun 25 15:25:18 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Jun 2008 16:25:18 +0100 Subject: 32bit PowerPC questions. In-Reply-To: <1214396072.14225.87.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> <1214395136.25155.15.camel@localhost.localdomain> <1214396072.14225.87.camel@weaponx> Message-ID: <1214407518.10393.9.camel@pmac.infradead.org> On Wed, 2008-06-25 at 08:14 -0400, Josh Boyer wrote: > We last had working support for 43p-150 machines in FC6. Something in > the kernel has broken it since, and despite good attempts to fix it we > still don't have a working kernel there. I have a B50 now, and it shouldn't be hard to fix. As soon as my new workshop has power, it'll start working again. A few people have been asking about it. -- dwmw2 From rdieter at math.unl.edu Wed Jun 25 15:32:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Jun 2008 10:32:14 -0500 Subject: Ugly broken paths in F7 to F8 upgrade References: <48626324.3010605@odu.neva.ru> Message-ID: Dmitry Butskoy wrote: > knetworkmanager-0.2.2-3.fc7 knetworkmanager-0.2-0.7.fc8.i386.rpm Can't speak for the others, but knm was (for all intents and purposes) EOL'd, so you're best bet would be to simply rpm -e knetworkmanager -- Rex From dwheeler at dwheeler.com Wed Jun 25 15:35:45 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Wed, 25 Jun 2008 11:35:45 -0400 (EDT) Subject: Review request: new package (zfuzz), "new" maintainer Message-ID: Could anyone review my new package (zfuzz), a "Type-checker and LaTeX style for the Z spec language"? It's a small package; bugzilla at: https://bugzilla.redhat.com/show_bug.cgi?id=452559 I'm not new to Linux or OSS, but this is my first RPM submission to the Fedora repository, so review and sponsorship would be great. (Yes, I already set FE-NEEDSPONSOR). Its rpmlint is clean, it mock-builds on F9 i386, and I believe it meets all Fedora guidelines and review items. Rationale, etc., are in comments in the .spec file. I know that it also builds on x86_64 rawhide. The only thing that I know needs doing is testing on PPC, but I'll just exclude those architectures if they don't work. BTW, I think that the documentation for _creating_ Fedora RPMs was awful. So I created a page on the Wiki for those who are creating their first RPM package, so that others who want to create Fedora RPMs have a fighting chance: http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo If anyone else wants to make improvements to that, that'd be great. --- David A. Wheeler From nicolas.mailhot at laposte.net Wed Jun 25 15:56:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 25 Jun 2008 17:56:00 +0200 Subject: Help building rpm, works with f8 fails in f9 In-Reply-To: <1214324493.3119.15.camel@localhost.localdomain> References: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> <1214313228.3119.6.camel@localhost.localdomain> <20080624103629.00e0565a@localhost.localdomain> <1214324493.3119.15.camel@localhost.localdomain> Message-ID: <1214409360.14946.3.camel@rousalka.okg> Le mardi 24 juin 2008 ? 12:21 -0400, Tom "spot" Callaway a ?crit : > On Tue, 2008-06-24 at 10:36 -0400, Ed Hill wrote: > > On Tue, 24 Jun 2008 09:13:48 -0400 "Tom \"spot\" Callaway" wrote: > > > http://spot.fedorapeople.org/Summit2008/ > > Just out of curiosity, is there any particular license associated with > > it? May I have your permission to re-use part or all of it? > You'd think I'd have thought of this already. :) 1. It'd be mighty nice if this presentation was linked from http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo 2. It'd be ever nicer if FUDCON & other RH Summit, etc presentations were collected and published on a central place. Big conventions like eclipsecon do it and it's invaluable for people who could not make it to the event. -- 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 supersonicandtails at gmail.com Wed Jun 25 16:07:57 2008 From: supersonicandtails at gmail.com (Peter Fernandes) Date: Wed, 25 Jun 2008 12:07:57 -0400 Subject: Review request: new package (zfuzz), "new" maintainer In-Reply-To: <20080625160010.459AA8E01BB@hormel.redhat.com> References: <20080625160010.459AA8E01BB@hormel.redhat.com> Message-ID: <200806251207.58070.supersonicandtails@gmail.com> >BTW, I think that the documentation for _creating_ Fedora RPMs was awful. >So I created a page on the Wiki for those who are creating their first RPM package, >so that others who want to create Fedora RPMs have a fighting chance: >http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo >If anyone else wants to make improvements to that, that'd be great. http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-creating-rpms.html -- Peter Fernandes Hypersonic Software - http://www.hypersonicsoft.org From kevin at scrye.com Wed Jun 25 17:05:47 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 25 Jun 2008 11:05:47 -0600 Subject: Fedora Support channels Improvement ideas In-Reply-To: <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> Message-ID: <20080625110547.0189c88b@ohm.scrye.com> Looking at the schedule on #fedora-meeting, thursday is looking a bit busy, so I would like to propose: Friday, 2008-06-27 at 18:00 UTC in #fedora-meeting for a brainstorming session/inital meeting of anyone interested in improving IRC support. Does that time work for most people? I'm happy to shift it if we can get more of the current #fedora ops in attendance. I have put up a draft of some guidelines at: https://fedoraproject.org/wiki/User:Kevin/DRAFT-IRCSupportConduct with some discussion points. Feel free to make changes, suggest changes here, suggest changes in email to me, or come to the meeting and discuss changes there. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ivazqueznet at gmail.com Wed Jun 25 17:10:46 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 25 Jun 2008 13:10:46 -0400 Subject: Review request: new package (zfuzz), "new" maintainer In-Reply-To: References: Message-ID: <1214413846.30544.8.camel@ignacio.lan> On Wed, 2008-06-25 at 11:35 -0400, David A. Wheeler wrote: > BTW, I think that the documentation for _creating_ Fedora RPMs was awful. > So I created a page on the Wiki for those who are creating their first RPM package, > so that others who want to create Fedora RPMs have a fighting chance: > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo > If anyone else wants to make improvements to that, that'd be great. Just out of curiosity, why didn't you continue work on the Building Packages Guide[1] that's already a draft in the Docs project? [1] ?http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide -- 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 kevin at scrye.com Wed Jun 25 17:19:05 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 25 Jun 2008 11:19:05 -0600 Subject: Meeting time (was Re: Fedora Support channels Improvement ideas) In-Reply-To: <20080625110547.0189c88b@ohm.scrye.com> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> <20080625110547.0189c88b@ohm.scrye.com> Message-ID: <20080625111905.5cf31ee8@ohm.scrye.com> On Wed, 25 Jun 2008 11:05:47 -0600 kevin at scrye.com (Kevin Fenzi) wrote: > Looking at the schedule on #fedora-meeting, thursday is looking a bit > busy, so I would like to propose: > > Friday, 2008-06-27 at 18:00 UTC in #fedora-meeting for a brainstorming > session/inital meeting of anyone interested in improving IRC support. > > Does that time work for most people? I'm happy to shift it if we can > get more of the current #fedora ops in attendance. Looks like thursday (2008-06-26) at 18:00 UTC (right after the FESCo meeting) would be better. So, lets move to that time. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Jun 25 17:27:06 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 25 Jun 2008 20:27:06 +0300 Subject: Ugly broken paths in F7 to F8 upgrade In-Reply-To: <48626324.3010605@odu.neva.ru> References: <48626324.3010605@odu.neva.ru> Message-ID: <200806252027.06996.ville.skytta@iki.fi> On Wednesday 25 June 2008, Dmitry Butskoy wrote: > I am upgrading now from Fedora 7 to Fedora 8, and have discovered that > some packages in Fedora 8 is "earlier" than in my current Fedora 7. [...] > rpmlint-0.83-1.fc7 rpmlint-0.82-2.fc8.noarch.rpm This seems to have been pushed directly to F-7 stable updates, while 0.83 for F-8 and F-9 are still in testing. I've just asked them to be pushed to stable too. From rdieter at math.unl.edu Wed Jun 25 17:36:34 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Jun 2008 12:36:34 -0500 Subject: Review request: new package (zfuzz), "new" maintainer References: <1214413846.30544.8.camel@ignacio.lan> Message-ID: Ignacio Vazquez-Abrams wrote: > On Wed, 2008-06-25 at 11:35 -0400, David A. Wheeler wrote: >> BTW, I think that the documentation for _creating_ Fedora RPMs was awful. >> So I created a page on the Wiki for those who are creating their first >> RPM package, so that others who want to create Fedora RPMs have a >> fighting chance: >> http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo >> If anyone else wants to make improvements to that, that'd be great. > > Just out of curiosity, why didn't you continue work on the Building > Packages Guide[1] that's already a draft in the Docs project? > > [1] ?http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide Out on a limb here, because he (nor I) even new about that. neat both ways. -- Rex From aoliva at redhat.com Wed Jun 25 17:46:38 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 25 Jun 2008 14:46:38 -0300 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214382706.3224.12.camel@hughsie-work> (Richard Hughes's message of "Wed\, 25 Jun 2008 09\:31\:46 +0100") References: <1212917892.32207.488.camel@pmac.infradead.org> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> <1214382706.3224.12.camel@hughsie-work> Message-ID: On Jun 25, 2008, Richard Hughes wrote: > On Tue, 2008-06-24 at 22:21 -0300, Alexandre Oliva wrote: >> And then, "shut up or I'll leave" is quite tempting. If you don't >> want to participate, just don't. > You are posting this from your @redhat.com email address. As a fellow > Red Hatter, I want you to stop posting from your corporate email, and > instead use something else (maybe oliva at gnu.org might be best). Doing > so makes the community think this is the view of Red Hat, when quite > clearly it's not. That's quite a leap of logic. It doesn't follow that, if I use say my gmail address, I'm speaking on behalf of Google; if I post from my GNU address, I was speaking on behalf of the GNU Project; if I write from my university address, I'm speaking on behalf of the university; if I post from my FSFLA address, I'm speaking on behalf of FSFLA; if I post from my ACM or IEEE addresses, I'm speaking on behalf of these associations; etc, etc. All of these assumptions would be just as unwarranted as assuming I'm speaking on behalf of Red Hat. Even more so when my signature you read and picked on earlier states I'm a compiler engineer and I'm clearly not talking about compiler issues. If you look at it, you'll see there's more of 'free software philosophy activist' in there than there is 'free software code monkey', which is quite in line with my personal priorities. > If you are indeed writing these emails in work time, I'm not, but then I am, but then I'm not. It's hard to tell. Red Hat formally supports my work at FSFLA, and I work on linux-libre and on promoting awareness of Free Software for FSFLA, so you could count that as (voluntary) work time if you wanted to. But my decision to invest time on this thread, and FSFLA's general guidance for me to put time into linux-libre and spread awareness of Free Software issues in general is not something my manager or Red Hat would have any say on, and it didn't cost Red Hat anything other than it would have cost if I had used any other e-mail address. > Sorry to sound harsh, No reason to apologize. > but I _am_ part of Red Hat and you are making _me_ look bad. Now you lost me. Please help me understand what you're getting at. Why would speaking of Free Software, promoting freedom, clarifying common misunderstandings of the Free Software philosophy, of copyleft, and of the GPL, make us look bad? Red Hat does all of that on its own. Why would discussing Fedora policies on the mailing list where Fedora policies are discussed make us bad? Now, maybe some developers' allergy to policies that are not strictly technical suggests a need for a mailing lists in which such policies could be discussed. Of course they'd then be better advised to follow those lists as well, otherwise they'd not participate in discussions that would affect them as much as or even more than strictly technical policies. And then we'd have created a list for the purposes of either keeping people uninformed about ongoing discussions, or for the purpose of requiring people to subscribe to multiple lists for the sake of remaining informed. None of these sound better than what we have now, and it sounds to me like the only ways to avoid this kind of argument you've just started would be to get people to understand that some discussions will take place that won't be interesting to them, or to rule out certain kinds of discussions from Fedora. Based on Fedora's history, I wouldn't expect Fedora to rule out discussions on moral and ethical principles related with software freedom, as well as on goals and policies to comply with them, even when such discussions make some people here uncomfortable. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jspaleta at gmail.com Wed Jun 25 18:11:25 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 Jun 2008 10:11:25 -0800 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: <1214391880.14225.85.camel@weaponx> References: <1212917892.32207.488.camel@pmac.infradead.org> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> <1214382706.3224.12.camel@hughsie-work> <1214391880.14225.85.camel@weaponx> Message-ID: <604aa7910806251111p7f149170jcc1eafc9ee1152fa@mail.gmail.com> On Wed, Jun 25, 2008 at 3:04 AM, Josh Boyer wrote: > I think you need to give the community more credit. I'm not sure I should give the laypress that much credit. I cringe at the thought of seeing some of this discussion taken out of context and sensationalized on sites which make a living by selling ads on pages containing sensationalized articles. But to be honest, this is an internal employer-employee relationship issue... so its none of my business. -jef From hughsient at gmail.com Wed Jun 25 18:52:46 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 25 Jun 2008 19:52:46 +0100 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <1213104270.32207.770.camel@pmac.infradead.org> <20080610144325.GA28121@devserv.devel.redhat.com> <1213111970.32207.835.camel@pmac.infradead.org> <484EAC68.2020303@gmail.com> <4853253B.1040906@gmail.com> <4853F7CF.3050800@gmail.com> <48546856.9050900@gmail.com> <4859728D.8090309@gmail.com> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> <1214382706.3224.12.camel@hughsie-work> Message-ID: <1214419966.3224.57.camel@hughsie-work> On Wed, 2008-06-25 at 14:46 -0300, Alexandre Oliva wrote: > But my decision to invest time on this thread I have no time to invest on this thread, as I have better things to do. Richard. From bpepple at fedoraproject.org Wed Jun 25 19:30:31 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 25 Jun 2008 12:30:31 -0700 Subject: Plan for tomorrows (20080626) FESCO meeting Message-ID: <1214422231.4818.3.camel@kennedy> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- sponsor nominations -- Remi Collet /topic FESCo-Meeting -- sponsor nominations -- Axel Thimm /topic FESCo-Meeting -- sponsor nominations -- G?rard Milmeister /topic FESCO-Meeting -- FESCo Responsibilities/Role -- all /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. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. 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: 197 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Wed Jun 25 19:20:24 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 25 Jun 2008 20:20:24 +0100 Subject: Static to dynamic lib Message-ID: <1214421624.10154.4.camel@T7.Linux> Hi, I've been looking at getting the portable .NET stuff into fedora. However, the treecc package only builds a .a lib. Is there a way to convert that a dynamic lib? 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: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Jun 25 21:03:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 Jun 2008 13:03:08 -0800 Subject: Meeting time (was Re: Fedora Support channels Improvement ideas) In-Reply-To: <20080625111905.5cf31ee8@ohm.scrye.com> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> <20080625110547.0189c88b@ohm.scrye.com> <20080625111905.5cf31ee8@ohm.scrye.com> Message-ID: <604aa7910806251403l1c5f1802nb31fd38dd51194da@mail.gmail.com> 2008/6/25 Kevin Fenzi : > Looks like thursday (2008-06-26) at 18:00 UTC (right after the FESCo > meeting) would be better. So, lets move to that time. I just got the word that I'm doing the final walk through before closing on the new house tomorrow morning. I won't be able to make it. Can you make sure you log the irc meeting and provide some sort of executive summary if you task out any action items. -jef From j.w.r.degoede at hhs.nl Wed Jun 25 21:20:04 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 25 Jun 2008 23:20:04 +0200 Subject: Static to dynamic lib In-Reply-To: <1214421624.10154.4.camel@T7.Linux> References: <1214421624.10154.4.camel@T7.Linux> Message-ID: <4862B684.9080005@hhs.nl> Paul wrote: > Hi, > > I've been looking at getting the portable .NET stuff into fedora. > However, the treecc package only builds a .a lib. Is there a way to > convert that a dynamic lib? > There are a couple, if it uses libtool + automake, the .am Makefiles can be patched. If it uses a plain makefile, that can be patched. If it uses something nasty (like autoxxx without libtool) you can add -fPIC to the CFLAGS, and then just use the .o files build for a final manual linking into a .so file, you can get a list of the .o files to put in the .so from the .a file using ar (works just like tar). Do you have any idea how stable the ABI of the treecc .a lib is? Regards, Hans From tcallawa at redhat.com Wed Jun 25 22:08:44 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 25 Jun 2008 18:08:44 -0400 Subject: Help building rpm, works with f8 fails in f9 In-Reply-To: <1214409360.14946.3.camel@rousalka.okg> References: <5E1EB72454DA40ECAB920099E8DB610B@Q9450> <1214313228.3119.6.camel@localhost.localdomain> <20080624103629.00e0565a@localhost.localdomain> <1214324493.3119.15.camel@localhost.localdomain> <1214409360.14946.3.camel@rousalka.okg> Message-ID: <1214431724.16592.1.camel@localhost.localdomain> On Wed, 2008-06-25 at 17:56 +0200, Nicolas Mailhot wrote: > 1. It'd be mighty nice if this presentation was linked from > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo Feel free to add it if you think it would be useful. > 2. It'd be ever nicer if FUDCON & other RH Summit, etc presentations > were collected and published on a central place. Big conventions like > eclipsecon do it and it's invaluable for people who could not make it > to the event. Agreed. I was rather unhappy with how IDG handled the presentations for the RH Summit. ~spot From jspaleta at gmail.com Wed Jun 25 23:57:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 Jun 2008 15:57:34 -0800 Subject: Fedora 9 kernel configuration In-Reply-To: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> References: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> Message-ID: <604aa7910806251657n34c451e2w3884defd3f09a76b@mail.gmail.com> 2008/6/25 Adrian Joian : > Moreover in the kernel config files i see no file that is containg all of > the 3 settings. Specifically.. which files are you looking at for the settings. Chuck referenced the /boot/config-2.6.25.6-55.fc9.i686 file which is the exact configuration file used at build time for the 6.25.6-55.fc9.i686 kernel. It is provided as part of the kernel package. If you are not looking in /boot for a config file that is part of the kernel package you are interested in, then you are most likely looking in the wrong place. -jef From wolfy at nobugconsulting.ro Thu Jun 26 00:06:47 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 26 Jun 2008 03:06:47 +0300 Subject: Ugly broken paths in F7 to F8 upgrade In-Reply-To: <200806252027.06996.ville.skytta@iki.fi> References: <48626324.3010605@odu.neva.ru> <200806252027.06996.ville.skytta@iki.fi> Message-ID: <4862DD97.5080204@nobugconsulting.ro> On 06/25/2008 08:27 PM, Ville Skytt? wrote: > On Wednesday 25 June 2008, Dmitry Butskoy wrote: > >> I am upgrading now from Fedora 7 to Fedora 8, and have discovered that >> some packages in Fedora 8 is "earlier" than in my current Fedora 7. >> > [...] > >> rpmlint-0.83-1.fc7 rpmlint-0.82-2.fc8.noarch.rpm >> > > This seems to have been pushed directly to F-7 stable updates, that was me. I wanted to be sure it gets pushed before F7 went EOL. sorry for the mess From poelstra at redhat.com Thu Jun 26 00:10:49 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 25 Jun 2008 17:10:49 -0700 Subject: Plan for tomorrows (20080626) FESCO meeting In-Reply-To: <1214422231.4818.3.camel@kennedy> References: <1214422231.4818.3.camel@kennedy> Message-ID: <4862DE89.7060908@redhat.com> Brian Pepple said the following on 06/25/2008 12:30 PM Pacific Time: > Hi all, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo-Meeting -- sponsor nominations -- Remi Collet > > /topic FESCo-Meeting -- sponsor nominations -- Axel Thimm > > /topic FESCo-Meeting -- sponsor nominations -- G?rard Milmeister > > /topic FESCO-Meeting -- FESCo Responsibilities/Role -- all > > /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. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > Later, > /B > Being that it has been confirmed so far that FESCo still owns the feature process are we ready to proceed with the Fedora 10 feature process? I'd still like evaluate this before starting: http://fedoraproject.org/wiki/Features/F10PolicyReview Thanks, John From davej at redhat.com Thu Jun 26 04:59:10 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Jun 2008 00:59:10 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080624221846.GA2268@devserv.devel.redhat.com> References: <20080624201551.GA11499@redhat.com> <20080624221846.GA2268@devserv.devel.redhat.com> Message-ID: <20080626045910.GB6590@redhat.com> On Tue, Jun 24, 2008 at 06:18:46PM -0400, Alan Cox wrote: > On Tue, Jun 24, 2008 at 04:15:51PM -0400, Dave Jones wrote: > > it is. ("powermac G4" for eg). Also useful would be lspci output, and > > the answer to "does it have ISA slots?". > > Careful: our 'ISA' in the kernel also coverse the various LPC busses that > replaced it. That would be a bug if so. CONFIG_ISA always meant 'show me drivers that I can plug into an isa slot'. CONFIG_ISA_DMA_API is there for non-slot LPC type devices. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Jun 26 05:00:40 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Jun 2008 01:00:40 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214399154.14225.111.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> Message-ID: <20080626050040.GC6590@redhat.com> On Wed, Jun 25, 2008 at 09:05:54AM -0400, Josh Boyer wrote: > On Tue, 2008-06-24 at 21:14 -0400, Josh Boyer wrote: > > On Tue, 2008-06-24 at 16:15 -0400, Dave Jones wrote: > > > PPC32 kernel builds take _forever_ in the build system. They're slowing things > > > down to such extent that I'm usually still waiting for them several hours > > > after the other architectures have finished building. > > > > Has anyone looked at _why_ they are so slow? Do you have timing > > information for a particular kernel flavor? > > > > If I'm remembering correctly, local kernel builds on my G5 were quite > > faster than what is in koji. Finding out why might be a good start. > > Ok, so I did a cvs checkout of the devel kernel last night and timed a > simple 'make ppc'. That built both the UP and SMP ppc kernels, with all > the associated -devel and -debuginfo packages. > > This was done on a dual-cpu G5 with 1.5 GiB of DRAM running F9. Gnome, > Evolution, X-Chat, and Rhythmbox were running, but it was otherwise > unused. > > The results: > > real 117m16.886s > user 133m27.480s > sys 20m47.314s > > How does that compare with koji builds? The last one I timed yesterday took about 4-5 hours. Dave -- http://www.codemonkey.org.uk From adrian.joian at fedoraproject.ro Thu Jun 26 07:26:44 2008 From: adrian.joian at fedoraproject.ro (adrian.joian at fedoraproject.ro) Date: Thu, 26 Jun 2008 00:26:44 -0700 (PDT) Subject: Fedora 9 kernel configuration In-Reply-To: <604aa7910806251657n34c451e2w3884defd3f09a76b@mail.gmail.com> References: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> <604aa7910806251657n34c451e2w3884defd3f09a76b@mail.gmail.com> Message-ID: <63103.208.97.187.133.1214465204.squirrel@mail.fedoraproject.ro> Hello, You are right in the /boot config file everything is ok. But if you install the kernel source and look in the config-debug, config-x86 and so on files non of them contain the 3 values all toghether. Best regards, Adrian Joian > 2008/6/25 Adrian Joian : >> Moreover in the kernel config files i see no file that is containg all >> of >> the 3 settings. > > Specifically.. which files are you looking at for the settings. Chuck > referenced the > /boot/config-2.6.25.6-55.fc9.i686 file which is the exact > configuration file used at build time for the 6.25.6-55.fc9.i686 > kernel. It is provided as part of the kernel package. If you are > not looking in /boot for a config file that is part of the kernel > package you are interested in, then you are most likely looking in the > wrong place. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rawhide at fedoraproject.org Thu Jun 26 09:53:23 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 26 Jun 2008 09:53:23 +0000 (UTC) Subject: rawhide report: 20080626 changes Message-ID: <20080626095323.627E7208285@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080625/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080626/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package spicebird Spicebird Collaboration Suite New package staden-io_lib General purpose library to handle gene sequencing machine trace files Removed package kyum Updated Packages: R-Biobase-2.0.1-1.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 pingou 2.0.1-1 - Update to version 2.0.1 * Fri May 2 18:00:00 2008 Pingou 2.0.0-1 - Update to bioconductor 2.2 R-DynDoc-1.18.0-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Pingou 1.18.0-2 - Change the url afflib-3.2.1-2.fc10 ------------------- * Wed Jun 25 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.1-2 - Fix redefinition of typedef AFFILE anaconda-11.4.1.9-1 ------------------- * Wed Jun 25 18:00:00 2008 Chris Lumens 11.4.1.9-1 - Query for anaconda rather than anaconda-runtime in buildinstall (jkeating). audit-viewer-0.3-1.fc10 ----------------------- * Wed Jun 25 18:00:00 2008 Miloslav Trma?? - 0.3-1 - Update to audit-viewer-0.3. ca-certificates-2008-6 ---------------------- * Wed Jun 25 18:00:00 2008 Thomas Fitzsimmons - 2008-6 - Change generate-cacerts.pl to produce pretty aliases. cairo-dock-1.6.1-0.1.svn1142_trunk.fc10 --------------------------------------- * Thu Jun 26 18:00:00 2008 Mamoru Tasaka - rev. 1142 crack-attack-1.1.14-14.fc10 --------------------------- * Tue Jun 24 18:00:00 2008 Hans de Goede 1.1.14-14 - Fix sound on bigendian machines (bz 452394) ctrlproxy-3.0.6-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 3.0.6-2 - rebuild with new gnutls * Sun May 25 18:00:00 2008 Bernardo Innocenti 3.0.6-1 - Update to latest upstream - Drop ctrlproxy-fix-irssi-log.patch - Add initscript - Create a ctrlproxy user to run ctrlproxy as a daemon db4-4.6.21-6.fc9 ---------------- * Wed Jun 25 18:00:00 2008 Jindrich Novy 4.6.21-6 - apply new upstream patch - fixes potentially wrong number of mutexes to be allocated - update URLs to patches exiv2-0.17.1-1.fc10 ------------------- * Mon Jun 23 18:00:00 2008 Rex Dieter 0.17.1-1 - exiv2-0.17.1 filezilla-3.0.11-2.fc10 ----------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 3.0.11-2 - rebuild with new gnutls gdm-2.22.0-8.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Ray Strode - 1:2.22.0-8 - After discussion with X team, turn tcp connections off by default, but add back option to toggle on (bug 446672) * Wed Jun 25 18:00:00 2008 Ray Strode - 1:2.22.0-7 - enable tcp connections by default geeqie-1.0-0.5.alpha1.fc10 -------------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter - 1.0-0.5.alpha1 - respin for exiv2 gkrellm-2.3.1-4.fc10 -------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz 2.3.1-4 - rebuild with new gnutls gnash-0.8.3-2.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Patrice Dumas 0.8.3-2 - add glib in the link, thanks Daniel Drake (#452767) gnome-commander-1.2.6-3.fc10 ---------------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter - 1.2.6-3 - respin for exiv2 gobby-0.4.5-4.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.4.5-4 - rebuild with new gnutls grub-0.97-34.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Peter Jones - 0.97-34 - Add keystatus patch from krh. gtk-gnutella-0.96.5-2.fc10 -------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.96.5-2 - rebuild with new gnutls gtk-vnc-0.3.6-2.fc10 -------------------- * Wed Jun 25 18:00:00 2008 Daniel P. Berrange - 0.3.6-2.fc10 - Rebuild for GNU TLS ABI change gurlchecker-0.10.1-9.fc10 ------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.10.1-9 - rebuild with new gnutls gwget-0.99-7.fc10 ----------------- * Thu Jun 5 18:00:00 2008 Christoph Wickert - 0.99-7 - Fix for latest epiphany (#440744) - Add Debian patch to fix missing remove signals * Sat Apr 5 18:00:00 2008 Christoph Wickert - 0.99-6 - Build against epiphany 2.22 - Remove the obsolte category Application from desktop file haddock-2.0.0.0-3.fc10 ---------------------- * Thu Jun 26 18:00:00 2008 Jens Petersen - 2.0.0.0-3.fc10 - drop ghcver subpackage in line with ghc - obsolete ghc682-haddock - add haddock-2.0.0.0-ghc683-process.patch to fix build with ghc-6.8.3 heartbeat-2.1.3-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 2.1.3-2 - rebuild with new gnutls ice-3.3.0-2 ----------- * Sat Jun 28 18:00:00 2008 Mary Ellen Foster 3.3.0-2 - Add patch from ZeroC * Mon Jun 9 18:00:00 2008 Mary Ellen Foster 3.3.0-1 - Update for 3.3 final - Fix ppc64 issues with directories in Mono .pc files (I hope) - Incorporate patches and man pages from Debian package * Tue May 6 18:00:00 2008 Mary Ellen Foster 3.3-0.1.b - Update for 3.3 beta prerelease - Fix Python sitelib/sitearch issues iksemel-1.3-5.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Tomas Mraz - 1.3-5 - rebuild with new gnutls - remove texinfo dir file from buildroot imsettings-0.101.2-3.fc10 ------------------------- jabbim-0.4.2-1.fc10 ------------------- * Wed Jun 25 18:00:00 2008 Michal Schmidt - 0.4.2-1 - Upstream release 0.4.2. - dropped jabbim-0.4-lost-initial-message-if-empty-sender-mood.diff, now upstream kazehakase-0.5.4-5.fc10 ----------------------- * Wed Jun 25 18:00:00 2008 Mamoru Tasaka - 0.5.4-5 - Apply xulrunner related patches from debian by Mike Hommey (debian bug 480796, rh bug 402641) This time kazehakase actually works with xulrunner! kde-i18n-3.5.9-7.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Than Ngo 3.5.9-7 - bump release because of Koji failure * Mon Jun 23 18:00:00 2008 Than Ngo 3.5.9-6 - on F9+, remove documentation which conflicts with kde-l10n rh#452391 kdegraphics-4.0.83-2.fc10 ------------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter 4.0.83-2 - respin for exiv2 kdelibs-4.0.83-2.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter 4.0.83-2 - -common: move %{_kde4_docdir}/HTML/en/sonnet/ here (#341751) kernel-2.6.26-0.93.rc8.fc10 --------------------------- * Wed Jun 25 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-06-25 (http://marc.info/?l=linux-wireless&m=121440912502527&w=2) * Wed Jun 25 18:00:00 2008 Dave Jones - Reenable a few ppc32 modules. * Wed Jun 25 18:00:00 2008 Dave Jones - 2.6.26-rc8 kipi-plugins-0.1.6-0.2.beta1.fc10 --------------------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter 0.1.6-0.2.beta1 - respin for exiv2 kphotoalbum-3.1.1-3.fc10 ------------------------ * Wed Jun 25 18:00:00 2008 Rex Dieter 3.1.1-3 - respin for exiv2 kvm-70-2.fc10 ------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 70-2 - rebuild with new gnutls lam-7.1.4-1.fc10 ---------------- * Tue Jun 24 18:00:00 2008 Doug Ledford - 2:7.1.4-1 - Update to latest upstream version - Make sure to remove APSL licensed files from upstream tarball and rename tarball to version-rh1 to indicate such - Make lam exist in its own prefix, which forestalls all conflicts with other mpi implementations and also eliminates the need for an alternatives setup - Make environment-modules required for lam-libs and the default means of selecting between lam/openmpi/other mpi implementations - Only apply the archmode patch on arches where gcc will accept a mode flag - Make sure we remove any stale lam alternatives configs when we install so that upgrades will work properly * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 2:7.1.2-12 - Autorebuild for GCC 4.3 less-424-1.fc10 --------------- * Wed Jun 25 18:00:00 2008 Zdenek Prikryl - 424-1 - Update to 424 libepc-0.3.5-2.fc10 ------------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz - 0.3.5-2 - rebuild with new gnutls libggz-0.0.14.1-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.0.14.1-2 - rebuild with new gnutls libkexiv2-0.1.7-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Rex Dieter 1.1.7-2 - respin for exiv2 libopensync-plugin-irmc-0.36-1.fc9 ---------------------------------- * Fri Jun 20 18:00:00 2008 Andreas Bierfert - 0.36-1 - version upgrade libprelude-0.9.17.1-2.fc10 -------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.9.17.1-2 - fixed build of perl bindings * Tue Jun 24 18:00:00 2008 Steve Grubb - rebuild for new gnutls libpreludedb-0.9.14.1-3.fc10 ---------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.9.14.1-3 - rebuild with new gnutls - fix install of perl bindings libtranslate-0.99-15.fc10 ------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.99-15 - rebuild with new gnutls libvirt-0.4.4-1.fc10 -------------------- * Wed Jun 25 18:00:00 2008 Daniel Veillard - 0.4.4-1.fc10 - upstream release 0.4.4 - fix a few bugs in previous release limph-1.9.5-3.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Jon Ciesla - 1.9.5-3 - Corrected php requires. loudmouth-1.4.0-2.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 1.4.0-2 - rebuild with new gnutls lvm2-2.02.38-2.fc10 ------------------- * Wed Jun 25 18:00:00 2008 Alasdair Kergon > - 2.02.38-2 - dmsetup: Add --unquoted and --rows to 'info -c' command. - libdevmapper: Fix inverted no_flush debug message. man-pages-de-0.5-1.fc10 ----------------------- man-pages-it-2.80-1.fc10 ------------------------ * Thu Jun 26 18:00:00 2008 Ding-Yi Chen - 2.80-1 - [Bug 451982] New: RFE: New version of man-pages-it available - Obsoletes man-pages-it-extra mapserver-5.0.3-2.fc10 ---------------------- * Thu Jun 26 18:00:00 2008 Devrim GUNDUZ - 5.0.3-2 - Rebuilt against Geos 3.0.0 munin-1.2.6-1.fc10 ------------------ * Fri Jun 20 18:00:00 2008 Kevin Fenzi - 1.2.6-1 - Upgrade to 1.2.6 mutt-1.5.18-3.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Miroslav Lichvar 5:1.5.18-3 - buildrequire aspell (#452133) - rebuild with new gnutls neon-0.28.2-4 ------------- * Wed Jun 25 18:00:00 2008 Joe Orton 0.28.2-4 - rebuild for new GnuTLS net6-1.3.5-4.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 1.3.5-4 - rebuild with new gnutls nfs-utils-1.1.2-8.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Steve Dickson 1.1.2-8 - FQDNs in the rmtab causes exportfs to seg fault (bz 444275) * Mon Jun 23 18:00:00 2008 Steve Dickson 1.1.2-7 - Added -D_FILE_OFFSET_BITS=64 to CFLAGS - make nfsstat read and print stats as unsigned integers - Added (but not installed) the mountstats and nfs-iostat python scripts. ntfsprogs-2.0.0-8.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 2.0.0-8 - rebuild with new gnutls obby-0.4.4-4.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.4.4-4 - rebuild with new gnutls perl-Algorithm-Permute-0.12-1.fc9 --------------------------------- perl-Catalyst-Manual-5.7012-2.fc10 ---------------------------------- * Wed Jun 25 18:00:00 2008 Chris Weyl 5.7012-2 - re-exclude Catalyst::Manual.3pm perl-Class-MOP-0.62-1.fc10 -------------------------- * Wed Jun 25 18:00:00 2008 Chris Weyl 0.62-1 - update to 0.62 - tweak provides filtering perl-Devel-StackTrace-1.1901-1.fc10 ----------------------------------- * Wed Jun 25 18:00:00 2008 Ralf Cors??pius - 1.1901-1 - Upstream update. perl-JSON-2.11-1.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Chris Weyl 2.11-1 - update to 2.11 * Wed May 28 18:00:00 2008 Chris Weyl 2.09-1 - update to 2.09 pixman-0.11.6-1.fc10 -------------------- * Wed Jun 25 18:00:00 2008 Soren Sandmann 0.11.6-1 - Upgrade to 0.11.6. Drop fix for leak. pl-5.6.57-1.fc10 ---------------- * Wed Jun 25 18:00:00 2008 Mary Ellen Foster - 5.6.57-1 - Another update, after vacation * Mon May 19 18:00:00 2008 Mary Ellen Foster - 5.6.55-1 - Update to 5.6.55 (wow, fast updates!) - Un-split xpce for now - Conditionally build jpl (on Fedora 9 with openjdk, and on Fedora 8 non-ppc with icedtea) * Wed May 7 18:00:00 2008 Mary Ellen Foster - 5.6.54-1 - Update to 5.6.54 and prepare to actually push this - Try splitting xpce into own package * Tue Apr 15 18:00:00 2008 Mary Ellen Foster - 5.6.53-1 - Update to 5.6.53 -- fixes ppc64 problems, yay! * Wed Apr 9 18:00:00 2008 Mary Ellen Foster - 5.6.52-2 - Put JPL stuff where the new Java packaging guidelines say it should be and make all of the necessary adjustments in other files - Split out "-devel" and "-static" packages per guidelines * Mon Mar 31 18:00:00 2008 Mary Ellen Foster - 5.6.52-1 - Switch jpl requirement from IcedTea to OpenJDK and enable it everywhere - Upgrade to 5.6.52 - Patch jpl configure script to find Java libraries on ppc{64} - NB: Still broken on ppc64, still trying to figure out why * Mon Feb 25 17:00:00 2008 Mary Ellen Foster - 5.6.51-1 - Upgrade to 5.6.51 * Fri Feb 22 17:00:00 2008 Mary Ellen Foster - 5.6.50-1 - Update to 5.6.50 - Enable JPL (as a sub-package) -- NB: it only builds with icedtea for now, so we disable that sub-package on ppc64 and ppc for the moment * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 5.6.47-9 - Autorebuild for GCC 4.3 * Thu Dec 6 17:00:00 2007 Gerard Milmeister - 5.6.47-8 - compile with -fno-strict-aliasing plymouth-0.4.0-4.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Ray Strode - 0.4.0-4 - Make "Password: " show up correctly in text plugin * Wed Jun 25 18:00:00 2008 Ray Strode - 0.4.0-3 - Require elfutils (bug 452797) postgis-1.3.3-3.fc10 -------------------- * Thu Jun 26 18:00:00 2008 Devrim GUNDUZ - 1.3.3-3 - Rebuilt against geos 3.0.0 * Thu May 29 18:00:00 2008 Todd Zullinger - 1.3.3-2 - fix license tags prelude-lml-0.9.12.2-2.fc10 --------------------------- * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.9.12.2-2 - rebuild with new gnutls prelude-manager-0.9.12.1-2.fc10 ------------------------------- * Tue Jun 24 18:00:00 2008 Steve Grubb 0.9.12.1-2 - add prelude-manager user qemu-0.9.1-10.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Daniel P. Berrange - 0.9.1-10.fc10 - Rebuild for GNU TLS ABI change rpmreaper-0.1.4-1.fc10 ---------------------- * Wed Jun 25 18:00:00 2008 Miroslav Lichvar 0.1.4-1 - update to 0.1.4 rsyslog-3.19.7-3.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Peter Vrabec 3.19.7-3 - rebuild because of new gnutls ruby-1.8.6.230-2.fc10 --------------------- * Wed Jun 25 18:00:00 2008 Akira TAGOH - 1.8.6.230-2 - Fix a segfault issue. (#452810) snort-2.8.1-4.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Tomas Mraz - 2.8.1-4 - rebuild with new gnutls sobby-0.4.4-3.fc10 ------------------ * Wed Jun 25 18:00:00 2008 Tomas Mraz - 0.4.4-3 - rebuild with new gnutls swfdec-0.7.2-1.fc10 ------------------- * Wed Jun 25 18:00:00 2008 Brian Pepple - 0.7.2-1 - Update to 0.7.2 swfdec-mozilla-0.7.2-1.fc10 --------------------------- * Wed Jun 25 18:00:00 2008 Brian Pepple - 0.7.2-1 - Update to 0.7.2. tcl-8.5.2-2.fc10 ---------------- * Tue Jun 24 18:00:00 2008 Marcela Maslanova - 1:8.5.2-2 - update to 8.5.2 - 451750 PostgreSQL need tclConfig.sh in paths - 437399 now really own directories ufraw-0.13-5.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Rex Dieter - 0.13-5 - respin for exiv2 virt-viewer-0.0.3-2.fc10 ------------------------ * Wed Jun 25 18:00:00 2008 Daniel P. Berrange - 0.0.3-2.fc10 - Rebuild for GNU TLS ABI bump wqy-zenhei-fonts-0.6.26-0.fc10 ------------------------------ * Wed Jun 25 18:00:00 2008 Qianqian Fang 0.6.26-0 - new upstream release xen-3.2.0-14.fc10 ----------------- * Wed Jun 25 18:00:00 2008 Daniel P. Berrange - 3.2.0-14.fc10 - Rebuild for GNU TLS ABI change * Fri Jun 13 18:00:00 2008 Markus Armbruster - 3.2.0-13.fc10 - Correctly limit PVFB size (CVE-2008-1952) Summary: Added Packages: 2 Removed Packages: 1 Modified Packages: 84 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 gedit-plugins-2.22.0-1.fc9.i386 requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 hugin-0.7.0-0.3.20080528svn.fc10.i386 requires libexiv2.so.2 hugin-base-0.7.0-0.3.20080528svn.fc10.i386 requires libexiv2.so.2 koffice-krita-1.9.95.8-1.fc10.i386 requires libexiv2.so.2 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 liferea-1.4.15-5.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-5.fc9.i386 requires libgnutls.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13 msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 qtpfsgui-1.9.2-1.fc10.i386 requires libexiv2.so.2 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 vinagre-2.23.3.1-1.fc10.i386 requires libgnutls.so.13 weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-gnome-1.0.0-2.fc9.i386 requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gedit-plugins-2.22.0-1.fc9.x86_64 requires libgucharmap.so.6()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) hugin-0.7.0-0.3.20080528svn.fc10.x86_64 requires libexiv2.so.2()(64bit) hugin-base-0.7.0-0.3.20080528svn.fc10.i386 requires libexiv2.so.2 hugin-base-0.7.0-0.3.20080528svn.fc10.x86_64 requires libexiv2.so.2()(64bit) koffice-krita-1.9.95.8-1.fc10.i386 requires libexiv2.so.2 koffice-krita-1.9.95.8-1.fc10.x86_64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-5.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-5.fc9.x86_64 requires libgnutls.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 qtpfsgui-1.9.2-1.fc10.x86_64 requires libexiv2.so.2()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) vinagre-2.23.3.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.x86_64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 gedit-plugins-2.22.0-1.fc9.ppc requires libgucharmap.so.6 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 hugin-0.7.0-0.3.20080528svn.fc10.ppc requires libexiv2.so.2 hugin-base-0.7.0-0.3.20080528svn.fc10.ppc requires libexiv2.so.2 hugin-base-0.7.0-0.3.20080528svn.fc10.ppc64 requires libexiv2.so.2()(64bit) koffice-krita-1.9.95.8-1.fc10.ppc requires libexiv2.so.2 koffice-krita-1.9.95.8-1.fc10.ppc64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-5.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-5.fc9.ppc requires libgnutls.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13 msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 qtpfsgui-1.9.2-1.fc10.ppc requires libexiv2.so.2 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 vinagre-2.23.3.1-1.fc10.ppc requires libgnutls.so.13 weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gedit-plugins-2.22.0-1.fc9.ppc64 requires libgucharmap.so.6()(64bit) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) hugin-0.7.0-0.3.20080528svn.fc10.ppc64 requires libexiv2.so.2()(64bit) hugin-base-0.7.0-0.3.20080528svn.fc10.ppc64 requires libexiv2.so.2()(64bit) koffice-krita-1.9.95.8-1.fc10.ppc64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-5.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-5.fc9.ppc64 requires libgnutls.so.13()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot m17n-contrib-hindi-1.1.6-4.fc10.noarch requires m17n-db-hindi >= 0:1.4.0 mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot qtpfsgui-1.9.2-1.fc10.ppc64 requires libexiv2.so.2()(64bit) scim-lang-hindi-1.4.7-25.fc10.ppc64 requires m17n-db-hindi scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) vinagre-2.23.3.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.ppc64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From marc at mwiriadi.id.au Thu Jun 26 10:55:08 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Thu, 26 Jun 2008 18:55:08 +0800 Subject: Orphaning package Message-ID: <1214477708.31884.8.camel@localhost.localdomain> Hey all, I am struggling at the moment with time commitments in real life and my new job. I need to orphan one of the demanding packages that I have. That package is liferea which has upgraded their package and I haven't had the time at the moment to have a good look at it. If you want to be the packager of it please email me directly since I haven't been able to keep up with any of the conversations lately. Cheers, Marc From joshuacov at googlemail.com Thu Jun 26 11:01:56 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Thu, 26 Jun 2008 13:01:56 +0200 Subject: Custom DSDT Table in the fedora kernel at boot time In-Reply-To: <20080625125054.GA28479@mokona.greysector.net> References: <5f6f8c5f0806250527md333561s81bd5e8b3d624fe6@mail.gmail.com> <20080625125054.GA28479@mokona.greysector.net> Message-ID: <5f6f8c5f0806260401h303fce19qe80e23b9e862857b@mail.gmail.com> I reopened my bug at http://bugzilla.kernel.org/show_bug.cgi?id=10237 . Maybe the acpi code should be corrected to circumvent the broken dsdt code. if windows works, why shouldn't linux do it either? 2008/6/25 Dominik 'Rathann' Mierzejewski : > On Wednesday, 25 June 2008 at 14:27, Joshua C. wrote: > [...] > > This with my dsdt in the maistream kernel (as missing code) was > > just a joke. I think the kernel shouldn't collect fixes for broken > > dsdt tables but just provide a way to insert a custom one at boot > > time. I think it is poor judgemnt to incorporate anyones dsdt (or > > other system specific code like bioses) in the mainstream kernel. > > > > Just in case if this could have happended: at boot the kernel > > should look throught a register with broken dsdt tables and apply > > the "correct" one. and with new bios - should we incorporate our > > new dsdt? Should the kernel check (on the millions of pcs it runs > > on) for my/anyones dsdt? This is insane! > > Nobody is suggesting anything of the sort. The fix (or probably > a workaround) should be done in the kernel acpi code, because if > Windows works, then so should Linux. We don't want users to mess > with their DSDT tables, however broken they may be. > > Regards, > R. > > -- > Fedora http://fedoraproject.org/wiki/User:Rathann > Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > "Faith manages." > -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > > -- > 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 Thu Jun 26 11:35:47 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 26 Jun 2008 07:35:47 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <20080626050040.GC6590@redhat.com> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> Message-ID: <1214480147.14225.123.camel@weaponx> On Thu, 2008-06-26 at 01:00 -0400, Dave Jones wrote: > On Wed, Jun 25, 2008 at 09:05:54AM -0400, Josh Boyer wrote: > > On Tue, 2008-06-24 at 21:14 -0400, Josh Boyer wrote: > > > On Tue, 2008-06-24 at 16:15 -0400, Dave Jones wrote: > > > > PPC32 kernel builds take _forever_ in the build system. They're slowing things > > > > down to such extent that I'm usually still waiting for them several hours > > > > after the other architectures have finished building. > > > > > > Has anyone looked at _why_ they are so slow? Do you have timing > > > information for a particular kernel flavor? > > > > > > If I'm remembering correctly, local kernel builds on my G5 were quite > > > faster than what is in koji. Finding out why might be a good start. > > > > Ok, so I did a cvs checkout of the devel kernel last night and timed a > > simple 'make ppc'. That built both the UP and SMP ppc kernels, with all > > the associated -devel and -debuginfo packages. > > > > This was done on a dual-cpu G5 with 1.5 GiB of DRAM running F9. Gnome, > > Evolution, X-Chat, and Rhythmbox were running, but it was otherwise > > unused. > > > > The results: > > > > real 117m16.886s > > user 133m27.480s > > sys 20m47.314s > > > > How does that compare with koji builds? > > The last one I timed yesterday took about 4-5 hours. Just for ppc32 kernels, or the whole kernel koji job? josh From promac at gmail.com Thu Jun 26 13:25:43 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 26 Jun 2008 10:25:43 -0300 Subject: Backport F-9's grub to F-8 Message-ID: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> Hi, a couple of days ago I received a Dell Vostro 1400. I dumped its windows vista Home edition, and install an F8 x86_64 image on it (I just copied the partitions from another computer). Then, I run grub-install /dev/sda using an F8 install DVD. The problem is that when I tried to boot using the latest kernel 2.6.25-6-27.fc8, and the newer grub, the boot hanged trying to load initrd. However, I could boot normally using a 2.6.24 or 2.6.23 kernel. Then, I downgraded grub to 0.97-19 and finally I could boot to kernel 2.6.25. I also noted that kernel 2.6.25 had a setup=0x300 and the previous kernels 0x2c00 (the only difference I could see loading initrd). My question is: what has changed in grub, and if I had run grub-install from the newer grub (0.97-33.1) the issue would also be solved or could I get stuck for all kernels (not only for 2.6.25). Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From loupgaroublond at gmail.com Thu Jun 26 13:57:03 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 26 Jun 2008 15:57:03 +0200 Subject: Backport F-9's grub to F-8 In-Reply-To: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> References: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> Message-ID: <7f692fec0806260657v69578c8al566608b0b9610cc2@mail.gmail.com> Hi Paulo, 2008/6/26 Paulo Cavalcanti : > Hi, > > a couple of days ago I received a Dell Vostro 1400. I have a Vostro 1400 as well. I have never had this problem. Perhaps you want to try editing your grub.conf file in /boot/grub and try using setup=0x2c00. I never even saw that switch being set up on my machine. If you have the chance, can you tell if this problem also exists in Fedora 9 or not? -Yaakov From sandeen at redhat.com Thu Jun 26 14:04:54 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 26 Jun 2008 09:04:54 -0500 Subject: Fedora 9 kernel configuration In-Reply-To: <63103.208.97.187.133.1214465204.squirrel@mail.fedoraproject.ro> References: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> <604aa7910806251657n34c451e2w3884defd3f09a76b@mail.gmail.com> <63103.208.97.187.133.1214465204.squirrel@mail.fedoraproject.ro> Message-ID: <4863A206.7050308@redhat.com> adrian.joian at fedoraproject.ro wrote: > Hello, > > You are right in the /boot config file everything is ok. > > But if you install the kernel source and look in the config-debug, > config-x86 and so on files non of them contain the 3 values all toghether. The RPM build assembles/combines those files in interesting ways, IIRC, to create the final config. -Erric From sandeen at redhat.com Thu Jun 26 14:09:49 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 26 Jun 2008 09:09:49 -0500 Subject: Backport F-9's grub to F-8 In-Reply-To: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> References: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> Message-ID: <4863A32D.6030503@redhat.com> Paulo Cavalcanti wrote: > Hi, > > a couple of days ago I received a Dell Vostro 1400. > > I dumped its windows vista Home edition, > and install an F8 x86_64 image on it (I just copied the partitions from > another computer). > Then, I run grub-install /dev/sda using an F8 install DVD. > > The problem is that when I tried to boot using the latest kernel > 2.6.25-6-27.fc8, > and the newer grub, the boot hanged trying to load initrd. > > However, I could boot normally using a 2.6.24 or 2.6.23 kernel. > > Then, I downgraded grub to 0.97-19 and finally I could boot > to kernel 2.6.25. > > I also noted that kernel 2.6.25 had a setup=0x300 and > the previous kernels 0x2c00 (the only difference I could see > loading initrd). > > My question is: what has changed in grub, and > if I had run grub-install from the newer grub (0.97-33.1) the issue > would also be solved or could I get stuck for all kernels (not only for > 2.6.25). I'm not sure of the details of your problem, but just FWIW: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-4690 the latest grub is already headed for F8, for other reasons (handling the larger ext3 inode size on F9 filesystems). -Eric From jkeating at redhat.com Thu Jun 26 15:45:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jun 2008 11:45:32 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214480147.14225.123.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> Message-ID: <1214495132.17827.11.camel@localhost.localdomain> On Thu, 2008-06-26 at 07:35 -0400, Josh Boyer wrote: > > > real 117m16.886s > > > user 133m27.480s > > > sys 20m47.314s > > > > > > How does that compare with koji builds? > > > > The last one I timed yesterday took about 4-5 hours. > > Just for ppc32 kernels, or the whole kernel koji job? According to koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=680976) Created Wed, 25 Jun 2008 21:01:43 UTC Completed Wed, 25 Jun 2008 23:06:09 UTC so 2 hours. Comparatively the x86_64 build took 50 minutes. That time holds true for the last couple builds, but if you go back farther to http://koji.fedoraproject.org/koji/taskinfo?taskID=678487 you'll see one that took far longer, a full 5 hours. Now that box may have been building something else at the time, it's a little difficult to pull that kind of information. What's disturbing is from that point back, all the ppc build times are 4 hours or longer, some even 7 hours. On different hosts too, not just a specific slow host. Did the PPC config change after kernel-2.6.26-0.87.rc7.git2.fc10 ? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From promac at gmail.com Thu Jun 26 15:53:08 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 26 Jun 2008 12:53:08 -0300 Subject: Backport F-9's grub to F-8 In-Reply-To: <4863A32D.6030503@redhat.com> References: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> <4863A32D.6030503@redhat.com> Message-ID: <68720af30806260853q5d34b112of8149a2e5e487126@mail.gmail.com> On Thu, Jun 26, 2008 at 11:09 AM, Eric Sandeen wrote: > Paulo Cavalcanti wrote: > > Hi, > > > > a couple of days ago I received a Dell Vostro 1400. > > > > I dumped its windows vista Home edition, > > and install an F8 x86_64 image on it (I just copied the partitions from > > another computer). > > Then, I run grub-install /dev/sda using an F8 install DVD. > > > > The problem is that when I tried to boot using the latest kernel > > 2.6.25-6-27.fc8, > > and the newer grub, the boot hanged trying to load initrd. > > > > However, I could boot normally using a 2.6.24 or 2.6.23 kernel. > > > > Then, I downgraded grub to 0.97-19 and finally I could boot > > to kernel 2.6.25. > > > > I also noted that kernel 2.6.25 had a setup=0x300 and > > the previous kernels 0x2c00 (the only difference I could see > > loading initrd). > > > > My question is: what has changed in grub, and > > if I had run grub-install from the newer grub (0.97-33.1) the issue > > would also be solved or could I get stuck for all kernels (not only for > > 2.6.25). > > I'm not sure of the details of your problem, but just FWIW: > > https://admin.fedoraproject.org/updates/F8/FEDORA-2008-4690 > > the latest grub is already headed for F8, for other reasons (handling > the larger ext3 inode size on F9 filesystems). > > The problem is with this latest grub (0.97-33.1). It does not boot my kernel 2.6.25 on this laptop running F8 x86_64. It boots kernel 2.6.24 and 2.6.23, though. When I downgraded grub to 0.97-19, then kernel 2.6.25 booted just fine. The only thing is that I did not install using the DVD. I copied the partitions from another computer using partimage. The partitions were previously created with gparted: Filesystem Type Size Used Avail Use% Mounted on /dev/sda2 ext3 20G 13G 6.4G 66% / /dev/sda1 ext3 99M 24M 71M 25% /boot /dev/sda4 ext3 124G 12G 107G 10% /home (/dev/sda3 is for swapping). Of course, the new grub was working well on the computer the partitions were copied from. To write the MBR on the laptop for the first time, I used the grub-install from the original F8 x86_64 DVD. I think the problem is an incompatibility between gparted 0.3.7 (from system-rescueCD 1.0.3) and the new grub. Anyway, the laptop is working wonderfully well, including the webcam. The only thing I am not able to make work is the digital microphone (but an external analog mic does work fine). -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Thu Jun 26 16:15:16 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 26 Jun 2008 10:15:16 -0600 Subject: Meeting time (was Re: Fedora Support channels Improvement ideas) In-Reply-To: <604aa7910806251403l1c5f1802nb31fd38dd51194da@mail.gmail.com> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> <20080625110547.0189c88b@ohm.scrye.com> <20080625111905.5cf31ee8@ohm.scrye.com> <604aa7910806251403l1c5f1802nb31fd38dd51194da@mail.gmail.com> Message-ID: <20080626101516.26287298@ohm.scrye.com> On Wed, 25 Jun 2008 13:03:08 -0800 jspaleta at gmail.com ("Jeff Spaleta") wrote: > 2008/6/25 Kevin Fenzi : > > Looks like thursday (2008-06-26) at 18:00 UTC (right after the FESCo > > meeting) would be better. So, lets move to that time. > > > I just got the word that I'm doing the final walk through before > closing on the new house tomorrow morning. I won't be able to make > it. Can you make sure you log the irc meeting and provide some sort of > executive summary if you task out any action items. You bet. Will post that here, or a pointer here and a page on the wiki or something. > -jef kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From promac at gmail.com Thu Jun 26 16:17:28 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 26 Jun 2008 13:17:28 -0300 Subject: Backport F-9's grub to F-8 In-Reply-To: <68720af30806260853q5d34b112of8149a2e5e487126@mail.gmail.com> References: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> <4863A32D.6030503@redhat.com> <68720af30806260853q5d34b112of8149a2e5e487126@mail.gmail.com> Message-ID: <68720af30806260917n4c92151je0028bf1ad8bbb64@mail.gmail.com> On Thu, Jun 26, 2008 at 12:53 PM, Paulo Cavalcanti wrote: > > > On Thu, Jun 26, 2008 at 11:09 AM, Eric Sandeen wrote: > >> Paulo Cavalcanti wrote: >> > Hi, >> > >> > a couple of days ago I received a Dell Vostro 1400. >> > >> > I dumped its windows vista Home edition, >> > and install an F8 x86_64 image on it (I just copied the partitions from >> > another computer). >> > Then, I run grub-install /dev/sda using an F8 install DVD. >> > >> > The problem is that when I tried to boot using the latest kernel >> > 2.6.25-6-27.fc8, >> > and the newer grub, the boot hanged trying to load initrd. >> > >> > However, I could boot normally using a 2.6.24 or 2.6.23 kernel. >> > >> > Then, I downgraded grub to 0.97-19 and finally I could boot >> > to kernel 2.6.25. >> > >> > I also noted that kernel 2.6.25 had a setup=0x300 and >> > the previous kernels 0x2c00 (the only difference I could see >> > loading initrd). >> > >> > My question is: what has changed in grub, and >> > if I had run grub-install from the newer grub (0.97-33.1) the issue >> > would also be solved or could I get stuck for all kernels (not only for >> > 2.6.25). >> >> I'm not sure of the details of your problem, but just FWIW: >> >> https://admin.fedoraproject.org/updates/F8/FEDORA-2008-4690 >> >> the latest grub is already headed for F8, for other reasons (handling >> the larger ext3 inode size on F9 filesystems). >> >> > The problem is with this latest grub (0.97-33.1). > It does not boot my kernel 2.6.25 on this laptop running F8 x86_64. > It boots kernel 2.6.24 and 2.6.23, though. > > When I downgraded grub to 0.97-19, then kernel 2.6.25 booted just fine. > > The only thing is that I did not install using the DVD. > I copied the partitions from another computer using partimage. > The partitions were previously created with gparted: > > Filesystem Type Size Used Avail Use% Mounted on > /dev/sda2 ext3 20G 13G 6.4G 66% / > /dev/sda1 ext3 99M 24M 71M 25% /boot > /dev/sda4 ext3 124G 12G 107G 10% /home > > (/dev/sda3 is for swapping). > > Of course, the new grub was working well on the computer the partitions > were copied from. To write the MBR on the laptop for the first time, > I used the grub-install from the original F8 x86_64 DVD. > > I think the problem is an incompatibility between gparted 0.3.7 > (from system-rescueCD 1.0.3) and the new grub. > > Sorry, the problem is something else. If I power down the laptop, then kernel 2.6.25 hangs during the next boot. The "solution" is booting with kernel 2.6.24 and restarting (without powering down), before using kernel 2.6.25. Maybe something related to acpi??? -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Thu Jun 26 18:37:50 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Jun 2008 14:37:50 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214407518.10393.9.camel@pmac.infradead.org> References: <20080624201551.GA11499@redhat.com> <5256d0b0806241457h3a1d244fv796a4146f73dbf64@mail.gmail.com> <1214395136.25155.15.camel@localhost.localdomain> <1214396072.14225.87.camel@weaponx> <1214407518.10393.9.camel@pmac.infradead.org> Message-ID: <1214505470.24150.30.camel@localhost.localdomain> On Wed, 2008-06-25 at 16:25 +0100, David Woodhouse wrote: > On Wed, 2008-06-25 at 08:14 -0400, Josh Boyer wrote: > > We last had working support for 43p-150 machines in FC6. Something in > > the kernel has broken it since, and despite good attempts to fix it we > > still don't have a working kernel there. > > I have a B50 now, and it shouldn't be hard to fix. As soon as my new > workshop has power, it'll start working again. A few people have been > asking about it. Still got the 43p-150? There were two issues with that, first the problem with the graphic card hanging startup when jumping into the kernel (last seen message on screen was "jumping to kernel..." or something like that) and second, when doing serial installs, it'll install just great, but screws up on firstboot. Dan From jwboyer at gmail.com Thu Jun 26 19:12:12 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 26 Jun 2008 15:12:12 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214495132.17827.11.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> Message-ID: <1214507532.7698.6.camel@weaponx> On Thu, 2008-06-26 at 11:45 -0400, Jesse Keating wrote: > On Thu, 2008-06-26 at 07:35 -0400, Josh Boyer wrote: > > > > real 117m16.886s > > > > user 133m27.480s > > > > sys 20m47.314s > > > > > > > > How does that compare with koji builds? > > > > > > The last one I timed yesterday took about 4-5 hours. > > > > Just for ppc32 kernels, or the whole kernel koji job? > > According to koji > (http://koji.fedoraproject.org/koji/taskinfo?taskID=680976) > > Created Wed, 25 Jun 2008 21:01:43 UTC > Completed Wed, 25 Jun 2008 23:06:09 UTC > > so 2 hours. > > Comparatively the x86_64 build took 50 minutes. > > That time holds true for the last couple builds, but if you go back > farther to http://koji.fedoraproject.org/koji/taskinfo?taskID=678487 > you'll see one that took far longer, a full 5 hours. Now that box may > have been building something else at the time, it's a little difficult > to pull that kind of information. > > What's disturbing is from that point back, all the ppc build times are 4 > hours or longer, some even 7 hours. On different hosts too, not just a > specific slow host. Did the PPC config change after > kernel-2.6.26-0.87.rc7.git2.fc10 ? Yes. Dave dropped a bunch of modules. But my timing was done with that change included. So the current koji timings are on par with what I see on a G5 anyway. Which is still sad. josh From wwoods at redhat.com Thu Jun 26 19:25:28 2008 From: wwoods at redhat.com (Will Woods) Date: Thu, 26 Jun 2008 15:25:28 -0400 Subject: comps.rng Message-ID: <1214508328.19297.23.camel@metroid.rdu.redhat.com> If you check the 'comps' module in package CVS, you'll see the new file comps.rng[1]. This is a RELAX NG[2] schema for validating the grammar of our comps.xml files. We're hoping to rig this up to the CVS checkin procedure to ensure that all changes result in valid comps files. We're also going to use it as part of the daily acceptance testing for Rawhide. Nicolas Mailhot gets all the thanks for writing the schema - I just checked it into CVS. If anyone would care to comment on the undocumented[3] parts of comps - especially what the heck metapkg is for and whether we need it - it would be greatly appreciated. Thanks! -w ?1 http://cvs.fedoraproject.org/viewcvs/comps/comps.rng?rev=1.1&view=log 2 http://relaxng.org/ 3 Look for tagged items in comps.rng to see what's documented so far. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From moe at blagblagblag.org Thu Jun 26 19:30:29 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 26 Jun 2008 16:30:29 -0300 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623154146.6753ae91@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: <4863EE55.2010002@blagblagblag.org> Kevin Fenzi wrote: > Thats just a few ideas to get things going. I've always thought the following idea would be cool to implement. It's not IRC, but I figured I would throw this idea out there, especially now since you now have talk.fedoraproject.org. What about *free* telephone support? A rough outline: * newbie user has problem. Has no clue what IRC is. Knows what telephone is. * supergeeks live on IRC, read every message in fedora-devel (well, almost) and have VoIP software with talk.fedoraproject.org account. * Each supergeek, when available, goes to a webpage and clicks "available" to let fedora asterisk know they are available "agents" (in asterisk speek) that can receive calls from the support queue. * noob calls local number via the majick of a bunch of $2 DIDs around the world which connects them to the fedora asterisk server. "Welcome to the fedora telephone server..." They hit "1" for support. * fedora asterisk looks at all the available agents and routes the call to one of them. "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" Just an idea.... -Jeff From jkeating at redhat.com Thu Jun 26 20:29:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jun 2008 16:29:19 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214507532.7698.6.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> Message-ID: <1214512159.17827.34.camel@localhost.localdomain> On Thu, 2008-06-26 at 15:12 -0400, Josh Boyer wrote: > > Yes. Dave dropped a bunch of modules. > > But my timing was done with that change included. So the current koji > timings are on par with what I see on a G5 anyway. Which is still > sad. That must have been some module set! At least we're not in the situation where your hardware does things fantastically faster than the builders. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu Jun 26 20:33:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2008 15:33:32 -0500 Subject: 32bit PowerPC questions. In-Reply-To: <1214507532.7698.6.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> Yes. Dave dropped a bunch of modules. I had also gone in and cleaned out a bunch of spinning "dot" tasks; there were ten or so running on each PPC builder chewing CPU time. I did this on the 24th and the jobs had been running since the 16th, so if you tested between then you might have seen some additional slowness. - J< From jkeating at redhat.com Thu Jun 26 20:37:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jun 2008 16:37:13 -0400 Subject: 32bit PowerPC questions. In-Reply-To: References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> Message-ID: <1214512633.17827.36.camel@localhost.localdomain> On Thu, 2008-06-26 at 15:33 -0500, Jason L Tibbitts III wrote: > I had also gone in and cleaned out a bunch of spinning "dot" tasks; > there were ten or so running on each PPC builder chewing CPU time. I > did this on the 24th and the jobs had been running since the 16th, so > if you tested between then you might have seen some additional > slowness. Ah ok. Going farther back brings it to about 2.5 hours in time, which is slower than current but explainable by the module changes. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Thu Jun 26 20:38:14 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 26 Jun 2008 16:38:14 -0400 Subject: 32bit PowerPC questions. In-Reply-To: References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> Message-ID: <1214512694.7698.8.camel@weaponx> On Thu, 2008-06-26 at 15:33 -0500, Jason L Tibbitts III wrote: > >>>>> "JB" == Josh Boyer writes: > > JB> Yes. Dave dropped a bunch of modules. > > I had also gone in and cleaned out a bunch of spinning "dot" tasks; > there were ten or so running on each PPC builder chewing CPU time. I > did this on the 24th and the jobs had been running since the 16th, so > if you tested between then you might have seen some additional > slowness. That might have had a bigger effect. I though koji would only run one build job per builder? Or is it per CPU? josh From tibbs at math.uh.edu Thu Jun 26 20:41:03 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2008 15:41:03 -0500 Subject: 32bit PowerPC questions. In-Reply-To: <1214512694.7698.8.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> <1214512694.7698.8.camel@weaponx> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> That might have had a bigger effect. I though koji would only run JB> one build job per builder? Or is it per CPU? I don't know what koji does, but in this case koji was unaware that the jobs were still running. I guess they had been killed from the server but not cleaned up on the builders. - J< From sundaram at fedoraproject.org Thu Jun 26 20:48:41 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 27 Jun 2008 02:18:41 +0530 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4863EE55.2010002@blagblagblag.org> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> Message-ID: <486400A9.7090906@fedoraproject.org> jeff wrote: > Kevin Fenzi wrote: >> Thats just a few ideas to get things going. > > I've always thought the following idea would be cool to implement. It's > not IRC, but I figured I would throw this idea out there, especially now > since you now have talk.fedoraproject.org. > > What about *free* telephone support? Yeah, some of us discussed this already. We might just be able to pull it off soon. That indeed would be nice. I can volunteer some amount of time on a regular basis to participate. Rahul From lsof at nodata.co.uk Thu Jun 26 20:51:34 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 26 Jun 2008 22:51:34 +0200 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4863EE55.2010002@blagblagblag.org> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> Message-ID: <1214513494.2957.44.camel@sb-home> Am Donnerstag, den 26.06.2008, 16:30 -0300 schrieb jeff: > Kevin Fenzi wrote: > > Thats just a few ideas to get things going. > > I've always thought the following idea would be cool to implement. It's not > IRC, but I figured I would throw this idea out there, especially now since you > now have talk.fedoraproject.org. > > What about *free* telephone support? > > A rough outline: > > * newbie user has problem. Has no clue what IRC is. Knows what telephone is. > > * supergeeks live on IRC, read every message in fedora-devel (well, almost) and > have VoIP software with talk.fedoraproject.org account. > > * Each supergeek, when available, goes to a webpage and clicks "available" to > let fedora asterisk know they are available "agents" (in asterisk speek) that > can receive calls from the support queue. > > * noob calls local number via the majick of a bunch of $2 DIDs around the world > which connects them to the fedora asterisk server. "Welcome to the fedora > telephone server..." They hit "1" for support. > > * fedora asterisk looks at all the available agents and routes the call to one > of them. > > "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" > > Just an idea.... > > -Jeff > Wouldn't this shift the focus away from users finding answers for themselves (RTFM, essentially) and us writing good documentation? I can only see this being useful if it fed back into a knowledge base. From moe at blagblagblag.org Thu Jun 26 20:52:47 2008 From: moe at blagblagblag.org (jeff) Date: Thu, 26 Jun 2008 17:52:47 -0300 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214513494.2957.44.camel@sb-home> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> <1214513494.2957.44.camel@sb-home> Message-ID: <4864019F.4080206@blagblagblag.org> nodata wrote: > Am Donnerstag, den 26.06.2008, 16:30 -0300 schrieb jeff: >> Kevin Fenzi wrote: >>> Thats just a few ideas to get things going. >> I've always thought the following idea would be cool to implement. It's not >> IRC, but I figured I would throw this idea out there, especially now since you >> now have talk.fedoraproject.org. >> >> What about *free* telephone support? >> >> A rough outline: >> >> * newbie user has problem. Has no clue what IRC is. Knows what telephone is. >> >> * supergeeks live on IRC, read every message in fedora-devel (well, almost) and >> have VoIP software with talk.fedoraproject.org account. >> >> * Each supergeek, when available, goes to a webpage and clicks "available" to >> let fedora asterisk know they are available "agents" (in asterisk speek) that >> can receive calls from the support queue. >> >> * noob calls local number via the majick of a bunch of $2 DIDs around the world >> which connects them to the fedora asterisk server. "Welcome to the fedora >> telephone server..." They hit "1" for support. >> >> * fedora asterisk looks at all the available agents and routes the call to one >> of them. >> >> "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" >> >> Just an idea.... >> >> -Jeff >> > > Wouldn't this shift the focus away from users finding answers for > themselves (RTFM, essentially) and us writing good documentation? > > I can only see this being useful if it fed back into a knowledge base. Well, depending on their problem it could be as easy as just to say "open your browser and go to http://wiki...." if there is a solution there. Newbies have trouble even finding what doc is relevant to their problem (well, not just newbies either....) -Jeff From lsof at nodata.co.uk Thu Jun 26 21:02:22 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 26 Jun 2008 23:02:22 +0200 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4864019F.4080206@blagblagblag.org> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> <1214513494.2957.44.camel@sb-home> <4864019F.4080206@blagblagblag.org> Message-ID: <1214514142.2957.48.camel@sb-home> Am Donnerstag, den 26.06.2008, 17:52 -0300 schrieb jeff: > nodata wrote: > > Am Donnerstag, den 26.06.2008, 16:30 -0300 schrieb jeff: > >> Kevin Fenzi wrote: > >>> Thats just a few ideas to get things going. > >> I've always thought the following idea would be cool to implement. It's not > >> IRC, but I figured I would throw this idea out there, especially now since you > >> now have talk.fedoraproject.org. > >> > >> What about *free* telephone support? > >> > >> A rough outline: > >> > >> * newbie user has problem. Has no clue what IRC is. Knows what telephone is. > >> > >> * supergeeks live on IRC, read every message in fedora-devel (well, almost) and > >> have VoIP software with talk.fedoraproject.org account. > >> > >> * Each supergeek, when available, goes to a webpage and clicks "available" to > >> let fedora asterisk know they are available "agents" (in asterisk speek) that > >> can receive calls from the support queue. > >> > >> * noob calls local number via the majick of a bunch of $2 DIDs around the world > >> which connects them to the fedora asterisk server. "Welcome to the fedora > >> telephone server..." They hit "1" for support. > >> > >> * fedora asterisk looks at all the available agents and routes the call to one > >> of them. > >> > >> "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" > >> > >> Just an idea.... > >> > >> -Jeff > >> > > > > Wouldn't this shift the focus away from users finding answers for > > themselves (RTFM, essentially) and us writing good documentation? > > > > I can only see this being useful if it fed back into a knowledge base. > > Well, depending on their problem it could be as easy as just to say "open your > browser and go to http://wiki...." if there is a solution there. Newbies have > trouble even finding what doc is relevant to their problem (well, not just > newbies either....) > > -Jeff > Then is phone support useful? I mean phones are very inefficient/disruptive (and not the "good" disruptive) for this kind of thing since they prevent you from being able to queue requests (like on irc, jabber, email, etc); they require an instant response. Giving URLs over the phobe won't be fun either. From dcbw at redhat.com Thu Jun 26 21:16:23 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Jun 2008 17:16:23 -0400 Subject: 32bit PowerPC questions. In-Reply-To: References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> <1214512694.7698.8.camel@weaponx> Message-ID: <1214514983.18202.4.camel@localhost.localdomain> On Thu, 2008-06-26 at 15:41 -0500, Jason L Tibbitts III wrote: > >>>>> "JB" == Josh Boyer writes: > > JB> That might have had a bigger effect. I though koji would only run > JB> one build job per builder? Or is it per CPU? > > I don't know what koji does, but in this case koji was unaware that > the jobs were still running. I guess they had been killed from the > server but not cleaned up on the builders. This happened a lot with plague too. I think it's Just Hard in *NIX to ensure that all ancestors of a given task have been killed dead dead dead. Maybe they somehow get out of the parent's process group, they are just hung and don't respond to signals, they are in D state when the signals get sent, whatever. Running craploads of scripts and programs as part of the build process that fork and exec and do God-knows-what doesn't lend itself to being cleaned up easily. I think either cgroups (?) or putting each build in a clean VM which can be torn down completely is probably the answer. And out of those two, a whole new VM would be pretty heavy to create/destroy so it's probably out of the question. Dan From jwboyer at gmail.com Thu Jun 26 21:27:29 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 26 Jun 2008 17:27:29 -0400 Subject: 32bit PowerPC questions. In-Reply-To: <1214514983.18202.4.camel@localhost.localdomain> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> <1214512694.7698.8.camel@weaponx> <1214514983.18202.4.camel@localhost.localdomain> Message-ID: <1214515649.7698.11.camel@weaponx> On Thu, 2008-06-26 at 17:16 -0400, Dan Williams wrote: > On Thu, 2008-06-26 at 15:41 -0500, Jason L Tibbitts III wrote: > > >>>>> "JB" == Josh Boyer writes: > > > > JB> That might have had a bigger effect. I though koji would only run > > JB> one build job per builder? Or is it per CPU? > > > > I don't know what koji does, but in this case koji was unaware that > > the jobs were still running. I guess they had been killed from the > > server but not cleaned up on the builders. > > This happened a lot with plague too. I think it's Just Hard in *NIX to > ensure that all ancestors of a given task have been killed dead dead > dead. Maybe they somehow get out of the parent's process group, they > are just hung and don't respond to signals, they are in D state when the > signals get sent, whatever. Running craploads of scripts and programs > as part of the build process that fork and exec and do God-knows-what > doesn't lend itself to being cleaned up easily. > > I think either cgroups (?) or putting each build in a clean VM which can > be torn down completely is probably the answer. And out of those two, a > whole new VM would be pretty heavy to create/destroy so it's probably > out of the question. And impossible on ppc without LPAR support for every builder. Hopefully containers will help when the builders move to RHEL6 (if RHEL6 supports containers...). josh From dev at nigelj.com Thu Jun 26 21:39:43 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 27 Jun 2008 09:39:43 +1200 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214514142.2957.48.camel@sb-home> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> <1214513494.2957.44.camel@sb-home> <4864019F.4080206@blagblagblag.org> <1214514142.2957.48.camel@sb-home> Message-ID: <48640C9F.708@nigelj.com> nodata wrote: > Am Donnerstag, den 26.06.2008, 17:52 -0300 schrieb jeff: > >> nodata wrote: >> >>> Am Donnerstag, den 26.06.2008, 16:30 -0300 schrieb jeff: >>> >>>> Kevin Fenzi wrote: >>>> >>>>> Thats just a few ideas to get things going. >>>>> >>>> I've always thought the following idea would be cool to implement. It's not >>>> IRC, but I figured I would throw this idea out there, especially now since you >>>> now have talk.fedoraproject.org. >>>> >>>> What about *free* telephone support? >>>> >>>> A rough outline: >>>> >>>> * newbie user has problem. Has no clue what IRC is. Knows what telephone is. >>>> >>>> * supergeeks live on IRC, read every message in fedora-devel (well, almost) and >>>> have VoIP software with talk.fedoraproject.org account. >>>> >>>> * Each supergeek, when available, goes to a webpage and clicks "available" to >>>> let fedora asterisk know they are available "agents" (in asterisk speek) that >>>> can receive calls from the support queue. >>>> >>>> * noob calls local number via the majick of a bunch of $2 DIDs around the world >>>> which connects them to the fedora asterisk server. "Welcome to the fedora >>>> telephone server..." They hit "1" for support. >>>> >>>> * fedora asterisk looks at all the available agents and routes the call to one >>>> of them. >>>> >>>> "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" >>>> >>>> Just an idea.... >>>> >>>> -Jeff >>>> >>>> >>> Wouldn't this shift the focus away from users finding answers for >>> themselves (RTFM, essentially) and us writing good documentation? >>> >>> I can only see this being useful if it fed back into a knowledge base. >>> >> Well, depending on their problem it could be as easy as just to say "open your >> browser and go to http://wiki...." if there is a solution there. Newbies have >> trouble even finding what doc is relevant to their problem (well, not just >> newbies either....) >> >> -Jeff >> >> > > Then is phone support useful? > > I mean phones are very inefficient/disruptive (and not the "good" > disruptive) for this kind of thing since they prevent you from being > able to queue requests (like on irc, jabber, email, etc); they require > an instant response. Giving URLs over the phobe won't be fun either. > > My two cents... Pros: - It's there - It uses infrastructure that we control (we don't control the phone system, but we control our Asterisk setup) Cons: - As pointed out by nodata, it's sometimes hard to communicate over the phone - There is an expectation for an answer, you may not know, all forms of communication online, allow for you to say to someone "I'm sorry I don't know but if you stay a little while someone else might" or (in private) "Hey guys, I don't know the answer for X anyone know and mind taking it?" followed by a transfer. - If your having a bad day, anger is a bit more predominate over the phone too, and can leave someone with a bad impression of Fedora/Fedora Community. In essence, to much work to too little gain (phones anyway). - Nigel From haralevi at inf.fu-berlin.de Thu Jun 26 21:28:47 2008 From: haralevi at inf.fu-berlin.de (Andre Haralevi) Date: Thu, 26 Jun 2008 23:28:47 +0200 Subject: Security Assurance in FOSS: Request for contribution Message-ID: <200806262229.m5QMSx5S000415@mx3.redhat.com> Dear members of the Fedora project, we kindly ask for your participation in our survey on security assurance in free/open source software. Security assurances are confidence building activities through structured design processes, documentation, and testing. By participating in our survey you contribute to ongoing research with the aim to make free/open source software more secure. It will not take more than 10 minutes of your valuable time for our 21 questions. Our survey is online for the next two weeks until July 1 at: http://survey.mi.fu-berlin.de/public/survey.php?name=fosssecurity The survey is anonymous. Please find the results of the survey on the project page during July: https://www.inf.fu-berlin.de/w/SE/FOSSSecuritySurvey For further information about Open Source research at the Research Group Software Engineering at Freie Universitaet Berlin, please visit: https://www.inf.fu-berlin.de/w/SE/FOSSHome Thank you in anticipation, Sascha Rasmussen, Alexander Kunze, and Andre Haralevi In case you participate in more than one FOSS project, please fill out the questionnaire for the one where security is most important, or fill out one questionnaire per project. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu Jun 26 23:19:25 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 26 Jun 2008 17:19:25 -0600 Subject: F9 builds failing tcl/tk issues Message-ID: <486423FD.4030304@cora.nwra.com> DEBUG backend.py:490: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-211619-37259/root/ install 'zlib-devel' 'doxygen' 'cmake' 'readline-devel' '/usr/bin/desktop-file-install' 'python-devel' 'expat-devel' 'mesa-libOSMesa-devel' 'freetype-devel' 'openmpi-devel' 'qt4-devel' 'hdf5-devel' 'tk-devel' 'graphviz' 'libtiff-devel' DEBUG util.py:272: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-211619-37259/root/ install 'zlib-devel' 'doxygen' 'cmake' 'readline-devel' '/usr/bin/desktop-file-install' 'python-devel' 'expat-devel' 'mesa-libOSMesa-devel' 'freetype-devel' 'openmpi-devel' 'qt4-devel' 'hdf5-devel' 'tk-devel' 'graphviz' 'libtiff-devel' DEBUG util.py:250: Error: Missing Dependency: tcl-devel = 1:8.5.1 is needed by package tk-devel DEBUG util.py:250: Error: Missing Dependency: tcl = 1:8.5.1 is needed by package tk DEBUG backend.py:478: umount -n /var/lib/mock/dist-f9-build-211619-37259/root/proc Bad tcl update get in there? -- 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 linuxkernel at edcint.co.nz Fri Jun 27 00:01:33 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Fri, 27 Jun 2008 10:01:33 +1000 Subject: Packaging of Nagios Message-ID: <48642DDD.9000508@edcint.co.nz> I am waiting for the release of the fedora Nagios v3 package and was wondering if I could get involved to help speed up the process? From bojan at rexursive.com Fri Jun 27 00:47:38 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 27 Jun 2008 10:47:38 +1000 Subject: Kernel 2.6.25.9 Message-ID: <1214527658.2541.7.camel@shrek.rexursive.com> Is this update security related, given the log (search for sctp): http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.9 If so, can we get this into updates of F9? http://koji.fedoraproject.org/koji/buildinfo?buildID=53850 -- Bojan From kevin at scrye.com Fri Jun 27 04:01:09 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 26 Jun 2008 22:01:09 -0600 Subject: Meeting time (was Re: Fedora Support channels Improvement ideas) In-Reply-To: <20080626101516.26287298@ohm.scrye.com> References: <4860F5B6.5030803@math.vt.edu> <1214320898.6379.9.camel@bruiser.localdomain> <16de708d0806241228o233d0112jc1d91143452e261@mail.gmail.com> <20080625110547.0189c88b@ohm.scrye.com> <20080625111905.5cf31ee8@ohm.scrye.com> <604aa7910806251403l1c5f1802nb31fd38dd51194da@mail.gmail.com> <20080626101516.26287298@ohm.scrye.com> Message-ID: <20080626220109.58651d88@ohm.scrye.com> On Thu, 26 Jun 2008 10:15:16 -0600 kevin at scrye.com (Kevin Fenzi) wrote: > On Wed, 25 Jun 2008 13:03:08 -0800 > jspaleta at gmail.com ("Jeff Spaleta") wrote: > > > 2008/6/25 Kevin Fenzi : > > > Looks like thursday (2008-06-26) at 18:00 UTC (right after the > > > FESCo meeting) would be better. So, lets move to that time. > > > > > > I just got the word that I'm doing the final walk through before > > closing on the new house tomorrow morning. I won't be able to make > > it. Can you make sure you log the irc meeting and provide some sort > > of executive summary if you task out any action items. We made a bit of progress at the meeting today... some short term action items/goals, and some down the road dreaming. Action items: 1. Memo the ops list and ask about being involved or not. (DONE) 2. Start pointing users posting off topic posts to #fedora-social. 3. Add some new ops (roguedaemon and nirik). (DONE) 4. Discuss next meeting and post to Fedora-Devel-List. Scott Glaser (Sonar_Guy) was nice enough to write up this summary: https://fedoraproject.org/wiki/User:Kevin/DRAFT-IRCSupportConduct/Meeting-20080626 I would like to see us meet again next week or the week after, but we will need to figure out when a good time to meet would be. I would like us to see about forming a support SIG (If possible), and trying to do some recruitment for new helpers soon. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jun 27 07:12:57 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Jun 2008 09:12:57 +0200 Subject: F-8 updates packages are not in the F-8 buildroot!! Message-ID: <486492F9.7040602@hhs.nl> Hi All, For some strange reason F-8 updates packages are not in the F-8 buildroot, which is really bad!! 20 juni php-5.2.6 was pushed to updates-stable for F-8 and F-9, 21st juni I got a bug report about broken deps in maniadrive (which uses php-embedded) and that day I rebuild maniadrive for F-9 and pushed it directly to the stable updates. But I forgot F-8 so yesterday I received a bug for F-8 (duh) and rebuild it there too, today the bug was reopened as the rebuild version still dependended upon the old php. So I did another rebuild with an explicit: BuildRequires: php-devel >= 5.2.6, php-embedded-devel >= 5.2.6 Which then failed to build with: DEBUG util.py:250: No Package Found for php-devel >= 5.2.6 Which is strange as php-5.2.6 is in F-8 updates! Regards, Hans From mmaslano at redhat.com Fri Jun 27 07:15:27 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Fri, 27 Jun 2008 09:15:27 +0200 Subject: F9 builds failing tcl/tk issues In-Reply-To: <486423FD.4030304@cora.nwra.com> References: <486423FD.4030304@cora.nwra.com> Message-ID: <4864938F.30809@redhat.com> > Bad tcl update get in there? > No, I updated tcl to 8.5.2 (some bugfixes). There is need to tag also tcl-devel, which is still set on previous version. I've already filled ticket to release-eng. -- Marcela Ma?l??ov? BaseOS team Brno From nicolas.mailhot at laposte.net Fri Jun 27 07:35:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Jun 2008 09:35:08 +0200 (CEST) Subject: Fedora Support channels Improvement ideas In-Reply-To: <4863EE55.2010002@blagblagblag.org> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> Message-ID: <58027.192.54.193.59.1214552108.squirrel@rousalka.dyndns.org> Le Jeu 26 juin 2008 21:30, jeff a ?crit : > > Kevin Fenzi wrote: >> Thats just a few ideas to get things going. > > I've always thought the following idea would be cool to implement. > It's not > IRC, but I figured I would throw this idea out there, especially now > since you > now have talk.fedoraproject.org. > > What about *free* telephone support? That's good if you have native language channels. If you only have English ones, written media is much preferred. At least with written media you can take time to compose/read text in a foreign language, and can use all sorts of assistive aids (dictionnaries, etc) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Jun 27 07:48:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Jun 2008 09:48:07 +0200 (CEST) Subject: 32bit PowerPC questions. In-Reply-To: <1214507532.7698.6.camel@weaponx> References: <20080624201551.GA11499@redhat.com> <1214356497.14225.77.camel@weaponx> <1214399154.14225.111.camel@weaponx> <20080626050040.GC6590@redhat.com> <1214480147.14225.123.camel@weaponx> <1214495132.17827.11.camel@localhost.localdomain> <1214507532.7698.6.camel@weaponx> Message-ID: <31932.192.54.193.59.1214552887.squirrel@rousalka.dyndns.org> Le Jeu 26 juin 2008 21:12, Josh Boyer a ?crit : > Yes. Dave dropped a bunch of modules. > > But my timing was done with that change included. So the current koji > timings are on par with what I see on a G5 anyway. Which is still > sad. As someone who maintains a lot of noarch packages, I can tell you I was overjoyed the day they were non longer forced to be ppc-built. It was soo much faster. I suspect that for PPc you have two things: a bit slower setup and as a result tasks that queue up longer than on x86_64 (so more contention) -- Nicolas Mailhot From kevin.kofler at chello.at Fri Jun 27 08:19:46 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 27 Jun 2008 08:19:46 +0000 (UTC) Subject: F-8 updates packages are not in the F-8 buildroot!! References: <486492F9.7040602@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > For some strange reason F-8 updates packages are not in the F-8 buildroot, > which is really bad!! override supersedes updates, so this sort of problems are usually the result of an old php being left over in dist-f8-override. Run "koji latest-pkg dist-f8-build php" to get the confirmation: php-5.2.5-2.fc8 dist-f8-override jorton You have to ask rel-eng to untag all old php builds from dist-f8-override. Kevin Kofler From joshuacov at googlemail.com Fri Jun 27 09:28:17 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 27 Jun 2008 11:28:17 +0200 Subject: Backporting some F9 packages to F8 Message-ID: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Can someone backport some of the F9 packages to F8? Especially some of the following: firefox 3 openoffice.org 2.4.1 (3 beta) kdebase 4.0.83 beta mesa xorg-x11-drv-ati pulseaudio gdm gcc ............................ and other "basic" packages. It would be nice to have up-to-date F8. -joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraxis at telkomsa.net Fri Jun 27 09:49:51 2008 From: abraxis at telkomsa.net (Neil Thompson) Date: Fri, 27 Jun 2008 11:49:51 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <20080627094951.GA8129@eeyore.32.boerneef.vornavalley> On Fri, Jun 27, 2008 at 11:28:17AM +0200, Joshua C. wrote: > Can someone backport some of the F9 packages to F8? Especially some of the > following: > firefox 3 > [1]openoffice.org 2.4.1 (3 beta) > kdebase 4.0.83 beta > mesa > xorg-x11-drv-ati > pulseaudio > gdm > gcc > ............................ > > and other "basic" packages. It would be nice to have up-to-date F8. > The source is available - why don't you do it yourself, test the resulting packages and submit any necessary package changes to the current developers? -- Cheers! (Relax...have a homebrew) Neil ...aliquando et insanire iucundum est. -- Lucius Annaeus Seneca From kevin.kofler at chello.at Fri Jun 27 10:05:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 27 Jun 2008 10:05:14 +0000 (UTC) Subject: Backporting some F9 packages to F8 References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: Joshua C. googlemail.com> writes: > kdebase 4.0.83 beta That's not even in F9 yet (waiting for 4.1.0)! Kevin Kofler From lemenkov at gmail.com Fri Jun 27 10:09:21 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 27 Jun 2008 14:09:21 +0400 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: 2008/6/27 Joshua C. : > Can someone backport some of the F9 packages to F8? Especially some of the > following: > firefox 3 /me voting against Firefox 3. It doesn't work yet as well as good old Firefox 2 . -- With best regards! From rc040203 at freenet.de Fri Jun 27 10:13:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jun 2008 12:13:23 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <1214561604.6554.411.camel@beck.corsepiu.local> On Fri, 2008-06-27 at 11:28 +0200, Joshua C. wrote: > Can someone backport some of the F9 packages to F8? Especially some of > the following: > firefox 3 > openoffice.org 2.4.1 (3 beta) > kdebase 4.0.83 beta > mesa > xorg-x11-drv-ati > pulseaudio > gdm > gcc > ............................ > > and other "basic" packages. It would be nice to have up-to-date F8. Why don't you upgrade to FC8, instead? The packages you are proposing to upgrade are such kind of essential, an "update/backport" of them would almost equal an upgrade. Ralf From dan at danny.cz Fri Jun 27 10:16:11 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 27 Jun 2008 12:16:11 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <1214561771.3494.24.camel@eagle.danny.cz> Joshua C. p??e v P? 27. 06. 2008 v 11:28 +0200: > Can someone backport some of the F9 packages to F8? Especially some of > the following: > firefox 3 > openoffice.org 2.4.1 (3 beta) > kdebase 4.0.83 beta > mesa > xorg-x11-drv-ati > pulseaudio > gdm > gcc > ............................ > > and other "basic" packages. It would be nice to have up-to-date F8. And what will be then the reason to update from F-8 to F-9? Dan From bnocera at redhat.com Fri Jun 27 10:23:36 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 27 Jun 2008 11:23:36 +0100 Subject: Fedora Support channels Improvement ideas In-Reply-To: <20080623154146.6753ae91@ohm.scrye.com> References: <20080623154146.6753ae91@ohm.scrye.com> Message-ID: <1214562216.4435.18.camel@cookie.hadess.net> On Mon, 2008-06-23 at 15:41 -0600, Kevin Fenzi wrote: > Greetings. > Lets look at where we are now first. End users can seek peer provided > support from: > > - #fedora on irc.freenode.net > - #fedora-XX (for lang specific support) on irc.freenode.net > - The web based Fedora forum at http://fedoraforum.org > - The fedora-list email list at: > http://www.redhat.com/mailman/listinfo/fedora-list/ You're forgetting http://www.fedorafaq.org/ which seems to still have not been updated for F9 :/ I've even sent the guy details about the Totem changes in F9 compared to F8 for him to update those questions, but nothing yet... From rawhide at fedoraproject.org Fri Jun 27 10:38:41 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 27 Jun 2008 10:38:41 +0000 (UTC) Subject: rawhide report: 20080627 changes Message-ID: <20080627103841.C4E28209D25@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080626/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080627/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package javahelp2 JavaHelp is a full-featured, platform-independent, extensible help system New package perl-Crypt-GeneratePassword Generate secure random pronounceable passwords New package ranpwd A program to generate random passwords Updated Packages: amsn-0.97-4.fc9 --------------- * Thu Jun 26 18:00:00 2008 Sander Hoentjen - 0.97-4 - Added patch for server protocol change that breaks amsn login bind-9.5.0-37.fc10 ------------------ * Thu Jun 26 18:00:00 2008 Adam Tkac 32:9.5.0-37 - some compat changes to fix building on RHEL4 * Mon Jun 23 18:00:00 2008 Adam Tkac 32:9.5.0-36.3 - fixed typo in %posttrans script * Wed Jun 18 18:00:00 2008 Adam Tkac 32:9.5.0-36.2 - parse inner acls correctly (#450995) * Mon Jun 2 18:00:00 2008 Adam Tkac 32:9.5.0-36.1 - removed dns-keygen utility in favour of rndc-confgen -a (#449287) - some minor sample fixes (#449274) cellwriter-1.3.4-1.fc10 ----------------------- * Thu Jun 26 18:00:00 2008 Jeremy Katz - 1.3.4-1 - Update to 1.3.4 cernlib-2006-30.fc10 -------------------- * Thu Jun 26 18:00:00 2008 Patrice Dumas 2006-30 - debian paw 2.14.04.dfsg.2-6 patcheset cernlib-g77-2006-30.fc10 ------------------------ * Thu Jun 26 18:00:00 2008 Patrice Dumas 2006-30 - debian paw 2.14.04.dfsg.2-6 patcheset cronie-1.2-1.fc10 ----------------- * Thu Jun 26 18:00:00 2008 Marcela Maslanova - 1.2-1 - update to 1.2 freeradius-2.0.5-1.fc10 ----------------------- * Mon Jun 9 18:00:00 2008 John Dennis - 2.0.5-1 - upgrade to latest upstream, see Changelog for details, upstream now has more complete fix for bug #447545, local patch removed * Wed May 28 18:00:00 2008 John Dennis - 2.0.4-1 - upgrade to latest upstream, see Changelog for details - resolves: bug #447545: freeradius missing /etc/raddb/sites-available/inner-tunnel fusion-icon-0.1.0-0.3.5e2dc9git.fc10 ------------------------------------ * Thu Jun 26 18:00:00 2008 Karol Trzcionka - 0.1.0-0.3.5e2dc9git - Fix F10 building gcin-1.4.2-1.fc10 ----------------- * Thu Jun 26 18:00:00 2008 Chung-Yen Chang - 1.4.2-1 - update to 1.4.2 gedit-plugins-2.22.0-1.fc10 --------------------------- gmediaserver-0.13.0-4.fc10 -------------------------- * Thu Jun 26 18:00:00 2008 Karol Trzcionka - 0.13.0-4 - Change mediadir - Fix initscript according to guidelines - Add condrestart in %postun - Some changes in %pre section gtk2-2.13.3-3.fc10 ------------------ * Thu Jun 26 18:00:00 2008 Lubomir Rintel - 2.13.3-3 - Fix that makes gio-enabled file chooser return absolute paths hugin-0.7.0-0.4.20080528svn.fc10 -------------------------------- * Thu Jun 26 18:00:00 2008 Bruno Postle 0.7.0-0.4.20080528svn - rawhide rebuild for updated libexiv2 im-chooser-1.1.1-1.fc10 ----------------------- * Fri Jun 27 18:00:00 2008 Akira TAGOH - 1.1.1-1 - New upstream release. - Fix a segfault when no Input Method installed. (#452997) kdeedu-4.0.83-2.fc10 -------------------- * Thu Jun 26 18:00:00 2008 Rex Dieter 4.0.83-2 - %description: update for new apps - -math subpkg (#446093) - -devel: omit a few lib*.so symlinks for those with non-public apis - -devel: move designer plugins here kdelibs-4.0.83-3.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Kevin Kofler - 4.0.83-3 - fix kstandarddirs patch so /usr/libexec/kde4 is found (#453063) kdepim-4.0.83-3.fc10 -------------------- * Thu Jun 26 18:00:00 2008 Rex Dieter 4.0.83-3 - -devel: move designer plugin here libertas-usb8388-firmware-5.110.22.p14-1.fc10 --------------------------------------------- * Tue May 27 18:00:00 2008 Dennis Gilmore - 2:5.110.22.p14-1 - update to 5.110.22.p14 - http://dev.laptop.org/ticket/6993 * Sat Apr 12 18:00:00 2008 Dennis Gilmore - 2:5.110.22.p6-1 - update to 5.110.22.p6 - http://dev.laptop.org/ticket/6706 * Wed Jan 30 17:00:00 2008 Dennis Gilmore - 2:5.110.22.p1-1 - update to 5.110.22.p1 - less racy libselinux-2.0.67-1.fc10 ------------------------ liferea-1.4.15-6.fc9 -------------------- * Thu Jun 26 18:00:00 2008 Martin Stransky - 1.4.15-6 - Rebuild against new xulrunner (nspr package is not provided by xulrunner-embedding.pc now) maven-scm-1.0-0.2.b3.1jpp.5.fc10 -------------------------------- * Thu Jun 26 18:00:00 2008 Deepak Bhole 1.0-0.2.b3.1jpp.5 - Fix mapping for the scm plugin * Thu May 29 18:00:00 2008 Tom "spot" Callaway 1.0-0.2.b3.1jpp.4 - fix license tag mdadm-2.6.7-1.fc10 ------------------ * Thu Jun 26 18:00:00 2008 Doug Ledford - 2.6.7-1 - Update to latest upstream version (should resolve #444237) - Drop incremental patch as it's now part of upstream - Clean up all the open() calls in the code (#437145) - Fix the build process to actually generate mdassemble (#446988) - Update the udev rules to get additional info about arrays being assembled from the /etc/mdadm.conf file (--scan option) (#447818) - Update the udev rules to run degraded arrays (--run option) (#452459) openhpi-2.11.3-1.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Dan Horak - 2.11.3-1 - update to 2.11.3 perl-5.10.0-32.fc10 ------------------- * Fri Jun 27 18:00:00 2008 Stepan Kasal 4:5.10.0-32 - bump the release number, so that it is not smaller than in F-9 perl-Test-WWW-Mechanize-1.20-1.fc10 ----------------------------------- * Wed Jun 25 18:00:00 2008 Chris Weyl 1.20-1 - update to 1.20 - update BR's plymouth-0.4.5-1.fc10 --------------------- * Thu Jun 26 18:00:00 2008 Ray Strode - 0.4.5-1 - Update to version 0.4.5 - Make text plugin blue and less 80s pulseaudio-0.9.11-0.6.git20080626.fc10 -------------------------------------- * Thu Jun 26 18:00:00 2008 Lennart Poettering 0.9.11-0.6.git20080626 - New GIT snapshot python-sqlobject-0.10.2-1.fc10 ------------------------------ * Thu Jun 26 18:00:00 2008 Luke Macken 0.10.2-1 - Update to 0.10.2 - Add {MySQL,postgresql}-python to Requires qtpfsgui-1.9.2-2.fc10 --------------------- * Thu Jun 26 18:00:00 2008 Douglas E. Warner 1.9.2-2 - rebuild for libexiv2 rt3-3.6.7-1.fc10 ---------------- * Thu Jun 26 18:00:00 2008 Ralf Cors??pius - 3.6.7-1 - Upstream update. - Add --with-testdeps. shorewall-4.0.12-1.fc10 ----------------------- * Fri Jun 27 18:00:00 2008 Jonathan G. Underwood - 4.0.12-1 - Update to version 4.0.12 telepathy-salut-0.2.3-2.fc9 --------------------------- * Wed Jun 25 18:00:00 2008 Morgan Collett - 0.2.3-2 - Enable OLPC config Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 32 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 koffice-krita-1.9.95.8-1.fc10.i386 requires libexiv2.so.2 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.i386 requires libgnutls.so.13 msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.i386 requires libgnutls.so.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 vinagre-2.23.3.1-1.fc10.i386 requires libgnutls.so.13 weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-gnome-1.0.0-2.fc9.i386 requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) koffice-krita-1.9.95.8-1.fc10.i386 requires libexiv2.so.2 koffice-krita-1.9.95.8-1.fc10.x86_64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.x86_64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.x86_64 requires libgnutls.so.13()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) vinagre-2.23.3.1-1.fc10.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.x86_64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 koffice-krita-1.9.95.8-1.fc10.ppc requires libexiv2.so.2 koffice-krita-1.9.95.8-1.fc10.ppc64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls-extra.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls-openssl.so.13 mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) mcabber-0.9.6-1.fc9.ppc requires libgnutls.so.13 msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) msmtp-1.4.13-4.fc9.ppc requires libgnutls.so.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 vinagre-2.23.3.1-1.fc10.ppc requires libgnutls.so.13 weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) weechat-0.2.6-3.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc requires libgnutls.so.13 xenwatch-0.5.2-3.fc9.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) koffice-krita-1.9.95.8-1.fc10.ppc64 requires libexiv2.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls-extra.so.13()(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) mcabber-0.9.6-1.fc9.ppc64 requires libgnutls.so.13()(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) msmtp-1.4.13-4.fc9.ppc64 requires libgnutls.so.13()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) vinagre-2.23.3.1-1.fc10.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13()(64bit) weechat-0.2.6-3.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) xenwatch-0.5.2-3.fc9.ppc64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From bnocera at redhat.com Fri Jun 27 10:41:29 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 27 Jun 2008 11:41:29 +0100 Subject: Fedora Support channels Improvement ideas In-Reply-To: <4863EE55.2010002@blagblagblag.org> References: <20080623154146.6753ae91@ohm.scrye.com> <4863EE55.2010002@blagblagblag.org> Message-ID: <1214563289.4435.28.camel@cookie.hadess.net> On Thu, 2008-06-26 at 16:30 -0300, jeff wrote: > Kevin Fenzi wrote: > > Thats just a few ideas to get things going. > > I've always thought the following idea would be cool to implement. It's not > IRC, but I figured I would throw this idea out there, especially now since you > now have talk.fedoraproject.org. > > What about *free* telephone support? > > A rough outline: > > * newbie user has problem. Has no clue what IRC is. Knows what telephone is. If newbie doesn't want to do any research, I'm sure there are companies that will gladly provide services such as support and training in exchange of money. > "Thanks for calling Fedora support! This is supergeek $foo. How can I help?" I don't really expect anyone to catch up onto that, because: - they'll have a torrid time on the phone with people expecting professional support - not everyone speaks English - doing support just isn't fun Trying to get more people on board the forums, and making sure documentation is easily searchable is a much better idea IMO. For the forums, I could see a point in maintainers of packages being slightly higher status if they were to create accounts on fedoraforum.org. /Bastien, RH support engineer for 4.5 years From joshuacov at googlemail.com Fri Jun 27 11:24:42 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 27 Jun 2008 13:24:42 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: <1214561771.3494.24.camel@eagle.danny.cz> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> <1214561771.3494.24.camel@eagle.danny.cz> Message-ID: <5f6f8c5f0806270424m6cbe63c0t754689e4af3063f3@mail.gmail.com> I have F8 and I like it. F9 is better but there are still some issue for me. My ati card isn't resonably supported by the free ati driver. the fglrx I don't like either and other minor problems (acer hk, kde359 is still better than 404 I think, etc). therefore I'm kind of "stuck" with f8. I'm still waiting for the upgrade to F9. 2008/6/27 Dan Hor?k : > > Joshua C. p??e v P? 27. 06. 2008 v 11:28 +0200: > > Can someone backport some of the F9 packages to F8? Especially some of > > the following: > > firefox 3 > > openoffice.org 2.4.1 (3 beta) > > kdebase 4.0.83 beta > > mesa > > xorg-x11-drv-ati > > pulseaudio > > gdm > > gcc > > ............................ > > > > and other "basic" packages. It would be nice to have up-to-date F8. > > And what will be then the reason to update from F-8 to F-9? > > > Dan > > > -- > 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 joshuacov at googlemail.com Fri Jun 27 11:29:23 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 27 Jun 2008 13:29:23 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <5f6f8c5f0806270429n681847aoa30fd360d1f9cde@mail.gmail.com> I agree with you but, but maybe there are more pros than cons for version 3. 2008/6/27 Peter Lemenkov : > 2008/6/27 Joshua C. : > > Can someone backport some of the F9 packages to F8? Especially some of > the > > following: > > firefox 3 > > /me voting against Firefox 3. > It doesn't work yet as well as good old Firefox 2 . > > -- > With best regards! > > -- > 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 loupgaroublond at gmail.com Fri Jun 27 11:34:12 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 27 Jun 2008 13:34:12 +0200 Subject: Backport F-9's grub to F-8 In-Reply-To: <68720af30806260853q5d34b112of8149a2e5e487126@mail.gmail.com> References: <68720af30806260625i4bdda80eye48d0a35e0423eda@mail.gmail.com> <4863A32D.6030503@redhat.com> <68720af30806260853q5d34b112of8149a2e5e487126@mail.gmail.com> Message-ID: <7f692fec0806270434o2afb0b20u584b97e409882266@mail.gmail.com> 2008/6/26 Paulo Cavalcanti : > Anyway, the laptop is working wonderfully well, including the webcam. > The only thing I am not able to make work is the digital microphone (but an > external analog mic does work fine). Off topic, but the microphone only really works in windows. It uses some digital array system to get a better sound pickup. This requires some special work in alsa, I think, and possibly something from pulseaudio too. It already took about 3 months before I saw a decent audio driver codec for the laptop show up (with the HDA audio). -Yaakov From kevin.kofler at chello.at Fri Jun 27 11:42:31 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 27 Jun 2008 11:42:31 +0000 (UTC) Subject: Backporting some F9 packages to F8 References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> <1214561771.3494.24.camel@eagle.danny.cz> <5f6f8c5f0806270424m6cbe63c0t754689e4af3063f3@mail.gmail.com> Message-ID: Joshua C. googlemail.com> writes: > I have F8 and I like it. F9 is better but there are still some issue for me. > My ati card isn't resonably supported by the free ati driver. the fglrx I > don't like either and other minor problems (acer hk, kde359 is still better > than 404 I think, etc). therefore I'm kind of "stuck" with f8.I'm still > waiting for the upgrade to F9. Other people have other reasons not to upgrade to F9, we can't produce hundreds of F8/F9 hybrids to make everyone happy. Either you want the new stuff or you don't. (That said, some people have had success with upgrading to F9 while keeping the X.Org X11 from F8, which would look like almost what you want. It requires some tweaking though, and isn't really a "supported" configuration. If you prefer KDE 4.0.83 to 4.0.5, you can get that for F9 from kde-redhat unstable. The plan is to push KDE 4.1 to F9 when it is actually released.) In any case, what's sure is that no KDE 4.x.y will ever be pushed as an official F8 upgrade (except for the parts which are already there: the development platform and Dolphin). In kde-redhat unstable maybe (it currently has 4.0.4 for F8), but Rex is focusing on F9 and newer these days, so he might not have the time and/or interest to push 4.1 down to the F8 repo at kde-redhat. Kevin Kofler From rjones at redhat.com Fri Jun 27 12:47:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 27 Jun 2008 13:47:40 +0100 Subject: ca-certificates deprecates openssl? Message-ID: <20080627124723.GA19109@thinkpad> I'm getting: file /etc/pki/tls/certs/ca-bundle.crt from install of ca-certificates-2008-6.noarch conflicts with file from package openssl-0.9.8g-6.fc9.i686 Does this indicate that one or other package should be deprecated and include a Conflicts line? Rich. From paul at city-fan.org Fri Jun 27 12:56:10 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 27 Jun 2008 13:56:10 +0100 Subject: ca-certificates deprecates openssl? In-Reply-To: <20080627124723.GA19109@thinkpad> References: <20080627124723.GA19109@thinkpad> Message-ID: <4864E36A.6070904@city-fan.org> Richard W.M. Jones wrote: > I'm getting: > > file /etc/pki/tls/certs/ca-bundle.crt from install of ca-certificates-2008-6.noarch conflicts with file from package openssl-0.9.8g-6.fc9.i686 > > Does this indicate that one or other package should be > deprecated and include a Conflicts line? No, the file moved from the openssl package to the ca-certificates package in openssl-0.9.8g-10.fc10 Paul. From debarshi.ray at gmail.com Fri Jun 27 14:55:00 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 27 Jun 2008 20:25:00 +0530 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <3170f42f0806270755r3fcb87fcg73188b8d4aab51d0@mail.gmail.com> > Can someone backport some of the F9 packages to F8? Especially some of the > following: > [...] > gcc During the F-9 development cycle, I was able to install gcc and glibc from Rawhide on my F-8 system. I am using gcc-4.3 on F-8 since then. Updating gcc and friends will break many F-8 packages, which do not build with gcc-4.3. For some of these packages, Fedora is carrying downstream patches (eg., kernel). If these patches are not the same in F-8 and F-9 then it might be a lot of work. Happy hacking, Debarshi From hughsient at gmail.com Fri Jun 27 16:13:24 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jun 2008 17:13:24 +0100 Subject: kernel module options for cpufreq Message-ID: <1214583204.3394.30.camel@hughsie-work> At the moment we set: # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m This is not ideal from a power-saving point of view. In an ideal world we would: * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job on all workloads * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace that needs this sort of control, and if we did, the latency would be horrible * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really want to be running this on all systems that support it * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed to something else by cpuspeed. You really don't want to be using USERSPACE at all. Matthew Garrett and I are working on a latency profile for power management, and having all these modules potentially loaded is bad. Comments? Richard. From rmo at sunnmore.net Fri Jun 27 16:22:30 2008 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Fri, 27 Jun 2008 18:22:30 +0200 Subject: Packaging of Nagios In-Reply-To: <48642DDD.9000508@edcint.co.nz> References: <48642DDD.9000508@edcint.co.nz> Message-ID: <486513C6.6050109@sunnmore.net> Matthew Jurgens skreiv: > I am waiting for the release of the fedora Nagios v3 package and was > > wondering if I could get involved to help speed up the process? I've packaged Nagios 3 for my self and contacted Shawn Starr and asked if he was interested in the updates to the existing package. He replied that it wasn't interesting before the nagios 2 line was killed off. So, it seems like fedora has been debianized ;) From jspaleta at gmail.com Fri Jun 27 16:22:53 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jun 2008 08:22:53 -0800 Subject: Fedora Support channels Improvement ideas In-Reply-To: <1214562216.4435.18.camel@cookie.hadess.net> References: <20080623154146.6753ae91@ohm.scrye.com> <1214562216.4435.18.camel@cookie.hadess.net> Message-ID: <604aa7910806270922p7b341c83p1952461388b98665@mail.gmail.com> On Fri, Jun 27, 2008 at 2:23 AM, Bastien Nocera wrote: > You're forgetting http://www.fedorafaq.org/ which seems to still have > not been updated for F9 :/ I'm not sure that site is relevant any longer as a way to compile a faq. The fedoraforum site might be for better place for a preferred unofficial faq to individuals to drive people to. What really needs to happen is a wiki model for a a community faq, that is reasonable open for editting under some small group oversight. The problem is we can't host this sort of faq centrally as part of the project. Nor can we centrally drive people to it in the release notes or firstboot or whatever, because a subset of the q/a are things we can't touch as a project. -jef From casimiro.barreto at gmail.com Fri Jun 27 16:26:23 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Fri, 27 Jun 2008 13:26:23 -0300 Subject: Xen kernel freezing during boot after upgrading from FC8 to FC9 Message-ID: <486514AF.6060704@gmail.com> Hello, I've posted this before... but it seems it is not solved yet. After I upgraded from FC8 to FC9 Xen kernels are freezing during boot. More precisely just after the message: (Xen) ... relinquishing VGA The same problem happens with 2.6.25.3-1.fc9.i686 and 2.6.25.3-2.fc9.i686 Best regards, Casimiro Barreto From dan at danny.cz Fri Jun 27 16:32:24 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 27 Jun 2008 18:32:24 +0200 Subject: Packaging of Nagios In-Reply-To: <486513C6.6050109@sunnmore.net> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> Message-ID: <1214584344.3494.29.camel@eagle.danny.cz> Roy-Magne Mo p??e v P? 27. 06. 2008 v 18:22 +0200: > Matthew Jurgens skreiv: > > I am waiting for the release of the fedora Nagios v3 package and was > > > > wondering if I could get involved to help speed up the process? > > I've packaged Nagios 3 for my self and contacted Shawn Starr and asked > if he was interested in the updates to the existing package. He replied > that it wasn't interesting before the nagios 2 line was killed off. > > So, it seems like fedora has been debianized ;) > But you can submit a package called nagios3 and when there will be no conflicts with nagios then Fedora will have both. Dan -- Fedora and Red Hat package maintainer From sstarr at platform.com Fri Jun 27 16:33:59 2008 From: sstarr at platform.com (Shawn Starr) Date: Fri, 27 Jun 2008 12:33:59 -0400 Subject: Packaging of Nagios Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Roy-Magne Mo > Sent: Friday, June 27, 2008 12:23 PM > To: Development discussions related to Fedora > Subject: Re: Packaging of Nagios > > > Matthew Jurgens skreiv: > > I am waiting for the release of the fedora Nagios v3 package and was > > > > wondering if I could get involved to help speed up the process? > > I've packaged Nagios 3 for my self and contacted Shawn Starr > and asked > if he was interested in the updates to the existing package. > He replied > that it wasn't interesting before the nagios 2 line was killed off. > > So, it seems like fedora has been debianized ;) > It's not that. If we want to drop Nagios 2.x how will people upgrade properly? We could make a nagios3 package but my worry is what depends on Nagios (I haven't seen the list yet). Shawn. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mmcgrath at redhat.com Fri Jun 27 16:35:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 27 Jun 2008 11:35:22 -0500 (CDT) Subject: Packaging of Nagios In-Reply-To: <1214584344.3494.29.camel@eagle.danny.cz> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> Message-ID: On Fri, 27 Jun 2008, Dan Hor?k wrote: > > Roy-Magne Mo p??e v P? 27. 06. 2008 v 18:22 +0200: > > Matthew Jurgens skreiv: > > > I am waiting for the release of the fedora Nagios v3 package and was > > > > > > wondering if I could get involved to help speed up the process? > > > > I've packaged Nagios 3 for my self and contacted Shawn Starr and asked > > if he was interested in the updates to the existing package. He replied > > that it wasn't interesting before the nagios 2 line was killed off. > > > > So, it seems like fedora has been debianized ;) > > > > But you can submit a package called nagios3 and when there will be no > conflicts with nagios then Fedora will have both. > > It amuses me that, for whatever reason, none of you have bothered to contact me about it and instead went to a list that already gets way to much traffic. My email address is: mmcgrath at fedoraproject.org If you're interested in getting nagios 3 ready and into Fedora, I could certainly use help with that. -Mike From clydekunkel7734 at cox.net Fri Jun 27 16:36:40 2008 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 27 Jun 2008 12:36:40 -0400 Subject: Xen kernel freezing during boot after upgrading from FC8 to FC9 In-Reply-To: <486514AF.6060704@gmail.com> References: <486514AF.6060704@gmail.com> Message-ID: <48651718.3000401@cox.net> Casimiro de Almeida Barreto wrote: > Hello, > > I've posted this before... but it seems it is not solved yet. > > After I upgraded from FC8 to FC9 Xen kernels are freezing during boot. > More precisely just after the message: (Xen) ... relinquishing VGA > The same problem happens with 2.6.25.3-1.fc9.i686 and 2.6.25.3-2.fc9.i686 > > Best regards, > > Casimiro Barreto > Same in current rawhide.... -- --------------------------------- Regards, Old Fart From rmo at sunnmore.net Fri Jun 27 16:47:53 2008 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Fri, 27 Jun 2008 18:47:53 +0200 Subject: Packaging of Nagios In-Reply-To: References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> Message-ID: <486519B9.9020900@sunnmore.net> Mike McGrath skreiv: > On Fri, 27 Jun 2008, Dan Hor?k wrote: > >> Roy-Magne Mo p??e v P? 27. 06. 2008 v 18:22 +0200: >>> Matthew Jurgens skreiv: >>>> I am waiting for the release of the fedora Nagios v3 package and was >>>> >>>> wondering if I could get involved to help speed up the process? >>> I've packaged Nagios 3 for my self and contacted Shawn Starr and asked >>> if he was interested in the updates to the existing package. He replied >>> that it wasn't interesting before the nagios 2 line was killed off. >>> >>> So, it seems like fedora has been debianized ;) >>> >> But you can submit a package called nagios3 and when there will be no >> conflicts with nagios then Fedora will have both. >> >> > > It amuses me that, for whatever reason, none of you have bothered to > contact me about it and instead went to a list that already gets way to > much traffic. My email address is: mmcgrath at fedoraproject.org > > If you're interested in getting nagios 3 ready and into Fedora, I could > certainly use help with that. Hi, I will register a bugzilla in a couple of hours with a upgrade request. The changes required to upgrade to Nagios 3 isn't all that big spec wise. There are some changes to the config format, so people should be aware when upgrading. I've been running this rpm in production for at least a month now. This is the spec file: http://www.sunnmore.net/div/nagios.spec This is the source rpm: http://www.sunnmore.net/div/nagios-3.0.3-1.src.rpm -- Roy-Magne Mo From csnook at redhat.com Fri Jun 27 16:49:26 2008 From: csnook at redhat.com (Chris Snook) Date: Fri, 27 Jun 2008 12:49:26 -0400 Subject: Xen kernel freezing during boot after upgrading from FC8 to FC9 In-Reply-To: <48651718.3000401@cox.net> References: <486514AF.6060704@gmail.com> <48651718.3000401@cox.net> Message-ID: <48651A16.4000301@redhat.com> Clyde E. Kunkel wrote: > Casimiro de Almeida Barreto wrote: >> Hello, >> >> I've posted this before... but it seems it is not solved yet. >> >> After I upgraded from FC8 to FC9 Xen kernels are freezing during boot. >> More precisely just after the message: (Xen) ... relinquishing VGA >> The same problem happens with 2.6.25.3-1.fc9.i686 and 2.6.25.3-2.fc9.i686 >> >> Best regards, >> >> Casimiro Barreto >> > > Same in current rawhide.... > F9 switched to using the upstream paravirt_ops infrastructure for Xen, so that the Xen kernels can keep in sync with the baremetal kernel, rather than lagging behind several releases. Unfortunately, there are still some features necessary to be a dom0 Xen host that have not yet been ported to paravirt_ops, so the F9 Xen kernel can't boot your physical box, though it'll run just fine under an F8 dom0. F10 is expected to have full dom0 support, using paravirt_ops, but for now, you'll either have to use F8 in your dom0, or use something like KVM that's fully merged. -- Chris From wwoods at redhat.com Fri Jun 27 16:53:18 2008 From: wwoods at redhat.com (Will Woods) Date: Fri, 27 Jun 2008 12:53:18 -0400 Subject: Xen kernel freezing during boot after upgrading from FC8 to FC9 In-Reply-To: <48651718.3000401@cox.net> References: <486514AF.6060704@gmail.com> <48651718.3000401@cox.net> Message-ID: <1214585598.19297.35.camel@metroid.rdu.redhat.com> On Fri, 2008-06-27 at 12:36 -0400, Clyde E. Kunkel wrote: > Casimiro de Almeida Barreto wrote: > > Hello, > > > > I've posted this before... but it seems it is not solved yet. > > > > After I upgraded from FC8 to FC9 Xen kernels are freezing during boot. > > More precisely just after the message: (Xen) ... relinquishing VGA > > The same problem happens with 2.6.25.3-1.fc9.i686 and 2.6.25.3-2.fc9.i686 F9 and Rawhide kernel-xen are not usable as a dom0 / Xen host. You can run them as Xen guests but they won't work on bare metal. Hopefully F10 will bring a working Xen dom0 kernel. Until then, if you want a Xen host, run F8 or RHEL or CentOS or something. See http://fedoraproject.org/wiki/Features/XenPvops and http://fedoraproject.org/wiki/Features/XenPvopsDom0 for more info. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From hunter at userfriendly.net Fri Jun 27 17:04:22 2008 From: hunter at userfriendly.net (Michael Weiner) Date: Fri, 27 Jun 2008 13:04:22 -0400 Subject: Packaging of Nagios In-Reply-To: <486519B9.9020900@sunnmore.net> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> <486519B9.9020900@sunnmore.net> Message-ID: On Fri, Jun 27, 2008 at 12:47 PM, Roy-Magne Mo wrote: > I will register a bugzilla in a couple of hours with a upgrade request. The > changes required to upgrade to Nagios 3 isn't all that big spec wise. There > are some changes to the config format, so people should be aware when > upgrading. > > I've been running this rpm in production for at least a month now. > > This is the spec file: > http://www.sunnmore.net/div/nagios.spec > > This is the source rpm: > http://www.sunnmore.net/div/nagios-3.0.3-1.src.rpm > > Looking at the spec file, it isnt clear to me why there is an initrd patch for nagios? Could you please shed a little more light on that for me, please? Thanks in advance Michael Weiner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Fri Jun 27 17:07:40 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jun 2008 09:07:40 -0800 Subject: Fedora 9 kernel configuration In-Reply-To: <63103.208.97.187.133.1214465204.squirrel@mail.fedoraproject.ro> References: <20080625143737.6792ABF2CF@postalmail-a5.g.dreamhost.com> <604aa7910806251657n34c451e2w3884defd3f09a76b@mail.gmail.com> <63103.208.97.187.133.1214465204.squirrel@mail.fedoraproject.ro> Message-ID: <604aa7910806271007t3907b346mf1e7b11663e27d9a@mail.gmail.com> On Wed, Jun 25, 2008 at 11:26 PM, wrote: > Hello, > > You are right in the /boot config file everything is ok. > > But if you install the kernel source and look in the config-debug, > config-x86 and so on files non of them contain the 3 values all toghether. You are simply interpreting what you are seeing in the kernel source package incorrectly. To understand how those files are used to compile the final config files, you would need to parse all of the build logic in the spec file that comes in the kernel srpm. While instructive, its not what you want. The final config file used to build each binary kernel is shipped in the binary kernel package and placed in /boot/ on kernel install. That is the only file you need to typically review when looking for specific kernel config settings. -jef From rmo at sunnmore.net Fri Jun 27 17:12:06 2008 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Fri, 27 Jun 2008 19:12:06 +0200 Subject: Packaging of Nagios In-Reply-To: References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> <486519B9.9020900@sunnmore.net> Message-ID: <48651F66.90606@sunnmore.net> Michael Weiner skreiv: > On Fri, Jun 27, 2008 at 12:47 PM, Roy-Magne Mo > wrote: > > I will register a bugzilla in a couple of hours with a upgrade > request. The changes required to upgrade to Nagios 3 isn't all that > big spec wise. There are some changes to the config format, so > people should be aware when upgrading. > > I've been running this rpm in production for at least a month now. > > This is the spec file: > http://www.sunnmore.net/div/nagios.spec > > This is the source rpm: > http://www.sunnmore.net/div/nagios-3.0.3-1.src.rpm > > > Looking at the spec file, it isnt clear to me why there is an initrd > patch for nagios? Could you please shed a little more light on that for > me, please? These changes were carried on from the existing spec-file. The initrd patch is for the initscript. The diff between my nagios.spec and the existing nagios-2.12-3 is here: http://www.sunnmore.net/div/nagios.spec.diff From hunter at userfriendly.net Fri Jun 27 17:18:52 2008 From: hunter at userfriendly.net (Michael Weiner) Date: Fri, 27 Jun 2008 13:18:52 -0400 Subject: Packaging of Nagios In-Reply-To: <48651F66.90606@sunnmore.net> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> <486519B9.9020900@sunnmore.net> <48651F66.90606@sunnmore.net> Message-ID: On Fri, Jun 27, 2008 at 1:12 PM, Roy-Magne Mo wrote: > Michael Weiner skreiv: > >> Looking at the spec file, it isnt clear to me why there is an initrd patch >> for nagios? Could you please shed a little more light on that for me, >> please? >> > > These changes were carried on from the existing spec-file. The initrd patch > is for the initscript. > > The diff between my nagios.spec and the existing nagios-2.12-3 is here: > http://www.sunnmore.net/div/nagios.spec.diff > Thanks, the diff is what i was looking for. And the initrd naming convention threw me off as its not really related to initrd, but an init script :) Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From devrim at commandprompt.com Fri Jun 27 17:37:01 2008 From: devrim at commandprompt.com (=?iso-8859-9?Q?Devrim_G=DCND=DCZ?=) Date: Fri, 27 Jun 2008 10:37:01 -0700 (PDT) Subject: Devrim is going to vacation Message-ID: Hi, I'm going to vacation for 2 weeks. I have Internet connection, but I have limited (no) access to my e-mail. I will update packages whenever necessary. You may find me online at freenode , my nickname is devrimgunduz . Regards, -- Devrim G?ND?Z RHCE, PostgreSQL Consultant @ Command Prompt, Inc. http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org From overholt at redhat.com Fri Jun 27 17:29:39 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 27 Jun 2008 13:29:39 -0400 Subject: Who wants to take over the developer spin? Message-ID: <20080627172938.GA1565@redhat.com> Hi, I apologize but I just don't have the time to maintain the developer spin. There's really no transition to be done since I always just funnelled kickstart changes through Jeremy :) I don't think it'll require much work, since the list of packages was pretty decent when it was initially created for F8. I had assumed it was going to be automatically done for Fedora 9 without changes but I haven't kept up with the changes happening with spins and don't know the current status. Andrew From arjan at infradead.org Fri Jun 27 17:48:17 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 27 Jun 2008 10:48:17 -0700 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080627104817.6c47de51@infradead.org> On Fri, 27 Jun 2008 17:13:24 +0100 Richard Hughes wrote: > At the moment we set: > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > This is not ideal from a power-saving point of view. > > In an ideal world we would: > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better > job on all workloads > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in > userspace that needs this sort of control, and if we did, the latency > would be horrible > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just > changed to something else by cpuspeed. You really don't want to be > using USERSPACE at all. > > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. > > Comments? > I totally agree with your suggestions. -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From overholt at redhat.com Fri Jun 27 18:14:58 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 27 Jun 2008 14:14:58 -0400 Subject: /usr/share/eclipse/* -> %{_libdir}/eclipse/ Message-ID: <20080627181458.GB3604@redhat.com> Hi, In the past we've struggled with multilib issues in the Eclipse SDK package. Examples include having to re-pack every JAR to have a common timestamp, shuffling arch-specific JARs off to %{_libdir} thus causing headaches with upstream mechanisms (which I'm concerned will continue with the new version), etc. I just found out today that Debian ships everything in %{_libdir}/eclipse to avoid these issues. I'm proposing we do the same for Fedora 10 and beyond. Pros: - self-contained installation like upstream - dramatically speeds up builds - remove potential for bugs with the multiple locations - looks like an upstream download - consistency with other distributions Cons: - larger disk footprint for multilib installations (on the order of 100 MB ... although the vast majority of users don't use both) Does anyone have any thoughts on this? Thanks, Andrew From sundaram at fedoraproject.org Fri Jun 27 18:48:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 28 Jun 2008 00:18:08 +0530 Subject: Who wants to take over the developer spin? In-Reply-To: <20080627172938.GA1565@redhat.com> References: <20080627172938.GA1565@redhat.com> Message-ID: <486535E8.4070009@fedoraproject.org> Andrew Overholt wrote: > Hi, > > I apologize but I just don't have the time to maintain the developer > spin. There's really no transition to be done since I always just > funnelled kickstart changes through Jeremy :) > > I don't think it'll require much work, since the list of packages was > pretty decent when it was initially created for F8. I had assumed it > was going to be automatically done for Fedora 9 without changes but I > haven't kept up with the changes happening with spins and don't know the > current status. I will be working with Siddharth Upmanyu (cc'ed) who has volunteered to start maintaining it. Rahul From overholt at redhat.com Fri Jun 27 18:53:32 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 27 Jun 2008 14:53:32 -0400 Subject: Who wants to take over the developer spin? In-Reply-To: <486535E8.4070009@fedoraproject.org> References: <20080627172938.GA1565@redhat.com> <486535E8.4070009@fedoraproject.org> Message-ID: <20080627185331.GA6041@redhat.com> > I will be working with Siddharth Upmanyu (cc'ed) who has volunteered to > start maintaining it. Thanks! Andrew From walters at verbum.org Fri Jun 27 18:55:21 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 27 Jun 2008 14:55:21 -0400 Subject: Who wants to take over the developer spin? In-Reply-To: <20080627172938.GA1565@redhat.com> References: <20080627172938.GA1565@redhat.com> Message-ID: On Fri, Jun 27, 2008 at 1:29 PM, Andrew Overholt wrote: > Hi, > > I apologize but I just don't have the time to maintain the developer > spin. There's really no transition to be done since I always just > funnelled kickstart changes through Jeremy :) > Is there a way we could redesign it such that it was trivial to turn the regular desktop install into the full developer install? The answer here might just be "comps" and some packagekit UI work. Or are there other customizations besides the package set? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreiser at BitWagon.com Fri Jun 27 19:07:29 2008 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 27 Jun 2008 12:07:29 -0700 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <48653A71.80705@BitWagon.com> Richard Hughes wrote: > In an ideal world we would: > * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed > to something else by cpuspeed. You really don't want to be using > USERSPACE at all. How can an administrator set a known constant frequency, so that the CPU might be able to deliver the same amount of work per unit time, over a span of half an hour? Some performance measurement and tuning is much simpler when this is so. -- From nicolas.mailhot at laposte.net Fri Jun 27 19:17:23 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Jun 2008 21:17:23 +0200 Subject: /usr/share/eclipse/* -> %{_libdir}/eclipse/ In-Reply-To: <20080627181458.GB3604@redhat.com> References: <20080627181458.GB3604@redhat.com> Message-ID: <1214594243.12046.10.camel@rousalka.okg> Le vendredi 27 juin 2008 ? 14:14 -0400, Andrew Overholt a ?crit : > Does anyone have any thoughts on this? I'd rather you worked with Fernando Nasser and the other guys in Fedora's java place on common jar deployment rules, instead of reinventing the private app root dead-end that makes sharing resources next to impossible and encourages library forking and duplication -- 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 davej at redhat.com Fri Jun 27 19:18:51 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 27 Jun 2008 15:18:51 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080627191851.GF7061@redhat.com> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > At the moment we set: > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > This is not ideal from a power-saving point of view. > > In an ideal world we would: > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job > on all workloads > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace > that needs this sort of control, and if we did, the latency would be > horrible needed for the cpuspeed governor > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed > to something else by cpuspeed. You really don't want to be using > USERSPACE at all. Not all CPUs are capable of running ondemand because of the latency they incur during transitions. > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. I don't follow this. Can you show whatever numbers you have that you're basing this on ? Dave -- http://www.codemonkey.org.uk From alan at redhat.com Fri Jun 27 19:28:39 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 27 Jun 2008 15:28:39 -0400 Subject: Packaging of Nagios In-Reply-To: References: Message-ID: <20080627192839.GC29550@devserv.devel.redhat.com> On Fri, Jun 27, 2008 at 12:33:59PM -0400, Shawn Starr wrote: > It's not that. If we want to drop Nagios 2.x how will people upgrade properly? We could make a nagios3 package but my worry is what depends on Nagios (I haven't seen the list yet). Wrong way around I think ? Package nagios-3.x.x and nagios-compat- That way we end up in future with sensible package names and it follows the standard style From drago01 at gmail.com Fri Jun 27 19:16:46 2008 From: drago01 at gmail.com (drago01) Date: Fri, 27 Jun 2008 21:16:46 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes wrote: > You really don't want to be using > USERSPACE at all. seems like cpufreq-applet uses it.... From overholt at redhat.com Fri Jun 27 19:36:01 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 27 Jun 2008 15:36:01 -0400 Subject: /usr/share/eclipse/* -> %{_libdir}/eclipse/ In-Reply-To: <1214594243.12046.10.camel@rousalka.okg> References: <20080627181458.GB3604@redhat.com> <1214594243.12046.10.camel@rousalka.okg> Message-ID: <20080627193601.GA7756@redhat.com> * Nicolas Mailhot [2008-06-27 15:17]: > Le vendredi 27 juin 2008 ? 14:14 -0400, Andrew Overholt a ?crit : > > > Does anyone have any thoughts on this? > > I'd rather you worked with Fernando Nasser and the other guys in > Fedora's java place on common jar deployment rules, instead of > reinventing the private app root dead-end that makes sharing resources > next to impossible and encourages library forking and duplication The JARs are 99% application-specific so putting them into a subdirectory makes sense to me and follows the guidelines we have in place. We have no library forking or duplication of the dependent JARs, either. Andrew From overholt at redhat.com Fri Jun 27 19:37:20 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 27 Jun 2008 15:37:20 -0400 Subject: Who wants to take over the developer spin? In-Reply-To: References: <20080627172938.GA1565@redhat.com> Message-ID: <20080627193719.GB7756@redhat.com> * Colin Walters [2008-06-27 14:55]: > On Fri, Jun 27, 2008 at 1:29 PM, Andrew Overholt wrote: > > Hi, > > I apologize but I just don't have the time to maintain the developer > spin. There's really no transition to be done since I always just > funnelled kickstart changes through Jeremy :) > > > Is there a way we could redesign it such that it was trivial to turn the > regular desktop install into the full developer install? > > The answer here might just be "comps" and some packagekit UI work. Or are > there other customizations besides the package set? There was one small customization beside the package set which could easily be thrown away. Ideas were tossed around for the longer term ideas like pre-set httpd for development, etc. but none of it came to fruition. Andrew From sstarr at platform.com Fri Jun 27 19:47:03 2008 From: sstarr at platform.com (Shawn Starr) Date: Fri, 27 Jun 2008 15:47:03 -0400 Subject: Packaging of Nagios Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Alan Cox > Sent: Friday, June 27, 2008 3:29 PM > To: Development discussions related to Fedora > Subject: Re: Packaging of Nagios > > > On Fri, Jun 27, 2008 at 12:33:59PM -0400, Shawn Starr wrote: > > It's not that. If we want to drop Nagios 2.x how will > people upgrade properly? We could make a nagios3 package but > my worry is what depends on Nagios (I haven't seen the list yet). > > Wrong way around I think ? > > Package nagios-3.x.x and nagios-compat- > > That way we end up in future with sensible package names and > it follows the > standard style Yes, that's what we're going to do. We're going to drop Nagios 2.x altogether for Fedora only (EPEL will remain at 2.x for now) so the nagios packages themselves will not change and the standard style remains. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From hughsient at gmail.com Fri Jun 27 20:01:34 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jun 2008 21:01:34 +0100 Subject: kernel module options for cpufreq In-Reply-To: References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <1214596894.3394.34.camel@hughsie-work> On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > wrote: > > You really don't want to be using > > USERSPACE at all. > > seems like cpufreq-applet uses it.... Sure, it shouldn't. If you're using userspace for thermal or latency reasons, then a setuid applet is totally the wrong way to achieve both of these :-) Maybe we can just use these as loadable modules (i.e. not built default) rather than built-in and loaded by default. DaveJ, do these suggestions seem acceptable? Richard. From wart at kobold.org Fri Jun 27 20:19:25 2008 From: wart at kobold.org (Michael Thomas) Date: Fri, 27 Jun 2008 13:19:25 -0700 Subject: Packaging of Nagios In-Reply-To: <486519B9.9020900@sunnmore.net> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> <486519B9.9020900@sunnmore.net> Message-ID: <48654B4D.9020706@kobold.org> Roy-Magne Mo wrote: > Mike McGrath skreiv: >> On Fri, 27 Jun 2008, Dan Hor?k wrote: >> >>> Roy-Magne Mo p??e v P? 27. 06. 2008 v 18:22 +0200: >>>> Matthew Jurgens skreiv: >>>>> I am waiting for the release of the fedora Nagios v3 package and was >>>>> >>>>> wondering if I could get involved to help speed up the process? >>>> I've packaged Nagios 3 for my self and contacted Shawn Starr and asked >>>> if he was interested in the updates to the existing package. He replied >>>> that it wasn't interesting before the nagios 2 line was killed off. >>>> >>>> So, it seems like fedora has been debianized ;) >>>> >>> But you can submit a package called nagios3 and when there will be no >>> conflicts with nagios then Fedora will have both. >>> >>> >> >> It amuses me that, for whatever reason, none of you have bothered to >> contact me about it and instead went to a list that already gets way to >> much traffic. My email address is: mmcgrath at fedoraproject.org >> >> If you're interested in getting nagios 3 ready and into Fedora, I could >> certainly use help with that. > > Hi, > I will register a bugzilla in a couple of hours with a upgrade request. > The changes required to upgrade to Nagios 3 isn't all that big spec > wise. There are some changes to the config format, so people should be > aware when upgrading. Does/will Nagios3 provide some config file migration tool to ease the pain for folks who want to migrate from v2 to v3? Or are the changes simple enough to perform by hand, even for large Nagios installations? --Wart From drago01 at gmail.com Fri Jun 27 20:56:04 2008 From: drago01 at gmail.com (drago01) Date: Fri, 27 Jun 2008 22:56:04 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214596894.3394.34.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes wrote: > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: >> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes >> wrote: >> > You really don't want to be using >> > USERSPACE at all. >> >> seems like cpufreq-applet uses it.... > > Sure, it shouldn't. If you're using userspace for thermal or latency > reasons, then a setuid applet is totally the wrong way to achieve both > of these :-) its not a setuid applet .. something seems to allow non root to do this (hal? consolekit? pam? udev? .. dunno) From skvidal at fedoraproject.org Fri Jun 27 21:16:22 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 27 Jun 2008 17:16:22 -0400 Subject: Who wants to take over the developer spin? In-Reply-To: References: <20080627172938.GA1565@redhat.com> Message-ID: <1214601382.28151.5.camel@rosebud> On Fri, 2008-06-27 at 14:55 -0400, Colin Walters wrote: > On Fri, Jun 27, 2008 at 1:29 PM, Andrew Overholt > wrote: > Hi, > > I apologize but I just don't have the time to maintain the > developer > spin. There's really no transition to be done since I always > just > funnelled kickstart changes through Jeremy :) > > Is there a way we could redesign it such that it was trivial to turn > the regular desktop install into the full developer install? > > The answer here might just be "comps" and some packagekit UI work. Or > are there other customizations besides the package set? > The answer is just 'comps', yah. yum groupinstall -sv From bnocera at redhat.com Fri Jun 27 22:47:31 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 27 Jun 2008 23:47:31 +0100 Subject: kernel module options for cpufreq In-Reply-To: References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: <1214606851.4435.73.camel@cookie.hadess.net> On Fri, 2008-06-27 at 22:56 +0200, drago01 wrote: > On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes wrote: > > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > >> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > >> wrote: > >> > You really don't want to be using > >> > USERSPACE at all. > >> > >> seems like cpufreq-applet uses it.... > > > > Sure, it shouldn't. If you're using userspace for thermal or latency > > reasons, then a setuid applet is totally the wrong way to achieve both > > of these :-) > > its not a setuid applet .. something seems to allow non root to do > this (hal? consolekit? pam? udev? .. dunno) It currently uses consolehelper to get root. IMO, it shouldn't allow setting frequencies at all. From davej at redhat.com Fri Jun 27 23:31:34 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 27 Jun 2008 19:31:34 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214596894.3394.34.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: <20080627233134.GA28666@redhat.com> On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote: > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > > wrote: > > > You really don't want to be using > > > USERSPACE at all. > > > > seems like cpufreq-applet uses it.... > > Sure, it shouldn't. If you're using userspace for thermal or latency > reasons, then a setuid applet is totally the wrong way to achieve both > of these :-) > > Maybe we can just use these as loadable modules (i.e. not built default) > rather than built-in and loaded by default. > > DaveJ, do these suggestions seem acceptable? Having the userspace governor built-in means absolutely nothing in terms of overhead, until something in userspace actually uses it. When the cpuspeed init script starts up, the first thing it does is check if the CPU is on the whitelist for using ondemand, and if so, it starts up ondemand. Not a single line of the userspace governor code gets run in this case. The only time the above isn't true is when the CPU isn't on that whitelist, when it's incapable of running ondemand, in which case we need to use.. ta-da... userspace, and then we start the cpuspeed process. Again, if you're seeing overhead from using userspace, it's due to your CPU being crap. There's nothing we can do about it. Whilst ondemand will load on some of these CPUs, the associated overhead of switching is very noticable on benchmarks. Even 'conservative' was too demanding for some of the challenged CPUs. 'crap' here doesn't mean really old stuff too. Any pre-centrino Intel CPU, any VIA CPU before Nehemiah generation, all mobile Athlons. We're using ondemand on all K8's too, but the first generation also sucked iirc, but we're just sucking it up because a) it makes the already convoluted startup script even more messy and b) no-one can remember which stepping/models were affected. Dave -- http://www.codemonkey.org.uk From Bl0ngo067 at aim.com Sat Jun 28 02:31:36 2008 From: Bl0ngo067 at aim.com (brad longo) Date: Fri, 27 Jun 2008 22:31:36 -0400 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270424m6cbe63c0t754689e4af3063f3@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> <1214561771.3494.24.camel@eagle.danny.cz> <5f6f8c5f0806270424m6cbe63c0t754689e4af3063f3@mail.gmail.com> Message-ID: <4865A288.4040609@aim.com> Joshua C. wrote: > I have F8 and I like it. F9 is better but there are still some issue > for me. My ati card isn't resonably supported by the free ati driver. > the fglrx I don't like either and other minor problems (acer hk, > kde359 is still better than 404 I think, etc). therefore I'm kind of > "stuck" with f8. > > I'm still waiting for the upgrade to F9. > > > 2008/6/27 Dan Hor?k >: > > > Joshua C. p??e v P? 27. 06. 2008 v 11:28 +0200: > > Can someone backport some of the F9 packages to F8? Especially > some of > > the following: > > firefox 3 > > openoffice.org 2.4.1 (3 beta) > > kdebase 4.0.83 beta > > mesa > > xorg-x11-drv-ati > > pulseaudio > > gdm > > gcc > > ............................ > > > > and other "basic" packages. It would be nice to have up-to-date F8. > > And what will be then the reason to update from F-8 to F-9? > > > Dan > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I thought about creating an rpm for Firefox 3.0 for Fedora 8 because my brother's computer doesn't like Fedora 9 and Firefox 3.0 better suits his needs than Firefox 2.0. Whether or not v2 is better than v3 is up to personal opinion, in my opinion, and I understand your ATI card issue as well because I have the same issue. Anyway if I get around to creating the rpm, and it works, I'll send you the rpm. -- Brad From kevin.kofler at chello.at Sat Jun 28 04:04:15 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jun 2008 04:04:15 +0000 (UTC) Subject: Backporting some F9 packages to F8 References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> <1214561771.3494.24.camel@eagle.danny.cz> <5f6f8c5f0806270424m6cbe63c0t754689e4af3063f3@mail.gmail.com> <4865A288.4040609@aim.com> Message-ID: brad longo aim.com> writes: > I thought about creating an rpm for Firefox 3.0 for Fedora 8 because my > brother's computer doesn't like Fedora 9 and Firefox 3.0 better suits > his needs than Firefox 2.0. Whether or not v2 is better than v3 is up > to personal opinion, in my opinion, and I understand your ATI card issue > as well because I have the same issue. Anyway if I get around to > creating the rpm, and it works, I'll send you the rpm. You don't have to create your own RPM, Remi Collet already dit it: http://blog.famillecollet.com/ Kevin Kofler From rawhide at fedoraproject.org Sat Jun 28 10:13:31 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 28 Jun 2008 10:13:31 +0000 (UTC) Subject: rawhide report: 20080628 changes Message-ID: <20080628101331.8DB45209D23@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080627/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080628/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package jbrout Photo manager, written in python/pygtk New package libmatthew-java A few useful Java libraries New package mediawiki-ParserFunctions Enhances the Mediawiki parser with logical functions New package nethogs A tool resembling top for network traffic New package python-pylons Pylons web framework New package rdma Infiniband/iWARP Kernel Module Initializer Removed package fonts-sinhala Updated Packages: Pound-2.4-2.fc10 ---------------- * Fri Jun 27 18:00:00 2008 Dennis Gilmore 2.4-2 - sparc arches dont have tcmalloc anthy-9100e-3.fc10 ------------------ * Fri Jun 27 18:00:00 2008 Akira TAGOH - 9100e-3 - Fix a segfault with some words containing vu. (#452779) audacious-1.5.1-2.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Ralf Ertzinger 1.5.1-2 - Add Requires: dbus-glib-devel to audacious-devel bluez-libs-3.34-1.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 - Bastien Nocera - 3.34-1 - Update to 3.34 bluez-utils-3.34-1.fc10 ----------------------- * Fri Jun 27 18:00:00 2008 - Bastien Nocera - 3.34-1 - Update to 3.34 cairo-dock-1.6.1-0.1.svn1148_trunk.fc10 --------------------------------------- * Sat Jun 28 18:00:00 2008 Mamoru Tasaka - rev. 1148 clutter-gtk-0.6.1-1.fc10 ------------------------ * Thu Jun 26 18:00:00 2008 Colin Walters 0.6.1-1 - Update to 0.6.1 so we can make tweet go - Loosen files globs so we don't have to touch them every version dovecot-1.1.1-2.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Dan Horak - 1:1.1.1-2 - update default settings to listen on both IPv4 and IPv6 instead of IPv6 only ecryptfs-utils-50-0.fc10 ------------------------ * Fri Jun 27 18:00:00 2008 Mike Halcrow 50-0 - Add umount.ecryptfs_private symlink - Add pam_mount session hooks for mount and unmount * Fri Jun 27 18:00:00 2008 Eric Sandeen 49-1 - build with TrouSerS key module * Fri Jun 27 18:00:00 2008 Eric Sandeen 49-0 - New upstream version fetchmail-6.3.8-7.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Vitezslav Crhonek - 6.3.8-7 - Fix CVE-2008-2711 gcin-1.4.2-2.fc10 ----------------- * Fri Jun 27 18:00:00 2008 Chung-Yen Chang - 1.4.2-2 - update gcin.conf (change gcin to /usr/bin/gcin) - add imsettings to Requires - fix bug #453085 gnome-commander-1.2.7-0.1.svn1862_trunk.fc10 -------------------------------------------- * Sat Jun 28 18:00:00 2008 Mamoru Tasaka - try rev 1862 ice-3.3.0-3.fc10 ---------------- kazehakase-0.5.4-6.svn3506_trunk.fc10 ------------------------------------- * Sat Jun 28 18:00:00 2008 Mamoru Tasaka - 0.5.4-6.svn3506_trunk - Try rev 3506 - Workaround for bug 447444 (xulrunner vs hunspell conflict) kde-l10n-4.0.83-2.fc10 ---------------------- * Sat Jun 28 18:00:00 2008 Kevin Kofler 4.0.83-2 - disable Serbian for now, it's broken - fix file list for Ukranian * Thu Jun 19 18:00:00 2008 Than Ngo 4.0.83-1 - 4.0.83 (beta2) kdeaccessibility-4.0.84-1.fc10 ------------------------------ * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdeadmin-4.0.84-1.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdeartwork-4.0.84-1.fc10 ------------------------ * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdebase-4.0.84-1.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdebase-runtime-4.0.84-1.fc10 ----------------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdebase-workspace-4.0.84-1.fc10 ------------------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 * Fri Jun 27 18:00:00 2008 Kevin Kofler 4.0.83-2 - port and apply kde#154119/kde#158301 patch for moving icons on panel (#439587) kdebindings-4.0.84-2.fc10 ------------------------- * Sat Jun 28 18:00:00 2008 Kevin Kofler 4.0.84-2 - fix Python bindings for Phonon and Soprano * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdeedu-4.0.84-1.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdegames-4.0.84-1.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdegraphics-4.0.84-1.fc10 ------------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdelibs-4.0.84-1.fc10 --------------------- kdemultimedia-4.0.84-1.fc10 --------------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdenetwork-4.0.84-1.fc10 ------------------------ * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdepim-4.0.84-1.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdepimlibs-4.0.84-1.fc10 ------------------------ * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdeplasmoids-4.0.84-1.fc10 -------------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdesdk-4.0.84-1.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdetoys-4.0.84-1.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 kdeutils-4.0.84-1.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 4.0.84-1 - 4.0.84 koffice-1.9.95.8-2.fc10 ----------------------- * Fri Jun 27 18:00:00 2008 Rex Dieter 1.9.95-8.2 - respin (eviv2) libdrm-2.4.0-0.13.fc10 ---------------------- * Wed Jun 18 18:00:00 2008 Dave Airlie 2.4.0-0.13 - add modeset ctl interface fix * Wed May 28 18:00:00 2008 Dave Airlie 2.4.0-0.12 - add r500 support patch * Tue Apr 29 18:00:00 2008 Adam Jackson 2.4.0-0.11 - libdrm-2.4.0-no-bc.patch: Delete the /proc/dri BC code. It's not needed, and the kernel implementation is sufficiently broken that we should avoid ever touching it. libevent-1.4.4-1.fc10 --------------------- * Mon Jun 2 18:00:00 2008 Steve Dickson 1.4.4-1 - Updated to latest stable upstream version 1.4.4-stable libgssglue-0.1-6.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Steve Dickson 0.1-6 - Changed gssapi_mech.conf to use libgssapi_krb5.so.2 instead of libgssapi_krb5.so (bz 447503) libnl-1.1-5.fc10 ---------------- * Fri Jun 27 18:00:00 2008 Dan Williams - 1.1-5 - Build documentation in -devel package (rh #452646) * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 1.1-4 - fix license tag libpcap-0.9.8-3.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Miroslav Lichvar 14:0.9.8-3 - use CFLAGS when linking (#445682) libtirpc-0.1.8-2.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Steve Dickson 0.1.8-2 - Added super-H(sh3,4) architecture support (bz 446559) libxklavier-3.6-2.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Ray Strode - 3.6-2 - Apply upstream patch to fix libxklavier crash (bug 452966) liferea-1.4.16b-3.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Steven Parrish - 1.4.16b - removed uneeded patch files * Fri Jun 27 18:00:00 2008 Steven Parrish - 1.4.16b - Cleaned up spec file and removed support for firefox-devel lklug-fonts-0.2.2-6.fc10 ------------------------ * Fri Jun 27 18:00:00 2008 Rahul Bhalerao - 0.2.2-6 - Updated spec to obsolete fonts-sinhala lvm2-2.02.39-3.fc10 ------------------- * Fri Jun 27 18:00:00 2008 Alasdair Kergon > - 2.02.39-3 - Fix up cache for PVs without mdas after consistent VG metadata is processed. - Update validation of safe mirror log type conversions in lvconvert. - Fix lvconvert to disallow snapshot and mirror combinations. - Fix reporting of LV fields alongside unallocated PV segments. - Add --unquoted and --rows to reporting tools. - Avoid undefined status code after _memlock commands in lvm shell. - Fix and improve readahead 'auto' calculation for stripe_size. - Fix lvchange output for -r auto setting if auto is already set. - Fix add_mirror_images not to dereference uninitialized log_lv upon failure. - Add --force to lvextend and lvresize. - Fix vgchange to not activate component mirror volumes directly. mcabber-0.9.7-1.fc10 -------------------- * Sat Jun 28 18:00:00 2008 Michael Fleming - 0.9.7-1 - Version upgrade (#bz 452437) - Build against GNUTLS 2.4 mfiler3-1.1.1-1.fc10 -------------------- * Sat Jun 28 18:00:00 2008 Mamoru Tasaka - 1.1.1-1 - 1.1.1 mrtg-2.16.2-1.fc10 ------------------ * Fri Jun 27 18:00:00 2008 Vitezslav Crhonek - 2.16.2-1 - Update to 2.16.2 - Mark /etc/crond.d/mrtg file as "noreplace" to keep current setup during mrtg update Related: #391261 - Fix mrtg complains of undefined subroutine AF_UNSPEC Resolves: #451783 msmtp-1.4.15-1.fc10 ------------------- * Fri Jun 27 18:00:00 2008 Nikolay Vladimriov - 1.4.15-1 - new upstream release - rebuild for new gnutls * Sat Apr 19 18:00:00 2008 Nikolay Vladimirov - 1.4.14-1 - new upstream release nemiver-0.5.4-1.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Peter Gordon - 0.5.4-1 - Update to new upstream release (0.5.4) - Rename -devel subpackage to -headers and adjust the %description accordingly. (It no longer contains any shared library symlinks or pkgconfig data; and thus would not be multilib-friendly. We can't put it in the main package due to its additional *-devel dependencies. Finally, upstream has said that nothing should really be using the libnemivercommon API yet anyway.) - Drop the libnemiver global library patch (fixed upstream)L - make-libnemivercommon-global-lib.patch nfs-utils-1.1.2-9.fc10 ---------------------- * Fri Jun 27 18:00:00 2008 Steve Dickson 1.1.2-9 - Removed the nfslock service start/stop from %post section (bz 453046) nfs-utils-lib-1.1.1-4.fc10 -------------------------- * Fri Jun 27 18:00:00 2008 Steve Dickson 1.1.1-4 - In idmapd.conf, commented out 'Domain' so DNS will be used to define the domainname. (bz 447237) perl-Log-Dispatch-FileRotate-1.18-1.fc10 ---------------------------------------- * Fri Jun 27 18:00:00 2008 Ralf Cors??pius - 1.18-1 - Upstream update. - Add --with-tests. perl-XML-Generator-DBI-1.00-5.fc10 ---------------------------------- * Fri Jun 27 18:00:00 2008 Xavier Bachelot - 1.00-5 - Add missing Requires on perl and tidy "find" argument order (RHBZ#453100). policycoreutils-2.0.49-10.fc10 ------------------------------ * Tue Jun 24 18:00:00 2008 Dan Walsh 2.0.49-10 - Fix spelling of enforcement prelude-manager-0.9.13-1.fc10 ----------------------------- * Fri Jun 27 18:00:00 2008 Steve Grubb 0.9.13-1 - new upstream version 0.9.13 - Prelude-Manager-SMTP plugin is now included rpcbind-0.1.5-4.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Steve Dickson 0.1.5-4 - Removed the documentation about the non-existent '-L' flag (bz 446915) * Fri Jun 27 18:00:00 2008 Steve Dickson 0.1.5-3 - Set password and service lookups to be local (bz 447092) schroedinger-1.0.3-1.fc10 ------------------------- * Fri Jun 27 18:00:00 2008 Jeffrey C. Ollie - 1.0.3-1 - Update to 1.0.3. - Update URLs. selinux-policy-3.4.2-8.fc10 --------------------------- * Thu Jun 26 18:00:00 2008 Dan Walsh 3.4.2-8 - Allow vpnc to run ifconfig spamassassin-3.2.5-1.fc10 ------------------------- * Fri Jun 27 18:00:00 2008 Warren Togami - 3.2.5-1 - 3.2.5 starplot-0.95.5-1.fc10 ---------------------- * Sat Jun 28 18:00:00 2008 Debarshi Ray - 0.95.5-1 - Version bump to 0.95.5. Closes Red Hat Bugzilla bug #446948. - .desktop file, and docdir and gcc-4.3 patches included by upstream. vinagre-2.23.4-2.fc10 --------------------- * Wed Jun 25 18:00:00 2008 - Bastien Nocera - 2.23.4-2 - Rebuild * Tue Jun 17 18:00:00 2008 - Bastien Nocera - 2.23.4-1 - Update to 2.23.4 - Fix URL (#451746) weechat-0.2.6-4.fc10 -------------------- * Fri Jun 27 18:00:00 2008 Paul P. Komkoff Jr - 0.2.6-4 - rebuild because of ssl/tls deps xen-3.2.0-15.fc10 ----------------- * Fri Jun 27 18:00:00 2008 Markus Armbruster - 3.2.0-15.fc10 - Re-enable QEMU image format auto-detection, without the security loopholes xenwatch-0.5.2-4.fc10 --------------------- * Fri Jun 27 18:00:00 2008 Richard W.M. Jones - 0.5.2-4 - Rebuild against new gnutls library. xorg-x11-drv-openchrome-0.2.902-8.fc10 -------------------------------------- * Mon Jun 23 18:00:00 2008 Xavier Bachelot - 0.2.902-8 - New version of the panel and hw cursor patch. Summary: Added Packages: 6 Removed Packages: 1 Modified Packages: 66 Broken deps for i386 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.i386 requires libevent-1.3e.so.1 bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 memcached-1.2.4-4.fc9.i386 requires libevent-1.3e.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.i386 requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.i386 requires libevent-1.3e.so.1 perl-Event-Lib-1.03-2.fc10.i386 requires libevent-1.3e.so.1 scanssh-2.1-16.fc9.i386 requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 trickle-1.07-3.fc10.i386 requires libevent-1.3e.so.1 wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-gnome-1.0.0-2.fc9.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) memcached-1.2.4-4.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) perl-Event-Lib-1.03-2.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) scanssh-2.1-16.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) trickle-1.07-3.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.ppc requires libevent-1.3e.so.1 bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) memcached-1.2.4-4.fc9.ppc requires libevent-1.3e.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.ppc requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.ppc requires libevent-1.3e.so.1 perl-Event-Lib-1.03-2.fc10.ppc requires libevent-1.3e.so.1 scanssh-2.1-16.fc9.ppc requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 trickle-1.07-3.fc10.ppc requires libevent-1.3e.so.1 wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot memcached-1.2.4-4.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) mysql-proxy-0.6.1-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) perl-Event-Lib-1.03-2.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scanssh-2.1-16.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) trickle-1.07-3.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From hughsient at gmail.com Sat Jun 28 11:17:51 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 28 Jun 2008 12:17:51 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080627191851.GF7061@redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080627191851.GF7061@redhat.com> Message-ID: <1214651871.3963.21.camel@hughsie-work> On Fri, 2008-06-27 at 15:18 -0400, Dave Jones wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > At the moment we set: > > > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > > > This is not ideal from a power-saving point of view. > > > > In an ideal world we would: > > > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job > > on all workloads > > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace > > that needs this sort of control, and if we did, the latency would be > > horrible > > needed for the cpuspeed governor Sure, I might have been a bit hasty in saying _remove_ - I don't really care about old CPU types but I appreciate lots of people do. > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > > want to be running this on all systems that support it > > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed > > to something else by cpuspeed. You really don't want to be using > > USERSPACE at all. > > Not all CPUs are capable of running ondemand because of the latency they > incur during transitions. Right, isn't the latency exported by the kernel? Surely it's a userspace decision (policy) if the latency is acceptable? The little tool Matthew and I prototyped yesterday allows an admin to tweak the latency they want in the whole system, and depending on the latency acceptable, different things like ALPM, ASPM and the governor are put in different modes. Obviously these new switches help in powersaving (lots) but each add appreciable latency which may be unacceptable. > > Matthew Garrett and I are working on a latency profile for power > > management, and having all these modules potentially loaded is bad. > > I don't follow this. Can you show whatever numbers you have that you're > basing this on ? Well, not bad from a speed point of view, bad from a complexity view. If we compile in ondemand, performance and userspace then we can leave it up to policy in the system to decide what makes sense. The policy in userspace can get the latency of the ondemand change and make a decision on that. Some of the logic in cpuspeed seems a little complex, and I'm wondering if we need to be running a service like cpuspeed on a desktop laptop. Richard. From paul at all-the-johnsons.co.uk Sat Jun 28 11:45:53 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 28 Jun 2008 12:45:53 +0100 Subject: gtkhtml3/evolution problem Message-ID: <1214653553.6132.3.camel@T7.Linux> Hi, I'm trying to figure out how to reproduce a really annoying problem between gtkhtml3 and evolution which causes emails when previewed to be completely grey and emails which can be previewed go completely grey when I hit reply to. Am I better off installing the debug packages or is there something I can issue prior to starting evolution which can capture the problem? It's damned annoying and unfortunately the maintainer of the packages can't seem to reproduce the problem. 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: 197 bytes Desc: This is a digitally signed message part URL: From johnp at redhat.com Sat Jun 28 13:00:22 2008 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 28 Jun 2008 09:00:22 -0400 Subject: Attribution for feature lists Message-ID: <1214658022.27760.32.camel@localhost.localdomain> A good point was brought up, perhaps not so gracefully, on the gnome blogs[1] and my follow up[2]. The issue was about credit for a particular author's work in a feature list. Now please don't devolve this thread into a distribution flame fest but I think it is important that we do a couple of things when releasing our feature lists and other such documents. First language is important. It is quite alright to gush over the contributions that came directly out of Fedora but we do sit on top of a larger upstream community and should make sure our language does not imply we wrote things we have not. Not that this has ever happened. Second, since we can't list every contributor I suggest we make an effort to point to an authors page inside of each item listed as a major feature of our next release instead of some fine print that mildly acknowledges contributions of others. By doing this we maintain good ties with upstream and are able to credit ourselves for the work that we have done also. [1] http://zee-nix.blogspot.com/2008/06/shame-ubuntu-shame.html [2] http://www.j5live.com/2008/06/27/credit-and-where-it-is-due/ From bnocera at redhat.com Sat Jun 28 14:38:59 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 28 Jun 2008 15:38:59 +0100 Subject: gtkhtml3/evolution problem In-Reply-To: <1214653553.6132.3.camel@T7.Linux> References: <1214653553.6132.3.camel@T7.Linux> Message-ID: <1214663939.4435.100.camel@cookie.hadess.net> On Sat, 2008-06-28 at 12:45 +0100, Paul wrote: > Hi, > > I'm trying to figure out how to reproduce a really annoying problem > between gtkhtml3 and evolution which causes emails when previewed to be > completely grey and emails which can be previewed go completely grey > when I hit reply to. > > Am I better off installing the debug packages or is there something I > can issue prior to starting evolution which can capture the problem? > > It's damned annoying and unfortunately the maintainer of the packages > can't seem to reproduce the problem. That's the bug I opened: https://bugzilla.redhat.com/show_bug.cgi?id=370601 From bnocera at redhat.com Sat Jun 28 14:43:12 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 28 Jun 2008 15:43:12 +0100 Subject: Attribution for feature lists In-Reply-To: <1214658022.27760.32.camel@localhost.localdomain> References: <1214658022.27760.32.camel@localhost.localdomain> Message-ID: <1214664192.4435.103.camel@cookie.hadess.net> On Sat, 2008-06-28 at 09:00 -0400, John (J5) Palmieri wrote: > A good point was brought up, perhaps not so gracefully, on the gnome > blogs[1] and my follow up[2]. The issue was about credit for a > particular author's work in a feature list. Now please don't devolve > this thread into a distribution flame fest but I think it is important > that we do a couple of things when releasing our feature lists and other > such documents. > > First language is important. It is quite alright to gush over the > contributions that came directly out of Fedora but we do sit on top of a > larger upstream community and should make sure our language does not > imply we wrote things we have not. Not that this has ever happened. > > Second, since we can't list every contributor I suggest we make an > effort to point to an authors page inside of each item listed as a major > feature of our next release instead of some fine print that mildly > acknowledges contributions of others. We should already be linking to the features page for big features, where it should be quite clear which parts were upstream, and which ones were Fedora specific/Fedora driven. From seg at haxxed.com Sat Jun 28 15:24:23 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 28 Jun 2008 10:24:23 -0500 Subject: PLEASE SHUT UP! Was: Fedora Freedom and linux-libre In-Reply-To: References: <1212917892.32207.488.camel@pmac.infradead.org> <48598E6A.5020406@gmail.com> <48599D8A.8020507@gmail.com> <1214168908.3377.58.camel@hughsie-work> <1214382706.3224.12.camel@hughsie-work> Message-ID: <1218b5bc0806280824u22057b74wda3138614422cd9f@mail.gmail.com> On Wed, Jun 25, 2008 at 12:46 PM, Alexandre Oliva wrote: > > but I _am_ part of Red Hat and you are making _me_ look bad. > > Now you lost me. Please help me understand what you're getting at. ^^^^ I think that pretty much sums up the entire thread right there. Put that in your summary: "Violence Erupts On Fedora Development List as Zealots Talk Past Each Other, Hundreds of Dead Horses Beaten" -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Sat Jun 28 22:00:30 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 29 Jun 2008 00:00:30 +0200 Subject: Review request: new package (zfuzz), "new" maintainer In-Reply-To: <1214413846.30544.8.camel@ignacio.lan> References: <1214413846.30544.8.camel@ignacio.lan> Message-ID: <20080628220029.GA2583@free.fr> On Wed, Jun 25, 2008 at 01:10:46PM -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2008-06-25 at 11:35 -0400, David A. Wheeler wrote: > > BTW, I think that the documentation for _creating_ Fedora RPMs was awful. > > So I created a page on the Wiki for those who are creating their first RPM package, > > so that others who want to create Fedora RPMs have a fighting chance: > > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo > > If anyone else wants to make improvements to that, that'd be great. > > Just out of curiosity, why didn't you continue work on the Building > Packages Guide[1] that's already a draft in the Docs project? > > [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide Having read both, it seems to me that https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo is more complete, though some generic information in the first case study in http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide could be used in the other page. The case studies are also interesting, maybe what is generic in this page should be merged to the other one and only the case studies would be left, and it would become a page with case studies? -- Pat From mmcgrath at redhat.com Sat Jun 28 23:56:10 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 28 Jun 2008 18:56:10 -0500 (CDT) Subject: Any interactions with Roozbeh Pournader? Message-ID: Has anyone talked to Roozbeh in a while? We've been trying to get ahold of him to re-sync his FAS and bugzilla passwords but without response. He's not listed on: http://fedoraproject.org/wiki/Vacation -Mike From bpepple at fedoraproject.org Sun Jun 29 06:02:20 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 28 Jun 2008 23:02:20 -0700 Subject: FESCo Election Nominations Message-ID: <1214719340.26580.0.camel@kennedy> Hi all, It's that time of year again (and yes, we're really going to have the election this time). Everyone that wants to run for the next FESCo needs to nominate him/herself for it by July 13th, 2008 0:00 UTC; that self-nomination should contain some information's like "Mission Statement, Past work summary and Future plans". ?FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, SIGs and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction. It should be noted that this is the first FESCo election that reduces the overall number of FESCo members to 9, down from 13. This is important, as the smaller number of members will hopefully produce a bit more competition for seats. The actual election will start on Tuesday, July 15th, 2008 0:01 UTC and will last until Monday, July 21st, 2008 23:59 UTC. The results will be posted to the fedora-devel list. The first meeting of the "new" FESCo will be on Thursday, July 24th, 2008 on #fedora-meeting at 17:00 UTC, and a new chair will be elected. ?Please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections 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: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Sun Jun 29 06:02:30 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 28 Jun 2008 23:02:30 -0700 Subject: FESCo Meeting Summary for 2008-06-26 Message-ID: <1214719350.26580.1.camel@kennedy> == Members == === Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Josh Boyer (jwb) === Absent === * Christopher Aillon (caillon) * Tom Callaway (spot) * Christian Iseli (c4chris) == Summary == === Packaging Sponsor Requests === * FESCo has approved the sponsor requests for: * Remi Collet (remi) * Axel Thimm (athimm) * G?rard Milmeister (gemi) === FESCo Election === * The overall mission statement for FESCo was added to the wiki (1), and it was decided to run the election now. bpepple will send an announcement over the weekend. (1) http://fedoraproject.org/wiki/Development/SteeringCommittee#Overall_Mission IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-06-26.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: 197 bytes Desc: This is a digitally signed message part URL: From mcepl at redhat.com Sun Jun 29 08:38:55 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 29 Jun 2008 10:38:55 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? Message-ID: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5819 Why in the world the package was pushed to stable, when it is known to be broken? (and for the record, I don't think Marcela did it -- she is usually too smart to work on Saturdays ;-)). Mat?j From thomas.moschny at gmail.com Sun Jun 29 10:11:29 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Sun, 29 Jun 2008 12:11:29 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? In-Reply-To: References: Message-ID: 2008/6/29 Matej Cepl : > https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5819 > > Why in the world the package was pushed to stable, when it is > known to be broken? Funny enough, on x86_64 yum decides to install tcl-1:8.5.1-4.fc9.i386 in addition to updating to tcl-1:8.5.2-2.fc9.x86_64, in order to solve the dependency problem, which seems to be the wrong solution to me. Known multilib problem? - Thomas From rawhide at fedoraproject.org Sun Jun 29 10:30:04 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 29 Jun 2008 10:30:04 +0000 (UTC) Subject: rawhide report: 20080629 changes Message-ID: <20080629103004.21988209D42@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080628/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080629/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package wastesedge Official game package for Adonthell New package xesam-glib A GObject library for dealing with Xesam services New package xesam-tools A toolkit for Xesam compliant services Updated Packages: cairo-dock-1.6.1-0.1.svn1153_trunk.fc10 --------------------------------------- * Sun Jun 29 18:00:00 2008 Mamoru Tasaka - rev. 1153 duplicity-0.4.11-2.fc10 ----------------------- * Sat Jun 28 18:00:00 2008 Robert Scheck 0.4.11-2 - Added patch for incremental backups using python 2.3 (#453069) dvipdfm-0.13.2d-39.fc10 ----------------------- * Sat Jun 28 18:00:00 2008 Jonathan G. Underwood - 0.13.2d-39 - Add dvipdfm-0.13.2d-pdfobj-fix.patch to fix BZ 453283 and 228078 echo-icon-theme-0.3.89.0-0.4.gitb404252.fc10 -------------------------------------------- * Sat Jun 28 18:00:00 2008 Martin Sourada - 0.3.89.0-0.4.gitb404252 - New git snapshot eclipse-phpeclipse-1.2.0-0.1.svn1573.fc10 ----------------------------------------- * Sat Jun 28 18:00:00 2008 Mat Booth 1.2.0-0.1.svn1573 - New maintainer. - Update to version 1.2.0 pre-release, svn1573. - Adapt patches to new version. - Update package for new Eclipse plugin guidelines. haproxy-1.3.14.6-1.fc10 ----------------------- * Sat Jun 28 18:00:00 2008 Jeremy Hinegardner - 1.3.14.6-1 - update to 1.3.14.6 - remove gcc 4.3 patch, it has been applied upstream - remove MIT license as that code has been removed from upstream * Mon Apr 14 18:00:00 2008 Jeremy Hinegardner - 1.3.14.4-1 - update to 1.3.14.4 kernel-2.6.26-0.97.rc8.fc10 --------------------------- * Fri Jun 27 18:00:00 2008 John W. Linville - Upstream wireless updates from 2008-06-27 (http://marc.info/?l=linux-wireless&m=121458164930953&w=2) * Fri Jun 27 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-06-27 (http://marc.info/?l=linux-wireless&m=121459423021061&w=2) * Thu Jun 26 18:00:00 2008 Dave Jones - Print out modules list when we hit soft lockup. ltsp-5.1.9-1.fc9 ---------------- * Fri Jun 6 18:00:00 2008 Warren Togami - 5.1.9-1 - jetpipe script was missing from ltsp-client This should allow local printers to work if configured in lts.conf. * Fri May 16 18:00:00 2008 Warren Togami - 5.1.8-1 - Fix NBD swap - Fix grabbing of lts.conf, it happens from the rootfs server now pcmanfm-0.4.5-1.fc10 -------------------- * Sat Jun 28 18:00:00 2008 Mamoru Tasaka - 0.4.5-1 - 0.4.5 (remote server access function temporally removed) - BR: intltool perl-DateTime-Format-Oracle-0.05-1.fc10 --------------------------------------- * Sat Jun 28 18:00:00 2008 Chris Weyl 0.05-1 - update to 0.05 perl-Event-Lib-1.03-3.fc10 -------------------------- * Sat Jun 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.3-3 - rebuild for libevent perl-Expect-Simple-0.04-1.fc10 ------------------------------ * Sat Jun 28 18:00:00 2008 Chris Weyl 0.04-1 - update to 0.04 - add Test::More as a br perl-MRO-Compat-0.09-1.fc10 --------------------------- * Sat Jun 28 18:00:00 2008 Chris Weyl 0.09 - update to 0.09 perl-Moose-0.51-1.fc10 ---------------------- * Sat Jun 28 18:00:00 2008 Chris Weyl 0.51-1 - update to 0.51 php-pear-Log-1.11.0-1.fc10 -------------------------- * Sat Jun 28 18:00:00 2008 Remi Collet 1.11.0-1 - update to 1.11.0 : swicth from PHP to MIT license ruby-RMagick-2.5.1-1.fc10 ------------------------- * Sun Jun 29 18:00:00 2008 Mamoru Tasaka - 2.5.1-1 - 2.5.1 waf-1.4.3-1.fc10 ---------------- * Sat Jun 28 18:00:00 2008 Thomas Moschny - 1.4.3-1 - Update to 1.4.3. - Remove fcntl patch (fixed upstream). - Prefix has to be set in a configure step now. - Pack the bash completion file. Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 17 Broken deps for i386 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.i386 requires libevent-1.3e.so.1 bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 memcached-1.2.4-4.fc9.i386 requires libevent-1.3e.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.i386 requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.i386 requires libevent-1.3e.so.1 scanssh-2.1-16.fc9.i386 requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 trickle-1.07-3.fc10.i386 requires libevent-1.3e.so.1 wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-gnome-1.0.0-2.fc9.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) memcached-1.2.4-4.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) scanssh-2.1-16.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) trickle-1.07-3.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.i386 requires libgnutls.so.13 wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.x86_64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.ppc requires libevent-1.3e.so.1 bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) memcached-1.2.4-4.fc9.ppc requires libevent-1.3e.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.ppc requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.ppc requires libevent-1.3e.so.1 scanssh-2.1-16.fc9.ppc requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 trickle-1.07-3.fc10.ppc requires libevent-1.3e.so.1 wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) wireshark-1.0.0-2.fc9.ppc requires libgnutls.so.13 wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- Io-language-extras-20071010-5.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot memcached-1.2.4-4.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) mysql-proxy-0.6.1-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot scanssh-2.1-16.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) trickle-1.07-3.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) wireshark-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) wireshark-gnome-1.0.0-2.fc9.ppc64 requires libgnutls.so.13()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From linuxkernel at edcint.co.nz Sun Jun 29 12:19:09 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Sun, 29 Jun 2008 22:19:09 +1000 Subject: Packaging of Nagios In-Reply-To: <48654B4D.9020706@kobold.org> References: <48642DDD.9000508@edcint.co.nz> <486513C6.6050109@sunnmore.net> <1214584344.3494.29.camel@eagle.danny.cz> <486519B9.9020900@sunnmore.net> <48654B4D.9020706@kobold.org> Message-ID: <48677DBD.4090300@edcint.co.nz> The migration from v2 to v3 is simple. Nagios is pretty good at maintaining backwards compatibility and moving options/settings into a deprecated state to give people time to migrate. Most of the changes will not affect most people at all. Refer http://nagios.sourceforge.net/docs/3_0/upgrading.html#nagios2x > > Does/will Nagios3 provide some config file migration tool to ease the > pain for folks who want to migrate from v2 to v3? Or are the changes > simple enough to perform by hand, even for large Nagios installations? > > --Wart > From kevin.kofler at chello.at Sun Jun 29 12:22:15 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Jun 2008 12:22:15 +0000 (UTC) Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? References: Message-ID: Matej Cepl redhat.com> writes: > Is really bodhi so stupid^H^H^H^Hnon-smart? [from the subject] Yes, you have to follow procedures, which unfortunately Marcela didn't. Can somebody in the Brno office please explain her how dist-f9-override works? :-) > Why in the world the package was pushed to stable, when it is > known to be broken? Because it was already submitted for stable and the push didn't get canceled when you sent your -1 (presumably because it was Saturday and Marcela didn't see it). > (and for the record, I don't think Marcela did it -- she is usually too smart > to work on Saturdays ). The update was submitted on "2008-06-26 06:26:25", that's Friday morning, presumably the push to stable was requested right there. Kevin Kofler From seg at haxxed.com Sun Jun 29 15:53:41 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 29 Jun 2008 10:53:41 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1213915327.17201.22.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> Message-ID: <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> On Thu, Jun 19, 2008 at 5:42 PM, Matthew Saltzman wrote: > On Thu, 2008-06-19 at 17:04 -0400, Horst H. von Brand wrote: > > Matthew Saltzman wrote: > > > Plenty of companies that would be willing to release free software are > > > leery of releasing it as GPL > > > > Why? > > You'd have to ask their lawyers. But it's a fact. > > > > > > and of using GPL software. > > > > Now that is completely unwarranted. > > You'd have to tell their lawyers. But it's a fact. > As much as I hate to drag on this clusterfsck of zelotry any longer, I can't let this bullshit fly unopposed. Here, I'll stick to a concrete example: Linden Lab is a small start-up, which may or may not even be pulling a profit yet, running off venture capital. They developed a closed-source virtual world, Second Life. A year ago they chose to release their client open source. What license did they choose? They chose the GPLv2. Think about it, if they had used a BSD-style license, some other company could take their code, start up their own for-profit service, and profit off Linden Lab's work without giving anything back, quite possibly putting Linden Lab out of business. Their investors would have never let that happen. Without a license like the GPL, which ensures that derived works remain free, Linden Lab would have never open sourced the Second Life client. And that's a fact. -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Sun Jun 29 16:37:36 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Sun, 29 Jun 2008 12:37:36 -0400 Subject: Any interactions with Roozbeh Pournader? In-Reply-To: References: Message-ID: <1214757456.3150.3.camel@behdad.behdad.org> On Sat, 2008-06-28 at 18:56 -0500, Mike McGrath wrote: > Has anyone talked to Roozbeh in a while? We've been trying to get ahold > of him to re-sync his FAS and bugzilla passwords but without response. I'll write you off list. > He's not listed on: http://fedoraproject.org/wiki/Vacation > > -Mike > -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From behdad at behdad.org Sun Jun 29 16:39:16 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Sun, 29 Jun 2008 12:39:16 -0400 Subject: Any interactions with Roozbeh Pournader? In-Reply-To: References: Message-ID: <1214757556.3150.5.camel@behdad.behdad.org> Hey, About a year ago Roozbeh lost his laptop at which time I asked and his Fedora access was disabled. He never enabled it again. Then earlier this year he moved to the US and was without a non-work machine for a while. He's generally distanced from Free Software work right now, though he's trying to come back slowly. I've CC'ed his gmail account which he reads. behdad On Sat, 2008-06-28 at 18:56 -0500, Mike McGrath wrote: > Has anyone talked to Roozbeh in a while? We've been trying to get ahold > of him to re-sync his FAS and bugzilla passwords but without response. > > He's not listed on: http://fedoraproject.org/wiki/Vacation > > -Mike > -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From mjs at clemson.edu Sun Jun 29 16:39:25 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Sun, 29 Jun 2008 12:39:25 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> Message-ID: <1214757565.14710.25.camel@valkyrie.localdomain> On Sun, 2008-06-29 at 10:53 -0500, Callum Lerwick wrote: On Thu, Jun 19, 2008 at 5:42 PM, Matthew Saltzman wrote: > On Thu, 2008-06-19 at 17:04 -0400, Horst H. von Brand wrote: > > Matthew Saltzman wrote: > > > Plenty of companies that would be willing to release free software are > > > leery of releasing it as GPL > > > > Why? > > You'd have to ask their lawyers. But it's a fact. > > > > > > and of using GPL software. > > > > Now that is completely unwarranted. > > You'd have to tell their lawyers. But it's a fact. > As much as I hate to drag on this clusterfsck of zelotry any longer, I can't let this bullshit fly unopposed. Here, I'll stick to a concrete example: Linden Lab is a small start-up, which may or may not even be pulling a profit yet, running off venture capital. They developed a closed-source virtual world, Second Life. A year ago they chose to release their client open source. What license did they choose? They chose the GPLv2. Think about it, if they had used a BSD-style license, some other company could take their code, start up their own for-profit service, and profit off Linden Lab's work without giving anything back, quite possibly putting Linden Lab out of business. Their investors would have never let that happen. Without a license like the GPL, which ensures that derived works remain free, Linden Lab would have never open sourced the Second Life client. And that's a fact. Good for them. (No sarcasm intended.) But an anecdote is not a proof. I'm not arguing that companies that shy away from open source in general or the GPL in particular always do so for good reasons. But it's clear from the variety of licenses available that a significant number of developers perceive that there are issues with the GPL that make them uncomfortable, even if they are generally pro-FOSS. The GPL is not the only license that protects code released under it from incorporation into proprietary products. But some clauses in the GPL prevent interoperability with other software that (for whatever reason) was released under different licenses that even the FSF acknowledges are in the spirit of freedom and open source. That's too bad for free and open-source software. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jkeating at j2solutions.net Sun Jun 29 16:42:08 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 29 Jun 2008 12:42:08 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214757565.14710.25.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> Message-ID: <1214757728.3307.43.camel@localhost.localdomain> On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: > I'm not arguing that companies that shy away from open source in general > or the GPL in particular always do so for good reasons. Where "good reason" means "gross misunderstanding of the GPL licenses and OpenSource development in general". -- Jesse Keating RHCE (jkeating.livejournal.com) Fedora Project (fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From the.masch at gmail.com Sun Jun 29 18:20:04 2008 From: the.masch at gmail.com (Mario Chacon) Date: Sun, 29 Jun 2008 15:20:04 -0300 Subject: Update for Gnome-do 0.5 In-Reply-To: <93d66b780806231331g6bfd5ccbha285d034256b1799@mail.gmail.com> References: <93d66b780806231156s732c5253y7d97cb4e68d09037@mail.gmail.com> <20080623222105.7cfbeb6c@laposte.net> <93d66b780806231331g6bfd5ccbha285d034256b1799@mail.gmail.com> Message-ID: <93d66b780806291120l32708c14m7ed5edf79ccf1a1c@mail.gmail.com> H! I am again, i have no answer for that bug. Is there something that i can do to update these libs?...or Are there another dependency problem? Thanks... On Mon, Jun 23, 2008 at 5:31 PM, Mario Chacon wrote: > i will try that way. > > Thanks.. > > On Mon, Jun 23, 2008 at 5:21 PM, Martin-Gomez Pablo > wrote: >> Le Mon, 23 Jun 2008 15:56:38 -0300, >> "Mario Chacon" a ?crit : >> >>> >>> Hi! >>> >>> How Can i help to update the gnome-do to ?version ?0.5? >>> >>> >>> Thanks.. >>> >> Hi, >> >> Maybe by reading this bug : >> https://bugzilla.redhat.com/show_bug.cgi?id=451492 >> >> Regards >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From ivazqueznet at gmail.com Sun Jun 29 18:30:49 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 29 Jun 2008 14:30:49 -0400 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? In-Reply-To: References: Message-ID: <1214764249.30544.93.camel@ignacio.lan> On Sun, 2008-06-29 at 10:38 +0200, Matej Cepl wrote: > https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5819 > > Why in the world the package was pushed to stable, when it is > known to be broken? (and for the record, I don't think Marcela > did it -- she is usually too smart to work on Saturdays ;-)). 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 siddharth at techbugs.org Sun Jun 29 18:51:42 2008 From: siddharth at techbugs.org (Siddharth Upmanyu) Date: Mon, 30 Jun 2008 00:21:42 +0530 Subject: Who wants to take over the developer spin? In-Reply-To: <20080627185331.GA6041@redhat.com> References: <20080627172938.GA1565@redhat.com> <486535E8.4070009@fedoraproject.org> <20080627185331.GA6041@redhat.com> Message-ID: On Sat, Jun 28, 2008 at 12:23 AM, Andrew Overholt wrote: >> I will be working with Siddharth Upmanyu (cc'ed) who has volunteered to >> start maintaining it. > > Thanks! > > Andrew > Hi Andrew I'll be needing some kick off knowledge transfer from you before i can catch up the slang, looking forward to it (as previous mails mentioned,,, should'nt be much of a headache) just for a start we dont have any mingw things anymore in F9?? (or somethings have changed in Fedora regarding cross compiling?) Thanks Siddharth From ssorce at redhat.com Sun Jun 29 18:54:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 29 Jun 2008 14:54:33 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214757565.14710.25.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> Message-ID: <1214765673.1573.10.camel@localhost.localdomain> On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: > The GPL is not the only license that protects code released under it > from incorporation into proprietary products. But some clauses in the > GPL prevent interoperability with other software that (for whatever > reason) was released under different licenses that even the FSF > acknowledges are in the spirit of freedom and open source. That's too > bad for free and open-source software. Copyleft licenses are by nature incompatible with a number of other licenses, and it's not because they are 'veil', a brief thinking about the reasons for strong copyleft will make it evident why some licenses are incompatible with others. Companies that are 'scared' by whatever license should just change lawyers/managers, they clearly do not understand the world they are supposed to operate *. Companies that strategically choose to not release software under specific free software license just make choices. You have to ask their managers. not their lawyers, why they made the choice. Simo. * I have personally met lawyers so used to proprietary licenses they simply did *not* understand the GPL and other free software license. Once they stop trying to read only the legalese and start first understanding the philosophy beyond a Free Software License, they usually come to term with these licenses. -- Simo Sorce * Red Hat, Inc * New York From lesmikesell at gmail.com Sun Jun 29 19:29:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 29 Jun 2008 14:29:25 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214765673.1573.10.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> Message-ID: <4867E295.3060605@gmail.com> Simo Sorce wrote: > On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: >> The GPL is not the only license that protects code released under it >> from incorporation into proprietary products. But some clauses in the >> GPL prevent interoperability with other software that (for whatever >> reason) was released under different licenses that even the FSF >> acknowledges are in the spirit of freedom and open source. That's too >> bad for free and open-source software. > > Copyleft licenses are by nature incompatible with a number of other > licenses, and it's not because they are 'veil', a brief thinking about > the reasons for strong copyleft will make it evident why some licenses > are incompatible with others. Perhaps there are places who want to prevent better versions than their own from ever being available and use this to justify the GPL restrictions on combinations with other components. From a user's perspective, though, this is just as harmful as any other anti-competitive ploy to limit choices. And unfortunately, even if the business reasons to maintain the restrictions on a particular product go away, the restrictions, once applied, never do. -- Les Mikesell lesmikesell at gmail.com From yersinia.spiros at gmail.com Sun Jun 29 20:27:52 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Sun, 29 Jun 2008 22:27:52 +0200 Subject: Review request: new package (zfuzz), "new" maintainer In-Reply-To: <20080628220029.GA2583@free.fr> References: <1214413846.30544.8.camel@ignacio.lan> <20080628220029.GA2583@free.fr> Message-ID: I think that some merge between the two document could be useful. But i have a simple question about http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo Why it is referenced, to the end the document, only rpm5.org as a fork, probably it is because it is not the fedora rpm version but i don't know much about, if also suse or mandriva have their rpm fork and different implementation : - fedora, suse, mandriva have different macros so interoperability is an issue (http://www.mail-archive.com/rpm-maint at lists.rpm.org/msg00942.html) - suse have "patch" rpm, different dependency capability (e.g. Obsolete can't be a capability just an example ) - in fedora we have not such restriction - Mandriva now almost use another rpm code base of rpm 4.4.2, use some patch not upstrem now as file trigger and probably other http://wiki.mandriva.com/en/Rpm_filetriggers Not to write about other distro - PLD, ARK ecc. Thanks in advance for your reply On Sun, Jun 29, 2008 at 12:00 AM, Patrice Dumas wrote: > On Wed, Jun 25, 2008 at 01:10:46PM -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2008-06-25 at 11:35 -0400, David A. Wheeler wrote: > > > BTW, I think that the documentation for _creating_ Fedora RPMs was > awful. > > > So I created a page on the Wiki for those who are creating their first > RPM package, > > > so that others who want to create Fedora RPMs have a fighting chance: > > > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo > > > If anyone else wants to make improvements to that, that'd be great. > > > > Just out of curiosity, why didn't you continue work on the Building > > Packages Guide[1] that's already a draft in the Docs project? > > > > [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide > > Having read both, it seems to me that > https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo > is more complete, though some generic information in the first case > study in > http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide > could be used in the other page. The case studies are also interesting, > maybe what is generic in this page should be merged to the other one and > only the case studies would be left, and it would become a page with > case studies? > > -- > Pat > > -- > 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 chitlesh.goorah at gmail.com Sun Jun 29 21:06:43 2008 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sun, 29 Jun 2008 23:06:43 +0200 Subject: LEGAL: SystemC Open Source License 2.3 Message-ID: <50baabb30806291406q6f8210bs88c96519a7195519@mail.gmail.com> Hello there, I'm wishing someone could point out _whether_ the : SYSTEMC OPEN SOURCE LICENSE v2.3 is compatible with Fedora Licenses policies. http://chitlesh.fedorapeople.org/systemC/License.pdf I've just requested a package review for systemc. https://bugzilla.redhat.com/show_bug.cgi?id=453335 http://en.wikipedia.org/wiki/SystemC SystemC's entrance on Fedora repositories will considerably elevate FEL's professional status. We will attract more professionals than hobbyists. Fedora Electronic Lab is a platform for designing hardware with opensource software. Cadence and Synopsys, two big leading 'enemies' companies in the semiconductor world have worked together for systemc. Thus with systemc in the fedora repositories, * we can provide quality and entreprise solutions to our Fedora Users. * more universities or hardware engineers will be interested. * more chances having embedded solutions by FEL in the future. Another issue is that to obtain the sources, one has to subscribe on their website. There is already a Linux distribution shipping systemc, SCLinux: http://sclive.wordpress.com/about/ Aside FEL is shipping VHDL and Verilog support, systemc's inclusion would simply be the best professional and entreprise solution that we can provide. kind regards, chitlesh From j.w.r.degoede at hhs.nl Sun Jun 29 21:32:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Jun 2008 23:32:38 +0200 Subject: LEGAL: SystemC Open Source License 2.3 In-Reply-To: <50baabb30806291406q6f8210bs88c96519a7195519@mail.gmail.com> References: <50baabb30806291406q6f8210bs88c96519a7195519@mail.gmail.com> Message-ID: <4867FF76.1060500@hhs.nl> Chitlesh GOORAH wrote: > Hello there, > > I'm wishing someone could point out _whether_ the : > SYSTEMC OPEN SOURCE LICENSE v2.3 is compatible with Fedora Licenses policies. > http://chitlesh.fedorapeople.org/systemC/License.pdf > Hmm, In general it looks ok, but .. INAS (I Am Not Spot) but this could be a problem: 2.6 License to Marks. (b) Recipient shall assist OSCI to the extent reasonably necessary to protect and maintain the Marks worldwide, including, but not limited to, giving prompt notice to OSCI of any known or potential infringement of the Marks, and cooperating with OSCI in preparing and executing any documents necessary to register the Marks, or as may be required by the laws or rules of any country or jurisdiction. In its sole discretion, OSCI may commence, prosecute or defend any action or claim concerning the Marks. OSCI shall have the right to control any such litigation, and Recipient shall fully cooperate with OSCI in any such litigation. OSCI shall reimburse Recipient for the reasonable costs associated with providing such assistance, except to the extent that such costs result from Recipient?s breach of this Section 2.6. Recipient shall not commence any action regarding the Marks without OSCI?s prior written consent. So in effect the person receiving the license is in turn promising to help sue people who are in breach of the SystemC trademark, hmmmmm. Regards, Hans From kevin.kofler at chello.at Sun Jun 29 23:43:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Jun 2008 23:43:24 +0000 (UTC) Subject: Who wants to take over the developer spin? References: <20080627172938.GA1565@redhat.com> <486535E8.4070009@fedoraproject.org> <20080627185331.GA6041@redhat.com> Message-ID: Siddharth Upmanyu techbugs.org> writes: > just for a start we dont have any mingw things anymore in F9?? (or > somethings have changed in Fedora regarding cross compiling?) We never had any MinGW stuff in Fedora. Kevin Kofler From jwilliam at xmission.com Mon Jun 30 03:58:29 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Sun, 29 Jun 2008 21:58:29 -0600 Subject: This session is running as a privileged user box? Message-ID: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> I am getting tired of clicking Continue when the "This session is running as a privileged user" box pops up each time I login as root. I am the only user most of the time on the box and I know that you should login as a normal user most of the time. So could we add a check box to this dialog box that says "Don't show this to me again." ? I saw this a bunch at the Summit as well. People login as root and have to keep clicking "Continue" and it slows things down. And most people know about running things as root and really only need to see this once. Thanks! Jerry Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Mon Jun 30 04:29:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 30 Jun 2008 00:29:50 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> Message-ID: <1214800190.2259.12.camel@localhost.localdomain> On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: > I am the only user most of the time on the box and I know that you > should login as a normal user most of the time. No, really, what you should do is login as a normal user _all_ of the time, and use sudo or su to take root access only when you really need it. What you're doing is analogous to using a loaded shotgun as a golf club, and what you're suggesting is that we take the safety off, because it interferes with your golf game. ~spot From tcallawa at redhat.com Mon Jun 30 04:45:39 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 30 Jun 2008 00:45:39 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <1214800190.2259.12.camel@localhost.localdomain> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> Message-ID: <1214801139.2259.17.camel@localhost.localdomain> On Mon, 2008-06-30 at 00:29 -0400, Tom "spot" Callaway wrote: > On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: > > I am the only user most of the time on the box and I know that you > > should login as a normal user most of the time. > > No, really, what you should do is login as a normal user _all_ of the > time, and use sudo or su to take root access only when you really need > it. > > What you're doing is analogous to using a loaded shotgun as a golf club, > and what you're suggesting is that we take the safety off, because it > interferes with your golf game. Although, it is also worth pointing out that if you still think it is a good idea, you should write the patch and submit it upstream (i'm pretty sure you want to look in gnome-session). http://bugzilla.gnome.org/show_bug.cgi?id=162960 has some of the back story here, from an upstream perspective. ~spot From sundaram at fedoraproject.org Mon Jun 30 05:55:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Jun 2008 11:25:10 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <4867E295.3060605@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> Message-ID: <4868753E.4030403@fedoraproject.org> Les Mikesell wrote: > > Perhaps there are places who want to prevent better versions than their > own from ever being available and use this to justify the GPL > restrictions on combinations with other components. From a user's > perspective, though, this is just as harmful as any other > anti-competitive ploy to limit choices. And unfortunately, even if the > business reasons to maintain the restrictions on a particular product go > away, the restrictions, once applied, never do. That's factually incorrect. Relicensing, dual or even tri licensing happens all the time. Rahul From sundaram at fedoraproject.org Mon Jun 30 05:57:03 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Jun 2008 11:27:03 +0530 Subject: Review request: new package (zfuzz), "new" maintainer In-Reply-To: References: <1214413846.30544.8.camel@ignacio.lan> <20080628220029.GA2583@free.fr> Message-ID: <486875AF.3080907@fedoraproject.org> yersinia wrote: > > I think that some merge between the two document could be useful. > But i have a simple question about > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo > > Why it is referenced, to the end the document, only rpm5.org > as a fork, probably it is because it is not the > fedora rpm version but i don't know much about, if also suse or > mandriva have their rpm fork and different implementation : Not really. There are some patches which haven't been merged upstream but those distributions have been working with rpm.org to do so. Rahul From mcepl at redhat.com Mon Jun 30 05:55:22 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 30 Jun 2008 07:55:22 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? References: Message-ID: On 2008-06-29, 12:22 GMT, Kevin Kofler wrote: > Matej Cepl redhat.com> writes: >> Is really bodhi so stupid^H^H^H^Hnon-smart? [from the subject] > > Yes, you have to follow procedures, which unfortunately Marcela didn't. Can > somebody in the Brno office please explain her how dist-f9-override works? :-) Could you elaborate on this, please, or point to some explanation? I don't understand how dist-f9-override works myself ... :-( Mat?j From kevin.kofler at chello.at Mon Jun 30 07:07:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 30 Jun 2008 07:07:54 +0000 (UTC) Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? References: Message-ID: Matej Cepl redhat.com> writes: > Could you elaborate on this, please, or point to some > explanation? I don't understand how dist-f9-override works myself > ... :-( The problem is that updates to released distributions don't automatically end up in the buildroots for dependent packages to build against. That's because updates may be revoked, so usually it is safer to build against the latest stable version in order not to introduce accidental dependencies on updates which don't actually get pushed. Only when an update moves to the stable updates, it ends up in the buildroot. So until there it sounds all reasonable, but then where's the problem? Well, sometimes libraries break compatibility both ways, meaning a build against the old version will not run against the new one. (Usually, this happens when a library bumps their soname, Tcl is a bit special there, but it has the same effect.) Another potential problem is that you want to push a new version of an application using the library together with the new library version, but that new application version needs the new version of the library to build. (That's the regular situation for KDE.) And of course we don't want to push the update to the stable updates before the dependencies are being rebuilt (otherwise we end up with the problem which started this thread)... So what now? This is where Release Engineering (rel-eng) enters into action. Rel-eng has the power to force packages from updates-candidate or updates-testing into the buildroot. They do this by tagging the package in Koji with an override tag for the distribution, i.e. currently dist-f9-override or dist-f8-override. The buildroot will prefer the packages with the override tag to the ones from (stable) updates (even if they're older, so it's important to remove the override tags when no longer needed, but rel-eng normally takes care of that). That in turn allows dependent packages to be rebuilt so they can be pushed all at once. Thus, the workflow is as follows: 1. build the library (DO NOT submit an update yet!) 2. send an e-mail to rel-eng asking to tag the library with dist-f9-override 3. wait for rel-eng to (manually) process the request, you'll normally get both a confirmation mail from rel-eng and an automated tagging notification from Koji (the mail from rel-eng goes to whomever requested the tagging, the Koji notification goes to whomever built the library) 4. wait for Koji to complete its newRepo task (normally takes less than an hour) 5. build the package(s) depending on the new library 6. for more complicated dependency chains, repeat steps 2 to 5 as often as necessary 7. submit a grouped update with all the affected packages through the Koji web interface (If you don't have commit access to the dependent packages, you should request it so you can do 5. and 7., otherwise some coordination with the other affected maintainers is needed.) Kevin Kofler From atkac at redhat.com Mon Jun 30 07:10:28 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 30 Jun 2008 09:10:28 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. > > Comments? > I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. Adam -- Adam Tkac, Red Hat, Inc. From alcapcom at gmail.com Mon Jun 30 09:03:09 2008 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Mon, 30 Jun 2008 11:03:09 +0200 Subject: /usr/share/eclipse/* -> %{_libdir}/eclipse/ In-Reply-To: <20080627181458.GB3604@redhat.com> References: <20080627181458.GB3604@redhat.com> Message-ID: <4868A14D.5010506@gmail.com> Andrew Overholt a ?crit : > - dramatically speeds up builds > +1. That should be something really useful... building the whole eclipse packages take at the moment too many time. Regards, Alphonse From aph at redhat.com Mon Jun 30 09:13:18 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Jun 2008 10:13:18 +0100 Subject: [fedora-java] Re: /usr/share/eclipse/* -> %{_libdir}/eclipse/ In-Reply-To: <20080627193601.GA7756@redhat.com> References: <20080627181458.GB3604@redhat.com> <1214594243.12046.10.camel@rousalka.okg> <20080627193601.GA7756@redhat.com> Message-ID: <4868A3AE.7090608@redhat.com> Andrew Overholt wrote: > * Nicolas Mailhot [2008-06-27 15:17]: >> Le vendredi 27 juin 2008 ? 14:14 -0400, Andrew Overholt a ?crit : >> >>> Does anyone have any thoughts on this? >> I'd rather you worked with Fernando Nasser and the other guys in >> Fedora's java place on common jar deployment rules, instead of >> reinventing the private app root dead-end that makes sharing resources >> next to impossible and encourages library forking and duplication > > The JARs are 99% application-specific so putting them into a > subdirectory makes sense to me and follows the guidelines we have in > place. We have no library forking or duplication of the dependent JARs, > either. I agree. Eclipse's deployment problems are somewhat unusual. Debian's solution looks like a practical way to solve these problems. Andrew. From hughsient at gmail.com Mon Jun 30 09:54:32 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 30 Jun 2008 10:54:32 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> Message-ID: <1214819672.3511.26.camel@hughsie-work> On Mon, 2008-06-30 at 09:10 +0200, Adam Tkac wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > I don't think removal of powersave governor is good idea. Generally > ondemand governor does great job but in some cases doesn't. For > example when I play some films in mplayer ondemand sets frequency to > max which is not needed, of course. Right, so we need to fix ondemand to be cleverer. > Powersave governor is also good in case that you have bad fan in your > laptop and you are going to compile some big source. Without powersave > it is not possible (yes, it really happens :) ) Right, thermal management is similar to power management for the action but not for the policy. I don't think forcing the lowest speed setting is the correct way to fix this. If the laptop is running cool, why use the slowest speed? > > Matthew Garrett and I are working on a latency profile for power > > management, and having all these modules potentially loaded is bad. > > > > Comments? > > > > I think we should preserve ondemand and powersave governors (and > potentialy others as Dave Jones wrote in this thread). Please don't > drop them in favour of your project which might be generally better but > I believe there are cases where current governors are better. Right, cheers for your feedback. In view of everybodies comments, what about the following: * Compile _into_ the kernel ondemand, performance, powersave and userspace. * Default to performance in the kernel rather than userspace * Build as a module conservative with the view of just fixing ondemand if there are any special use-cases that conservative is better at * Export the P and C state latency to userspace and let the system policy dictate the governor. For instance, even for machines that have a long latency for changing P states should be able to use ondemand if we want to save maximum power. How does that sound? Richard. From rawhide at fedoraproject.org Mon Jun 30 10:01:59 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 30 Jun 2008 10:01:59 +0000 (UTC) Subject: rawhide report: 20080630 changes Message-ID: <20080630100159.DEC32209D2E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080629/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080630/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package bootconf GRUB configuration utility Removed package extragear-plasma Updated Packages: Io-language-20071010-6.fc10 --------------------------- * Sun Jun 29 18:00:00 2008 Hans de Goede 20071010-6 - Rebuild for new libevent baekmuk-ttf-fonts-2.2-8.fc10 ---------------------------- * Mon Jun 30 18:00:00 2008 Caius Chance - 2.2-8.fc10 - Resolves: rhbz#453080 (fonts-korean is deprecated and should be removed.) blobAndConquer-0.96-1.fc10 -------------------------- * Thu Jun 26 18:00:00 2008 Hans de Goede 0.96-1 - New upstream release 0.96 cairo-dock-1.6.1-0.1.svn1160_trunk.fc10 --------------------------------------- * Mon Jun 30 18:00:00 2008 Mamoru Tasaka - rev. 1160 cjkunifonts-0.1.20060928-5.fc10 ------------------------------- * Mon Jun 30 18:00:00 2008 Caius Chance - 0.1.20060928-5.fc10 - Resolved: rhbz#453078 (fonts-chinese is deprecated and should be removed.) * Fri Aug 31 18:00:00 2007 Jens Petersen - remove superfluous ttfmkdir requires cups-pdf-2.4.8-1.fc10 --------------------- * Fri Mar 28 18:00:00 2008 Remi Collet 2.4.8-1 - update to 2.4.8 echo-icon-theme-0.3.89.0-0.5.git7ec79f3.fc10 -------------------------------------------- * Sun Jun 29 18:00:00 2008 Martin Sourada - 0.3.89.0-0.5.git7ec79f3 - New git snapshot eclipse-phpeclipse-1.2.0-0.2.svn1573.fc10 ----------------------------------------- * Sun Jun 29 18:00:00 2008 Mat Booth 1.2.0-0.2.svn1573 - Add patch for Show External Preview functionality. - Add patch for Use External PHP Parser functionality. eclipse-rpm-editor-0.4.0-1.fc10 ------------------------------- * Sun Jun 29 18:00:00 2008 Alphonse Van Assche 0.4.0-1 - bump to 0.4.0 * Wed Jun 25 18:00:00 2008 Alphonse Van Assche 0.3.0-3 - Using pdebuild. * Thu May 1 18:00:00 2008 Alphonse Van Assche 0.3.0-2 - Bump to 0.3.0 * Wed Apr 23 18:00:00 2008 Alphonse Van Assche 0.2.1-4 - Revert last changes goocanvas-0.10-1.fc10 --------------------- * Sun Jun 29 18:00:00 2008 Bernard Johnson - 0.10-1 - v 0.10 gscan2pdf-0.9.24-1.fc10 ----------------------- * Sun Jun 29 18:00:00 2008 Bernard Johnson - 0.9.24-1 - v 0.9.24 hedgewars-0.9.4-1.fc10 ---------------------- * Thu Jun 26 18:00:00 2008 Hans de Goede 0.9.4-1 - New upstream release 0.9.4 jd-2.0.0-0.6.svn2156_trunk.fc10 ------------------------------- * Mon Jun 30 18:00:00 2008 Mamoru Tasaka - svn 2156 kde-filesystem-4-16.fc10 ------------------------ * Sun Jun 29 18:00:00 2008 Rex Dieter 4-16 - + %_datadir/apps/konqueror(/servicemenus) * Fri May 16 18:00:00 2008 Rex Dieter 4-15 - omit %_sysconfdir/kde/xdg (see also #249109) ldns-1.3.0-3.fc10 ----------------- * Wed May 28 18:00:00 2008 Paul Wouters - 1.3.0-3 - enable SHA2 functionality * Wed May 28 18:00:00 2008 Paul Wouters - 1.3.0-2 - re-tag (don't do builds while renaming local repo dirs) * Wed May 28 18:00:00 2008 Paul Wouters - 1.3.0-1 - Updated to latest release libselinux-2.0.67-2.fc10 ------------------------ * Sun Jun 29 18:00:00 2008 Dan Walsh - 2.0.67-2 - Add Karel Zak patch for freecon man page memcached-1.2.5-2.fc10 ---------------------- * Tue Mar 4 17:00:00 2008 Paul Lindner - 1.2.5-1 - Upgrade to memcached-1.2.5 mlocate-0.21-1.fc10 ------------------- * Mon Jun 30 18:00:00 2008 Miloslav Trma?? - 0.21-1 - Update to mlocate-0.21 - Define PRUNENAMES to exclude .svn and .hg nsd-3.1.0-1.fc10 ---------------- * Mon Jun 30 18:00:00 2008 Paul Wouters - 3.1.0-1 - Updated to 3.1.0 pdfedit-0.4.1-1.fc10 -------------------- * Sun Jun 29 18:00:00 2008 Bernard Johnson - 0.4.1-1 - 0.4.1 * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0.3.2-6 - fix license tag * Fri Apr 11 18:00:00 2008 Bernard Johnson - 0.3.2-5 - build fix, now requires qt3-devel instead of qt-devel (bz #440291) perl-Time-Duration-1.06-4.fc10 ------------------------------ * Sun Jun 29 18:00:00 2008 Marc Bradshaw 1.06-4 - A few bugs fixed in specfile * Sun Jun 29 18:00:00 2008 Marc Bradshaw 1.06-3 - Rebuild for F9 ruby-aws-0.3.3-1.fc10 --------------------- * Sun Jun 29 18:00:00 2008 Mamoru Tasaka - 0.3.3-1 - 0.3.3 sgml-common-0.6.3-24.fc10 ------------------------- * Mon Jun 30 18:00:00 2008 Ondrej Vasik 0.6.3-24 - mark catalog files as (not md5 size mtime) for verify to prevent info about changed files (#453271) subcommander-1.9.93-2.fc10 -------------------------- * Sun Jun 29 18:00:00 2008 Jochen Schmitt 1.9.93-2 - New prerelease 2.0.0b3 of subcommander trickle-1.07-4.fc10 ------------------- * Sun Jun 29 18:00:00 2008 Nicoleau Fabien 1.07-4 - rebuild for new libevent wireshark-1.0.0-3.fc10 ---------------------- * Sun Jun 29 18:00:00 2008 Dennis Gilmore 1.0.0-3 - add sparc arches to -fPIE - rebuild for new gnutls wordwarvi-0.17-1.fc10 --------------------- * Mon Jun 30 18:00:00 2008 Hans de Goede 0.17-1 - New upstream release 0.17 Summary: Added Packages: 1 Removed Packages: 1 Modified Packages: 27 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.i386 requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.i386 requires libevent-1.3e.so.1 pygoocanvas-0.9.0-3.fc9.i386 requires goocanvas = 0:0.9 scanssh-2.1-16.fc9.i386 requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.x86_64 requires libevent-1.3e.so.1()(64bit) pygoocanvas-0.9.0-3.fc9.x86_64 requires goocanvas = 0:0.9 scanssh-2.1-16.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 mysql-proxy-0.6.1-1.fc9.ppc requires libevent-1.3e.so.1 1:nfs-utils-1.1.2-9.fc10.ppc requires libevent-1.3e.so.1 pygoocanvas-0.9.0-3.fc9.ppc requires goocanvas = 0:0.9 scanssh-2.1-16.fc9.ppc requires libevent-1.3e.so.1 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot mysql-proxy-0.6.1-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) 1:nfs-utils-1.1.2-9.fc10.ppc64 requires libevent-1.3e.so.1()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot pygoocanvas-0.9.0-3.fc9.ppc64 requires goocanvas = 0:0.9 scanssh-2.1-16.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From choeger at cs.tu-berlin.de Mon Jun 30 10:21:40 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 30 Jun 2008 12:21:40 +0200 Subject: diploma thesis with kvm Message-ID: <1214821300.16221.12.camel@choeger6> Hi, I am going to work on my diploma thesis in autumn. Currently I am working on an idea and could need some feedback. My idea is to extend kvm virtualisation with a feature that could be usefull in cluster computing: The ability to sync network traffic between several machines to make a snapshot of many machines which interact with each other. The basic concept is to log the outgoing and incoming packets for a while until each machine is ready to be paused, then pause all, do whatever you want (make a snapshot, migrate etc.). When the machines are started again the packet log is compared and missing packets are sent to their targets again. So if any of you could answer me some questions I would be gratefull: 1. Is that already possible (I hope not ;) )? 2. Is that usefull? 3. Is that generally possible? 4. Are there any papers out there about how the network stack is implemented in KVM? thank you for any advice. Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From paul at all-the-johnsons.co.uk Mon Jun 30 10:35:10 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 30 Jun 2008 11:35:10 +0100 Subject: Evolution glib problems anyone? Message-ID: <20080630103158.M50149@all-the-johnsons.co.uk> Hi, I'm trying to start up evolution and all I seem to get are the following back [paul at t7 ~]$ evolution CalDAV Eplugin starting up ... ** (evolution:4765) : DEBUG: mailto URL command: evolution %s ** (evolution>7465) : DEBUG: mailto URL program: evolution GLib-ERROR **: gmem.c:136: failed to allocate 31740376080 bytes aborting... Trace/breakpoint trap I'm not sure why it's trying to allocate such a huge amount of memory either. TTFN Paul -- Programmer, GirlGamer www.girlgamer.com From mjg59 at srcf.ucam.org Mon Jun 30 11:20:43 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Mon, 30 Jun 2008 12:20:43 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> Message-ID: <20080630112043.GA21246@srcf.ucam.org> On Mon, Jun 30, 2008 at 09:10:28AM +0200, Adam Tkac wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > I don't think removal of powersave governor is good idea. Generally > ondemand governor does great job but in some cases doesn't. For > example when I play some films in mplayer ondemand sets frequency to > max which is not needed, of course. The same can be achieved by altering /sys/devices/system/cpu/*/cpufreq/scaling_max_freq, but it's still likely that you're consuming less power when ondemand is setting your frequency to max. An idle fast processor consumes less power than an active slow one. > Powersave governor is also good in case that you have bad fan in your > laptop and you are going to compile some big source. Without powersave > it is not possible (yes, it really happens :) ) http://lkml.org/lkml/2008/6/16/100 > I think we should preserve ondemand and powersave governors (and > potentialy others as Dave Jones wrote in this thread). Please don't > drop them in favour of your project which might be generally better but > I believe there are cases where current governors are better. I'm open to indications as to what these are :) Powersave is semantically identical to ondemand with scaling_max_freq altered. Performance is semantically identical to ondemand with scaling_min_freq altered. -- Matthew Garrett | mjg59 at srcf.ucam.org From mcrha at redhat.com Mon Jun 30 12:07:43 2008 From: mcrha at redhat.com (Milan Crha) Date: Mon, 30 Jun 2008 14:07:43 +0200 Subject: Evolution glib problems anyone? In-Reply-To: <20080630103158.M50149@all-the-johnsons.co.uk> References: <20080630103158.M50149@all-the-johnsons.co.uk> Message-ID: <1214827663.5548.10.camel@Lion> On Mon, 2008-06-30 at 11:35 +0100, Paul F. Johnson wrote: > Hi, > > I'm trying to start up evolution and all I seem to get are the following back > > [paul at t7 ~]$ evolution > CalDAV Eplugin starting up ... > ** (evolution:4765) : DEBUG: mailto URL command: evolution %s > ** (evolution>7465) : DEBUG: mailto URL program: evolution > > GLib-ERROR **: gmem.c:136: failed to allocate 31740376080 bytes > aborting... > Trace/breakpoint trap > > I'm not sure why it's trying to allocate such a huge amount of memory either. > > TTFN > > Paul Hi, can you install debug info packages for evolution, evolution-data-server, evolution-exchange and gtkhtml3, and try to run evolution under gdb and paste to the bugzilla report result of the "thread apply all bt" command? It will hopefully show where it tries to allocate such amount of memory. Thanks, Milan From mjs at clemson.edu Mon Jun 30 12:16:40 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Mon, 30 Jun 2008 08:16:40 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4868753E.4030403@fedoraproject.org> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> Message-ID: <1214828201.4411.44.camel@valkyrie.localdomain> On Mon, 2008-06-30 at 11:25 +0530, Rahul Sundaram wrote: > Les Mikesell wrote: > > > > Perhaps there are places who want to prevent better versions than their > > own from ever being available and use this to justify the GPL > > restrictions on combinations with other components. From a user's > > perspective, though, this is just as harmful as any other > > anti-competitive ploy to limit choices. And unfortunately, even if the > > business reasons to maintain the restrictions on a particular product go > > away, the restrictions, once applied, never do. > > That's factually incorrect. Relicensing, dual or even tri licensing > happens all the time. Well, sometimes. Arranging for retroactive relicensing of existing projects is often problematic, particularly when there are numerous, widely distributed developers, or when the developers are unreachable or unwilling to consider it. > > Rahul > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sundaram at fedoraproject.org Mon Jun 30 12:26:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Jun 2008 17:56:13 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214828201.4411.44.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> <1214828201.4411.44.camel@valkyrie.localdomain> Message-ID: <4868D0E5.4030705@fedoraproject.org> Matthew Saltzman wrote: > On Mon, 2008-06-30 at 11:25 +0530, Rahul Sundaram wrote: >> Les Mikesell wrote: >>> Perhaps there are places who want to prevent better versions than their >>> own from ever being available and use this to justify the GPL >>> restrictions on combinations with other components. From a user's >>> perspective, though, this is just as harmful as any other >>> anti-competitive ploy to limit choices. And unfortunately, even if the >>> business reasons to maintain the restrictions on a particular product go >>> away, the restrictions, once applied, never do. >> That's factually incorrect. Relicensing, dual or even tri licensing >> happens all the time. > > Well, sometimes. Arranging for retroactive relicensing of existing > projects is often problematic, particularly when there are numerous, > widely distributed developers, or when the developers are unreachable or > unwilling to consider it. That makes "never" factually incorrect. You are agreeing with my point. Besides large projects such as Mozilla, gstreamer and others have managed retroactive relicensing. So it is certainly possible although possibly difficult in some cases. Rahul From lesmikesell at gmail.com Mon Jun 30 12:29:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 30 Jun 2008 07:29:53 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <4868753E.4030403@fedoraproject.org> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> Message-ID: <4868D1C1.3030707@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> >> Perhaps there are places who want to prevent better versions than >> their own from ever being available and use this to justify the GPL >> restrictions on combinations with other components. From a user's >> perspective, though, this is just as harmful as any other >> anti-competitive ploy to limit choices. And unfortunately, even if >> the business reasons to maintain the restrictions on a particular >> product go away, the restrictions, once applied, never do. > > That's factually incorrect. Relicensing, dual or even tri licensing > happens all the time. It's possible, but rare for project that has been under the GPL for any length of time. Since there is no requirement to track the copyright ownership of contributers there is generally no way to get permission from all of them for a change. Of course a dual license could be applied from the start with one being less restrictive like perl's to eliminate that problem. -- Les Mikesell lesmikesell at gmail.com From ajax at redhat.com Mon Jun 30 13:56:24 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 30 Jun 2008 09:56:24 -0400 Subject: Backporting some F9 packages to F8 In-Reply-To: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> Message-ID: <1214834184.24769.25.camel@localhost.localdomain> On Fri, 2008-06-27 at 11:28 +0200, Joshua C. wrote: > Can someone backport some of the F9 packages to F8? Especially some of > the following: > > mesa > xorg-x11-drv-ati We typically do not do wholesale upgrades of drivers in older releases. There's just too much churn happening to keep up with it. Mesa is particularly problematic since it has complex build interdependencies with the X server itself. I hope to be able to change this stance at sonme point in the future, but F9 is really the first release where I might feel comfortable starting to do that. If you have specific problems that are fixed by updating to newer packages, we can investigate either backporting the fixes or updating the driver. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Mon Jun 30 14:09:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2008 10:09:32 -0400 Subject: LEGAL: SystemC Open Source License 2.3 In-Reply-To: <4867FF76.1060500@hhs.nl> References: <50baabb30806291406q6f8210bs88c96519a7195519@mail.gmail.com> <4867FF76.1060500@hhs.nl> Message-ID: <1214834972.353.3.camel@localhost.localdomain> On Sun, 2008-06-29 at 23:32 +0200, Hans de Goede wrote: > Chitlesh GOORAH wrote: > > Hello there, > > > > I'm wishing someone could point out _whether_ the : > > SYSTEMC OPEN SOURCE LICENSE v2.3 is compatible with Fedora Licenses policies. > > http://chitlesh.fedorapeople.org/systemC/License.pdf > > > > Hmm, > > In general it looks ok, but .. > INAS (I Am Not Spot) but this could be a problem: > > 2.6 License to Marks. > > (b) Recipient shall assist OSCI to the extent reasonably necessary to > protect and maintain the Marks worldwide, including, but not limited to, > giving prompt notice to OSCI of any known or potential infringement of the > Marks, and cooperating with OSCI in preparing and executing any > documents necessary to register the Marks, or as may be required by the > laws or rules of any country or jurisdiction. In its sole discretion, OSCI > may commence, prosecute or defend any action or claim concerning the > Marks. OSCI shall have the right to control any such litigation, and > Recipient shall fully cooperate with OSCI in any such litigation. OSCI shall > reimburse Recipient for the reasonable costs associated with providing > such assistance, except to the extent that such costs result from > Recipient?s breach of this Section 2.6. Recipient shall not commence any > action regarding the Marks without OSCI?s prior written consent. > > > So in effect the person receiving the license is in turn promising to help sue > people who are in breach of the SystemC trademark, hmmmmm. IANAL, but I think this license is troublesome. The definition of "Contributor" and section 3 need real Legal overview. They may make this license non free. On a cursory read it seem that rights are given only to "Contributors" and that "Contributors" must go through a complex system to disclose back changes. I may be wrong, but certainly the language warrants a very careful read. Simo. -- Simo Sorce * Red Hat, Inc * New York From jwilliam at xmission.com Mon Jun 30 14:50:19 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Mon, 30 Jun 2008 08:50:19 -0600 Subject: This session is running as a privileged user box? In-Reply-To: <1214800190.2259.12.camel@localhost.localdomain> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> Message-ID: <1967F2C5DB2B4CD2A2DBECDACC527CF1@Q9450> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Tom "spot" Callaway > Sent: Sunday, June 29, 2008 10:30 PM > To: Development discussions related to Fedora > Subject: Re: This session is running as a privileged user box? > > On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: > > I am the only user most of the time on the box and I know that you > > should login as a normal user most of the time. > > No, really, what you should do is login as a normal user _all_ of the > time, and use sudo or su to take root access only when you really need > it. Hmm, I guess I need to think about why I am trying to do things by logging in as root. The first reason is that another account wasn't set up. The other reason, that looks like it isn't an issue, was I wanted to run some of the GUI tools as root, but it looks like they just ask for the root password when run as a normal person, if they need root. But then why does root's GUI profile have things like a browser or games or stuff like that? Stuff you should never run as root? I did attend a desktop security presentation at the Summit and it seemed pretty good to try and fix some of these things, as far as letting a user change things like timezone without needing the root password. > > What you're doing is analogous to using a loaded shotgun as a golf club, > and what you're suggesting is that we take the safety off, because it > interferes with your golf game. > > ~spot So shouldn't we be removing some of the lead from the shells if we can? Like not putting a browser in roots GUI? I am thinking the biggest reason I login as root is pretty much habit. And that is now sounding like that is a bad habit, that I should try and break. So I am going to try and not login as root any more and see what issues I run into. Thanks! Jerry Williams From tcallawa at redhat.com Mon Jun 30 14:57:18 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 30 Jun 2008 10:57:18 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <1967F2C5DB2B4CD2A2DBECDACC527CF1@Q9450> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1967F2C5DB2B4CD2A2DBECDACC527CF1@Q9450> Message-ID: <1214837838.2259.27.camel@localhost.localdomain> On Mon, 2008-06-30 at 08:50 -0600, Jerry Williams wrote: > But then why does root's GUI profile have things like a browser or > games or stuff like that? Stuff you should never run as root? These are valid questions. I know there was some discussion about making the root GUI session a super-minimal session, but I'm not sure where it went from there. ~spot From dwheeler at dwheeler.com Mon Jun 30 15:07:32 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Mon, 30 Jun 2008 11:07:32 -0400 (EDT) Subject: CreatingPackageHowTo Message-ID: I think there that there is a real need for the "CreatingPackageHowTo" page. The "RPM Guide" by Eric Foster-Johnson is not a bad book, nor is "Maximum RPM". However... Documents like the "RPM Guide" tend to be generic for any distro, and fail to give enough Fedora-specific info. E.G, for _Fedora_: * You need to know about "yum install rpmdevtools", and "rpmdev-setuptree". * For each tag, you need to know the Fedora rules, right when you learn about the tag. E.G., generic docs will tell you "Summary:" exists, but not "Use American English". For "Group:" where do you find the list of groups? For "License:", where's the list of license abbreviations? * %build should use%{?_smp_mflags} with make, where appropriate. * There are lots of Fedora-specific guidelines that should an intro document should link to, if you're creating Fedora packages. Many of the documents on RPM don't seem have clear statements explaining misleading terminology, and as a result they're very confusing. The "build directory" and "build root" are fundamentally different, yet many existing docs don't make it _clear_ that there is a difference. The "%install" section doesn't actually do the final software install (when you have a build root), but this is often not made clear; a reader might think that's what is run when users install a binary RPM. Finally, most of the RPM docs aren't well-maintained. For example, Fedora packages are supposed to use "%check", which is essentially undocumented, and are supposed to AVOID "%makeinstall" if they can. WHY aren't the docs maintained? I believe a key reason is that they aren't on a Wiki. Wikis (by their nature) are easy to update/fix, and thus they tend to be more up-to-date. I don't think it has to be either/or. The "CreatingPackageHowTo" page gives the overall info, and then links to specific chapters for specific information when it's needed. --- David A. Wheeler From mjs at clemson.edu Mon Jun 30 15:10:52 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Mon, 30 Jun 2008 11:10:52 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214757728.3307.43.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> Message-ID: <1214838652.25060.32.camel@valkyrie.localdomain> On Sun, 2008-06-29 at 12:42 -0400, Jesse Keating wrote: > On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: > > I'm not arguing that companies that shy away from open source in general > > or the GPL in particular always do so for good reasons. > > Where "good reason" means "gross misunderstanding of the GPL licenses > and OpenSource development in general". This sort of fanboyism gets old in a hurry. The IBM/Common Public License was developed by IBM lawyers. Are you seriously suggesting that they exhibit "gross misunderstanding of the GPL licenses and OpenSource [sic] development in general"? If so, I think you'll find that even the FSF doesn't share your opinion. One of IBM's concerns that led to the development of the IPL/CPL was a lack of protection against patent abuses in GPLv2. The FSF listed the IPL/CPL as a "free software license incompatible with the GPL". They dubbed the patent clauses (paraphrasing) "not a bad idea, but still incompatible". Were IBM's concerns born of "gross misunderstanding of the GPL licenses and OpenSource development in general"? Well, similar protections ended up in GPLv3. You be the judge. Is the problem solved by GPLv3? No: IBM seems content with the IPL/CPL for a lot of its software (including contributions to a project I work on). And the IPL/CPL is still a free software license incompatible with the GPL. Changing IBM's opinion is a long and difficult process that takes time and energy people would prefer to spend developing new code, and with no guarantee of success in the end. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mcepl at redhat.com Mon Jun 30 15:10:16 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 30 Jun 2008 17:10:16 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? References: Message-ID: On 2008-06-30, 07:07 GMT, Kevin Kofler wrote: > The problem is that updates to released distributions don't > automatically end up in the buildroots for dependent packages > to build against. That's because updates may be revoked, so > usually it is safer to build against the latest stable version > in order not to introduce accidental dependencies on updates > which don't actually get pushed. Only when an update moves to > the stable updates, it ends up in the buildroot. Thanks for the explanation, but couldn't this tck/tk non-complicated case solved just by chain-build? Mat?j From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jun 30 15:21:49 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 01 Jul 2008 00:21:49 +0900 Subject: CreatingPackageHowTo In-Reply-To: References: Message-ID: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> David A. Wheeler wrote, at 07/01/2008 12:07 AM +9:00: > I think there that there is a real need for the > "CreatingPackageHowTo" page. The "RPM Guide" by > Eric Foster-Johnson is not a bad book, nor is "Maximum RPM". However... .... Have you looked at https://fedoraproject.org/wiki/Packaging/Guidelines ? As you seem to be a new contributor, please also see: https://fedoraproject.org/wiki/PackageMaintainers/Join (all new contributors are supposed to see this wiki). Mamoru From casimiro.barreto at gmail.com Mon Jun 30 15:32:09 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Mon, 30 Jun 2008 12:32:09 -0300 Subject: Xen kernel freezing during boot after upgrading from FC8 to FC9 In-Reply-To: <1214585598.19297.35.camel@metroid.rdu.redhat.com> References: <486514AF.6060704@gmail.com> <48651718.3000401@cox.net> <1214585598.19297.35.camel@metroid.rdu.redhat.com> Message-ID: <4868FC79.6040502@gmail.com> Will Woods escreveu: > On Fri, 2008-06-27 at 12:36 -0400, Clyde E. Kunkel wrote: > >> Casimiro de Almeida Barreto wrote: >> >>> Hello, >>> >>> I've posted this before... but it seems it is not solved yet. >>> >>> After I upgraded from FC8 to FC9 Xen kernels are freezing during boot. >>> More precisely just after the message: (Xen) ... relinquishing VGA >>> The same problem happens with 2.6.25.3-1.fc9.i686 and 2.6.25.3-2.fc9.i686 >>> > > F9 and Rawhide kernel-xen are not usable as a dom0 / Xen host. You can > run them as Xen guests but they won't work on bare metal. Hopefully F10 > will bring a working Xen dom0 kernel. > > Until then, if you want a Xen host, run F8 or RHEL or CentOS or > something. > > See http://fedoraproject.org/wiki/Features/XenPvops and > http://fedoraproject.org/wiki/Features/XenPvopsDom0 for more info. > > -w > Ok. Understood. As a suggestion to the development team in charge, why not to implement tests and issue adequate messages like: processor not supported or anything like that? Anyways Xen tests processor flags... -CdAB -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Jun 30 15:34:45 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 30 Jun 2008 17:34:45 +0200 (CEST) Subject: Fedora Freedom and linux-libre In-Reply-To: <1214838652.25060.32.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> Message-ID: <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> Le Lun 30 juin 2008 17:10, Matthew Saltzman a ?crit : > > > On Sun, 2008-06-29 at 12:42 -0400, Jesse Keating wrote: >> On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: >> > I'm not arguing that companies that shy away from open source in >> general >> > or the GPL in particular always do so for good reasons. >> >> Where "good reason" means "gross misunderstanding of the GPL >> licenses >> and OpenSource development in general". > > This sort of fanboyism gets old in a hurry. > > The IBM/Common Public License was developed by IBM lawyers. Are you > seriously suggesting that they exhibit "gross misunderstanding of the > GPL licenses and OpenSource [sic] development in general"? I'd be very careful about listing IBM as counter-example to any argument. IBM is big and diversified enough it can afford legal strategies others entities can not. That IBM wrote its own license says little about the GPL and a lot about IBM. -- Nicolas Mailhot From drago01 at gmail.com Mon Jun 30 15:34:51 2008 From: drago01 at gmail.com (drago01) Date: Mon, 30 Jun 2008 17:34:51 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? In-Reply-To: References: Message-ID: On Mon, Jun 30, 2008 at 5:10 PM, Matej Cepl wrote: > On 2008-06-30, 07:07 GMT, Kevin Kofler wrote: >> The problem is that updates to released distributions don't >> automatically end up in the buildroots for dependent packages >> to build against. That's because updates may be revoked, so >> usually it is safer to build against the latest stable version >> in order not to introduce accidental dependencies on updates >> which don't actually get pushed. Only when an update moves to >> the stable updates, it ends up in the buildroot. > > Thanks for the explanation, but couldn't this tck/tk > non-complicated case solved just by chain-build? nope chain-builds only work in devel From yersinia.spiros at gmail.com Mon Jun 30 15:36:30 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Mon, 30 Jun 2008 17:36:30 +0200 Subject: CreatingPackageHowTo In-Reply-To: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> References: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> Message-ID: woot, perhaps David is a new contributor to Fedora but everyone in the world know it as author of seminal papers, and contributor of the free/libre world. http://www.dwheeler.com/ On Mon, Jun 30, 2008 at 5:21 PM, Mamoru Tasaka wrote: > David A. Wheeler wrote, at 07/01/2008 12:07 AM +9:00: > >> I think there that there is a real need for the >> "CreatingPackageHowTo" page. The "RPM Guide" by >> Eric Foster-Johnson is not a bad book, nor is "Maximum RPM". However... >> > > .... > > Have you looked at https://fedoraproject.org/wiki/Packaging/Guidelines ? > As you seem to be a new contributor, please also see: > https://fedoraproject.org/wiki/PackageMaintainers/Join (all new > contributors > are supposed to see this wiki). > > Mamoru > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Mon Jun 30 15:42:42 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Jun 2008 21:12:42 +0530 Subject: CreatingPackageHowTo In-Reply-To: References: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> Message-ID: <4868FEF2.3090701@fedoraproject.org> yersinia wrote: > woot, > > perhaps David is a new contributor to Fedora but everyone in the world > know it as author > of seminal papers, and contributor of the free/libre world. > > http://www.dwheeler.com/ Yes, that doesn't change the possibility that a contributor new to Fedora might have missed some reference documentation. Rahul From dledford at redhat.com Mon Jun 30 16:14:47 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 30 Jun 2008 12:14:47 -0400 Subject: CreatingPackageHowTo In-Reply-To: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> References: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> Message-ID: <1214842487.32506.30.camel@firewall.xsintricity.com> On Tue, 2008-07-01 at 00:21 +0900, Mamoru Tasaka wrote: > David A. Wheeler wrote, at 07/01/2008 12:07 AM +9:00: > > I think there that there is a real need for the > > "CreatingPackageHowTo" page. The "RPM Guide" by > > Eric Foster-Johnson is not a bad book, nor is "Maximum RPM". However... > > .... > > Have you looked at https://fedoraproject.org/wiki/Packaging/Guidelines ? > As you seem to be a new contributor, please also see: > https://fedoraproject.org/wiki/PackageMaintainers/Join (all new contributors > are supposed to see this wiki). David's guide and the above guide are two different things and do not serve the same role. You can think of David's guide as a quick start, hello-world version of how to create a good package. The above listed guide is more like the C Coding Style Reference Manual. They simply aren't intended for nor useful to the same audience. And I happened to find David's guide very well written and something that I think I would point people new to rpm packaging to without problem. I would expect people new to rpm packaging to be overwhelmed and lost on the above referenced guide. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dledford at redhat.com Mon Jun 30 16:16:59 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 30 Jun 2008 12:16:59 -0400 Subject: CreatingPackageHowTo In-Reply-To: <4868FEF2.3090701@fedoraproject.org> References: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> <4868FEF2.3090701@fedoraproject.org> Message-ID: <1214842619.32506.33.camel@firewall.xsintricity.com> On Mon, 2008-06-30 at 21:12 +0530, Rahul Sundaram wrote: > yersinia wrote: > > woot, > > > > perhaps David is a new contributor to Fedora but everyone in the world > > know it as author > > of seminal papers, and contributor of the free/libre world. > > > > http://www.dwheeler.com/ > > Yes, that doesn't change the possibility that a contributor new to > Fedora might have missed some reference documentation. Who says he missed it (he might have, I don't know)? Regardless, the other docs just aren't that great for someone brand new. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From yersinia.spiros at gmail.com Mon Jun 30 16:19:55 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Mon, 30 Jun 2008 18:19:55 +0200 Subject: CreatingPackageHowTo In-Reply-To: <4868FEF2.3090701@fedoraproject.org> References: <4868FA0D.2040607@ioa.s.u-tokyo.ac.jp> <4868FEF2.3090701@fedoraproject.org> Message-ID: Ok, i don't think so - it is like to tell to linus as to build rpm for an kernel module......... But anyway.. On RPM exists many document, two book an obviously the mailing list for the corner case. - Book : Maximun RPM http://www.rpm.org/max-rpm/ Red Hat RPM Guide http://docs.fedoraproject.org/drafts/rpm-guide-en/ Errata of this book http://foster-johnson.com/rpm.html For David, in this book is explained the difference between "build dir" and "build root" - course online GuruLabs ( http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF) - For other distro other Fedora http://www.mandrivaclub.com/xwiki/bin/view/KB/MandrivaRpmHowTo - For Fedora http://fedoraproject.org/wiki/Packaging/Guidelines and other in the draft section, other that the presentation to RedHat summit of Tom Spot Colloway http://spot.fedorapeople.org/Summit2008/ Regards On Mon, Jun 30, 2008 at 5:42 PM, Rahul Sundaram wrote: > yersinia wrote: > >> woot, >> >> perhaps David is a new contributor to Fedora but everyone in the world >> know it as author >> of seminal papers, and contributor of the free/libre world. >> >> http://www.dwheeler.com/ >> > > Yes, that doesn't change the possibility that a contributor new to Fedora > might have missed some reference documentation. > > Rahul > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Mon Jun 30 16:30:36 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 30 Jun 2008 12:30:36 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214819672.3511.26.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> <1214819672.3511.26.camel@hughsie-work> Message-ID: <200806301230.36335.jwilson@redhat.com> On Monday 30 June 2008 05:54:32 am Richard Hughes wrote: > Right, cheers for your feedback. In view of everybodies comments, what > about the following: > > * Compile _into_ the kernel ondemand, performance, powersave and > userspace. Sounds reasonable. > * Default to performance in the kernel rather than userspace What's the difference? Both leave the cpu at its max speed all the time, unless the cpuspeed daemon gets started up in the userspace case. > * Build as a module conservative with the view of just fixing ondemand > if there are any special use-cases that conservative is better at > * Export the P and C state latency to userspace and let the system > policy dictate the governor. For instance, even for machines that have a > long latency for changing P states should be able to use ondemand if we > want to save maximum power. > > How does that sound? Mostly sane. System policy dictating governor over the ugliness we do in the cpuspeed init script would be nice. Even nicer would be if we could outright get rid of the initscript (not sure what people who need the cpuspeed daemon are to do in that case though). -- Jarod Wilson jwilson at redhat.com From yersinia.spiros at gmail.com Mon Jun 30 16:51:23 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Mon, 30 Jun 2008 18:51:23 +0200 Subject: LEGAL: SystemC Open Source License 2.3 In-Reply-To: <1214834972.353.3.camel@localhost.localdomain> References: <50baabb30806291406q6f8210bs88c96519a7195519@mail.gmail.com> <4867FF76.1060500@hhs.nl> <1214834972.353.3.camel@localhost.localdomain> Message-ID: Someone else are thinking as you http://www.eetindia.co.in/ART_8800387245_1800001_TA_7b571e0b.HTM Best Regards On Mon, Jun 30, 2008 at 4:09 PM, Simo Sorce wrote: > On Sun, 2008-06-29 at 23:32 +0200, Hans de Goede wrote: > > Chitlesh GOORAH wrote: > > > Hello there, > > > > > > I'm wishing someone could point out _whether_ the : > > > SYSTEMC OPEN SOURCE LICENSE v2.3 is compatible with Fedora Licenses > policies. > > > http://chitlesh.fedorapeople.org/systemC/License.pdf > > > > > > > Hmm, > > > > In general it looks ok, but .. > > INAS (I Am Not Spot) but this could be a problem: > > > > 2.6 License to Marks. > > > > (b) Recipient shall assist OSCI to the extent reasonably necessary to > > protect and maintain the Marks worldwide, including, but not limited to, > > giving prompt notice to OSCI of any known or potential infringement of > the > > Marks, and cooperating with OSCI in preparing and executing any > > documents necessary to register the Marks, or as may be required by the > > laws or rules of any country or jurisdiction. In its sole discretion, > OSCI > > may commence, prosecute or defend any action or claim concerning the > > Marks. OSCI shall have the right to control any such litigation, and > > Recipient shall fully cooperate with OSCI in any such litigation. OSCI > shall > > reimburse Recipient for the reasonable costs associated with providing > > such assistance, except to the extent that such costs result from > > Recipient's breach of this Section 2.6. Recipient shall not commence any > > action regarding the Marks without OSCI's prior written consent. > > > > > > So in effect the person receiving the license is in turn promising to > help sue > > people who are in breach of the SystemC trademark, hmmmmm. > > IANAL, > but I think this license is troublesome. > > The definition of "Contributor" and section 3 need real Legal overview. > They may make this license non free. On a cursory read it seem that > rights are given only to "Contributors" and that "Contributors" must go > through a complex system to disclose back changes. > I may be wrong, but certainly the language warrants a very careful read. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > 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 dan at danny.cz Mon Jun 30 16:55:41 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 30 Jun 2008 18:55:41 +0200 Subject: sg3_utils updated in rawhide Message-ID: <1214844941.3458.27.camel@eagle.danny.cz> Hi, I have updated sg3_utils to a new upstream version 1.26 with new soname for the library (and name too libsgutils => libsgutils2) and repoquery told me, that 3 packages depends on it lsvpd libgpod libipoddevice All will need some updates to rebuild successfully. Dan From dledford at redhat.com Mon Jun 30 17:09:07 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 30 Jun 2008 13:09:07 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <1214800190.2259.12.camel@localhost.localdomain> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> Message-ID: <1214845747.32506.41.camel@firewall.xsintricity.com> On Mon, 2008-06-30 at 00:29 -0400, Tom "spot" Callaway wrote: > On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: > > I am the only user most of the time on the box and I know that you > > should login as a normal user most of the time. > > No, really, what you should do is login as a normal user _all_ of the > time, and use sudo or su to take root access only when you really need > it. There are valid reasons to log in as root. Sometimes even always log in as root (think test machine you wipe out over and over again and root is the only account that ever exists on the machine, or times when NIS is down and all the user accounts don't exist temporarily, or times when NIS is up, but NFS is down and user home directories don't exist). Regardless, the ability to turn off a nag over something you know well and understand and accept the risks of doesn't seem to out of the question to me (although I could also see hiding the knob to turn it off in some deep foo so that a person can't turn it off without really knowing what they are doing, which implies maybe they know what they are doing logging in as they are). > What you're doing is analogous to using a loaded shotgun as a golf club, > and what you're suggesting is that we take the safety off, because it > interferes with your golf game. Hehehe, if that's how a person wants to play golf.... ;-) -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From csnook at redhat.com Mon Jun 30 17:18:22 2008 From: csnook at redhat.com (Chris Snook) Date: Mon, 30 Jun 2008 13:18:22 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> Message-ID: <4869155E.5020005@redhat.com> Jerry Williams wrote: > I am getting tired of clicking Continue when the ?This session is > running as a privileged user? box pops up each time I login as root. > > > > I am the only user most of the time on the box and I know that you > should login as a normal user most of the time. > > > > So could we add a check box to this dialog box that says ?Don?t show > this to me again.? ? > > > > I saw this a bunch at the Summit as well. > > People login as root and have to keep clicking ?Continue? and it slows > things down. > > And most people know about running things as root and really only need > to see this once. How about we add a button to launch system-config-users, so that people can create a non-root account and not have to deal with it again? -- Chris From lordmorgul at gmail.com Mon Jun 30 17:46:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 30 Jun 2008 10:46:14 -0700 Subject: This session is running as a privileged user box? In-Reply-To: <1214837838.2259.27.camel@localhost.localdomain> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1967F2C5DB2B4CD2A2DBECDACC527CF1@Q9450> <1214837838.2259.27.camel@localhost.localdomain> Message-ID: <48691BE6.8040805@gmail.com> Tom "spot" Callaway wrote: > On Mon, 2008-06-30 at 08:50 -0600, Jerry Williams wrote: >> But then why does root's GUI profile have things like a browser or >> games or stuff like that? Stuff you should never run as root? > > These are valid questions. I know there was some discussion about making > the root GUI session a super-minimal session, but I'm not sure where it > went from there. > > ~spot Perhaps a normal user account should always be created during installation without any feedback (choice of username/passwd) which can only be logged in to from the local console. Such a user could be the 'I need to do initial maint' account rather than root... and still need the root password to make changes. Something like 'fedora/fedora' for user/pass which is always created and needs to be disabled once installed. Once another normal user is created, the 'fedora' user could be automatically removed (perhaps by firstboot once users are created)? -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lordmorgul at gmail.com Mon Jun 30 17:53:54 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 30 Jun 2008 10:53:54 -0700 Subject: This session is running as a privileged user box? In-Reply-To: <1214845747.32506.41.camel@firewall.xsintricity.com> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1214845747.32506.41.camel@firewall.xsintricity.com> Message-ID: <48691DB2.3080202@gmail.com> Doug Ledford wrote: > On Mon, 2008-06-30 at 00:29 -0400, Tom "spot" Callaway wrote: >> On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: >>> I am the only user most of the time on the box and I know that you >>> should login as a normal user most of the time. >> No, really, what you should do is login as a normal user _all_ of the >> time, and use sudo or su to take root access only when you really need >> it. > > There are valid reasons to log in as root. Sometimes even always log in > as root (think test machine you wipe out over and over again and root is > the only account that ever exists on the machine If this was an install-test machine you really don't need to setup configurations like 'do not show me this again' anyway. If its meant to test anything more significant than installation a normal user should be created because you are not testing normal use scenarios if you're logged in as root. > or times when NIS is > down and all the user accounts don't exist temporarily, or times when > NIS is up, but NFS is down and user home directories don't exist). > Regardless, the ability to turn off a nag over something you know well > and understand and accept the risks of doesn't seem to out of the > question to me (although I could also see hiding the knob to turn it off > in some deep foo so that a person can't turn it off without really > knowing what they are doing, which implies maybe they know what they are > doing logging in as they are). I question whether anyone knows what they are doing when logging in graphically as root... if they know what they are doing they'll be fixing any of those above problems from a virtual terminal, or remotely from a normal user elsewhere. It is never necessary to login to an X session as root, and probably shouldn't even be allowed. >> What you're doing is analogous to using a loaded shotgun as a golf club, >> and what you're suggesting is that we take the safety off, because it >> interferes with your golf game. > > Hehehe, if that's how a person wants to play golf.... ;-) Better not to be the one to caddy for this 'club' user though. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From dledford at redhat.com Mon Jun 30 18:24:19 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 30 Jun 2008 14:24:19 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <48691DB2.3080202@gmail.com> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1214845747.32506.41.camel@firewall.xsintricity.com> <48691DB2.3080202@gmail.com> Message-ID: <1214850259.32506.49.camel@firewall.xsintricity.com> On Mon, 2008-06-30 at 10:53 -0700, Andrew Farris wrote: > Doug Ledford wrote: > > On Mon, 2008-06-30 at 00:29 -0400, Tom "spot" Callaway wrote: > >> On Sun, 2008-06-29 at 21:58 -0600, Jerry Williams wrote: > >>> I am the only user most of the time on the box and I know that you > >>> should login as a normal user most of the time. > >> No, really, what you should do is login as a normal user _all_ of the > >> time, and use sudo or su to take root access only when you really need > >> it. > > > > There are valid reasons to log in as root. Sometimes even always log in > > as root (think test machine you wipe out over and over again and root is > > the only account that ever exists on the machine > > If this was an install-test machine you really don't need to setup > configurations like 'do not show me this again' anyway. If its meant to test > anything more significant than installation a normal user should be created > because you are not testing normal use scenarios if you're logged in as root. Sometimes, not testing "normal use scenarios" is exactly what you want. As a kernel developer, I don't really want to mess with broken console-kit rules in order to test if kernel module Y actually works (any console rules are a separate issue from the kernel module working). > I question whether anyone knows what they are doing when logging in graphically > as root... You can question it all you want, but I assure you I *do* know what I'm doing, and I'll happily tell anyone that tells me otherwise to kindly attend to their own affairs, kthxbye. > if they know what they are doing they'll be fixing any of those > above problems from a virtual terminal, or remotely from a normal user > elsewhere. It is never necessary to login to an X session as root, and probably > shouldn't even be allowed. Shouldn't even be allowed? Boy, that's going a long ways down the road of "I know what's best for you, so shut up and deal with it...", which would be a big part of the reason I never liked Microsoft or Apple OSes...let's please not go down that road. > >> What you're doing is analogous to using a loaded shotgun as a golf club, > >> and what you're suggesting is that we take the safety off, because it > >> interferes with your golf game. > > > > Hehehe, if that's how a person wants to play golf.... ;-) > > Better not to be the one to caddy for this 'club' user though. Not asking anyone to be my caddy, just for them not to deny me the right to caddy my own game as I see fit. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dan at danny.cz Mon Jun 30 18:53:27 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 30 Jun 2008 20:53:27 +0200 Subject: sg3_utils updated in rawhide In-Reply-To: <1214844941.3458.27.camel@eagle.danny.cz> References: <1214844941.3458.27.camel@eagle.danny.cz> Message-ID: <1214852007.3458.30.camel@eagle.danny.cz> Dan Hor?k p??e v Po 30. 06. 2008 v 18:55 +0200: > Hi, > > I have updated sg3_utils to a new upstream version 1.26 with new soname > for the library (and name too libsgutils => libsgutils2) and repoquery > told me, that 3 packages depends on it > > lsvpd > libgpod > libipoddevice > > All will need some updates to rebuild successfully. All 3 packages are patched and rebuilt. Dan From mjs at clemson.edu Mon Jun 30 18:38:06 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Mon, 30 Jun 2008 18:38:06 +0000 Subject: Fedora Freedom and linux-libre In-Reply-To: <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> Message-ID: <1214851086.25060.66.camel@valkyrie.localdomain> On Mon, 2008-06-30 at 17:34 +0200, Nicolas Mailhot wrote: > Le Lun 30 juin 2008 17:10, Matthew Saltzman a ?crit : > > > > > > On Sun, 2008-06-29 at 12:42 -0400, Jesse Keating wrote: > >> On Sun, 2008-06-29 at 12:39 -0400, Matthew Saltzman wrote: > >> > I'm not arguing that companies that shy away from open source in > >> general > >> > or the GPL in particular always do so for good reasons. > >> > >> Where "good reason" means "gross misunderstanding of the GPL > >> licenses > >> and OpenSource development in general". > > > > This sort of fanboyism gets old in a hurry. > > > > The IBM/Common Public License was developed by IBM lawyers. Are you > > seriously suggesting that they exhibit "gross misunderstanding of the > > GPL licenses and OpenSource [sic] development in general"? > > I'd be very careful about listing IBM as counter-example to any argument. > > IBM is big and diversified enough it can afford legal strategies > others entities can not. That IBM wrote its own license says little > about the GPL and a lot about IBM. My point was just that there can be legitimate reasons for businesses to be concerned about the terms of the GPL and to choose to use alternative licenses *even for free software*. It is certainly true that IBM can deal with those concerns in ways that other businesses can't. On the other hand, the number of FOSS licenses (some well written, some not-so-well written) indicates that the concerns exist and may not be due simply to "gross misunderstanding of the GPL licenses and OpenSource development in general". My original point was simply that interoperability of GPL software and software released under a number of other FOSS licenses is hindered by the GPL's prohibition^H^H^H^H^H^H^H^H^H^H^H lack of permission to distribute combined works. Unfortunately, an all-GPL world is a utopian dream; the real world is more complicated and more frustrating. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From tcallawa at redhat.com Mon Jun 30 19:11:47 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 30 Jun 2008 15:11:47 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <1214845747.32506.41.camel@firewall.xsintricity.com> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1214845747.32506.41.camel@firewall.xsintricity.com> Message-ID: <1214853107.2259.36.camel@localhost.localdomain> On Mon, 2008-06-30 at 13:09 -0400, Doug Ledford wrote: > although I could also see hiding the knob to turn it off > in some deep foo so that a person can't turn it off without really > knowing what they are doing, which implies maybe they know what they > are doing logging in as they are I could make the argument that having the ability to modify the source code is sufficiently equivalent to this. ~spot From ssorce at redhat.com Mon Jun 30 19:26:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2008 15:26:56 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214851086.25060.66.camel@valkyrie.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> Message-ID: <1214854016.353.26.camel@localhost.localdomain> On Mon, 2008-06-30 at 18:38 +0000, Matthew Saltzman wrote: > > My original point was simply that interoperability of GPL software and > software released under a number of other FOSS licenses is hindered by > the GPL's prohibition^H^H^H^H^H^H^H^H^H^H^H lack of permission to > distribute combined works. Unfortunately, an all-GPL world is a > utopian > dream; the real world is more complicated and more frustrating. Sorry but this comment is either grossly imprecise and dictated by hurry in writing up[, or it underlines a gross misunderstanding of the GPL. In either case, as it is just false. First, a copyleft license by nature, cannot be compatible with just any license, but only with licenses that follow certain rules, for obvious reasons. Trying to discuss this point is like trying to argue that gravity sucks and whine about it. Second, you should really differentiate between GPLv2 and GPLv3, as GPLv3 address, with many others, also the license compatibility problem, making GPLv3 more compatible with other copyleft licenses. Third and not less important the first, the GPL (v2/3) does NOT prohibit distribution of combined works as long as all pieces use GPL compatible licenses. Being GPL compatible is not difficult at all, in most cases modern licenses that are not GPL (at least v3) compatible, are not by choice, so you should really look at both sides of the equation, you cannot blame the GPL for lack of compatibility, compatibility is always a two sides story. That said I am not pointing fingers at anyone, as I believe everyone have the right to choose and draft the license for their own software they way they want. Finally, please let's keep this para-legal quasi-trolling off the fedora-*DEVEL* mailing list thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York From dledford at redhat.com Mon Jun 30 19:28:45 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 30 Jun 2008 15:28:45 -0400 Subject: This session is running as a privileged user box? In-Reply-To: <1214853107.2259.36.camel@localhost.localdomain> References: <65DD2FE4D07B41D0854C8E370D0C353A@Q9450> <1214800190.2259.12.camel@localhost.localdomain> <1214845747.32506.41.camel@firewall.xsintricity.com> <1214853107.2259.36.camel@localhost.localdomain> Message-ID: <1214854125.32506.57.camel@firewall.xsintricity.com> On Mon, 2008-06-30 at 15:11 -0400, Tom "spot" Callaway wrote: > On Mon, 2008-06-30 at 13:09 -0400, Doug Ledford wrote: > > although I could also see hiding the knob to turn it off > > in some deep foo so that a person can't turn it off without really > > knowing what they are doing, which implies maybe they know what they > > are doing logging in as they are > > I could make the argument that having the ability to modify the source > code is sufficiently equivalent to this. Not really...if it can't be done with the package in the repo, then I would argue that it isn't a deeply hidden knob, that's no knob. Besides, do you *really* want to step into the "you have the source, modify it" cold war control/escalation game over something that's so obviously the user's own choice/fault if they choose to do so? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Jun 30 19:40:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 30 Jun 2008 14:40:08 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214854016.353.26.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> <1214854016.353.26.camel@localhost.localdomain> Message-ID: <48693698.9090803@gmail.com> Simo Sorce wrote: > > Sorry but this comment is either grossly imprecise and dictated by hurry > in writing up[, or it underlines a gross misunderstanding of the GPL. In > either case, as it is just false. > > First, a copyleft license by nature, Can you define copyleft? I don't think that term helps clear up any misunderstandings. > cannot be compatible with just any > license, but only with licenses that follow certain rules, for obvious > reasons. Those reasons are not at all obvious. There is never any need to restrict combinations of works. > Being GPL compatible is not difficult at all, in most cases modern > licenses that are not GPL (at least v3) compatible, are not by choice, > so you should really look at both sides of the equation, you cannot > blame the GPL for lack of compatibility, compatibility is always a two > sides story. When the GPL is the only one placing requirements on the other components it is not a two sided story. -- Les Mikesell lesmikesell at gmail.com From ssorce at redhat.com Mon Jun 30 19:43:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2008 15:43:01 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <4868D1C1.3030707@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> <4868D1C1.3030707@gmail.com> Message-ID: <1214854981.353.28.camel@localhost.localdomain> On Mon, 2008-06-30 at 07:29 -0500, Les Mikesell wrote: > Rahul Sundaram wrote: > > Les Mikesell wrote: > >> > >> Perhaps there are places who want to prevent better versions than > >> their own from ever being available and use this to justify the GPL > >> restrictions on combinations with other components. From a user's > >> perspective, though, this is just as harmful as any other > >> anti-competitive ploy to limit choices. And unfortunately, even if > >> the business reasons to maintain the restrictions on a particular > >> product go away, the restrictions, once applied, never do. > > > > That's factually incorrect. Relicensing, dual or even tri licensing > > happens all the time. > > It's possible, but rare for project that has been under the GPL for any > length of time. Since there is no requirement to track the copyright > ownership of contributers there is generally no way to get permission > from all of them for a change. Of course a dual license could be > applied from the start with one being less restrictive like perl's to > eliminate that problem. Such dual licensing would be useless. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jun 30 19:46:27 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2008 15:46:27 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48693698.9090803@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> <1214854016.353.26.camel@localhost.localdomain> <48693698.9090803@gmail.com> Message-ID: <1214855187.353.32.camel@localhost.localdomain> On Mon, 2008-06-30 at 14:40 -0500, Les Mikesell wrote: > Simo Sorce wrote: > > > > Sorry but this comment is either grossly imprecise and dictated by hurry > > in writing up[, or it underlines a gross misunderstanding of the GPL. In > > either case, as it is just false. > > > > First, a copyleft license by nature, > > Can you define copyleft? I don't think that term helps clear up any > misunderstandings. http://www.gnu.org/copyleft/ > > cannot be compatible with just any > > license, but only with licenses that follow certain rules, for obvious > > reasons. > > Those reasons are not at all obvious. There is never any need to > restrict combinations of works. You cannot allow combination with licenses that have provisions that conflict with your license, otherwise such provisions would become useless, it's that simple. > > Being GPL compatible is not difficult at all, in most cases modern > > licenses that are not GPL (at least v3) compatible, are not by choice, > > so you should really look at both sides of the equation, you cannot > > blame the GPL for lack of compatibility, compatibility is always a two > > sides story. > > When the GPL is the only one placing requirements on the other > components it is not a two sided story. Can you provide an example of an incompatible license where the incompatibility lies only within the GPL itself ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dwheeler at dwheeler.com Mon Jun 30 20:11:13 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Mon, 30 Jun 2008 16:11:13 -0400 (EDT) Subject: CreatingPackageHowTo Message-ID: Mamoru Tasaka : > Have you looked at https://fedoraproject.org/wiki/Packaging/Guidelines ? > As you seem to be a new contributor, please also see: >https://fedoraproject.org/wiki/PackageMaintainers/Join (all new contributors > are supposed to see this wiki). Yes, absolutely. I read them (and many other pages) completely before developing "CreatingPackageHowTo". Neither is a tutorial on how to create Fedora RPMs; they both presume you _already_ know how to create Fedora RPM packages. The available tutorials are not very helpful, either. Most (e.g, "Maximum RPM" and "RPM Guide") are out of date and omit much of the Fedora-specific stuff that's important if you're creating a Fedora package. For example, how do I encode the "License:" value in Fedora, properly? I'm all for creating portable RPMs, but a tutorial needs to include the information necessary to easily comply with Fedora's key rules. Otherwise, you end up wasting a lot of time tracking that stuff down. Both SuSE and Mandriva have both switched to using a Wiki to maintain their RPM tutorials. Presumably, that's so they can be kept up-to-date and include the distro specifics. --- David A. Wheeler From sundaram at fedoraproject.org Mon Jun 30 20:40:25 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 Jul 2008 02:10:25 +0530 Subject: CreatingPackageHowTo In-Reply-To: References: Message-ID: <486944B9.8060206@fedoraproject.org> David A. Wheeler wrote: > > Both SuSE and Mandriva have both switched to > using a Wiki to maintain their RPM tutorials. Presumably, that's so they > can be kept up-to-date and include the distro specifics. Since the current rpm draft guide is unmaintained, you may well be right. If you want to copy the content to the wiki and make updates to it directly, feel free to do so. Rahul From lesmikesell at gmail.com Mon Jun 30 21:15:04 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 30 Jun 2008 16:15:04 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214855187.353.32.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> <1214854016.353.26.camel@localhost.localdomain> <48693698.9090803@gmail.com> <1214855187.353.32.camel@localhost.localdomain> Message-ID: <48694CD8.2080005@gmail.com> Simo Sorce wrote: > >>> First, a copyleft license by nature, >> Can you define copyleft? I don't think that term helps clear up any >> misunderstandings. > > http://www.gnu.org/copyleft/ Not much there about prohibiting combinations with other licenses. >> > cannot be compatible with just any >>> license, but only with licenses that follow certain rules, for obvious >>> reasons. >> Those reasons are not at all obvious. There is never any need to >> restrict combinations of works. > > You cannot allow combination with licenses that have provisions that > conflict with your license, otherwise such provisions would become > useless, it's that simple. I guess that depends on your concept of 'useless'. If the point is to prevent better works from being available as a result of such combinations, then I guess I'd agree, but I don't see why anyone wants that. The politics discussed here http://www.gnu.org/philosophy/why-not-lgpl.html sort of leans that way but I think it is wrong. >>> Being GPL compatible is not difficult at all, in most cases modern >>> licenses that are not GPL (at least v3) compatible, are not by choice, >>> so you should really look at both sides of the equation, you cannot >>> blame the GPL for lack of compatibility, compatibility is always a two >>> sides story. >> When the GPL is the only one placing requirements on the other >> components it is not a two sided story. > > Can you provide an example of an incompatible license where the > incompatibility lies only within the GPL itself ? I can't think of any other license where the incompatibility would not be only within the GPL, at least in every case where the components can be distributed separately. No other license that I know of has a 'work as a whole' clause to restrict a library from being linked with a main program or other libraries that are under different terms. -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Mon Jun 30 21:03:19 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 30 Jun 2008 23:03:19 +0200 Subject: Is really bodhi so stupid^H^H^H^Hnon-smart? References: Message-ID: On 2008-06-30, 15:34 GMT, drago01 wrote: > nope chain-builds only work in devel Auch. OK, thanks for explanation. Mat?j From lesmikesell at gmail.com Mon Jun 30 21:20:33 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 30 Jun 2008 16:20:33 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214854981.353.28.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> <4868D1C1.3030707@gmail.com> <1214854981.353.28.camel@localhost.localdomain> Message-ID: <48694E21.4090200@gmail.com> Simo Sorce wrote: > >> It's possible, but rare for project that has been under the GPL for any >> length of time. Since there is no requirement to track the copyright >> ownership of contributers there is generally no way to get permission >> from all of them for a change. Of course a dual license could be >> applied from the start with one being less restrictive like perl's to >> eliminate that problem. > > Such dual licensing would be useless. How has it harmed perl to not force it's users to worry, as this endless thread has, about whether or not some component that it links is too free or not free enough? -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Jun 30 21:23:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 Jul 2008 02:53:44 +0530 Subject: Fedora Freedom and linux-libre In-Reply-To: <48694E21.4090200@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> <4868D1C1.3030707@gmail.com> <1214854981.353.28.camel@localhost.localdomain> <48694E21.4090200@gmail.com> Message-ID: <48694EE0.2020309@fedoraproject.org> Les Mikesell wrote: > Simo Sorce wrote: >> >>> It's possible, but rare for project that has been under the GPL for >>> any length of time. Since there is no requirement to track the >>> copyright ownership of contributers there is generally no way to get >>> permission from all of them for a change. Of course a dual license >>> could be applied from the start with one being less restrictive like >>> perl's to eliminate that problem. >> >> Such dual licensing would be useless. > > How has it harmed perl to not force it's users to worry, as this endless > thread has, about whether or not some component that it links is too > free or not free enough? It has instead made them worry about the nuances of the artistic license which is far from a clear one. Rahul From ssorce at redhat.com Mon Jun 30 21:31:08 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2008 17:31:08 -0400 Subject: Fedora Freedom and linux-libre In-Reply-To: <48694E21.4090200@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214765673.1573.10.camel@localhost.localdomain> <4867E295.3060605@gmail.com> <4868753E.4030403@fedoraproject.org> <4868D1C1.3030707@gmail.com> <1214854981.353.28.camel@localhost.localdomain> <48694E21.4090200@gmail.com> Message-ID: <1214861468.353.43.camel@localhost.localdomain> On Mon, 2008-06-30 at 16:20 -0500, Les Mikesell wrote: > Simo Sorce wrote: > > > >> It's possible, but rare for project that has been under the GPL for any > >> length of time. Since there is no requirement to track the copyright > >> ownership of contributers there is generally no way to get permission > >> from all of them for a change. Of course a dual license could be > >> applied from the start with one being less restrictive like perl's to > >> eliminate that problem. > > > > Such dual licensing would be useless. > > How has it harmed perl to not force it's users to worry, as this endless > thread has, about whether or not some component that it links is too > free or not free enough? Heh, this discussion is actually useless too. You dislike the GPL, fine, I think everybody understood that. Now you have 2 options: come to terms with it, or not. In either case I'd suggest you express your frustrations about licenses on some other list, not on a development list. Simo. -- Simo Sorce * Red Hat, Inc * New York From pertusus at free.fr Mon Jun 30 21:39:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 30 Jun 2008 23:39:00 +0200 Subject: CreatingPackageHowTo In-Reply-To: References: Message-ID: <20080630213900.GA2621@free.fr> On Mon, Jun 30, 2008 at 11:07:32AM -0400, David A. Wheeler wrote: > I think there that there is a real need for the > "CreatingPackageHowTo" page. The "RPM Guide" by It is already there, on http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo Is time running back ;-) ? > I don't think it has to be either/or. The "CreatingPackageHowTo" > page gives the overall info, and then links to specific chapters > for specific information when it's needed. I think that care should be taken not to add too much info on this page, though, to keep it simple, usable for beginners. -- Pat From joshuacov at googlemail.com Mon Jun 30 22:21:41 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Tue, 1 Jul 2008 00:21:41 +0200 Subject: Backporting some F9 packages to F8 In-Reply-To: <1214834184.24769.25.camel@localhost.localdomain> References: <5f6f8c5f0806270228h244ed110i43ae576ee960655f@mail.gmail.com> <1214834184.24769.25.camel@localhost.localdomain> Message-ID: <5f6f8c5f0806301521k353654c7y4e21f8fa20527ef@mail.gmail.com> I have ati RS485 (Radeon Xpress 1100 IGP) and it has lots of issues with the fglrx. In partucular the fglrx has problems with the 2.6.25 kernel. I tried the f9 live-kde system and used the xorg-x11-drv-ati-6.8.192-rc2. See my post here http://www.phoronix.com/forums/showthread.php?t=11148** Now everything is ok but I still have f8 because of the kde. I'm waiting for the 4.1 release. In the mean time I decided to recompile the xorg-server-1.4.99-902 for f8 but it has so many dependancies. So i gave up. And there are other packages (in connection with xorg-server) that has to be recompiled for the f8. So I'm not sure if it's worth the effort to do such backporting. if you really want to try it, here is the list of the packages that I tried with the f9-live: mesa-libGL-7.1-0.37.fc9.i386 mesa-libGLU-7.1-0.37.fc9.i386 mesa-libOSMesa-7.1-0.37.fc9.i386 mesa-dri-drivers-7.1-0.37.fc9.i386 glx-utils-7.1-0.37.fc9.i386 xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9.i386 xorg-x11-server-utils-7.3-3.fc9.i386 xorg-x11-utils-7.3-3.fc9.i386 xorg-x11-drv-ati-6.8.0-18.fc9.i386 xorg-x11-drv-vesa-1.3.0-15.20080404.fc9.i386 xorg-x11-server-common-1.4.99.902-3.20080612.fc9.i386 I don't know. It is so much work in order to make the latest ati driver work in the f8 and have dri and 3d. 2008/6/30 Adam Jackson : > On Fri, 2008-06-27 at 11:28 +0200, Joshua C. wrote: > > Can someone backport some of the F9 packages to F8? Especially some of > > the following: > > > > mesa > > xorg-x11-drv-ati > > We typically do not do wholesale upgrades of drivers in older releases. > There's just too much churn happening to keep up with it. Mesa is > particularly problematic since it has complex build interdependencies > with the X server itself. I hope to be able to change this stance at > sonme point in the future, but F9 is really the first release where I > might feel comfortable starting to do that. > > If you have specific problems that are fixed by updating to newer > packages, we can investigate either backporting the fixes or updating > the driver. > > - ajax > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at flyn.org Mon Jun 30 23:25:38 2008 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 30 Jun 2008 18:25:38 -0500 (CDT) Subject: Question regarding Asterisk audio license and Fedora Message-ID: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> I am trying to help get some voice recordings for the Asterisk PBX into Fedora. These support features like voicemail and an echo test. Unfortunately, the audio files are not released with a clear license. As far as I know, the woman who made the recordings does not want the recordings used for commercial purposes. However, I am still looking for this in writing. Does anyone know of a clear statement on this matter from the copyright holder? There is an alternative recording available at http://www.voicevector.com/Downloads.php?PHPSESSID=001824a9b8a9a033cd47f95388c8825a. However, I don't know if the license would be acceptable to Fedora. Would someone review this license? For reference, please see https://bugzilla.redhat.com/show_bug.cgi?id=428832. Mike Petullo From txtoth at gmail.com Mon Jun 30 23:31:41 2008 From: txtoth at gmail.com (Ted X Toth) Date: Mon, 30 Jun 2008 18:31:41 -0500 Subject: how to startup without a display manager Message-ID: <48696CDD.5020002@gmail.com> I want to play with Openbox on Fedora as a standalone window manager. Do I need to configure /etc/X11/prefdm to not start any display manager? Ted From tony at bakeyournoodle.com Mon Jun 30 23:39:00 2008 From: tony at bakeyournoodle.com (Tony Breeds) Date: Tue, 1 Jul 2008 09:39:00 +1000 Subject: how to startup without a display manager In-Reply-To: <48696CDD.5020002@gmail.com> References: <48696CDD.5020002@gmail.com> Message-ID: <20080630233900.GS20457@bakeyournoodle.com> On Mon, Jun 30, 2008 at 06:31:41PM -0500, Ted X Toth wrote: > I want to play with Openbox on Fedora as a standalone window manager. Do > I need to configure /etc/X11/prefdm to not start any display manager? IIRC (it's been a while) You change the default init level from 5 to 3. You can do this by either: a) changing the "id" line of /etc/inittab from: id:5:initdefault: to id:3:initdefault: and rebooting or; b) Appending a "3" to your kernel options, and rebooting. That should leave you at a console login, from which you can startx Yours Tony linux.conf.au http://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! From smooge at gmail.com Mon Jun 30 23:56:09 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 30 Jun 2008 17:56:09 -0600 Subject: Question regarding Asterisk audio license and Fedora In-Reply-To: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> References: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> Message-ID: <80d7e4090806301656u180411b8w5d13b279199e57d2@mail.gmail.com> On Mon, Jun 30, 2008 at 5:25 PM, W. Michael Petullo wrote: > I am trying to help get some voice recordings for the Asterisk PBX into > Fedora. These support features like voicemail and an echo test. > > Unfortunately, the audio files are not released with a clear license. As > far as I know, the woman who made the recordings does not want the > recordings used for commercial purposes. However, I am still looking for > this in writing. Does anyone know of a clear statement on this matter from > the copyright holder? > It would be great if RH could get the old "voice of RH" to do CC licensed recordings of all the messages. Sandra had the best phone voice I have dealt with in many years. > There is an alternative recording available at > http://www.voicevector.com/Downloads.php?PHPSESSID=001824a9b8a9a033cd47f95388c8825a. > However, I don't know if the license would be acceptable to Fedora. Would > someone review this license? > > For reference, please see https://bugzilla.redhat.com/show_bug.cgi?id=428832. > > Mike Petullo > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"